Sjors Provoost [ARCHIVE] on Nostr: đź“… Original date posted:2018-01-28 đź“ť Original message:I can see how merging ...
đź“… Original date posted:2018-01-28
đź“ť Original message:I can see how merging after the fact could be more practical than appending existing transactions.
I think what Moral Agent suggested is the same as your original proposal, namely dropping rule 3. Only fee per weight unit increase from rule 4 would matter.
The minimum per WU increase could be far higher than the minimum relay fee. The few times I’ve used RBF in practice I increased the fee by at least 50%. Rule 4 could be made more strict. I don’t know what number, if any, would address concerns about relay spam?
This wouldn’t be backward compatible. Does that matter as long as there’s enough nodes that follow the new rules? Is there a punishment for relaying transactions that violate rule 3? Could a recipient using the older rules be mislead (in a way that’s worse than the fact that RBF allows the sender to replace the transaction with anything they want anyway)?
Peter Todd wrote:
> You'd also be able to push others' txs out of the mempool.
Can you elaborate on this issue?
And wrote:
> payment service for instance where a large number of deposits are aggregated into a smaller number of payments
So this would involve wallets (of users who deposit coins) cooperating with an exchange API to consolidate in-mempool transactions?
And wrote:
> In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.
Why would you need to consider the whole mempool? Let’s say a miner is considering to replace transaction A and B with transaction C, where C pays a higher fee per byte than both A and B. This creates space for ~ one additional transaction in the block. It seems to me the miner only needs to check that the lowest fee per weight transaction > min_fee(A,B). At least in first approximation.
Sjors
> Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
>
>> I'm confused, the mempool only sees 1 transaction at a time, first A, then later B. "the original transactions", plural, should not exist in the mempool.
>>
>> B's fee and rate needs to be larger than A's, but B will be greater than or equal to A anyway. So, just increasing the fee rate will cause a larger fee anyway.
>>
>> Am I missing something?
>
> Kind of. The first case is that you do the "smarter" type of merging, where you get an original transaction and then say add an additional output(s) to it.
>
> The issue with this, is from a practical perspective is _very_ complex. Because you really need to do a lot of tracking to see which of the two transactions actually confirm. And if you are promising fast payments, you can be stuck in a weird limbo state where you're waiting for the original one to "safely" confirm before it's safe to make a re-payment (even a non-malicious will likely contain the replacement).
>
> bip125 already supports this use-case, but I will suggest that the logic to deploy this is sufficiently complex that no one is going to attempt any time in the near future.
>
>
> But "retroactive transaction merging" is actually pretty approachable problem for a service to implement. You just get N valid transactions you've made, merge them into one. Strip extraneous inputs[1], and combine and alter the change amount.
>
> The reason this is so appealing to implement, is there is very little complexity. If the "retroactive transaction merge" fails, or doesn't get confirmed, it actually has no impact. If it does get confirmed, that's just pure cost-savings.
>
> However, the rules of bip125 currently make it (unnecessarily?) unappealing, because I can never lower the absolute amount of fees I pay. Hence I think it'd be pretty sweet if they could be relaxed to support this if it can be done in a pretty risk free way.
>
>
>
> [1] Need to be very careful with that, if you're ever merging a merged transaction.
>
>
>>
>>
>> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev wrote:
>>>> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>> Interesting. I didn't think about this before, but it seems like bip125 is
>>>>> rather incentive incompatible right now? If we're assuming a competitive
>>>>> mempool, it really doesn't seem generally rational to accept a replacement
>>>>> transaction of a lower fee rate.
>>>>
>>>> BIP125 replacement requires that the fee rate increases. The text of
>>>> the BIP document is written in a confusing way that doesn't make this
>>>> clear.
>>>
>>> In fact I considered only requiring an increase in fee rate, based on the
>>> theory that if absolute fee went down, the transaction must be smaller and thus
>>> miners could overall earn more from the additional transactions they could fit
>>> into their block. But to do that properly requires considering whether or not
>>> that's actually true in the particular state the mempool as a whole happens to
>>> be in, so I ditched that idea early on for the much simpler criteria of both a
>>> feerate and absolute fee increase.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>
đź“ť Original message:I can see how merging after the fact could be more practical than appending existing transactions.
I think what Moral Agent suggested is the same as your original proposal, namely dropping rule 3. Only fee per weight unit increase from rule 4 would matter.
The minimum per WU increase could be far higher than the minimum relay fee. The few times I’ve used RBF in practice I increased the fee by at least 50%. Rule 4 could be made more strict. I don’t know what number, if any, would address concerns about relay spam?
This wouldn’t be backward compatible. Does that matter as long as there’s enough nodes that follow the new rules? Is there a punishment for relaying transactions that violate rule 3? Could a recipient using the older rules be mislead (in a way that’s worse than the fact that RBF allows the sender to replace the transaction with anything they want anyway)?
Peter Todd wrote:
> You'd also be able to push others' txs out of the mempool.
Can you elaborate on this issue?
And wrote:
> payment service for instance where a large number of deposits are aggregated into a smaller number of payments
So this would involve wallets (of users who deposit coins) cooperating with an exchange API to consolidate in-mempool transactions?
And wrote:
> In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.
Why would you need to consider the whole mempool? Let’s say a miner is considering to replace transaction A and B with transaction C, where C pays a higher fee per byte than both A and B. This creates space for ~ one additional transaction in the block. It seems to me the miner only needs to check that the lowest fee per weight transaction > min_fee(A,B). At least in first approximation.
Sjors
> Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
>
>> I'm confused, the mempool only sees 1 transaction at a time, first A, then later B. "the original transactions", plural, should not exist in the mempool.
>>
>> B's fee and rate needs to be larger than A's, but B will be greater than or equal to A anyway. So, just increasing the fee rate will cause a larger fee anyway.
>>
>> Am I missing something?
>
> Kind of. The first case is that you do the "smarter" type of merging, where you get an original transaction and then say add an additional output(s) to it.
>
> The issue with this, is from a practical perspective is _very_ complex. Because you really need to do a lot of tracking to see which of the two transactions actually confirm. And if you are promising fast payments, you can be stuck in a weird limbo state where you're waiting for the original one to "safely" confirm before it's safe to make a re-payment (even a non-malicious will likely contain the replacement).
>
> bip125 already supports this use-case, but I will suggest that the logic to deploy this is sufficiently complex that no one is going to attempt any time in the near future.
>
>
> But "retroactive transaction merging" is actually pretty approachable problem for a service to implement. You just get N valid transactions you've made, merge them into one. Strip extraneous inputs[1], and combine and alter the change amount.
>
> The reason this is so appealing to implement, is there is very little complexity. If the "retroactive transaction merge" fails, or doesn't get confirmed, it actually has no impact. If it does get confirmed, that's just pure cost-savings.
>
> However, the rules of bip125 currently make it (unnecessarily?) unappealing, because I can never lower the absolute amount of fees I pay. Hence I think it'd be pretty sweet if they could be relaxed to support this if it can be done in a pretty risk free way.
>
>
>
> [1] Need to be very careful with that, if you're ever merging a merged transaction.
>
>
>>
>>
>> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev wrote:
>>>> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>> Interesting. I didn't think about this before, but it seems like bip125 is
>>>>> rather incentive incompatible right now? If we're assuming a competitive
>>>>> mempool, it really doesn't seem generally rational to accept a replacement
>>>>> transaction of a lower fee rate.
>>>>
>>>> BIP125 replacement requires that the fee rate increases. The text of
>>>> the BIP document is written in a confusing way that doesn't make this
>>>> clear.
>>>
>>> In fact I considered only requiring an increase in fee rate, based on the
>>> theory that if absolute fee went down, the transaction must be smaller and thus
>>> miners could overall earn more from the additional transactions they could fit
>>> into their block. But to do that properly requires considering whether or not
>>> that's actually true in the particular state the mempool as a whole happens to
>>> be in, so I ditched that idea early on for the much simpler criteria of both a
>>> feerate and absolute fee increase.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>