zhoujianfu
commented
6 years ago I think anybody can put out their own protocol and take suggestions how they'd like.. if they put out a dumb protocol or piss people off and nobody uses it, they should learn from it. So, 1. may be a good suggestion but it also may be that that process isn't proving effective.
For 2. I think it's fine to say this protocol supports requiring a minimum fee rate. Just like this protocol could require sending a shipping address too, and then rejecting it if it's deemed by the merchant as an invalid address. It's just a protocol to try and streamline confusing/complicated parts of a standard merchant checkout. Nobody has to use it, no wallet has to implement it.
And 3 is the same thing.. I think bitpay has actually gone through a lot of the problems with actual people buying actual things with actual bitcoin, and have come up with some solutions to some of the real issues. Again, if it's critically important to broadcast your own transaction, I guess your wallet won't work with bitpay merchants (well actually it will, I think they're just suggesting you send them the txn). If everybody uses your wallet, merchants will put pressure on bitpay or switch to a new provider. If everybody uses bitpay checkout (or this protocol), you'll probably need to consider implementing it in your wallet if you want users to use it.
But, I guess this is just a suggestion and you're letting bitpay know your thoughts, which is fine of course! (And I'm just adding counter-arguments and a vote against them.)
Note: I am a wallet developer on a wallet that support BIP70, but I'm commenting here in a personal capacity.
While I think the goal of simplifying/improving BIP70 is laudable, this proposal has some issues I think need addressing.
1) Lack of standard process
Please follow the standard process if you wish to gain consensus for this proposal. That would in my view include announcing/discussing on bitcoin-dev and following the BIP request/review process.
2) "requiredFeeRate - The minimum fee per byte required on this transaction. Payment will be rejected if fee rate included for the transaction is not at least this value. May be fractional value ie 0.123 sat/byte"
No. Users pay mining fees (or pay out of band/mine themselves), not you. Once you have given me an address to send to, and I have sent payment to it (and it confirms), if you want to 'reject' that payment then a) your incentives are broken and b) the merchant can expect trouble from the user since they have failed to provide a good/service which was just paid for. This is like you telling me I must pay my credit card provider a certain fee or you will ignore my payment - frankly its nuts, and its ripe for abuse.
If I assume benevolent intent then I must assume you believe you can calculate fees more accurately or cheaply than the user can. A less charitable interpretation of this is that you can make your own life easier by forcing exorbitant costs on the user, or continue to promote shitcoins by artificially inflating the fees on chains you wish to degrade (In a similar manner to your testnet site showing an $83 'network fee' for bitcoin and a $0.02 fee for bcash). Further, if you dictate the fees then this incentives collusion between you and miners to increase fees and split the difference with them.
No sane wallet is going to allow you to abuse/coerce their users in this manner.
3) "In general, the payment should not be broadcast by the client. If at any time the payment is rejected by the server your client must not broadcast the payment."
This is just not going to happen. If I have created and sent you a signed tx that pays to the address you already showed me, and is valid by the networks consensus rules, then I don't care that you 'reject' it for any other reason. The network decides if my tx is valid, not you.
Your own current handling of RBF with BIP70 is a case in point - If I broadcast an opt-in RBF transaction as a payment to the network, your systems process it correctly, but you currently refuse to return a payment ack for the same tx when I send the tx to you to broadcast on my behalf. Is that technical incompetence, or a political power play? Regardless, you process the payment because the alternative is a support request or legal action against the merchant, neither of which are good for your business. That doesn't change regardless of what you say in this specification.
No user is going to (or should be asked to) trust you to not send a tx you received because you decide you don't like it, and no sane wallet is going to pre-emptively double spend an output to ensure you don't process the payment anyway.