 Show Posts
|
|
Pages: [1] 2 »
|
|
Crap, you're right, in the OKPAY case the first transaction took so long to get into the slow 0.7 fork, the double spend didn't need to be sent until 3 hours later. So this would not have prevented the specific OKPAY case, although it would have alerted them as soon as possible.
I think it still would prevent the typical case where someone fires double spends into each fork at the same time, which is what you'd normally have to do to exploit a fork, especially if the dominant fork ends up winning.
|
|
|
|
It was practically unavoidable because transaction had more than 6 confirms in the +0.8 blockchain, which was later dumped by the miners.
But this would have avoided it. It would have detected the existence of a double spend seen on the network and locked the transaction for several days, like 500 blocks. Once you know a double spend exists of your payment, it is a dangerous payment and should be held for a long time before accepting it. |
|
|
|
I think the OKPAY double spend during the fork could have been prevented if the software did not ignore double spends it receives. The double spend transaction was not a secret. It was announced to the network to get into miner's pools. The OKPAY server probably received the double spend from at least one of its peers, but the software ignored it. Instead, it should really put the payment in a -1 conf penalty box for several 100 blocks until any possible fork or blockchain problem will have been sorted out. A caught double spend is nothing to take lightly. I wrote a dspend alert message proposal here https://github.com/bitcoin/bitcoin/issues/1034, but as BlueMatt suggests, even without a dspend alert, we can have 95% of the benefit just by taking appropriate notice of double spends we already see. If a node has 20 connections, then any double spend reaching more than 5% of the network will probably hit one of those 20 connections. |
|
|
|
If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.
Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. That's 12.5 * 32 = 402 bytes per second. It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash. No, I'm talking about the current silicon without implementing a merkle processor + coinbase generator in silicon. So was I. I'm sorry, maybe I'm missing something. The CPU increments the coinbase extra nonce and recalculates the merkle branch to make new merkle roots to send to the ASIC. Only the merkle roots need to go over the wire. |
|
|
|
If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.
Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. You don't need to send the whole header, only the merkle root changes. That's 12.5 * 32 = 402 bytes per second. It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash. Edit: Also it only needs a enough merkle roots to last for 1 second. After 1 second it can update nTime and cycle through its supply of merkle roots again. If you sent it the block header and 13 merkle roots, it would have all it needs. |
|
|
|
Any change to the block header is a hard fork upgrade, and should be avoided at all costs.
His point is stealing 2 bytes from version shouldn't be a hard fork or any fork. (unless 0.7.0 panics when it sees a new version number, I haven't read that code yet... nVersion is a signed int, so you could stipulate the high bit set so it makes a negative version number for <=0.7.0) The version bytes were put there for extensibility. We need some now. We could use them now, or save them for some future need for bytes. OTOH, Stratum seems to solve this nicely. The CPU has to do about 10 hashes and send 32 bytes of merkle root for every 4 billion hashes the ASIC does. ASIC is fast but is it anywhere near 400,000,000 times faster than CPU? I think CPU is like ~4 Mhash, so ASIC would have to be 100 petahash to outrun CPU's part of the job. |
|
|
|
I haven't considered if your newly proposed rule is sufficient yet or if it's otherwise dangerous. But it's deployment would be a fork risk unless it had super-majority miner support. Otherwise an attacker could intentionally split the network.
Two ways:
(1) If there is an unlikely moderately long gap between the median and now (5 blocks in 24 hours) he can just directly mine one block with a violating timestamp.
(2) Since you're already postulating majority hashpower attackers, one could replace the end of the chain with a violating chunk.
Those are valid concerns during phase-in before a majority of miners have the rule, but the usual procedure of making it enable at some future time or block number would cover that. |
|
|
|
It doesn't just require a simple majority, the chain must also be forked more than two weeks in the past (and at just over two weeks in the past it would take a long time to push the difficulty down), then must catchup and overtake in sum difficulty. This is _much_ harder than just a majority. With only a 1% advantage you'd be toiling for a very long time in secret to overtake after cutting month back.
We shouldn't rely too much on it being harder. The minimum 51% attack currently requires 22Thash. Time warp might require 44Thash to pull off. Someone having 22Thash is unlikely, but 44Thash isn't much less likely than 22Thash. Someone with the ability to get 22Thash could probably get 44Thash too. The chaos from a time warp attack could be an order of magnitude greater. Much more than the additional difficulty of pulling it off. Imagine if a time warp attacker divided up 10 million bogus BTC and sent it to every public bitcoin address in the chain. Many businesses would automatically take actions on receiving a confirmed payment, like initiating transfers of their own good BTC or fiat currency. Any bogus BTC circulating would mix with good BTC. All transactions based on mixed money would have to be rewound, but clean transactions would have to stay valid. If someone deposited a mixed transaction and withdrew a clean one, or vice versa, one side is out the money. Also, it would be a terrible mess to clean up all the screwed up wallets that think their coins are spent. I don't think that rule is sufficient. You can tick the clock just 1 second per 5 blocks without advancing forward the oldest permitted time.
I updated the OP to a more obvious idea #2. |
|
|
|
ArtForz posted here how the timestamp constraints can be gamed to walk backwards the timestamps used in difficulty adjustments. While a 51% attack is still incredibly difficult, this bug greatly increases the potential damage if there is one. In bitcoin.pdf, a 51% attack was supposed to be at least somewhat limited: "Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air... An attacker can only try to change one of his own transactions to take back money he recently spent." With the time warp bug, a 51% attacker can create value out of thin air by lowering the difficulty to 1 and generating the remaining 11 million BTC of block rewards for himself. Time warp keeps rewinding time to fit unlimited blocks before the current time. (I think ArtForz actually demonstrated the attack on one of the altcoins) Since time warp chains are so distinctively different from anything the real network would ever generate, it should be possible to come up with a way to block them without causing compatibility problems. Rule Idea #2: Rule: A block is invalid if timestamp is more than 24 hours after GetMedianTimePast() This limits the divergence between GetMedianTimePast() and single timestamps that the time warp takes advantage of. The time warp depends on making single timestamps far in the future and jumping back to the old time before the median is affected. It would really only need to apply to the two blocks involved in difficulty adjustment calculations. (only 2 out of 2016 blocks) It's hard to imagine there ever being a 24 hour gap in practice, but just in case, miners should cap timestamp at GetMedianTimePast() + 24 hours. (this part wouldn't require universal miner support, just enough to push through 2 blocks) |
|
|
|
|
What type of error was it? Capitalization, missing character, extra character, transposed, etc?
|
|
|
|
Arbitrarily small probabilistic micropayments are possible: https://en.bitcoin.it/wiki/NanopaymentsFor most payments (like 999/1000), there is only data back and forth between the buyer and seller without posting a transaction to the network. |
|
|
|
b) the ability to add a transaction fee to a transaction that you've received and that hasn't yet made it into a block…the client would do this by creating a new transaction with that transaction as an input and sending coins back to yourself (less the desired tx fee)…the client would immediately broadcast this new transaction
b) ... The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender. The sender can add fee by re-sending the change. It wouldn't be a big deal to make transactions always have change. There's usually change anyway. I think that's a problem that would fix itself if clients had this feature and people started using it. If you're a miner and are actively seeking fee bearing transactions, you really shouldn't be rejecting fee-less transactions if they are inputs to fee bearing transactions that meet your fee requirements.
I agree. |
|
|
|
Precisely because of the same logic etotheipi outlined escrow where both parties have monetary incentive to complete transaction. - If Bob doesn't have a risk deposit, he has no incentive to complete the transaction after he receives the merchandise (besides being a good person). If Alice isn't required to put in a risk deposit -- she could have Bob create the 2-of-3 transaction (or 2-of-2!) with her address, and then she backs out and leaves the money stranded. Then Bob will have to pay Charles to help unlock the money. Or if it's a 2-of-2 -- it's just locked forever.
Then there's your solution. The transaction must have some change the payer will lose if he double spends. |
|
|
|
"Double spend = same input, different outputs."
You would still need to reconsider the changed tx fee. That would require you to change the amount of the "change" adress, and/or add new inputs and/or outputs to the transaction (if the too-low-fee transaction also included inputs with too low value to be able to increase the fee) so the new fee add up correctly in equation.
Its hard to check in a safe way. I think a tx expiration feature would be better then.
We could allow the amount of only one output to change. The only thing they can do with that is change the fee, they can't take any money back. I prefer a cleaner way to increase the fee that doesn't require messy double spending and can be done by either side: The recipient can spend the low fee txn with a larger fee so miners have to include both transactions to get the larger fee. The payer can also do that by spending the change. Unfortunately, Theymos is right, tx expiration is not possible. I think the proposal have a flaw, consider next scenario.
1. Transaction 1 is broadcasted
2. Merchant accepts Transaction 1 with 0-confirmations and release the purchase
3. Transaction 2, which is double spend of Transaction 1, is broadcasted
4. Miner gets all the coins from Transaction 1
5. Merchant eats the loss.
The customer doesn't get anything back by doing that. There's no incentive. If you believe as some do that miners can be bribed with fees, then that's already possible. The customer could double spend it all to fee. The double-spend-becomes-fee model is strictly superior to the fee bribe model. Under fee bribe, part of the payment can be taken back by increasing the fee. Under this new model, any attempt to steal a payment back becomes proof the miner can use to take the whole amount. Under both models, they can give the entire amount to fee, but under this model, that's the only thing the double spender can do. He can't benefit from double spending. |
|
|
|
Can you remind me how "the miner gets it automatically"?
It's in "Defense against double spending" thread https://bitcointalk.org/index.php?topic=76276.0I think it would be a totally unacceptable change to allow coins to be transferred to a party/script that was not signed by the originator. i.e. AddrA signed a tx to go to AddrB, but instead the network allows it to be awarded to AddrC. I don't see how there's even a hint of feasibility in this idea, unless I'm misunderstanding the proposal...
Signing a second spend authorizes a miner to take it. So don't double spend! There's also some legit reasons a tx might end up appearing to be a double spend, even though it's not. Programmatically, it would be impossible to distinguish those cases, and miners would have free reign to eat up any such transactions anyway.
The legit cases are where the outputs are the same, or any non-final. Don't count those as double spends. Double spend = same input, different outputs. |
|
|
|
I see three options for who should get the double spent amount: 1. The first transaction - Currently working OK, although imperfect incentive for miners. Double spend race attack is manageable. 2. The highest fee double spender - Aligned with miner incentive, but rewards double-spending even more. 3. Neither, the miner gets it automatically - Aligned with miner incentive, trumps fee bribe, and removes all incentive to double spend. See https://bitcointalk.org/index.php?topic=76276.0 |
|
|
|
Suppose there's a transaction for 100,000BTC and several blocks later a double spend with 50,000BTC fee... and by then the 100,000BTC was already spent out to others in smaller amounts.
Or maybe you should wait 60 blocks before considering a half-a-million-dollar transaction final if you think there is any possibility of a mining cabal trying to do this. He should wait before delivering the goods, but there's no incentive for him to wait to spend the BTC. Actually, he's better off if he does spend it and someone else down the line takes the loss. What if they break it into 1000 payments of 100BTC, and then 1000 double spends with 50BTC fee? |
|
|
|
Or, in other words, you'd need to be pretty sure that you've got a majority of miners who will cooperate with you to rewrite the block chain. The longer the chain, the harder that will be (because it becomes increasingly likely that one of your co-conspirators mined one of the blocks you want to overwrite).
Suppose there's a transaction for 100,000BTC and several blocks later a double spend with 50,000BTC fee... and by then the 100,000BTC was already spent out to others in smaller amounts. It only takes 1 or 2 pool miners to have 51%. (Maybe there should be a maximum fee per transaction--edit: nevermind, not possible) |
|
|
|
I misread - I thought you wanted to include it as secondary inputs to the coinbase transaction. Still, the coinbase is limited to 100 bytes. It will be very hard to put two full transactions plus an extra output in there...
Ooooh, you're right. The extension data would have to be shoehorned in somewhere else, like an extra 0BTC output on the coinbase to a deadend scriptPubKey that contains the extension data in a push-drop. I think that would be about 15 bytes overhead, and only when there's a double spend to kill. It is possible for people create non-fraudulent double-spends. A common case: if they forgot to include a sufficient fee and the transaction goes into limbo, they can resend it with a fee. Under this proposal there's a small chance they could lose the entire balance if a miner who considers the no-fee transaction to be valid and then mines them both. Evil miners could even hoard such transactions hoping for the opportunity to confiscate a large fee.
To preserve this option, don't consider it a double spend if it goes to the same outputs. Double spend = same input, different outputs. |
|
|
|
If either or both of tx have fees it would require miners to intentionally choose less fees as opposed to just including the tx with highers fees.
I updated it again so the miners get the entire amount eventually, and in the future get it immediately. If you believe miners will take a double spend for a higher fee, then it's already completely unsafe to take 0-conf payments. Double spenders can bribe the miners at any time. In fact, if miners can be bribed with fees, then the network falls apart without this change. Send a 1000BTC payment. Wait 2 blocks. Double spend it with a 500BTC fee. All the miners switch to 2 blocks ago to get the 500BTC fee. It doesn't have to be one payment. Pay 10BTC to 100 people. Wait two blocks, double spend them all with 5BTC fee. leaving existing nodes vulnerable to deception from the "dead" outputs that the existing nodes don't see as dead.
That is true, but those will still stay permanently 0-conf, and it's already not safe at all to accept 0-conf. After the change, anyone who wants to safely accept 0-conf can upgrade. It's mostly merchants that want to accept 0-conf, and they generally keep up with the latest updates. This is not correct. Old nodes will not accept a block whose coinbase has more than one, or non-empty inputs.
The scriptSig of a coinbase is a scratch area that is ignored that can be used for extension data. |
|
|
|
|
