From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Tue, 3 Dec 2013 11:06:39 +0100 [thread overview]
Message-ID: <CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]
On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <gavinandresen@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!
[-- Attachment #2: Type: text/html, Size: 3194 bytes --]
next prev parent reply other threads:[~2013-12-03 10:06 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 11:51 Mike Hearn
2013-12-01 12:15 ` Andreas Schildbach
2013-12-01 13:41 ` Mike Hearn
2013-12-01 16:50 ` Andreas Schildbach
2013-12-01 17:19 ` Mike Hearn
2013-12-01 17:40 ` Andreas Schildbach
2013-12-01 17:52 ` Mike Hearn
2013-12-01 18:12 ` Peter Todd
2013-12-01 18:18 ` Mike Hearn
2013-12-01 18:37 ` Peter Todd
2013-12-02 13:54 ` Patrick Mead
2013-12-02 14:33 ` Mike Hearn
2013-12-02 14:37 ` Jeff Garzik
2013-12-02 14:44 ` Mike Hearn
2013-12-02 14:47 ` Jeff Garzik
2013-12-03 1:40 ` Gavin Andresen
2013-12-03 10:06 ` Mike Hearn [this message]
2013-12-03 10:36 ` Drak
2013-12-03 10:45 ` Mike Hearn
2013-12-03 11:04 ` Drak
2013-12-03 11:07 ` Gavin Andresen
2013-12-03 11:29 ` Mike Hearn
2013-12-03 11:37 ` Peter Todd
2013-12-03 11:41 ` Gavin Andresen
2013-12-03 11:46 ` Mike Hearn
2013-12-03 11:54 ` Gavin Andresen
2013-12-03 12:05 ` Drak
2013-12-03 11:57 ` Taylor Gerring
2013-12-03 12:07 ` Peter Todd
2013-12-03 13:20 ` Jamie McNaught
2013-12-03 13:20 ` Mike Hearn
2013-12-03 13:48 ` Taylor Gerring
2013-12-03 13:54 ` Mike Hearn
2013-12-03 14:42 ` Quinn Harris
2013-12-04 1:45 ` Jeremy Spilman
2013-12-04 10:40 ` Mike Hearn
2013-12-04 10:57 ` Peter Todd
2013-12-04 11:09 ` Mike Hearn
2013-12-04 13:06 ` Peter Todd
2013-12-04 13:48 ` Mike Hearn
2013-12-04 21:51 ` Peter Todd
2013-12-03 11:03 ` Peter Todd
2013-12-03 11:09 ` Drak
2013-12-03 11:33 ` Peter Todd
2013-12-04 5:50 ` kjj
2013-12-03 11:31 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox