Lawrence Nahum [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-12 📝 Original message:Mike Hearn <mike <at> ...
📅 Original date posted:2015-02-12
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
>
>
> I know you will ignore this as usual, but the entire replace-by-fee folly
is based on your fundamental misunderstanding of miner incentives.
I disagree, I think it is inevitable (but then of course I'm probably biased
and why wouldn't I disagree given I run a service that allows for zero
confirmation/double spend protection with third party trust.)
Fixing it now avoids having people build on top of very weak/broken
foundations (see Coinbase https://botbot.me/freenode/bitcoin-
wizards/msg/29818058/) which would cause bigger problems down the line.
One thing I don't understand from your position is how do you propose
handling transactions being stuck for days or longer because of low fees?
Even with floating fees you can have a sudden inflow of high fees
transactions taking over post broadcasting your transaction.
I also assume restricted replacement is very hard, especially from a UX point
of view and adds undue complexity
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
>
>
> I know you will ignore this as usual, but the entire replace-by-fee folly
is based on your fundamental misunderstanding of miner incentives.
I disagree, I think it is inevitable (but then of course I'm probably biased
and why wouldn't I disagree given I run a service that allows for zero
confirmation/double spend protection with third party trust.)
Fixing it now avoids having people build on top of very weak/broken
foundations (see Coinbase https://botbot.me/freenode/bitcoin-
wizards/msg/29818058/) which would cause bigger problems down the line.
One thing I don't understand from your position is how do you propose
handling transactions being stuck for days or longer because of low fees?
Even with floating fees you can have a sudden inflow of high fees
transactions taking over post broadcasting your transaction.
I also assume restricted replacement is very hard, especially from a UX point
of view and adds undue complexity