Change Contracts using Atomic Transfers

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
Forgive me if I'm missing something key.. but would sending the correct amount to yourself not solve the problem? So person wants to send 1 drk needs 9 drk change. Client sends anon funds to self splitting 1 and 9 into separate addresses. While both link back to the original 10 drk address it is anonymous so what can be gathered? 1 Drk is then sent to the merchant (still only links back to an anon address) and the 9 change will have to be reanonymized. Or is that how it works now?

These atomic contracts I imagine would be fantastic/necessary for instantX but is the above not a viable offline option?
This is exactly how change works as default in the client.

A -> B | C

A = 10DRK (source)
B = 1DRK (payment)
C = 9DRK (change)

That's the transaction you're describing. The problem is that you can B and C came from A. So later on when C is combined with other funds in the wallet you can follow the anonymous transaction forward to those funds.

C + D -> E (Payment) | F (change)

C = Change from previous example
D = Older funds in your wallet (linked to cryptsy or something else)
E = Payment
F = Change

If D knows you identity now, they also know you bought B previously.

----------------------------------

Here's how Change Contracts fix that

- payment

A -> B (User A - over pays)

A = 10DRK (source)
B = 10DRK (payment, desires to pay 1DRK)

- change

C -> D | E
C = 15DRK (merchant)
D = 9DRK (payment to user A)
E = 6DRK (change back to himself)

In this situation D has no link with B, so when it's combined later with pre-existing funds it doesn't give up anonymity at all.
 
  • Like
Reactions: JGCMiner

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
This is exactly how change works as default in the client.

A -> B | C

A = 10DRK (source)
B = 1DRK (payment)
C = 9DRK (change)

That's the transaction you're describing. The problem is that you can B and C came from A. So later on when C is combined with other funds in the wallet you can follow the anonymous transaction forward to those funds.

C + D -> E (Payment) | F (change)

C = Change from previous example
D = Older funds in your wallet (linked to cryptsy or something else)
E = Payment
F = Change

If D knows you identity now, they also know you bought B previously.

----------------------------------

Here's how Change Contracts fix that

- payment

A -> B (User A - over pays)

A = 10DRK (source)
B = 10DRK (payment, desires to pay 1DRK)

- change

C -> D | E
C = 15DRK (merchant)
D = 9DRK (payment to user A)
E = 6DRK (change back to himself)

In this situation D has no link with B, so when it's combined later with pre-existing funds it doesn't give up anonymity at all.
I have questions in this thread as it relates to this, namely timeliness (and how it will relate to instantx implementation), security, and privacy. Please answer at your leisure so I can get a better understanding if this actually can solve the issue.

EDIT: Come to think of it, there are a lot of valid questions in here that should be answered. Better to get the logistics out ahead of time before coding starts.
 
Last edited by a moderator:

darkwing

Active Member
Apr 8, 2014
149
110
103
This is exactly how change works as default in the client.

A -> B | C

A = 10DRK (source)
B = 1DRK (payment)
C = 9DRK (change)

That's the transaction you're describing. The problem is that you can B and C came from A. So later on when C is combined with other funds in the wallet you can follow the anonymous transaction forward to those funds.

C + D -> E (Payment) | F (change)

C = Change from previous example
D = Older funds in your wallet (linked to cryptsy or something else)
E = Payment
F = Change

If D knows you identity now, they also know you bought B previously.
I understand that I think I wasn't clear in my post.

I'm saying add an extra transaction if change is required.
Splitting the anon funds into the required amounts as a payment to self. Then send the exact amount to the retailer. That way the retailer doesn't have to issue change. And the full amount doesn't have to go over and come back.


A = 10DRK (source)
B = 1DRK (payment to self) ---> once confirmed pay to D = 1DRK payment to merchant
C = 9DRK (change - payment to self)

Could the change not be locked in a separate balance? Requires denomination?
 

paperThin

Member
Jun 13, 2014
106
19
68
Have the client automatically generate the exact 'chunk' prior to sending it, so there's no change. I like it. :) At least keeps the sub-denom amounts in wallet.
Maybe this helps explain...

Your idea moves the problem, but it is still there. The blockchain would show the exact change made ahead and the other part. i.e. if price was 3 that you made from a 10, so you split 7 and 3 and spend the 3. Now there is a permanent connection to the 7 even though you did it ahead of time. If it was a whole number "7" you could re-darksend denominate so you could spend again. Chances are that it will not be a whole number.
 

paperThin

Member
Jun 13, 2014
106
19
68
I have questions in this thread as it relates to this, namely timeliness (and how it will relate to instantx implementation), security, and privacy. Please answer at your leisure so I can get a better understanding if this actually can solve the issue.

EDIT: Come to think of it, there are a lot of valid questions in here that should be answered. Better to get the logistics out ahead of time before coding starts.
Here's a question... If the the receiver uses the original amount (ie 10 DRK) to make the change (9 DRK), then there will be a link in the blockchain. (original problem still present) They should use a different address for the change which would require "other funds" in the wallet... separate from the receiving DRK.

So you could have a problem with the receiver not having enough change, right?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Here's a question... If the the receiver uses the original amount (ie 10 DRK) to make the change (9 DRK), then there will be a link in the blockchain. (original problem still present) They should use a different address for the change which would require "other funds" in the wallet... separate from the receiving DRK.

So you could have a problem with the receiver not having enough change, right?
They would be making "change" from the overage from my understanding so there shouldn't be an instance where the receiver doesn't have enough funds to make change. The receiver should obviously send to a fresh address that the sender created... how the receiver actually knows this address is unknown (Evan hasn't answered). Then it seems you are going down the road of masternodes knowing the send-back address. This all then falls on the receiver leaving the wallet unlocked after receival to be able to send the new tx out (security risk).
 

paperThin

Member
Jun 13, 2014
106
19
68
They would be making "change" from the overage from my understanding so there shouldn't be an instance where the receiver doesn't have enough funds to make change. The receiver should obviously send to a fresh address that the sender created... how the receiver actually knows this address is unknown (Evan hasn't answered). Then it seems you are going down the road of masternodes knowing the send-back address. This all then falls on the receiver leaving the wallet unlocked after receival to be able to send the new tx out (security risk).
Right, but they can't use the "overage" because that keeps the original problem... A, B relating to C, D. C and D have to be "fresh and separate".
If they send to a new address, it still shows that it came from "A" which links it all together again.
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Right, but they can't use the "overage" because that keeps the original problem... A, B relating to C, D. C and D have to be "fresh and separate".
If they send to a new address, it still shows that it came from "A" which links it all together again.
It would be fresh and separate in the sense that it's not included in the same block. How would this be any different than someone sending funds and then the ending party deciding to buy something from someone else (with the address happening to belong to the initial sender) a block or so later?
 

paperThin

Member
Jun 13, 2014
106
19
68
It would be fresh and separate in the sense that it's not included in the same block. How would this be any different than someone sending funds and then the ending party deciding to buy something from someone else (with the address happening to belong to the initial sender) a block or so later?
Of course, this is still the "dead change" issue, right? We are on the same page there, right?

If they spend it with someone else... that is fine, or if randomly it goes around and comes back to the original user, that's fine too.

The problem we are trying to solve is for the buyer to be able to spend their change without that change having any connection to the original transaction. The "A,B then C, D" method does solve the dead-change problem. However, C,D must not have any connection (address-wise) to A or B.
(I agree on your other point... how does the seller know the new address? How is it passed to them securely and without trace?)

Good discussion!
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Of course, this is still the "dead change" issue, right? We are on the same page there, right?

If they spend it with someone else... that is fine, or if randomly it goes around and comes back to the original user, that's fine too.

The problem we are trying to solve is for the buyer to be able to spend their change without that change having any connection to the original transaction. The "A,B then C, D" method does solve the dead-change problem. However, C,D must not have any connection (address-wise) to A or B.
(I agree on your other point... how does the seller know the new address? How is it passed to them securely and without trace?)

Good discussion!
Correct, it all comes back to the dead change issue. In theory, by over paying, the initial tx has no change to come back to be "dead". Then the second tx (new block) that contains the change goes to a fresh address (which from a block chain glance could be anyone) that belongs to the initial sender. This should remove all linkages. The problem I see is passing in the original tx the newly generated change address to the receiver in a way that doesn't allow any linkages. If done by masternodes, then a rogue masternode can link.
 

paperThin

Member
Jun 13, 2014
106
19
68
Correct, it all comes back to the dead change issue. In theory, by over paying, the initial tx has no change to come back to be "dead". Then the second tx (new block) that contains the change goes to a fresh address (which from a block chain glance could be anyone) that belongs to the initial sender. This should remove all linkages. The problem I see is passing in the original tx the newly generated change address to the receiver in a way that doesn't allow any linkages. If done by masternodes, then a rogue masternode can link.
So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.
No, I'm saying you should be able to:

I (address A) want to buy something from you for 8 DRK. I send you 10 DRK to your address (address B) and no change comes back to me (A) in that block for that tx. In the next block or however many blocks, you (B) send 2 DRK to address C (which happens to belong to me) in a new tx. I get my change back and there shouldn't be a link to us. It should be no different than you deciding to send my received funds to anyone else other than me from a block chain glance. That second tx in theory is no different than tx 1 from a starting point. How you (address B) knows to send to my fresh change address C in a new tx is unknown to me.

I guess, what am I missing here in terms of linkages this way?
 
  • Like
Reactions: darkwing

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.
I'm thinking this is all digital, not paper money, so the receiver sure does have change, but the thing is, like Evan said, "the merchant must have a daemon running for it to work." And I'm not sure if merchants like to do this for DRK.
 
  • Like
Reactions: drkhouse

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
I'm thinking this is all digital, not paper money, so the receiver sure does have change, but the thing is, like Evan said, "the merchant must have a daemon running for it to work." And I'm not sure if merchants like to do this for DRK.
I don't agree a second daemon running being the way to go. It has to be in the client (qt) or daemon (darkcoind) as is. Further, this whole thing seems to disrupt instantx, not to mention leaving a security issue with the receiver needing to have their wallet unlocked just to allow that second tx to send.
 
  • Like
Reactions: drkhouse

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I don't agree a second daemon running being the way to go. It has to be in the client (qt) or daemon (darkcoind) as is. Further, this whole thing seems to disrupt instantx, not to mention leaving a security issue with the receiver needing to have their wallet unlocked just to allow that second tx to send.
I don't think depending on the receiver to return your change would work either, unless there's something I don't know or don't understand with this new plan. Digital cash is not quite like paper cash, so I'm not sure how this can work.
 

darkwing

Active Member
Apr 8, 2014
149
110
103
So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.
That's how I see it.. I love the idea of the contracts. But will exchanges implement this? And for merchants does having a daemon running expose you at all?

And as a retailer if someone breaks a high value DRK denomination (got change for 500?) they will have to have huge amounts of denominated funds to pay out the change.
And if they run out, they can no longer accept payments? Also what happens if they need change?

*edit* sorry to rant.. just not sure or not understanding.

On the plus side imagine you could use these contracts for things other than drk.

So I'll give you 10 DRK you give me 5 BTC :)
 

paperThin

Member
Jun 13, 2014
106
19
68
No, I'm saying you should be able to:

I (address A) want to buy something from you for 8 DRK. I send you 10 DRK to your address (address B) and no change comes back to me (A) in that block for that tx. In the next block or however many blocks, you (B) send 2 DRK to address C (which happens to belong to me) in a new tx. I get my change back and there shouldn't be a link to us. It should be no different than you deciding to send my received funds to anyone else other than me from a block chain glance. That second tx in theory is no different than tx 1 from a starting point. How you (address B) knows to send to my fresh change address C in a new tx is unknown to me.

I guess, what am I missing here in terms of linkages this way?
Yes... you are missing something... the 2 DRK cannot be sourced from the original 10 DRK in this transaction or any future transaction. It must come from another address completely different. Otherwise if you looked at the blockchain you would have the "trail of bread crumbs" (Shown below)
  1. Address B receives funds (10 DRK)
  2. Next block or other block in the future
  3. Address B sends funds to new Address D (How this address is know is a question we both have)
  4. Now the original buyer has their change in address D. If they spend D down the road, it links them to the original 10DRK transaction.
but if in step 3, the "seller" uses a new and different address (ie address "C" sending to "D", then there is no link to "A" or "B"

If you just don't get what I am saying... that's fine. Either I'm crazy or I just can't explain it right. I will be curious how the issues that have come up will be solved!
 

illodin

Member
Apr 26, 2014
122
71
78
You can denominate large change just like other funds. If you have 100 DRK denomination, and wanna send 15 DRK, you will get 85 DRK back as a change. So you can denominate that normally to 8x10 + 5x1. This problem stems from the change being too small (i.e. less than 2 DRK or so), which can't be combined with other funds and it can't be denominated either because it would cause bloat, right?

If this proposed system would be used, shouldn't it be used only for the remainder change after the smallest possible denomination?

But if this system would not be used, and the change would be anonymized normally (separately from normal funds of course), we'd need smaller denominations, which would cause bloat. But, what if the denominations would be for example 500, 100, 10, 5, 1, 0.5, 0.25, 0.1, 0.05, 0.025, 0.01? This would make the time it takes to find others to mix with longer, however it would lessen the bloat if we would denominate a change of 0.78 DRK it would generate 0.5 + 0.25 + 3x0.01 = 5 inputs instead of 7x0.1 + 8x0.01 = 15 inputs.

I just think a solution with a bit more bloat vs a system that can't work imo is better.
 

Ryan Taylor

Well-known Member
Dash Core Team
Foundation Member
Jul 3, 2014
550
1,649
263
Scottsdale, AZ, USA
Maybe I'm not understanding this, so could someone explain this... Why can't the sender's wallet just categorize any change as non-anonymized funds? Imagine the following scenario.

Initial setup: User has set 100 DRK as anonymous (and that 100 DRK has gone through the anonymization process) and 200 DRK total in their wallet
Step 1: User sends 7.50 DRK through Darksend to Merchant address
Step 2: Wallet uses anonymized funds to pay (say for this example a 10 DRK anonymized denomination), breaking the 10 DRK into 7.5 and 2.5 and sending the 7.5 to Merchant
Step 3: The wallet reclassifies the remaining 2.5 DRK to be non-anonymized funds
Step 4: The wallet is now showing only 90 DRK anonymized, and initiates anonymization process (which could prioritize "change" to be anonymized first) for additional 10 DRK
Step 5: The wallet re-anonymizes the 2.5 DRK plus an additional 7.5 DRK, returning a new 10 DRK denomination which has been through at LEAST two rounds or more depending on the wallet settings. If ever spent, the merchant would have no way of knowing who is spending it.

By simply treating / reclassifying any change as no longer anonymous, the users should be well aware that they are spending non-anonymous money if they ever spend the change without anonymizing it first. You could even have a higher-level protection in the form of an additional warning that displays "This transaction includes change from a previous transaction that has NOT been anonymized. The recipient of the previous transaction that resulted in the change will be able to identify you as the sender of the current transaction unless you use anonymous funds. Enter your password again if you understand these risks and wish to continue with the transaction anyway."

Does this solve the change problem? Or is there something I'm not considering?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Yes... you are missing something... the 2 DRK cannot be sourced from the original 10 DRK in this transaction or any future transaction. It must come from another address completely different. Otherwise if you looked at the blockchain you would have the "trail of bread crumbs" (Shown below)
  1. Address B receives funds (10 DRK)
  2. Next block or other block in the future
  3. Address B sends funds to new Address D (How this address is know is a question we both have)
  4. Now the original buyer has their change in address D. If they spend D down the road, it links them to the original 10DRK transaction.
but if in step 3, the "seller" uses a new and different address (ie address "C" sending to "D", then there is no link to "A" or "B"

If you just don't get what I am saying... that's fine. Either I'm crazy or I just can't explain it right. I will be curious how the issues that have come up will be solved!
Ah, I knew I was missing something simple. I guess you're right, you cannot assume that the change back address that we both are unsure how it is given is funded from funds already in the wallet even if there would be enough excess from the initial transaction. So you could run into issues where the receiver doesn't have the funds available to send for change. You could solve this by forcing the excess to be anon'd through darksend before going back but then you are prolonging the time it takes for the initial sender to get their rightfully owned change back, right? Further, you still run into issues than with change back sourced from funds under the denomination threshold.
 

darkwing

Active Member
Apr 8, 2014
149
110
103
Maybe I'm not understanding this, so could someone explain this... Why can't the sender's wallet just categorize any change as non-anonymized funds? Imagine the following scenario.

Initial setup: User has set 100 DRK as anonymous (and that 100 DRK has gone through the anonymization process) and 200 DRK total in their wallet
Step 1: User sends 7.50 DRK through Darksend to Merchant address
Step 2: Wallet uses anonymized funds to pay (say for this example a 10 DRK anonymized denomination), breaking the 10 DRK into 7.5 and 2.5 and sending the 7.5 to Merchant
Step 3: The wallet reclassifies the remaining 2.5 DRK to be non-anonymized funds
Step 4: The wallet is now showing only 90 DRK anonymized, and initiates anonymization process (which could prioritize "change" to be anonymized first) for additional 10 DRK
Step 5: The wallet re-anonymizes the 2.5 DRK plus an additional 7.5 DRK, returning a new 10 DRK denomination which has been through at LEAST two rounds or more depending on the wallet settings. If ever spent, the merchant would have no way of knowing who is spending it.

By simply treating / reclassifying any change as no longer anonymous, the users should be well aware that they are spending non-anonymous money if they ever spend the change without anonymizing it first. You could even have a higher-level protection in the form of an additional warning that displays "This transaction includes change from a previous transaction that has NOT been anonymized. The recipient of the previous transaction that resulted in the change will be able to identify you as the sender of the current transaction unless you use anonymous funds. Enter your password again if you understand these risks and wish to continue with the transaction anyway."

Does this solve the change problem? Or is there something I'm not considering?
The change would have to be unspendable (until redenominated) as spending it in the future would expose the previous transaction.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
What about proof of burn for the change? Gets logged by the MNs and all burners get whatever has been burned back from freshly minted blocks. This wouldn't have to be deflationary, extra DRK could be minted each block to cover it.

Getting a bit radical... :tongue:

In fact, if every tx was burned and the receiver instead got freshly minted DRK, privacy would be perfect as no DRK would ever have any history. :D
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
The change would have to be unspendable (until redenominated) as spending it in the future would expose the previous transaction.
Add a 0.10 denomination and then implement masternode locks on change under denomination limits until it reaches a point to be mixed? I feel like this idea was already mentioned in the dead change thread.
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
What about proof of burn for the change? Gets logged by the MNs and all burners get whatever has been burned back from freshly minted blocks. This wouldn't have to be deflationary, extra DRK could be minted each block to cover it.

Getting a bit radical... :tongue:

In fact, if every tx was burned and the receiver instead got freshly minted DRK, privacy would be perfect as no DRK would ever have any history. :D
I don't like the idea of messing with the block rewards again but it is an interesting idea for a new coin. One burn address for the network, the receiver automatically sends their received tx to the burn address. The network scans the burn address for amounts and from addresses, sums the total amount burned and adds that to the normal block reward with the block found sending the fresh coins to the from addresses found at the burn address. Although I believe this would be very bloated. Probably something obvious missing here as well in terms of privacy but it sounded cool.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
I don't like the idea of messing with the block rewards again but it is an interesting idea for a new coin. One burn address for the network, the receiver automatically sends their received tx to the burn address. The network scans the burn address for amounts and from addresses, sums the total amount burned and adds that to the normal block reward with the block found sending the fresh coins to the from addresses found at the burn address. Although I believe this would be very bloated. Probably something obvious missing here as well in terms of privacy but it sounded cool.
Solves the change problem, pretty sure it yields almost perfect privacy with fresh addresses each time, don't see it being bloaty at all, possibly the opposite, and we could still use the MN network for InstanTX's faster than the blocktime. Plus we could call it the Eschaton Protocol.

OK, I'll stop now. :tongue:
 

Ryan Taylor

Well-known Member
Dash Core Team
Foundation Member
Jul 3, 2014
550
1,649
263
Scottsdale, AZ, USA
Add a 0.10 denomination and then implement masternode locks on change under denomination limits until it reaches a point to be mixed? I feel like this idea was already mentioned in the dead change thread.
What downsides are there, then? The only mentioned so far:
1) You might need to wait for more funds to anonymize (but you have to do this anyway, so not really much of a "downside" vs. transactions without change)
2) Users could expose themselves, but only after being warned and deciding they are OK with it (for example, I might be fine letting Target.com know that in a later transaction I bought something from Walmart.com and override the warning if I don't feel like waiting for enough anonymous funds, but I might NOT be OK with spending change from a transaction with my wife at the casino)

Anything else? Basically, only spend anonymous funds and you remain anonymous. Sounds simple enough to me... this seems like a non-issue "red herring" to me, at least based on the objections so far.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
I think the bloat issue is overblown. Increasing the denomination resolution to whatever level is sensible given (hopefully) increasing DRK price isn't going to drastically increase the size of the blockchain beyond the amount (hopefully) adoption will anyway.

Is there such a thing as a purely deterministic/procedural blockchain? If block (x-1) could be recreated perfectly from block x, we wouldn't need to maintain store a blockchain at all.
 

paperThin

Member
Jun 13, 2014
106
19
68
Ah, I knew I was missing something simple. I guess you're right, you cannot assume that the change back address that we both are unsure how it is given is funded from funds already in the wallet even if there would be enough excess from the initial transaction. So you could run into issues where the receiver doesn't have the funds available to send for change. You could solve this by forcing the excess to be anon'd through darksend before going back but then you are prolonging the time it takes for the initial sender to get their rightfully owned change back, right? Further, you still run into issues than with change back sourced from funds under the denomination threshold.

The person making change can't fix the issue by doing "darksend denominates" (DSD is that how we are abbreviating?) using the payment from the buyer. Sure, that would work with the whole numbers, but it does not handle the fractional DRK. The whole numbers are not a real big issue anyway, because the buyer can premix whole numbers to exactly 1DRK above the cost. (ie 12.75 can be sent as 13DRK, so if he prepares his payment, he only has to wait for a fractional DRK.)
None of the original payment can be used to make fractional change (it is the fractional change that makes "bread crumbs")

As I write this, I realize that this A,B then C, D does not fix anything (see example)

Buyer: Joe
Seller: QuestionableProductsSeller (QPS)
  • Joe buys a butterfly knife from QPS for 8.25 DRK
  • Joe sends 9 DRK to QPS
    • All new addresses used for this example
    • (This step is A -> B)
    • Joe's 9 DRK were run through Darksend Denominate(DSD) 20x
  • QPS receives 9 DRK to his address B
  • A new block is found... time has elapsed
  • QPS sends Joe 0.75 DRK from a new and separate address
    • (This step is C -> D)
    • This is less than 1 DRK, so it would be impossible to DSD
    • QPS could not have DSD on this unless it came from a whole 1.0 DRK
    • Joe will not be able to DSD since it is fractional change
    • Joe should not mix this with other purchases if he does not want future trouble (dead change here)
  • If QPS used 1.0 DRK DSD 20x to make the payment to Joe...
    • then QPS would have 0.25 "dead change" that will link future purchases.
  • If QPS used exact change 0.75 DRK to make the payment to Joe...
    • then it was not DSD at QPS and not possible to DSD when received by Joe
  • We have a direct link from QPS to Joe
    • Even if both Joe and QPS did their best to be "careful", there is no method to stay private
    • Of course, donating the change is still a valid method...
If I am wrong here, please point out the flaw... Aswan, care to comment?

Zombies!!!
 

David

Well-known Member
Dash Support Group
Jun 21, 2014
618
628
163
I think the bloat issue is overblown. Increasing the denomination resolution to whatever level is sensible given (hopefully) increasing DRK price isn't going to drastically increase the size of the blockchain beyond the amount (hopefully) adoption will anyway.

Is there such a thing as a purely deterministic/procedural blockchain? If block (x-1) could be recreated perfectly from block x, we wouldn't need to maintain store a blockchain at all.
I agree with this. Darkcoin's MN network should be sufficient to store and serve the blockchain even without any other nodes running on people's PCs, etc. We currently have 1230 MNs, all serving the complete blockchain, and Evan's target is 2,000 - 3,000 within the next year. So I'm not really worried about bloat unless it's extreme (like the CN currencies).

Bitcoin has a market cap that's 431x as large as Darkcoin and does fine with 6766 full nodes (https://getaddr.bitnodes.io/).
 

illodin

Member
Apr 26, 2014
122
71
78
Just make the denoms 500, 100, 10, 5, 1, 0.5, 0.25, 0.1, 0.05, 0.025, 0.01 (and even 0.005, 0.0025, 0.001) and get this over with imo. Deal with bloating later if needed - "summary blocks", mini-blockchain, or some other form of pruning that is yet to be discovered.