Dead Change - an anonymity issue

[JGCMiner]

I would NOT make that mandatory (imagine what happens when DRK goes back to its all time high or more...I would certainly NOT donate ~$16 for each change).

And there WILL be lots of questions by Joe Average.
If I would be new to Darkcoin (and crypto in general) I would most probably avoid a coin which spends my change.

Scratch last statement, I would _certainly_ avoid that coin because I would suspect some kind of scam.

Make it low priority so it gets spend last, and _offer_ to "donate it or spend at your own risk" via pop-up and enough information for the end-user to make an educated decision.

I agree mandatory "donations" is a really REALLY bad idea. If we are going to go with an idea like this, then the best bet is to keep things as they are and just add a 0.1 denomination. If somebody tries spend change then give a warning and the OPTION to donate.

Also, are we sure there is no way to remix dead change with other peoples dead change in some sort of special Darksend pool?

As I see it, the current idea of removing big denominations, capping max anon coins, and forced donations... all of these things seem like a MAJOR step backwards and is going to be very hard to swallow. I think most would rather sacrifice a bit of hard disk space for the blockchain than to cripple Darksend in the nature that is being discussed and then on top of that forcing donations.

Let's spend a good long time thinking about things before making this change. A mistake could really hurt the coin.

 

[oblox]

If somebody tries spend change then give a warning and the OPTION to donate.

A warning isn't enough... the average person will say fuck it and send the coins anyone. The second that change is used as is, linkages start forming. I wouldn't mind hearing from Aswan in regards to paper's idea about the change jars.

 

[JGCMiner]

A warning isn't enough... the average person will say fuck it and send the coins anyone. The second that change is used as is, linkages start forming. I wouldn't mind hearing from Aswan in regards to paper's idea about the change jars.

Ok. Then they slit their own wrist... That is still better than forcing "donations" on EVERYBODY.

As far as I understand you can only hurt yourself with your dead change. Spending dead change willfully in the face of a warning is the same as using Bitcoin or not bothering to ever turn on Darksend. Why do we care?

 

[crowning]

If somebody tries spend change then give a warning...

:grin::grin::grin:

 

[Aswan]

Seems like for every 3 steps forward, we are having to go backwards more than half. Another idea is trying to build on the coinshuffle concept.

I am sorry for this being the 2nd Darksend flaw I had to point out in such a short time, but I think the coinjoin route is the right one, it's just not easy to get everything covered.

I think the only real way around this issue is to have the micro denominations (0.10 and .01) at the expense of bloating the chain

Micro denominations are useful for a variety of reasons, including paying Darksend fees. I am not sure the "randomly cashing in collateral" implementation is bullet proof. I'd like to know how this "random" is determined. When cashed, the collateral is a miners fee and miners as well as MNs profit from fees so they are incentivized to cash as many collaterals as possible. But that is another problem (if it is one at all, depends on how "random" is determined).

EDIT: OHHH I see... just found my answer... When I spend a change by itself, it can not lead to the origin but when I spend an amount more than the change, it takes the change and the non-anonymous DRK and yes, the transaction leads straight to the origin address...

It's still an anonymity issue even is the change is only spent by itself, because that way it link together the purchase it is used on plus the one that created it.

Just my two duffs, I think that mandatory donating change is not a good solution.

As the technical aspect of Darkcoin is not my forte, I don't have any solutions to offer, but I will add that this would not be popular.

Please take your time with this one, and reach a solution that encompasses all DRKs, and doesn't need to leave out change. This will be attacked by our competitors, and with good reason.

We are marketing ourselves as true anon, not 95% anon (keep the change). This is very important!

While I think that the donation solution is not a bad one, I have to agree that making is mandatory is a no-go from a marketing point of view.
Also, yes, Darkcoin is being marketed as a an anonymous coin and not a 95% anonymous coin in case you don't want to donate your change, which is why a solution not requiring you to donate your change would be better.
However, this can be as easy as naming is a "fee" instead of a donation and adjusting the fee so that there never actually exists a change (it would instead be donated as a miners fee). That way, there would be no direct beneficiary of such a donation, just a "Darksend network cost".

Aswan,
I follow your discussion and agree with your request for whole numbers (1,10,100 etc). It is more anonymous if they are indistinguishable from other non-darksend transactions. Outside observers would not know if blockchain transactions were purchases or a person mixing.

It seems that the idea of "dead change" can be handled through more darksend mixing if the numbers are whole and large. i.e. 5 drk "dead change" could be remixed if whole numbers were used to darksend mix. (making 1,1,1,1,1 remixed drks) It looks like this is still up for debate on how to resolve, but definitely solvable.

Yes, if the dead change amount is one that can exactly be re-denominated into darksend denominations without a leftover, this is possible. It would also be possible to donate the leftover or to make the leftover a miners fee in order to get the same result.

Regarding your 0.99 problem. I have a suggestion that I would like to hear your thoughts. What if...

• The "zombie" change was in the third category "dead change". This would be listed separately in the GUI as you suggested.
• I understand and agree that this "dead change" cannot be remixed with other dead change without exposing information.
• Here is my suggestion...
  • Save these change addresses in a separate category and let them build up (ie .99 , .85, .02 etc)
  • Each one of them would have their own address so no mixing problem yet.
  • Let the "dead change jar" build up to a standard amount in all people's clients. (ie 3, 5 or even 1 dark) Let's use 3 in this case.
    
  • It would not need to be an exact even amount because that would be unlikely to occur.
  • Here comes the magic...
    • Now my "dead change jar" is full (ie 3.12 drk)
    • I would wait until other clients are ready to mix "jars". Let's say 2 other people have jars "full" (3.2 and 3.3 drk)
      
    • We all "pour" our change into a single address (of course the masternode handles this) <--- the big jar
      
    • Then the masternode returns each of us our change (I would get 1, 1, 1 and 0.12 dark back from the masternode in 4 addresses.) You can see each person would get a similar return.
    • It would be difficult for an outside observer to know which of the "dead change" transactions were tied to me, especially if I then darksend denominated the 1,1,1 and dumped the 0.12 back in the "dead change jar".
    • More people mixing "jars" together or a larger "full jar" amount (ie 5 drk) improves anonymity.
    • This method causes little bloat to the blockchain
• Your thoughts?
• Anyone's thoughts?

This is a really interesting idea and when I first read it I thought this was the perfect solution. However, I kept thinking and came up with some problems:

What you suggest is simply Darksend mixing your dead change with other people with the special case that all inputs are non-anonymous and that at least 2 inputs belong to the same person.
Unfortunately, in this special case, Darksend is not quite as strong as it usually is.
Because all inputs are non-anonymous, this system is vulnerable to a falsification investigation.
An example:
There are 2 Participants (to make it easy) in such a dead change re-denomination Transaction (DCRD-Tx?), each one putting in 2 dead changes, resulting in 4 inputs.
One of the inputs was an output of a Tx that has been used to purchase something the investigator wants to know the buyer of (what a sentence ). He knows the buyer has at least 2 inputs in the transaction because thats how DCRD-Txs work. He also knows there can only be 1 other person participating in this Tx.
So he starts looking at the 3 other inputs and starts to investigate. If he can link only 2 of them together, he knows the last one belongs to the person he is looking for.
So how does he link 2 together? It certainly won't always work just as spending dead change doesn't always compromise your anonymity, it's just possible that it does.
2 Inputs could be linked together in case their parent Txs send coins to the same receiver (an exchange, a gambling site, a hidden marketplace etc.) or if one if the changes leads to the identity of a person that proofs it owns the other input as well.
Now ofc thats only with the minimum amount of people and the minimum amount of input. If there are 8 people with 2-4 inputs each, averaging 24 inputs, it's a lot harder.... but not impossible.
So why is this not a general problem of Darksend? The answer is it certainly can be but normal Darksend mixing is inherently different.
In Darksend mixing, you first anonymize your coins and then spend them, making the investigator go back on the transaction chain in order to try to find you.
DCRD-Txs attempt to anonymize your coins after you used them trying to cut the links (which in normal Darksend mixing don't exist yet at the time of mixing).
That way DCRD transactions don't have the option of multiple layers (like Darksend mixing does). Imagine Darksend only doing 1 round. It't like that but there's a reason the client required at least 2.

However, the concept is quite nice and if already improves anonymity, even if it's not at Darksend levels (yet). I think it has great potential and might be the route to go to fix the dead change issue. Maybe it just needs a little tweaking.
Another downside is you REALLY have to be careful with your leftover change from a DCRD-Tx sind it can de-anonymize all the purchases of all the parent transactions of all the inputs you used in it, and this chain will never be broken if it is reused. Maybe at some point there would be a donation taking place.

Coinjoin is so interesting... and I hope your idea can be further developed into a good solution to the problem. Implementing it would definitely improve anonymity, I just don't think it's enough since it's far from Darksend level anonymity.

Also thanks for supporting my request for whole numbers in DS denominations.

Edit: I forgot to mention that because one DCRD-Tx per 2 changes can take place for you, you will only get one masternode, which makes malicious masternodes really scary, which is another reason why with Darksend, there are multiple mixing instances.

A warning isn't enough... the average person will say fuck it and send the coins anyone. The second that change is used as is, linkages start forming. I wouldn't mind hearing from Aswan in regards to paper's idea about the change jars.

There you go

 

[crowning]

I am sorry for this being the 2nd Darksend flaw I had to point out in such a short time,

Sorry? We have to give you a big THANK YOU for this. Please find more!

Whatever is fixed NOW can't break Darkcoins neck once it is REALLY widely used.

It would also be possible to donate the leftover or to make the leftover a miners fee in order to get the same result.

I like the idea (no matter if it goes to the miners or the Masternodes), and wording it "fee" is a good idea.

Because all inputs are non-anonymous, this system is vulnerable to a falsification investigation.

Just a quick idea (I don't yet had my first coffee today, so my brain is still in sleepy mode): what if a Darksend transaction requires(!) already anonymised change?

 

[Aswan]

Just a quick idea (I don't yet had my first coffee today, so my brain is still in sleepy mode): what if a Darksend transaction requires(!) already anonymised change?

I am not sure I understand you here. The Darksend mixing process has no problem with all inputs being non-anonymous in the first iteration because there are more to follow and the critical spending will only happen after several instances.
A transaction using only coins that have been freshly anonymized by Darksend will always be an anonymous transaction.

So do you mean a mixing transaction or the transaction that happens after the mixing with "Darksend transaction"?

Anyway, this wouldn't change the problems with paperThins solution.

yeah big Thank You Aswan!!

Thanks

 

[oblox]

Definitely don't apologize Aswan for finding flaws, it's worthwhile knowing about them now before any sort of marketing initiative and/or adoption happens. Going back to Paper's coinjar idea, you already addressed the fact that about parties up to 8, but what if that was increased even farther. What if the minimum needed to be 25 or even 50 participants with at least 2 inputs (some obviously having more from more microchange build up). The change could be locked from spending (either the same way things are locked during the DS process or from the masternodes). And since this change can't be spent, it would be a natural event over time for there to be enough parties to pool their jars. As this happens with the amount of participants needed being so high and a certain threshold needed for the jar to get to, you will have some people contributing more than the arbitrary minimum (not sure if this helps or hurts the concept from a standpoint of linkages).

Other than that idea, I wouldn't mind hearing your thoughts on Coinshuffle either as an addition to the darksend mixing process or an additional at final send process. https://darkcointalk.org/threads/coinshuffle.3029/

 

[TaoOfSatoshi]

View attachment 636

:grin::grin::grin:

"can not be anonymized"

I find this difficult to accept. Give Evan enough time and he WILL find a solution. I don't like the look of that pop-up at all, and if I saw it on one of my transactions, I would wonder what I was doing using a coin that doesn't provide near 100% anonymity. That should always be our focus!

I just wish I could contribute technically, but I have complete confidence in Mr. Duffield.

 

[paperThin]

Aswan,

Thank you for taking the time to consider my approach. If I could bother you for with more questions.

(Let's assume that DS is improved to use whole numbers for this discussion.)​

Large Change:

Regarding "dead change" greater than 1.0. (i.e. 4.87 drk from a single transaction)... Do you see an method to strip off the whole numbers 4.0 drk using the current methods (darksend denominate) and leave the 0.87 as dead change? Im my earlier post, I assumed that this was possible using standard Darksend mixing based on your other posts.
​

Aswan:
"The problem in UdjinM6s example would be that 5 non-anonymized coins won't fully go into a Darksend pool. Instead, 4x 1.00000001 DRK would go into the Darksend, leaving a dead change of 0.99999996 DRK behind, which can never be spent due to it being smaller than the smallest denomination."

From this, I understand that while not implemented currently, the wallet could be set up to strip off the whole numbers of DRK and leave dead change always less than 1.0. As long as this change (less than 1.0) is isolated in the wallet and "locked", then nothing is contaminated. This does not sound like a major overhaul in the design. Do you agree?
​

Small Change (i.e. the change jar)

• So assuming that all "dead change" is less than 1.0 (if the above "Large Change" theory is ok), then it is safe to say that a standard 5 DRK "full jar" would always contain at least 6 "dead addresses" (i.e. 0.99 x 6 as the least number of addresses, but potentially many more).
• (One advantage to this is that no one would have a fortune tied up in dead change.)
• If the change jar mix occurs between at least 3 users, I do not see a difference between this method and the first round of a typical darksend denominate. Do you agree on this point?
• It seems that the existing software development would need very little alteration since the general theory is the same as darksend. The trick is to let it happen (all three people mixing) in the same transaction.
• Another critical point is that the "change" (less than 1.0) from the "jar mix" must return to the jar to be mixed on the next "jar mix". Also, the returned whole numbers (in this example 5 DRK = 1,1,1,1,1) should be run through darksend denominate a number of rounds.
• (Another advantage is that this method does not require a 0.1 denomination. That is, if bloating is a problem.)

(My whole goal here is to find a way to "revive" zombie change as usable and anonymous. First, to find a path to show it can be done. Later, a way to enforce it through the wallet. A method that "works sometimes" is useless. It has to work in all cases. Thank you for pointing out weaknesses in your earlier post.)
​

Aswan:
There are 2 Participants (to make it easy) in such a dead change re-denomination Transaction (DCRD-Tx?)...

I know you were just making a simple example to explain. I think that 3 participants would always be required. Also, as mentioned above a higher number of transactions each. I think the existing darksend denominate would have all the weaknesses you mention if it only handled 2 users with 2 transactions each. Please indulge me and explain why "jar mix" would be weaker than a single round of darksend denominate.
​

Aswan:So why is this not a general problem of Darksend? The answer is it certainly can be but normal Darksend mixing is inherently different.
In Darksend mixing, you first anonymize your coins and then spend them, making the investigator go back on the transaction chain in order to try to find you.
DCRD-Txs attempt to anonymize your coins after you used them trying to cut the links (which in normal Darksend mixing don't exist yet at the time of mixing).
That way DCRD transactions don't have the option of multiple layers (like Darksend mixing does). Imagine Darksend only doing 1 round. It't like that but there's a reason the client required at least 2.

Agreed on your second point ("doing 1 round"). The first point about darksend working because it anonymizes and then spends (in that order) is only half of the equation. A person must "sandwich" both sides of a transaction (before and after) with some form of "mixing" in order to protect identity. This is true of any crypto coin. An investigator can use either a forward or backward search to link transactions. Your excellent thread has fired up discussion on backward searching which was for the most part not discussed here. Thank you for helping the ThinkTank come up with ideas to improve the coin. I really appreciate your efforts.
​

Regarding malicious masternodes, I think this is an equal problem for any mixing not just "jar mixing". Remember, everyone has to mix "round 1" (first round) when they bring coins into their wallet. At that point, if they happen to get a malicious node they are just as exposed as a "jar mix". The master node could keep a record of where those coins came from.

Regarding the "other user" revealing their transitions (i.e. volunteering their identity and transactions openly on the web) this is the same problem as darksend denominate. By process of elimination, the other users can expose an unknowing victim. Is this really different (in a single round) from darksend denominate?

Finally (wow sorry about the long post!!!) regarding donations. It is my opinion that the donation idea would be fine for a coin like DODG but DRK is not destined for that kind of a "feel good" coin. We want to be bitcoin 2.0. We want it to be what everyone wishes bitcoin really could be. We should strive to find a real solution to make this coin useful and "liquid" to the smallest denominations. Imagine DRK at US$10 (not that hard to imagine) and purchasing an item for $2. Now you have to donate $8? That's not a good currency! (I realize you could use non-anonymous coins, but I am making a point.) We want this to work just like it should. Anonymous like cash. If there is a way to do it... let's find it!

​

 

[Aswan]

Aswan,

Thank you for taking the time to consider my approach. If I could bother you for with more questions.

(Let's assume that DS is improved to use whole numbers for this discussion.)​

Large Change:

Regarding "dead change" greater than 1.0. (i.e. 4.87 drk from a single transaction)... Do you see an method to strip off the whole numbers 4.0 drk using the current methods (darksend denominate) and leave the 0.87 as dead change? Im my earlier post, I assumed that this was possible using standard Darksend mixing based on your other posts.
​

Aswan:
"The problem in UdjinM6s example would be that 5 non-anonymized coins won't fully go into a Darksend pool. Instead, 4x 1.00000001 DRK would go into the Darksend, leaving a dead change of 0.99999996 DRK behind, which can never be spent due to it being smaller than the smallest denomination."

From this, I understand that while not implemented currently, the wallet could be set up to strip off the whole numbers of DRK and leave dead change always less than 1.0. As long as this change (less than 1.0) is isolated in the wallet and "locked", then nothing is contaminated. This does not sound like a major overhaul in the design. Do you agree?
​

I'll try to answer your whole post tomorrow. It's kinda late and I gotta walk the dog, but what you described is is exactly what I suggested. Dead change that is bigger than the smallest denomination can re-enter the Darksend pool, but it has to do so alone (you cannot use multiple dead changes in the same Tx without possibly compromising anonymity. However, with your jar mix suggestion it might still be viable if enough people and outputs participate in such a Tx).
However, once the remaining possible denominations are stripped off the change, there will be a new change that cannot be stripped anymore. This is the problematic one.
Maybe I wasn't clear on what I meant or maybe you missread something, but I am sure we both agree here.

If the initial big change can enter the Darksend pool on it's own, then thats perfectly fine. But you still have to deal with the leftover.

Good night and I'll try to answer the rest tomorrow

 

[paperThin]

I'll try to answer your whole post tomorrow. It's kinda late and I gotta walk the dog, but what you described is is exactly what I suggested. Dead change that is bigger than the smallest denomination can re-enter the Darksend pool, but it has to do so alone (you cannot use multiple dead changes in the same Tx without possibly compromising anonymity. However, with your jar mix suggestion it might still be viable if enough people and outputs participate in such a Tx).
However, once the remaining possible denominations are stripped off the change, there will be a new change that cannot be stripped anymore. This is the problematic one.
Maybe I wasn't clear on what I meant or maybe you missread something, but I am sure we both agree here.

If the initial big change can enter the Darksend pool on it's own, then thats perfectly fine. But you still have to deal with the leftover.

Good night and I'll try to answer the rest tomorrow

Thanks Aswan and have a good night. I will be out until late Sunday night... I look forward to reading your response.

Yes, it seems we are in agreement on most points, I just needed to be sure. My secondary points are useless if the primary assumptions do not hold up.

Thanks for lending your time and insight!!

 

[illodin]

Regarding bloating, there's mini-blockchain, dunno how hard that would be to implement though.

 

[oblox]

Bump

 

[Aswan]

Sorry for the late reply, I had a lot to do

Definitely don't apologize Aswan for finding flaws, it's worthwhile knowing about them now before any sort of marketing initiative and/or adoption happens. Going back to Paper's coinjar idea, you already addressed the fact that about parties up to 8, but what if that was increased even farther. What if the minimum needed to be 25 or even 50 participants with at least 2 inputs (some obviously having more from more microchange build up). The change could be locked from spending (either the same way things are locked during the DS process or from the masternodes). And since this change can't be spent, it would be a natural event over time for there to be enough parties to pool their jars. As this happens with the amount of participants needed being so high and a certain threshold needed for the jar to get to, you will have some people contributing more than the arbitrary minimum (not sure if this helps or hurts the concept from a standpoint of linkages).

You are right that more participants increase the anonymity with this jar solution. However, if there is a malicious masternode used to do this Tx, there might be a problem.

Other than that idea, I wouldn't mind hearing your thoughts on Coinshuffle either as an addition to the darksend mixing process or an additional at final send process. https://darkcointalk.org/threads/coinshuffle.3029/

I got the paper and will read it, then report back.

I know you were just making a simple example to explain. I think that 3 participants would always be required. Also, as mentioned above a higher number of transactions each. I think the existing darksend denominate would have all the weaknesses you mention if it only handled 2 users with 2 transactions each. Please indulge me and explain why "jar mix" would be weaker than a single round of darksend denominate.

It's true that only 2 Participants in Darksend are just as weak.
Also, I do not think that the jar mix would be weaker than a single round of darksend (if the amount of participants is the same in both).
This is the reason why the client required you to do at least 2 rounds of DS (more is obviously better).
The coin jar mix is only ever a single Tx, thus not allowing for more anonymity than a single round of DS.

However, more participants can increase the anonymity of the jar mix, making it an interesting solution that would be hard to get rolling (since you really need a lot of inputs to make it nearly as save as 4-5 rounds of DS.

Agreed on your second point ("doing 1 round"). The first point about darksend working because it anonymizes and then spends (in that order) is only half of the equation. A person must "sandwich" both sides of a transaction (before and after) with some form of "mixing" in order to protect identity. This is true of any crypto coin. An investigator can use either a forward or backward search to link transactions. Your excellent thread has fired up discussion on backward searching which was for the most part not discussed here. Thank you for helping the ThinkTank come up with ideas to improve the coin. I really appreciate your efforts.

Thanks

Regarding malicious masternodes, I think this is an equal problem for any mixing not just "jar mixing". Remember, everyone has to mix "round 1" (first round) when they bring coins into their wallet. At that point, if they happen to get a malicious node they are just as exposed as a "jar mix". The master node could keep a record of where those coins came from.

Say I just bought some DRK with my bitcoin on an exchange and withdrew them to my DRK wallet. Now those DRK could, by asking the exchange for the information, be traced back to the BTC address I fundet the exchange with and from there through the BTC network or if traced the other way, someone knows I bought DRK.

if I sent those coins into the DS pool and they start the first round, then that person is not sure anymore which outputs are mine and which aren't (except for the leftover that is returned by DS in the first DS TX).
If the Tx hit a malicious masternode, it it might still be known which coins are mine.
Up until here, it's the same chances as the jar mixing with 3 participants. However, there are more rounds to come and it is unlikely they all hit a malicious masternode.
Eventually the link will be broken during the mixing process.
Then, afterwards, when the link was broken, there comes the purchase that should not be linked to me. And it won't (provided I know how to deal with dead change).

Regarding the "other user" revealing their transitions (i.e. volunteering their identity and transactions openly on the web) this is the same problem as darksend denominate. By process of elimination, the other users can expose an unknowing victim. Is this really different (in a single round) from darksend denominate?

There is no difference between the jar mix and a single round of DS in that regard. However, the client required at least 2 rounds of DS, while more is obviously better.

Finally (wow sorry about the long post!!!) regarding donations. It is my opinion that the donation idea would be fine for a coin like DODG but DRK is not destined for that kind of a "feel good" coin. We want to be bitcoin 2.0. We want it to be what everyone wishes bitcoin really could be. We should strive to find a real solution to make this coin useful and "liquid" to the smallest denominations. Imagine DRK at US$10 (not that hard to imagine) and purchasing an item for $2. Now you have to donate $8? That's not a good currency! (I realize you could use non-anonymous coins, but I am making a point.) We want this to work just like it should. Anonymous like cash. If there is a way to do it... let's find it!

I agree that a solution not requiring a donation would be nice, but it is also possible to not call it a donation, but instead a fee that is used to protect anonymity (which it actually is). This Fee could not go to an address, but simply not appear in an output, thus resulting in a miners fee, which in turn help the miners and the masternodes. I think it's not a bad thing.

Regarding the DRK price rising: there can always be a smaller DS denomination introduced as price rises, so this fee could always be reasonably small.

Regarding bloating, there's mini-blockchain, dunno how hard that would be to implement though.

Blockchain pruning is something that probably doesn't fit into the thread, but once finished here, we could start a bloating discussion

 

[moli]

Sorry for the late reply, I had a lot to do

I agree that a solution not requiring a donation would be nice, but it is also possible to not call it a donation, but instead a fee that is used to protect anonymity (which it actually is). This Fee could not go to an address, but simply not appear in an output, thus resulting in a miners fee, which in turn help the miners and the masternodes. I think it's not a bad thing.

Could you explain how this could not go to an address? It sounds similar to the fee 0.0125 before.

 

[Aswan]

Could you explain how this could not go to an address? It sounds similar to the fee 0.0125 before.

Because the fee is paid by parts of the actual transaction(the leftover that would otherwise be change) and is not a separate input (like in the old DS)

 

[moli]

Because the fee is paid by parts of the actual transaction(the leftover that would otherwise be change) and is not a separate input (like in the old DS)

Okay... Is it possible for Evan to separate the "dead change" and give it a new address separate completely without any trace to the origin address? Like a brand new address coming from mining... So users can still use the change and do whatever they want with it?

 

[oblox]

Okay... Is it possible for Evan to separate the "dead change" and give it a new address separate completely without any trace to the origin address? Like a brand new address coming from mining... So users can still use the change and do whatever they want with it?

Change already gets a fresh address unless specified during the send.

 

[moli]

Change already gets a fresh address unless specified during the send.

I meant.. but it's connected to the origin address.. Can we make it not connected to the origin address?