Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-25 📝 Original message:On Fri, Oct 25, 2013 at ...
📅 Original date posted:2013-10-25
📝 Original message:On Fri, Oct 25, 2013 at 06:39:34AM +1000, Gavin Andresen wrote:
> Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
> the answer is "a small percentage."
>
> So: there are multiple layers of reasons why OOB fee payments will not
> screw up the fee estimation code:
I've responded to nearly all those arguments elsewhere, but anyway...
> And all of the above is completely orthogonal to child-pays-for-parent
> and/or replace-with-higher-fee.
Indeed. Quoting myself here: "What we should have is both: fee
estimation with replacement so you can replace transactions in the event
that the estimate was too low."
So on IRC you were talking about very agressive mempool expiration - as
little as a block or two before tx's are expired. Now if a tx does fail
to get mined in that short window, am I correct in saying you want a way
to modify the fee it pays and rebroadcast? In which case wallet software
and other players in the ecosystem will have to adjust to the fact that
they can expect to see relatively frequent double-spends of unconfirmed
transactions?
As you know I've already written relaying/mempool code for
tx-replacement and replace-by-fee; it's the wallet code that's the hard
part that I haven't done. If you're already planning on changing the
wallet side of things to handle replacement-through-expiration that'd
save me a lot of hard work. You're probably better qualified to write
that code too; I'm not very familiar with the wallet.
Worth thinking about the whole ecosystem of wallets involved; they all
have to handle double-spends gracefully to make tx replacement of any
kind user friendly. We should try to give people a heads up that this is
coming soon if that's your thinking.
Also, regarding tx replacement user experience:
> Come back a few hours later and find out you need to type in your
> password again so your client can unlock your wallet, resign, and
> re-transmit with a higher fee?
Password-using wallets sign multiple versions of the transaction in
advance of course and release the higher fee versions only later if
required. (could be applied to coinjoin too)
--
'peter'[:-1]@petertodd.org
0000000000000005391e2338afe5204414d66b1f140b172da651daedf5663af2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131025/7bbb7631/attachment.sig>;
📝 Original message:On Fri, Oct 25, 2013 at 06:39:34AM +1000, Gavin Andresen wrote:
> Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
> the answer is "a small percentage."
>
> So: there are multiple layers of reasons why OOB fee payments will not
> screw up the fee estimation code:
I've responded to nearly all those arguments elsewhere, but anyway...
> And all of the above is completely orthogonal to child-pays-for-parent
> and/or replace-with-higher-fee.
Indeed. Quoting myself here: "What we should have is both: fee
estimation with replacement so you can replace transactions in the event
that the estimate was too low."
So on IRC you were talking about very agressive mempool expiration - as
little as a block or two before tx's are expired. Now if a tx does fail
to get mined in that short window, am I correct in saying you want a way
to modify the fee it pays and rebroadcast? In which case wallet software
and other players in the ecosystem will have to adjust to the fact that
they can expect to see relatively frequent double-spends of unconfirmed
transactions?
As you know I've already written relaying/mempool code for
tx-replacement and replace-by-fee; it's the wallet code that's the hard
part that I haven't done. If you're already planning on changing the
wallet side of things to handle replacement-through-expiration that'd
save me a lot of hard work. You're probably better qualified to write
that code too; I'm not very familiar with the wallet.
Worth thinking about the whole ecosystem of wallets involved; they all
have to handle double-spends gracefully to make tx replacement of any
kind user friendly. We should try to give people a heads up that this is
coming soon if that's your thinking.
Also, regarding tx replacement user experience:
> Come back a few hours later and find out you need to type in your
> password again so your client can unlock your wallet, resign, and
> re-transmit with a higher fee?
Password-using wallets sign multiple versions of the transaction in
advance of course and release the higher fee versions only later if
required. (could be applied to coinjoin too)
--
'peter'[:-1]@petertodd.org
0000000000000005391e2338afe5204414d66b1f140b172da651daedf5663af2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131025/7bbb7631/attachment.sig>;