3 ms·

There are a few things I don't quite understand here. First, why bother cleaning up the spam? IIUC it has always been the case that miners are allowed to choo

There are a few things I don't quite understand here. First, why bother cleaning up the spam? IIUC it has always been the case that miners are allowed to choose which transactions they do and don't include in a block. The idea is that as the block solving reward diminishes, there will be a market for transaction fees. If you set the fee high enough, many people trying to make a block will add it to their list. If the fee is not high enough, then nobody will add it to the list and it will take a long time (possibly forever) to clear. Ignoring tiny transactions that have very small transaction fees seems like a completely reasonable thing to do to me... Is there a downside to this? This leads me to another question. If a transaction never gets processed, can the original person get their money back? I suppose they can double spend and the transaction that gets processed first wins, but that seems like a risky proposition. It's been a while since I looked at the protocol, but I can't recall anything about cancelling transactions (and I don't know how that would work...). So if nobody decided to add your transaction to a block, do you effectively lose that money? That seems like an unacceptable situation, so I have to imagine that there is some work around that I haven't imagined yet... Finally, if there is some way to cancel a transaction, then I suppose this can lead to a DOS attack by sending out lots of transactions and then cancelling them right away. While nobody needs to add a transaction to a block, I can't understand a way for the protocol to work unless the transactions are propogated to every miner so that they can at least choose what to add to their blocks. Is there anything in the protocol to limit the effect of someone simply flooding the network with worthless transactions? (Given the current problem, I'm guessing no...)

ikeboy 11y ago
>First, why bother cleaning up the spam? "to decrease UTXO bloat" from https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csv9sgk https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_tra... (In short, all these transactions were in memory on full nodes, taking up valuable RAM space) >If a transaction never gets processed, can the original person get their money back? I suppose they can double spend and the transaction that gets processed first wins, but that seems like a risky proposition. It's been a while since I looked at the protocol, but I can't recall anything about cancelling transactions (and I don't know how that would work...). So if nobody decided to add your transaction to a block, do you effectively lose that money? That seems like an unacceptable situation, so I have to imagine that there is some work around that I haven't imagined yet... You can send another transaction with a higher fee, and it's up to miners themselves whether they'll mine the new one. By default, Bitcoin Core currently has a "first-seen" policy; a miner will ignore any transaction that spends outputs already in the mempool. There are also some miners running the "replace-by-fee" patch [0], which does exactly what it sounds like; however, there's opposition to this being merged to Core [1]. There's also talk of a "child pays for parent", also exactly what it sounds like. >Finally, if there is some way to cancel a transaction, then I suppose this can lead to a DOS attack by sending out lots of transactions and then cancelling them right away. While nobody needs to add a transaction to a block, I can't understand a way for the protocol to work unless the transactions are propogated to every miner so that they can at least choose what to add to their blocks. Is there anything in the protocol to limit the effect of someone simply flooding the network with worthless transactions? (Given the current problem, I'm guessing no...) There's no way directly to cancel one, no "cancel" message in the protocol, so your first point doesn't matter. See also [2] and [3] for stuff on DOS protection. [0] https://www.reddit.com/r/Bitcoin/comments/235zv5/why_you_should_mine_with_replacebyfee_a/ https://www.reddit.com/r/Bitcoin/comments/235zv5/why_you_sho... [1] https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d [2] https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28D... [3] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...

ikeboy 11y ago

>First, why bother cleaning up the spam? "to decrease UTXO bloat" from https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csv9sgk https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_tra... (In short, all these transactions were in memory on full nodes, taking up valuable RAM space) >If a transaction never gets processed, can the original person get their money back? I suppose they can double spend and the transaction that gets processed first wins, but that seems like a risky proposition. It's been a while since I looked at the protocol, but I can't recall anything about cancelling transactions (and I don't know how that would work...). So if nobody decided to add your transaction to a block, do you effectively lose that money? That seems like an unacceptable situation, so I have to imagine that there is some work around that I haven't imagined yet... You can send another transaction with a higher fee, and it's up to miners themselves whether they'll mine the new one. By default, Bitcoin Core currently has a "first-seen" policy; a miner will ignore any transaction that spends outputs already in the mempool. There are also some miners running the "replace-by-fee" patch [0], which does exactly what it sounds like; however, there's opposition to this being merged to Core [1]. There's also talk of a "child pays for parent", also exactly what it sounds like. >Finally, if there is some way to cancel a transaction, then I suppose this can lead to a DOS attack by sending out lots of transactions and then cancelling them right away. While nobody needs to add a transaction to a block, I can't understand a way for the protocol to work unless the transactions are propogated to every miner so that they can at least choose what to add to their blocks. Is there anything in the protocol to limit the effect of someone simply flooding the network with worthless transactions? (Given the current problem, I'm guessing no...) There's no way directly to cancel one, no "cancel" message in the protocol, so your first point doesn't matter. See also [2] and [3] for stuff on DOS protection. [0] https://www.reddit.com/r/Bitcoin/comments/235zv5/why_you_should_mine_with_replacebyfee_a/ https://www.reddit.com/r/Bitcoin/comments/235zv5/why_you_sho... [1] https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d [2] https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28D... [3] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...