Just tested RBF - it already works much as I was suggesting it should, much different to what I saw described.
Regards, Damian Williamson ________________________________ From: Damian Williamson <[email protected]> Sent: Friday, 1 December 2017 5:40:10 PM To: [email protected] Subject: TLDR; summary Thank you for the discussion in reply, it is a complicated concern. I realize now with further consideration of the article that I originally posted, uncapped block sizes may introduce a problem. Another person posted a similar idea as a proposed BIP to the bitcoin-dev list yesterday. My realization was that there may be nothing to stop a rogue or greedy miner from scooping all of the transactions in the transaction pool into the next block, scooping all transaction fees for themselves. Then, with all transactions processing into the next block, there would be no need to pay fees. That would be bad for Bitcoin. However, the other person seemed to suggest that it would not be economical to scoop all transactions. Due to the extra computational bandwidth required their block would not likely be the first solved so, there would be an equilibrium point where you scoop some transactions to solve the block first and get paid. If that is correct, fully uncapped block sizes at miners choice would still not quite work as the next block would then always contain one transaction only to be the first solved for the least computational power. What I suggested was that each transaction has a likelihood of being included in the next block and, what I supposed is that all transactions whose lucky number comes up then get included. This would still provide a random distribution of solved blocks amongst all miners. How what I foresaw could be enforced amongst all mining software to stop block underskimming by rogues and just solving one transaction (or one or, two transactions less) for a block which would likely be an issue, I do not know. If there was a block minimum size, why would anybody risk expending more computational power with less likelihood of solving the block? A slight divergence on the topic of bad. IMO the current RBF implementation is bad. If store merchants operate on instant approval, as they would with EFTPOS and as we have seen already in implementations of Bitcoin at POS (not waiting for any confirms) then, a dishonest Bitcoin user could redivert the BTC back to themselves using RBF before there were any confirms and after they had already left the store. A solution would be to only allow RBF to replace the fee and not the whole transaction (replace with a higher fee). Another possibility would be for POS implementations of Bitcoin to not approve transactions with RBF set until there are confirms. The first does not introduce any additional issues but limits the possible uses of the RBF feature. The second would likely be problematic at POS - what to do if the customer pays with RBF set, have them take a seat for three to thirty days? Not an issue for online merchants where it is simple to wait for confirms - is Bitcoin actually seen as a live-in-store retail solution? Regards, Damian Williamson
_______________________________________________ bitcoin-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
