Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-12-03 📝 Original message:On Tue, Dec 3, 2013 at ...
📅 Original date posted:2013-12-03
📝 Original message:On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> optional uint64 allowfee tag number=1000
>
Let's just use a normal/low tag number. The extensions mechanism is great
for people who want to extend the protocol outside the core development
process. It'd be weird if nobody ever used the low numbers again though.
Tag numbers are varint encoded so using smaller ones does have a minor
efficiency benefit, it's not just aesthetics :)
> Allow up to allowfee satoshis to be deducted from the amount paid to be
> used to pay Bitcoin network transaction fees. A wallet implementation must
> not reduce the amount paid for fees more than allowfee, and transaction
> fees must be equal to or greater than the amount reduced.
>
Hmmm. Why "allow"? Should it not be called min_fee instead? Wallets would
have to attach at least that much in fees, right?
Also, why describe it as reducing the amount paid? Which output would be
reduced in value? Why not just have it be added to the total value
displayed to the user and the outputs are left alone/not reduced.
> We also want to allow users to pay MORE in fees, if they need to
> (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.
>
I like the idea but it seems this gets us back to the original problem -
senders don't care about confirmations, ever, not even if they make an
annoying set of transactions. The protocol allows users to submit
transactions directly to receivers, I guess, if the receiver does not like
the transactions they get they could potentially reject the payment. But
I'd hope that's really rare.
> PS: I think there was also consensus that the BIP72 request=... should
> be shortened to just r=... (save 6 chars in QR codes). Unless somebody
> objects, I'll change the BIP and the reference implementation code to make
> it so...
>
Sweet, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/26e3aaec/attachment.html>;
📝 Original message:On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> optional uint64 allowfee tag number=1000
>
Let's just use a normal/low tag number. The extensions mechanism is great
for people who want to extend the protocol outside the core development
process. It'd be weird if nobody ever used the low numbers again though.
Tag numbers are varint encoded so using smaller ones does have a minor
efficiency benefit, it's not just aesthetics :)
> Allow up to allowfee satoshis to be deducted from the amount paid to be
> used to pay Bitcoin network transaction fees. A wallet implementation must
> not reduce the amount paid for fees more than allowfee, and transaction
> fees must be equal to or greater than the amount reduced.
>
Hmmm. Why "allow"? Should it not be called min_fee instead? Wallets would
have to attach at least that much in fees, right?
Also, why describe it as reducing the amount paid? Which output would be
reduced in value? Why not just have it be added to the total value
displayed to the user and the outputs are left alone/not reduced.
> We also want to allow users to pay MORE in fees, if they need to
> (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.
>
I like the idea but it seems this gets us back to the original problem -
senders don't care about confirmations, ever, not even if they make an
annoying set of transactions. The protocol allows users to submit
transactions directly to receivers, I guess, if the receiver does not like
the transactions they get they could potentially reject the payment. But
I'd hope that's really rare.
> PS: I think there was also consensus that the BIP72 request=... should
> be shortened to just r=... (save 6 chars in QR codes). Unless somebody
> objects, I'll change the BIP and the reference implementation code to make
> it so...
>
Sweet, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/26e3aaec/attachment.html>;