Hmm I wonder if there is a way to use transaction locking to help with randomizing the fees. Have the number of blocks that the fees are frozen for be a randomized number between 3 and 8. The fee is not spendable anymore and will be deducted, but the transaction is off chain until the randomized amount of time? My brain hurts.
You could still monitor the lock messages, and doing a timing attack. But that data wouldn't be in the blockchain. It's a bit better, but it's still attackable. |
|
|
|
Alright Evan, would you mind recap what the proposal is so far?
Also I think a Pay per Darksend process is better than for a period of time, but it's the source of the issue, right?
Yeah, it's the source. The Proposal: Hardfork the network to provide completely zero-fee darksend mixing. However, when users start they'll pay a "subscription". When mixing on a masternode, they provide proof they own that subscription and the masternode will allow them to mix. After mixing, only masternodes are capable of transmitting these zero-fee transactions to the network by signing them, and they are restricted to only send 1 a day (some calculation based off the total amount of masternodes). Subscriptions could come in day/month/yearly forms. Edit: I've got to run! We'll continue this later |
|
|
|
Well... if the fee is for a darksend session so you pick the rounds (this only influences how long it will take) and then hit start session and pay your fee.
If you stop the session you'll have to pay the fee again.
Hey presto no spamming.
No, you could stop/start the session as much as you want. The wallet will see you have an active "subscription" and provide that. |
|
|
|
People are used to registering for monthly or yearly subscriptions.
Maybe offer those too, and give the user some discount?
monthly 10% off
yearly 50% off.
Definitely possible. |
|
|
|
Hard to implement no ? How about paying a (one time) fee randomly to one of the masternodes involved in the rounds ?
EDIT : hmm no the first round's masternode.
No, that part is pretty easy to implement. I've laid out most of the API for this type of thing already. Your idea sounds pretty much the same as mine, you pay once and then you provide proof of that to the nodes as you go. However, mine isn't tied to any transaction, so it's more secure. |
|
|
|
I think I misunderstood something here.. If someone pays a small amount to be able to darksend for 24hours, then it means those people could mega spam during 24 hours, regardless of the MNs, no?
EDIT: or you meant people pay for the time the anonymization process? Then they actually darksend 10 days later for free if they want to? So if it's about anonymizing the funds, then yes people can't spam or DDOS
If you owned 20 masternodes, you could send 10-20 transactions a day for free. That's the idea. Without the signature of the masternode, the transactions would be rejected. |
|
|
|
Just not sure about the fee for a period of time
Me too. Why? So you pay 0.05DRK when you want to mix, then you mix how ever much you want. If your client goes over 24 hours, it'll spend another 0.05DRK to keep going. It eliminates the timing attacks and double spending attacks. people could still spam during that window and bloat the network for free, no? DOS attacks? We could have a masternode sign the transaction when publishing it. The distribution should be really even among the masternodes, so that would eliminate bloat. So if you own 1 masternode, you could publish 1 transaction every 2 days currently. So it requires 1000DRK to use this feature and you still can't use it very much. |
|
|
|
I think I'm in favor of hard-forking the network to make Darksend transactions completely free. So there will be no fees to track at all. Instead of the miners, they could pay either the masternode network (the one you connected to even), the development fund, foundation fund, etc. These payments would be passed to the masternode and could be cashed later to avoid timing analysis. Another upside to this is it's impossible to do in Bitcoin and the fees could be MUCH lower than 0.0125. Thoughts?
Posted this over at DCT as well, but... Three thoughts/questions: 1. How exactly would this new fee --say, to the masternodes -- be enforced? 2. I thought the DS transaction fee was there not just to prevent Sybil attacks but also to ensure DS blocks get processed immediately by miners. I remember the days of 0.001 fees when RC4 was released and DS rounds >1 not working because of this issue. 3. This seems like a lot more work compared to adding a fees mixing phase. Is there some technical reason why the fee mixing phase can't be done or is a bad idea? 1. I'm thinking the user will pay for Darksend access for a period of time. For example, you do one transaction for 0.1 to the Darksend access address, this is the very first thing you do when Darksend starts. Then you send that transaction ID, and a signature proving you own the input. That gives you access to darksend for 1 day or something. 2. You're correct. That's what the hard fork is for. 3. I think there's a problem with the fee mixing phase. That would be much easier, but every round of a darksend would still go back to 1 Darksend fee mixing transaction. So you could follow a transaction from round 8,7...1. If you control the last masternode, you could tell who owns the final Darkcoin. no brainer. lose the fees. add the fees to InstantX - Give people the option to pay for first class mail, vs. second class mail. With no fees people would spam attack the network with Sybil identities and bloat up the blockchain via Darksend. @eduffield As for the duration fee, thinking about it more I now think it may not work well as spammers can still spam during that window. Maybe the 0.05 fee is enough to keep them away, dunno... DOS attacks? We could have a masternode sign the transaction when publishing it. The distribution should be really even among the masternodes, so that would eliminate bloat. So if you own 1 masternode, you could publish 1 transaction every 2 days currently. So it requires 1000DRK to use this feature and you still can't use it very much. |
|
|
|
Just not sure about the fee for a period of time
Me too. Why? So you pay 0.05DRK when you want to mix, then you mix how ever much you want. If your client goes over 24 hours, it'll spend another 0.05DRK to keep going. It eliminates the timing attacks and double spending attacks. |
|
|
|
I think I'm in favor of hard-forking the network to make Darksend transactions completely free. So there will be no fees to track at all. Instead of the miners, they could pay either the masternode network (the one you connected to even), the development fund, foundation fund, etc. These payments would be passed to the masternode and could be cashed later to avoid timing analysis. Another upside to this is it's impossible to do in Bitcoin and the fees could be MUCH lower than 0.0125. Thoughts?
making things more affordable for the enduser is always a good idea. But I don't understand, you want to make darksend transactions completely free, yet pass payments to the masternode network? Are you talking about voluntary fees? If something becomes completely free, doesn't this enable DOS attacks? I have always looked at fees as some sort of DOS hurdle, so that it would cost a fortune to flood the network with millions of transactions. Voluntary fees? No, but it would be much cheaper than it is now. DOS attacks? We could have a masternode sign the transaction when publishing it. The distribution should be really even among the masternodes, so that would eliminate bloat. So if you own 1 masternode, you could publish 1 transaction every 2 days currently. |
|
|
|
I think I'm in favor of hard-forking the network to make Darksend transactions completely free. So there will be no fees to track at all. Instead of the miners, they could pay either the masternode network (the one you connected to even), the development fund, foundation fund, etc. These payments would be passed to the masternode and could be cashed later to avoid timing analysis. Another upside to this is it's impossible to do in Bitcoin and the fees could be MUCH lower than 0.0125. Thoughts?
Posted this over at DCT as well, but... Three thoughts/questions: 1. How exactly would this new fee --say, to the masternodes -- be enforced? 2. I thought the DS transaction fee was there not just to prevent Sybil attacks but also to ensure DS blocks get processed immediately by miners. I remember the days of 0.001 fees when RC4 was released and DS rounds >1 not working because of this issue. 3. This seems like a lot more work compared to adding a fees mixing phase. Is there some technical reason why the fee mixing phase can't be done or is a bad idea? 1. I'm thinking the user will pay for Darksend access for a period of time. For example, you do one transaction for 0.1 to the Darksend access address, this is the very first thing you do when Darksend starts. Then you send that transaction ID, and a signature proving you own the input. That gives you access to darksend for 1 day or something. 2. You're correct. That's what the hard fork is for. 3. I think there's a problem with the fee mixing phase. That would be much easier, but every round of a darksend would still go back to 1 Darksend fee mixing transaction. So you could follow a transaction from round 8,7...1. If you control the last masternode, you could tell who owns the final Darkcoin. |
|
|
|
|
I think I'm in favor of hard-forking the network to make Darksend transactions completely free. So there will be no fees to track at all. Instead of the miners, they could pay either the masternode network (the one you connected to even), the development fund, foundation fund, etc. These payments would be passed to the masternode and could be cashed later to avoid timing analysis. Another upside to this is it's impossible to do in Bitcoin and the fees could be MUCH lower than 0.0125. Thoughts?
|
|
|
|
Will send mine when I'm at the computer where I can access them... in couple of hours.
Thanks! |
|
|
|
Alert: Masternode OperatorsI'm looking into why collateral has been randomly charged on the network. Can a few people send me their debug.log to evan@darkcoin.io. Thanks! Still need some debug.logs  Edit: Got what I needed, thanks! |
|
|
|
Alert: Masternode OperatorsI'm looking into why collateral has been randomly charged on the network. Can a few people send me their debug.log to evan@darkcoin.io. Thanks!Edit: got what I needed, thanks!
|
|
|
|
If you believe that, then you don't understand how it works. The whole process is off-blockchain, so there is no information left to source. |
|
|
|
I don't understand where those 6 confirmations came from. Your commentary suggest that you explicitly expected not less or more but exactly 6, even though there were no 6 new blocks, nor 6 masternodes, so this number seems to pop out of thin air. 6 block confirmation is considered to be a fully "confirmed" transaction. So if an exchange wants to allow deposits with instant transactions, they could set it to 6 and their systems will recognize it as confirmed. Alternatively, a vendor taking money by default will see 1 confirmation and know the money is safe (without the --instantxdepth parameter set). Awesome work, evan. If I understand you correctly an --instanttxdepth higher than 6 is not possible, right? Any additional number of confirmations will slowly come from the miners confirming the transactions. But it will never be possible to do an --instanttxdepth = 100. People will be able to set values from 1 - 6, but not higher, right? Please correct me if I am wrong. It can go much higher. But would take longer? Or what's the catch? I think you're missing the critical part of what's happening. When a client receives a transaction lock, they have cryptographic proof that 10 masternodes signed off on the transaction in question. That also means that the masternodes didn't detect anything funny happening while observing the network during the transaction and that afterwards, no other transaction with the same inputs can possibly enter the pool. It's basically a guarantee that the transaction will end up in a block, so the client will show X confirmations instead of 0. It'll still take 2.5 minutes per block confirmation as they normally happen. When block confirmations > instantxdepth setting, the client starts showing the actual block confirmations. |
|
|
|
|
Show Posts
