-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Mike Hearn <m...@plan99.net> wrote: >I think this US/other cultural issue is complicating things more than >we >appreciate. > >I am trying to imagine in my head how all this will work and what it >will >look like with allow_fee, and I just can't see it. Merchants want >customers >to pay the sticker price, deviance from that social norm is extremely >rare >even after the credit card company contracts that required it have been >invalidated. The only time it happens to me is when buying flight >tickets >with credit cards: but it's only for that method, other payment methods >are >still treated as "free" a.k.a interior fees. > >If you walk into a physical shop and try to pay a large bill with bags >of >pennies, the merchant won't enter into a complicated agreement where >they >agree to split the cost of processing with you. They will just reject >the >payment out of hand and tell you to get real. It has to be that way >because >otherwise the shop would carry the cost of counting all the pennies and >hauling them around, not the buyer (who "knows" he put the right number >of >pennies in the bags). > >As a buyer, I do not care about whether my transaction will confirm. If >I >try to pay with dust, there is no incentive for me to attach a higher >fee >than allow_fee to make that confirm, especially if the merchant has no >way >to reject the payment. What's more, as Jeremy points out, no clean fail >mechanism means large piles of manual work and lots of disputes due to >payments not clearing before the exchange rate shifts and other things >like >that. > >Trying to make the success of payment confirmation a two-person dance >seems >to have so many edge cases it makes my head hurt. For most >pay-to-merchant >cases, it has to be the receivers job to get a transaction confirmed, >and >if the sender doesn't follow the instructions a payment should hard >fail >and require trying again. If Bitcoin-Qt can't handle that today, that >does >seem like a problem. > >In the case of a transaction with too-low fee, either the payer can >> double-spend with a higher fee > > >You can't do that. When a tx doesn't have the right fee attached you're >out >of luck today, except for the fact that some pools run with a custom >child >pays for parent patch. So respending it would bump priority for some >miners >and not others. Here at the dark wallet conf there seems yo be rough consensus that replacement for fee bumping is a good thing and should be supported; I was talking to Taylor from hive specifically yesterday. The code is trivial on the node side of things and doesn't need consent of anymore than a small minority, and coinjoin forces wallets to handle double spends well anyway. I haven't heard anyone caring about zeroconf safety. I'll be proposing it for "formal" inclusion in our wallet best practices guidelines. Also fwiw apparently libbitcoin already implements a memory limited mempool and Amir is open to the idea of it using the satoshi consensus critical code for block validity. (therefor fairly safe mining) I wouldn't be surprised if libbitcoin based nodes start getting usage, and with a limited mempool it is very DoS attack safe for them to relay replacements regardless of miner support. -----BEGIN PGP SIGNATURE----- Version: APG v1.0.9 iQFQBAEBCAA6BQJSnwqsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhR5yCAC3vaQQeoBrLdqn/rO5 Dzblqwl1B6AE1UjFj5+abQEZ2+uPy5P+7dZidpUn8Ms+tDDcCCge6HVOg+UeseaE 8pDP3+VIHZHH+9n6Y3+4facLNpQ3dP/+Zsg4pC+QSAjVV6408+yWPLtpbC6V0apK T6K4qdq0Ct6V+54Ol0Thx+5cJlWLI+XbW2eXze3WjJzj3FgZUK0udBcVWa8JyWAV WD1tv8DpPoUvDDzdmjEyf0EdjvcmamH9mcIvtxRdVwzyY/siZoizv9X8/gXNL+fg JJ3Oxwrl1dOYSeENgp9VP8fU7GK7855bT1Wxd5zGNW7p/1gNxN4Lnx57XSMz2IHc dHbg =dcYz -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
