• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Change Contracts using Atomic Transfers

Great, so they can take a further look at the coin and see that DRK isn't truly anonymous.
Oblox, relax.. lol.. Happy Thanksgiving! :grin:

I think Evan is going to get the change issue solved after his Thanksgiving meal! :smile:
 
Oblox, relax.. lol.. Happy Thanksgiving! :grin:

I think Evan is going to get the change issue solved after his Thanksgiving meal! :smile:
Happy Thanksgiving to you as well.

I just want to see it addressed as to the viable outcome. The smart contracts was pitched but then no further information was given. It wasn't long after when you start breaking it down that it doesn't fix the issue and actually causes more problems. I would feel better knowing that the microdenoms and donated change is the only viable direction and that there is a timeline in place for implementation. Understandably, the blockchain will grow faster, but there are a few methods out there that could be used for pruning the transactions. Who knows, maybe Evan has another idea based off the masternode network.
 
LOL.. No problem.. As of now, if you blink and miss a few pages on DCT... you really have no idea what's being discussed, like what happened to me... I thought the change issue was if you use your change left from a previous DS transaction, the change would lead right back to your origin address.. So yesterday I did some testing and found that wasn't so... I posted here and people were like "what are you doing moli, what are you talking about, why did you do this..." hahahah.. Found out that wasn't exactly the issue, just because I didn't read everything that Aswan and everybody posted... tl,dr... lol

Indeed. I was almost two weeks out and my roaming data plan sucks. Traveling across europe, as soon as I got any wifi signal I would dive right into the forums, at the airport, hotel, etc, but that one completely went unnoticed.

Oblox, you are very right, but relax! You have no idea how many times it seemed Darkcoin would implode, and Evan always pulled through. And he was alone back then. Us drk "old timers" have become very used to these "crisis" situations. I can only guarantee you this. "What doesn't kill you makes you stronger" is like an anthem for Darkcoin. If Evan rolled out InstantTX testnet its because he (and dev team) has been working his ass off to roll it out knowing perfectly well further issues he needs to address. He's a smart cookie that one.

.
 
Indeed. I was almost two weeks out and my roaming data plan sucks. Traveling across europe, as soon as I got any wifi signal I would dive right into the forums, at the airport, hotel, etc, but that one completely went unnoticed.

Oblox, you are very right, but relax! You have no idea how many times it seemed Darkcoin would implode, and Evan always pulled through. And he was alone back then. Us drk "old timers" have become very used to these "crisis" situations. I can only guarantee you this. "What doesn't kill you makes you stronger" is like an anthem for Darkcoin. If Evan rolled out InstantTX testnet its because he (and dev team) has been working his ass off to roll it out knowing perfectly well further issues he needs to address. He's a smart cookie that one.

.

I've been with Darkcoin since March, I've been through everything and I know how it works. However, there still needs to be discussion on the direction we are going in to fix this. Evan pitched this idea and then pretty much left a ton of open questions unanswered. His idea doesn't solve the issue at hand. Fine, roll out instantx and do testing. Won't take long for others to stumble upon the dead change issue with no current resolve. I'm simply asking for Evan to comment on the ideas pitched and give us a rough idea on how long we are unable to have a truly anonymous coin. Yes, you can send exact change and not reuse dead change, but that's not a solution--that's a problem that will only compound itself as other users use it without knowing.

We all know instantx was coded a while back, he mentioned it... it was inevitable that testing was going to happen. I just don't want more days to go by with no clear solution in site to a much larger, more pressing issue.
 
I've been with Darkcoin since March, I've been through everything and I know how it works. However, there still needs to be discussion on the direction we are going in to fix this. Evan pitched this idea and then pretty much left a ton of open questions unanswered. His idea doesn't solve the issue at hand. Fine, roll out instantx and do testing. Won't take long for others to stumble upon the dead change issue with no current resolve. I'm simply asking for Evan to comment on the ideas pitched and give us a rough idea on how long we are unable to have a truly anonymous coin. Yes, you can send exact change and not reuse dead change, but that's not a solution--that's a problem that will only compound itself as other users use it without knowing.

We all know instantx was coded a while back, he mentioned it... it was inevitable that testing was going to happen. I just don't want more days to go by with no clear solution in site to a much larger, more pressing issue.

I totally totally get you. I'm not a coder so I cannot help. We've been in DRK for the same time, but for some reason our paths only cross now. So you know perfectly well that Evan has been working on it constantly, Saturday and Sundays included. Many times with multiple fixes in one day. He is totally dedicated and professional.

If he allowed InstantTX to testnet, that immediately means he is comfortable enough to let it go into the wild to see how it goes, so he can dedicate his time to fix the D+ issue. If it were a dramatic ship-sinking problem, he would drop everything to look into it. That is my experience with testnet since March, and why I'm not overly worried.

It is obviously a pressing issue, but I am absolutely confident he's is totally on it. It is his baby after all.

.
 
There are a ton of unanswered questions begging for answers. Feel free to answer them and then we can re-evaluate but so far it seems you either run the risk of the receiver not having funds to send back for change (because you can't use the excess change the initial party sent), the added problems of timing and how it will conflict with instantx implementation, the security issue of needing to have the wallet unlocked in order to send the second tx, additional steps running secondary daemons, how party B gets the address of party A (address C) etc, etc. On paper, it looks like it solves it but I think a few in there don't see how it actually would when you delve into the details.

Please, by all means, answer the questions everyone asked in the thread and we'll have a better idea of whether or not this works.

1. Risk of the receiver not having funds to send back for change? It's part of the protocol I'll write. If the merchant doesn't have money available to make change they can't receive a payment. The protocol can stop the transaction at any point without any risk of anyone losing money. It only actually happens if everything will work properly.
2. It'll be completely supported by InstantX. InstantX is agnostic and supports any transactions.
3. Read the first post, there's a new wallet mode that's not completely unlocked, but will support change contracts and Darksend.
4. There is no secondary daemon.
5. How parties communicate? Though the protocol via masternodes.

I have a complete idea of how to implement this in my head and it'll work. In the mean time, I'm going to mark change as "dead" in the wallet. This will give me some time to implement this (which will be v10.18)
 
1. Risk of the receiver not having funds to send back for change? It's part of the protocol I'll write. If the merchant doesn't have money available to make change they can't receive a payment. The protocol can stop the transaction at any point without any risk of anyone losing money. It only actually happens if everything will work properly.
2. It'll be completely supported by InstantX. InstantX is agnostic and supports any transactions.
3. Read the first post, there's a new wallet mode that's not completely unlocked, but will support change contracts and Darksend.
4. There is no secondary daemon.
5. How parties communicate? Though the protocol via masternodes.

I have a complete idea of how to implement this in my head and it'll work. In the mean time, I'm going to mark change as "dead" in the wallet. This will give me some time to implement this (which will be v10.18)

Just one question. What happens if the receiving party has the wallet offline the moment the coins are darksent?
 
1. Risk of the receiver not having funds to send back for change? It's part of the protocol I'll write. If the merchant doesn't have money available to make change they can't receive a payment. The protocol can stop the transaction at any point without any risk of anyone losing money. It only actually happens if everything will work properly.
2. It'll be completely supported by InstantX. InstantX is agnostic and supports any transactions.
3. Read the first post, there's a new wallet mode that's not completely unlocked, but will support change contracts and Darksend.
4. There is no secondary daemon.
5. How parties communicate? Though the protocol via masternodes.

I have a complete idea of how to implement this in my head and it'll work. In the mean time, I'm going to mark change as "dead" in the wallet. This will give me some time to implement this (which will be v10.18)
1. So new merchants would be unable to transact safely unless they held DRK in their wallet? So a brand new merchant wanting to accept DRK couldn't on a 0 balance wallet unless they themselves went out and bought some?
2. & 3. Good implementation
4. What was all the talk about needing to run a daemon then?
5. So rogue masternodes could still link transactions together because it wouldn't be going through multiple masternodes, right?

There is still the outstanding issue of change made under 1 drk. This change can never be used as is. There will always be cases where the change back will amount to some under the lowest current denomination.
 
Just one question. What happens if the receiving party has the wallet offline the moment the coins are darksent?

They won't be sent until they're both online (until the contract is in place and TX1/TX2 has been exchanged between both parties). Merchants run daemons anyway, that's how they can tell you just paid. For Darksend, all merchants will just need to run a daemon all of the time (it's really good for the network anyway).
 
1. So new merchants would be unable to transact safely unless they held DRK in their wallet? So a brand new merchant wanting to accept DRK couldn't on a 0 balance wallet unless they themselves went out and bought some?
2. & 3. Good implementation
4. What was all the talk about needing to run a daemon then?
5. So rogue masternodes could still link transactions together because it wouldn't be going through multiple masternodes, right?

There is still the outstanding issue of change made under 1 drk. This change can never be used as is. There will always be cases where the change back will amount to some under the lowest current denomination.

1. Yeah, they'll need about 10DRK in their wallet to take anon funds. Akin to putting cash in the drawer in your shop.
4. Not a secondary daemon, I'm not sure what the confusion is. They need to run a daemon, the same one that alerts them they've been paid.
5. Encryption. The masternodes will relay messages between the parties or the parties can talk directly. I'm not sure which implementation I want to do yet. Both will work.
 
I totally totally get you. I'm not a coder so I cannot help. We've been in DRK for the same time, but for some reason our paths only cross now. So you know perfectly well that Evan has been working on it constantly, Saturday and Sundays included. Many times with multiple fixes in one day. He is totally dedicated and professional.

If he allowed InstantTX to testnet, that immediately means he is comfortable enough to let it go into the wild to see how it goes, so he can dedicate his time to fix the D+ issue. If it were a dramatic ship-sinking problem, he would drop everything to look into it. That is my experience with testnet since March, and why I'm not overly worried.

It is obviously a pressing issue, but I am absolutely confident he's is totally on it. It is his baby after all.

.

The instantX branch is going to include a "dead change" fix, that just blocks users from using it. It's not a security issue AT ALL, unless it's merged with funds later, so the interim solution is to allow Darksend, but make sure the change stays dead. There's multiple ways to deal with the change and there will be instructions on what to do with it.
 
How does the other party keep his finances private then?

I want to send 7.5 DRK to someone anonymously. So I send him 10 DRK, he sends me back 3x1 and I send him back what, 0.5 DRK non-anonymous coins?
 
How does the other party keep his finances private then?

I want to send 7.5 DRK to someone anonymously. So I send him 10 DRK, he sends me back 3x1 and I send him back what, 0.5 DRK non-anonymous coins?
That's the point I brought up as well that there still are problems with change under the current lowest denomination (1). Preventing using it is for the time being is a solid interm. step, but change under 1 still needs to be made and those are the instances where it can't be denominated.
 
Interim Solution

Being that InstantX is pretty much done, I might as well release it with the interim fix for Darksend. The fix is going to include removing the larger denominations and using . 10DRK+1DRK+0.1DRK, when paying for something users will just over pay to the nearest denomination ($0.1 average). Change contracts are a better, longer term solution and improve the anonymity of the system greatly, but they'll also take me awhile to write.

The mixer will support 2 different mixing types:

.1 + 1DRK
.1 + 1 + 10DRK

The wallet will keep a balance of .1+1's automatically, so users should be able to buy what they want without issue. Also, it won't cause much bloat and again is a temporary solution till I can write the code for the contracts.
 
sounds great! I like the contracts solution because it models real world cash so nice, there you also need two open wallets for a deal. Only thing I dont like is loosing the advantage of darksending coins to a offline wallet, but perhaps this will still be possible with round amounts (without change)
Sure, with no change, we still can Darksend to offline wallets as usual.
 
Interim Solution

Being that InstantX is pretty much done, I might as well release it with the interim fix for Darksend. The fix is going to include removing the larger denominations and using . 10DRK+1DRK+0.1DRK, when paying for something users will just over pay to the nearest denomination ($0.1 average). Change contracts are a better, longer term solution and improve the anonymity of the system greatly, but they'll also take me awhile to write.

The mixer will support 2 different mixing types:

.1 + 1DRK
.1 + 1 + 10DRK

The wallet will keep a balance of .1+1's automatically, so users should be able to buy what they want without issue. Also, it won't cause much bloat and again is a temporary solution till I can write the code for the contracts.
Does this version also lock up the dead change sub 0.10 denomination from being combined and sent to others? I know a few posts up you mentioned preventing the ability to have them spent for the time being.
 
Does this version also lock up the dead change sub 0.10 denomination from being combined and sent to others? I know a few posts up you mentioned preventing the ability to have them spent for the time being.
I guess no - there is no point in combining these solutions: you either save every "dead change" and never use them OR you completely destroy it by sending as a fee to miners/masternoders. I like the second way of dealing with this a lot more. Kill all zombies! :mad::grin:
Quote from Evan's post - "when paying for something users will just over pay to the nearest denomination ($0.1 average)"
 
I guess no - there is no point in combining these solutions: you either save every "dead change" and never use them OR you completely destroy it by sending as a fee to miners/masternoders. I like the second way of dealing with this a lot more. Kill all zombies! :mad::grin:
Quote from Evan's post - "when paying for something users will just over pay to the nearest denomination ($0.1 average)"
As long as it can't be used, I'm down with it. If these means it's destroyed, I'm totally 100% behind that.
 
Back
Top