News for hackers. Stuff that matters.
Re:402 Payment Required, and why micropayments are doomed by CalmStorm on Tuesday May 19, 2020 @05:28PM (#23240479)
Since it is a micropayment, it is possible (or acceptable) to accept payment with zero confirmation (in less than 10 seconds), as pointed out by Satoshi in the "Bitcoin snack machine" post: https://bitcointalk.org/index.php?topic=423.msg3819#msg3819

Yes, there is a risk of double-spending, but since this is a small amount, the cost of the attack may be higher than the benefit. The payment processor can also deploy more full nodes in different geographic locations to monitor and detect potential double-spending transactions in the transaction memory pool.

Re:402 Payment Required, and why micropayments are doomed by fxtentacle on Tuesday May 19, 2020 @06:11PM (#23240908)
Since all you need is the software to generate your fake transaction with the right technical format, the cost of the attack can be zero.

And then a million fraudulent microtransactions will add up. Of course, that would never happen in practice, because the Blockchain cannot handle a million transactions in any reasonable time frame.

Re:402 Payment Required, and why micropayments are doomed by CalmStorm on Tuesday May 19, 2020 @06:42PM (#23241173)
In case there are multiple conflicting transactions (for double-spending purpose), the network will only accept the first one and reject the rest. So the micropayment processor needs to wait for a few seconds when it receives the first transaction in the mempool. If no other conflicting transactions arrive, the first transaction will be acccepted. These few seconds give the first transaction big advantage over the double-spending ones, as it will most likely be included in the block.

If the attacker sends the legit transaction and double-spending one at the same time, it will be detected due to the few seconds wait by the payment processor.

Re:402 Payment Required, and why micropayments are doomed by paulmd on Tuesday May 19, 2020 @08:02PM (#23241820)
there's no protocol-level guarantee of that, both transactions are perfectly valid, signed transactions and it's purely dependent on the good behavior of node operators to reject these

and in fact it is quite common to accept "double-spending" since that is really the only way to increase fees to push through a "stuck" transaction. Otherwise you have to wait an indeterminate (potentially forever) period of time until it exits the mempool of all network participants

Re:402 Payment Required, and why micropayments are doomed by CalmStorm on Tuesday May 19, 2020 @08:27PM (#23242013)
If there are two valid, signed transactions that spend the same unspent input transaction (UTXO), only one of them will be included in the block. This is indeed guaranteed by the protocol [1].

[1] https://bitcoin.stackexchange.com/questions/81624/can-two-or...

Re:402 Payment Required, and why micropayments are doomed by fxtentacle on Wednesday May 20, 2020 @01:36AM (#23243585)
Yes, but "included in the block" means you either wait some hours or pay higher fees.
Re:402 Payment Required, and why micropayments are doomed by sp332 on Tuesday May 19, 2020 @08:55PM (#23242205)
Yes but it is in the best interest of the node operators to behave well in that way, so it's reasonably trustworthy even without protocol-level guarantees.
Re:402 Payment Required, and why micropayments are doomed by lostmsu on Tuesday May 19, 2020 @09:57PM (#23242521)
Huh, I might misunderstand it, but that property appears to be broken in account-based cryptocurrencies like Ethereum. Since there's no concept of unspent outputs, what could protect ETH etc users in a similar way? Wallet transaction index?
Re:402 Payment Required, and why micropayments are doomed by murbard2 on Tuesday May 19, 2020 @11:43PM (#23243089)
There's a nonce on each account. If you see a transaction from the same account with the same nonce it's a double spend . Nonce can't be skipped either, so a double spend requires two transactions with the same nonce.
Re:402 Payment Required, and why micropayments are doomed by somebodythere on Tuesday May 19, 2020 @11:01PM (#23242880)
It is broken in Ethereum. In Ethereum, since consistency is enforced by transaction nonce rather than UTXOs, there is no way for a "watcher" to keep the payer honest by rebroadcasting a previously signed transaction output. Indeed, in Ethereum you can "cancel" a transaction in the mempool by signing a blank transaction with a higher fee and same nonce, which is by design.
Re:402 Payment Required, and why micropayments are doomed by decentralised on Wednesday May 20, 2020 @03:53AM (#23244397)
Mind you that a tx in the mempool has not yet produced any changes to state. In BTC you can also replace-by-fee for instance (https://en.bitcoin.it/wiki/Transaction_replacement).

This page (https://github.com/ethereum/wiki/wiki/Design-Rationale) contains a good overview of the UTXO vs Account model with each's strengths and weaknesses.

Re:402 Payment Required, and why micropayments are doomed by lostmsu on Tuesday May 19, 2020 @11:16PM (#23242962)
How does Bitcoin decide which of the two transactions spending the same UTXO to pick?