Change Contracts using Atomic Transfers

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

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

I think Evan is going to get the change issue solved after his Thanksgiving meal! :smile:
Click to expand...
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.
 
moli said:
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
Click to expand...

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.

.
 
yidakee said:
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.

.
Click to expand...

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.
 
oblox said:
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.
Click to expand...

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.

.
 
oblox said:
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.
Click to expand...

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)
 
eduffield said:
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)
Click to expand...

Just one question. What happens if the receiving party has the wallet offline the moment the coins are darksent?
 
eduffield said:
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)
Click to expand...
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.
 
Minotaur said:
Just one question. What happens if the receiving party has the wallet offline the moment the coins are darksent?
Click to expand...

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).
 
oblox said:
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.
Click to expand...

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.
 
yidakee said:
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.

.
Click to expand...

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?
 
illodin said:
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?
Click to expand...
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.
 
bituzer said:
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)
Click to expand...
Sure, with no change, we still can Darksend to offline wallets as usual.
 
eduffield said:
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.
Click to expand...
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.
 
oblox said:
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.
Click to expand...
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)"
 
UdjinM6 said:
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)"
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top