Hash: SHA256

Mike Hearn <m...@plan99.net> wrote:
>I think this US/other cultural issue is complicating things more than
>I am trying to imagine in my head how all this will work and what it
>look like with allow_fee, and I just can't see it. Merchants want
>to pay the sticker price, deviance from that social norm is extremely
>even after the credit card company contracts that required it have been
>invalidated. The only time it happens to me is when buying flight
>with credit cards: but it's only for that method, other payment methods
>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
>pennies, the merchant won't enter into a complicated agreement where
>agree to split the cost of processing with you. They will just reject
>payment out of hand and tell you to get real. It has to be that way
>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
>pennies in the bags).
>As a buyer, I do not care about whether my transaction will confirm. If
>try to pay with dust, there is no incentive for me to attach a higher
>than allow_fee to make that confirm, especially if the merchant has no
>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
>Trying to make the success of payment confirmation a two-person dance
>to have so many edge cases it makes my head hurt. For most
>cases, it has to be the receivers job to get a transaction confirmed,
>if the sender doesn't follow the instructions a payment should hard
>and require trying again. If Bitcoin-Qt can't handle that today, that
>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
>of luck today, except for the fact that some pools run with a custom
>pays for parent patch. So respending it would bump priority for some
>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 

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.
Version: APG v1.0.9


Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
Bitcoin-development mailing list

Reply via email to