Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2013-12-04 📝 Original message:-----BEGIN PGP SIGNED ...

📅 Original date posted:2013-12-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Mike Hearn <mike at 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-----