<unnamed>

Public Key

npub1pmw4p7tz6s8k62zrpdpxc93ajlmpxe0s03j275dcmcejv8wazz9qhe5c0r

Profile Code

nprofile1qqsqah2sl93dgrmd9ppsksnvzc7e0asnvhc8ce902xuduvexrhw3pzspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgayekcc

Publishing to

relay.primal.net

Last Notes

2023-06-07 18:10:02 UTC

- reply

📅 Original date posted:2018-01-22
📝 Original message:> Perhaps they could even replace old tx with economically equivalent summary transactions?
I imagine with schnorr signatures, the incentives will emerge for that to make sense. But right now if I want to merge my transaction with an untrusted party in general we're only really going to be saving like 12 bytes of overhead or something. But if I'm merging my own transactions, I can get that fixed overhead, strip extraneous inputs and merge my change outputs (which also means in the future it's cheaper to spend).
Although it's obviously a lot worse for privacy, I do like the pattern of broadcast the transaction standalone and then merge it for savings. It helps keep the more or less fire-and-forget style, without a ridiculous amount of complexity "if this happens, do this, if this, then this, ..."
-Ryan
-Ryan
-------- Original Message --------
On January 22, 2018 1:50 PM, Moral Agent <ethan.scruples at gmail.com> wrote:
> Along the same lines, I wonder if unrelated people with tx that are not confirming could cooperate to merge their disparate tx into a CoinJoin tx with a higher fee rate?
>
> Perhaps they could even replace old tx with economically equivalent summary transactions?
>
> The mempool seems like nature's accumulator for pre-mining compression opportunities.
>
> On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>> If you spent your change from transaction A, that would be safe. There'd be no way you John could end up with 2 BTC from you then.
>>
>> Yes, that's what the following paragraph says -- along with it's limitations =)
>>
>> -Ryan
>>
>> -------- Original Message --------
>> On January 22, 2018 1:16 PM, Alan Evans <thealanevans at gmail.com> wrote:
>>
>>>> So now I still owe John 1 BTC, however it's not immediately clear if it's safe to send to him
>>>
>>> If you spent your change from transaction A, that would be safe. There'd be no way you John could end up with 2 BTC from you then.
>>>
>>> On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> So my half-baked idea is very simple:
>>>>
>>>> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>>>>
>>>> This is currently not possible because of the bip125 rule:
>>>> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>>>>
>>>> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>>>>
>>>> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
>>>>
>>>> ---
>>>> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>>>>
>>>> From a "coin selection" point of view, this was significantly easier than
>>>> I had anticipated. I was able to encode the rules in my linear model and
>>>> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>>>>
>>>> However, the real problem is tracking the mess. Consider this sequence of events:
>>>> 1) I have unconfirmed transaction A
>>>> 2) I replace it with B, which pays John 1 BTC
>>>> 3) Transaction A gets confirmed
>>>>
>>>> So now I still owe John 1 BTC, however it's not immediately clear if
>>>> it's safe to send to him without waiting $n transactions. However even
>>>> for a small $n, this breaks my promise to pay him immediately.
>>>>
>>>> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>>>>
>>>> However, this will only work <50% of the time for me (most transactions
>>>> don't have change) and opens a pandora's box of complexity.
>>>>
>>>> There's a few other hacks you can do to make it work in a few more cases, but nothing that is realistic to expect anyone to implement any time soon.
>>>>
>>>> However, if there was a straight foward way to merge N unconfirmed transactions, it would be easy get into production, and potentially offer some pretty nice savings for everyone.
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/074be1a4/attachment.html>

2023-06-07 18:10:01 UTC

- reply

📅 Original date posted:2018-01-22
📝 Original message:> If you spent your change from transaction A, that would be safe. There'd be no way you John could end up with 2 BTC from you then.
Yes, that's what the following paragraph says -- along with it's limitations =)
-Ryan
-------- Original Message --------
On January 22, 2018 1:16 PM, Alan Evans <thealanevans at gmail.com> wrote:
>> So now I still owe John 1 BTC, however it's not immediately clear if it's safe to send to him
>
> If you spent your change from transaction A, that would be safe. There'd be no way you John could end up with 2 BTC from you then.
>
> On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> So my half-baked idea is very simple:
>>
>> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>>
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>>
>> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>>
>> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
>>
>> ---
>> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>>
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>>
>> However, the real problem is tracking the mess. Consider this sequence of events:
>> 1) I have unconfirmed transaction A
>> 2) I replace it with B, which pays John 1 BTC
>> 3) Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>>
>> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>>
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>>
>> There's a few other hacks you can do to make it work in a few more cases, but nothing that is realistic to expect anyone to implement any time soon.
>>
>> However, if there was a straight foward way to merge N unconfirmed transactions, it would be easy get into production, and potentially offer some pretty nice savings for everyone.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/f0b58cf0/attachment-0001.html>

2023-06-07 18:10:00 UTC

- reply

📅 Original date posted:2018-01-28
📝 Original message:I don't think this is a realistic concern. The incentive compatibility _already_ exists (just in reverse: miners are refusing transactions that would increase their total fees in the next block), and as the mempool is already generally competitive enough it's actually worse the way it is.
But I don't think it makes sense to take a zealous approach on "incentive compatibility". Bitcoin is already built on a whole bunch of incentive incompatible behaviors, even things as simple as "change outputs" (you'd be better off privately giving your transaction to trusted miners without change, who deduct the min fee they would've needed and refund the rest OOB). Not to mention, we expect miners to avoid reorgs and stuff even if it's in their short-term interest.
At least personally, I think DoS risks are the real concern.
-Ryan
-------- Original Message --------
On January 28, 2018 12:29 PM, David A. Harding <dave at dtrt.org> wrote:
> On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev wrote:
>
>> Peter Todd 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?
>
> Imagine a miner is only concerned with creating the next block and his
> mempool currently only has 750,000 vbytes in it. If two 250-vbyte
> transactions each paying a feerate of 100 nanobitcoins per vbyte (50k
> total) are replaced with one 325-vbyte transaction paying a feerate of
> 120 nBTC (39k total), the miner's potential income from mining the next
> block is reduced by 11k nBTC.
>
> Moving away from this easily worked example, the problem can still exist
> even if a miner has enough transactions to fill the next block. For
> replacement consideration only by increased feerate to be guaranteed
> more profitable, one has to assume the mempool contains an effectively
> continuous distribution of feerates. That may one day be true of the
> mempool (it would be good, because it helps keep block production
> regular sans subsidy) but it's often not the case these days.
>
> -Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180128/bc4e57d3/attachment-0001.html>

2023-06-07 18:09:58 UTC

- reply

📅 Original date posted:2018-01-24
📝 Original message:>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
>>
>>_______________________________________________
>> bitcoin-dev mailing list
>>bitcoin-dev at lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

2023-06-07 18:09:57 UTC

- reply

📅 Original date posted:2018-01-23
📝 Original message: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.
So how about if we change the fee requirement to bet at least:
MIN(
$ORIGINAL_FEE_RATE * $REPLACEMENT_TX_SIZE + $RELAY_FEE * ( REPLACEMENT_TX_SIZE + $ORIGINAL_SIZE),
$ORIGINAL_ABS_FEE / 3
) in fees
This could make it:
* More incentive compatible
* Support more use-cases (my transaction merging example)
* Be resistant to any attacks (that I can see, there's no doubt cases I haven't thought about)
-Ryan
-------- Original Message --------
On January 23, 2018 4:56 PM, Moral Agent <ethan.scruples at gmail.com> wrote:
> Another way to limit abuse would be to have the fee *rate* be required to increase, which is kind of the spirit of RBF, applied to this situation.
>
> That is to say, if you wished to replace transactions A and B with C which spends the same inputs as A and B, then the following must be true before C will be relayed:
>
> (Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight_C
>
> On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Getting back on topic:
>>
>>> It would definitely introduce DoS vectors by making it much cheaper to use
>>> relay bandwidth.
>>
>> I think I'm missing something, as I don't really understand this DoS vector. Relay bandwidth is already very cheap and easy to use by repeatedly fee bumping. And it's not obvious to me that requiring an absolute higher fee actually makes such an attack more expensive.
>>
>> I can see that my "proposed" change would make it cheaper to evict low-fee transactions from other node's mempool. Maybe I'm being naive, but I don't really see why this would be such a big deal.
>>
>> But what about a compromise, and require that the absolute fee must be >= half the original fees. I know everyone hates magic values, but I think in practice it will allow legitimate and useful use of "retroactive transaction merging" without much downside.
>>
>> And really the great thing about "retroactive transaction merging" is just how easy it is to implement. In fact, right now it's quite possible to do -- but because of the "higher absolute fee" rule the benefits are pretty muted (although if you can compress 2 change into 1, that's still likely worthwhile)
>>
>> -Ryan
>>
>> -------- Original Message --------
>> On January 22, 2018 3:00 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>>>
>>>> So my half-baked idea is very simple:
>>>> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>>>> This is currently not possible because of the bip125 rule:
>>>> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>>>> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>>>> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
>>>
>>> It would definitely introduce DoS vectors by making it much cheaper to use
>>> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>>>
>>>> ---------------------------------------------------------------
>>>> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>>>> From a "coin selection" point of view, this was significantly easier than
>>>> I had anticipated. I was able to encode the rules in my linear model and
>>>> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>>>> However, the real problem is tracking the mess. Consider this sequence of events:
>>>>
>>>> - I have unconfirmed transaction A
>>>> - I replace it with B, which pays John 1 BTC
>>>> - Transaction A gets confirmed
>>>> So now I still owe John 1 BTC, however it's not immediately clear if
>>>> it's safe to send to him without waiting $n transactions. However even
>>>> for a small $n, this breaks my promise to pay him immediately.
>>>> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>>>> However, this will only work <50% of the time for me (most transactions
>>>> don't have change) and opens a pandora's box of complexity.
>>>
>>> Most transactions don't have change?! Under what circumstance? For most
>>> use-cases the reverse is true: almost all all transactions have change, because
>>> it's rare for the inputs to exactly math the requested payment.
>>>
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/42431dec/attachment.html>

2023-06-07 18:09:56 UTC

- reply

📅 Original date posted:2018-01-23
📝 Original message:Getting back on topic:
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth.
I think I'm missing something, as I don't really understand this DoS vector. Relay bandwidth is already very cheap and easy to use by repeatedly fee bumping. And it's not obvious to me that requiring an absolute higher fee actually makes such an attack more expensive.
I can see that my "proposed" change would make it cheaper to evict low-fee transactions from other node's mempool. Maybe I'm being naive, but I don't really see why this would be such a big deal.
But what about a compromise, and require that the absolute fee must be >= half the original fees. I know everyone hates magic values, but I think in practice it will allow legitimate and useful use of "retroactive transaction merging" without much downside.
And really the great thing about "retroactive transaction merging" is just how easy it is to implement. In fact, right now it's quite possible to do -- but because of the "higher absolute fee" rule the benefits are pretty muted (although if you can compress 2 change into 1, that's still likely worthwhile)
-Ryan
-------- Original Message --------
On January 22, 2018 3:00 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
>> So my half-baked idea is very simple:
>> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>> ---------------------------------------------------------------
>>
>> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>> However, the real problem is tracking the mess. Consider this sequence of events:
>>
>> - I have unconfirmed transaction A
>> - I replace it with B, which pays John 1 BTC
>> - Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/aada91c2/attachment.html>

2023-06-07 18:09:56 UTC

- reply

📅 Original date posted:2018-01-22
📝 Original message:> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.
It's actually a common misconception. With good coin selection, I am able to avoid change about ~75% of the time in my simulations (on my real world data). In practice it's a bit lower, probably about 40-50% of the time because of the need to keep the majority of my funds offline where they can't be used for coin selection, and I have not been able to accurate simulate how I consolidate.
Also the other misconception is that inputs don't need to match exactly the requested payment, it's totally fine to do something I call a "miner sacrifice" where you overpay txfees up to the amount that that would otherwise be the total cost (immediate + consolidation) of creating change.
Also another trick I use, is something I call "output selection". If I have N queued non-time sensitive payments, I don't really need to send them all at the same time. So I can pick the best combination of inputs+outputs.
Obviously none of this applies to consumer wallets, who typically have less than a handful of options. But for a service, avoiding change can be the norm with good coin selection.
---
-Ryan
-------- Original Message --------
On January 22, 2018 3:00 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
>> So my half-baked idea is very simple:
>> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>> ---------------------------------------------------------------
>>
>> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>> However, the real problem is tracking the mess. Consider this sequence of events:
>>
>> - I have unconfirmed transaction A
>> - I replace it with B, which pays John 1 BTC
>> - Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/1abc39e2/attachment.html>

2023-06-07 18:09:55 UTC

- reply

📅 Original date posted:2018-01-22
📝 Original message:So my half-baked idea is very simple:
Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
This is currently not possible because of the bip125 rule:
"The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
---
Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
From a "coin selection" point of view, this was significantly easier than
I had anticipated. I was able to encode the rules in my linear model and
feed in all my unspent and in-flight transactions and it can solve it without difficulty.
However, the real problem is tracking the mess. Consider this sequence of events:
1) I have unconfirmed transaction A
2) I replace it with B, which pays John 1 BTC
3) Transaction A gets confirmed
So now I still owe John 1 BTC, however it's not immediately clear if
it's safe to send to him without waiting $n transactions. However even
for a small $n, this breaks my promise to pay him immediately.
One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
However, this will only work <50% of the time for me (most transactions
don't have change) and opens a pandora's box of complexity.
There's a few other hacks you can do to make it work in a few more cases, but nothing that is realistic to expect anyone to implement any time soon.
However, if there was a straight foward way to merge N unconfirmed transactions, it would be easy get into production, and potentially offer some pretty nice savings for everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/75c4190e/attachment.html>

2023-06-07 18:09:06 UTC

- reply

📅 Original date posted:2017-12-31
📝 Original message:The key to understanding how it works is to stop thinking in terms of a block size limit, but rather a block weight limit. 1 byte of witness data counts as 1 weight, the rest counts for 4 weight. A block must be less than 4 million weight. There's no separate limits at all, so any saving in the witness space (e.g. through signature aggregation) is useful for both witness/non-witness data.
-Ryan
> -------- Original Message --------
> Subject: [bitcoin-dev] Single signature for all transactions in a block?
> Local Time: December 31, 2017 5:39 PM
> UTC Time: December 31, 2017 11:39 PM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> I had a question relating to scaling and privacy enhancements.
> I believe that segwit combined with aggregated signatures
> and coinjoin can potentially achieve such. The idea is to
> use aggregated signatures in conjunction with coinjoin. So
> that all inputs of a coinjoin transaction would have a single
> signature vastly decreasing size while having privacy at the
> same time. If majority of transactions in a block did this I
> assume that significant more transactions could be fit into a
> block? However the question I have, with the extra blockspace
> made possible by segwit, is this extra blockspace limited to only
> witness data or can it be used for transaction data such as the
> scenario I have described here?
>
> ---------------------------------------------------------------
>
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon at cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJaSXSNAAoJEAYDai9lH2mwRy4QAMqhl6UWNqRy7ziDuxukm+nZ
> jWtjyc8G38b9r9Nya13/GslHWeEDdSmma6e7afFMVX1y9Qj+t0EZDJVlMMy8JRZr
> zDmSdXDxStNv6T+L3NVbSOBhdP+1MpcsvAAs3yd0Nl5cxfBF87ArHlXMbTLJF86S
> 1gijI4pg3x83tDg/Di6gf9BHk2oXGDc4vraF6LsMDTfQmp7S8pivnswaaEyb6etH
> 39ei6L3wkV7LvTmA2onCAB8vZtTuARhNuLTYSPfH5LAC4hha2bOCXci3p4Mz4qh3
> U4LqUnuYVR8nYOFFsrfhKggN3kptVWhrbDAoHR2fLoYDmfbMkqUdyjdmmc2Rvlgm
> eMJvpG91dYb+Q6JqTrar6DH+XSvoOVSWnBLe8Uwf4AnzGxMUpkTDzkyaBxGq4K1u
> Vv2Yg808KwA47MKKpvKSckB350YAq9Cr276Lq/giUrxmS1gOyDKDjm1e3yFLM+6d
> NancAwgnp17q43FwSX44cT0ISxk9USnWVhaKDQjSGK8MnirkZ1vuu2SshEW1AVhm
> 44Bt5nQdLmJDw7rqwkjv66sxofXvmCAnPD+p4yiVyfLNZ7OKw6XNcKm3zKAch2Fy
> fefWbZnw0yEA3IhNPiMZOSv/YnwTtfzpFUNuTCtLehs+3Xkp0bl72JDz0HRVYbHM
> RbsrLp60rD5kuJBq5dl7
> =3gku
> -----END PGP SIGNATURE-----
> ---------------------------------------------------------------
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171231/3562c354/attachment.html>

2023-06-07 18:08:44 UTC

- reply

📅 Original date posted:2017-12-15
📝 Original message:I don't have anything interesting to add, except that I have been using 'bits' on my site for over 3 years. It's a great unit that people quickly adapt to, and it's far more convenient. When dealing with large amounts of money, people have no problem naturally thinking in "thousand bits" or "million bits" (a bitcoin).
I would highly encourage it to be a default everywhere. Consistency is really important.
Also slightly unrelated, but the whole "sat/B" thing for fees is such a clusterfuck. Half the time it's used as "vbyte" and half the time actual bytes. Users are constantly confused because of explorers and wallet and stuff all showing it inconsistently. I would suggest there that there is a "standard" of "bits per kiloweight" (i.e. how many bits of fees to pay for a transaction that is 1000 weight)
-Ryan
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination
> Local Time: December 15, 2017 12:20 PM
> UTC Time: December 15, 2017 6:20 PM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Marcel Jamin <marcel at jamin.net>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
>>Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the >correct< approach. It's tidy, systematic and precise.
>
> The SI system is great, but it's nice if you pick a base unit that is easy for intuition to comprehend.
>
> It is a fact that I weigh approximately .000,000,000,000,000,000,000,014 Earth masses. If we arrived at rough consensus that this was a cumbersome way to express the mass of a human, we might then find a group of people making the superficially sensible proposal that we use SI prefixes and say I weigh 14 yoctoearths. This would be tidy, systematic and precise, but that might not be enough to make it the best option. It might be even better to choose a base unit that human intuition can make sense of, and THEN add prefixes as needed.
>
> I dislike the name "bits" but I think 100 satoshis does make a nice base unit. If we cannot crowdsource a more inspiring label we may be stuck with bits just due to linguistic network effects.
>
> -Ethan
>
> On Fri, Dec 15, 2017 at 1:27 AM, Marcel Jamin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think one could make the argument that the only people who talk
>> about and understand 24 bit audio or 256 bit cryptography are the ones
>> who can tell the difference very easily.
>>
>> To me, your example seems to try hard to make the case for a problem
>> that won't exist in reality.
>>
>> Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the
>>>correct< approach. It's tidy, systematic and precise. But that won't
>> stop people from using something that's easier to deal with as I just
>> had to google the µ character again.
>>
>> Let's also keep in mind that Coinbase has been using "bits" as the
>> default for over 2 years now:
>> https://blog.coinbase.com/bits-is-the-new-default-and-all-new-users-get-100-bits-for-free-9165f757594b
>>
>> Just from a linguistic standpoint, chances are we'll end up with bits
>> anyway. Why fight it? We don't have a SI prefix educational mandate.
>>
>> Marcel
>>
>> On 14 December 2017 at 23:01, Natanael <natanael.l at gmail.com> wrote:
>>>
>>> Reposting /u/BashCo's post on reddit here, for visibility:
>>>
>>> ---8<---------------------------------------------------------------
>>>
>>>> Before anyone says 'bits' are too confusing because it's a computer
>>>> science term, here's a list of homonyms
>>>> [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every
>>>> day. Homonyms are fine because our brains are able to interpret language
>>>> based on context, so it's a non-argument.
>>>
>>>
>>> This ignores the fact that there exists multiple meanings of bits *within
>>> the same context*, and that beginners likely can't tell them apart.
>>>
>>> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
>>> value with somebody who doesn't understand Bitcoin. Then explain that the
>>> cryptography uses 256 bit keys. I would be surprised if you could find
>>> somebody who would not be confused by that.
>>>
>>> Let's say a website says a song is 24 bits. Was that 24 bit audio resolution
>>> or 24 bit price? Somebody writes about 256 bit keys, are that their size or
>>> value?
>>>
>>> You guys here can probably tell the difference. Can everybody...? Bits will
>>> cause confusion, because plenty of people will not be able to tell these
>>> apart. They will not know WHEN to apply one definition or the other.
>>>
>>> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171215/375ec903/attachment.html>

2023-06-07 18:08:23 UTC

- reply

📅 Original date posted:2017-12-15
📝 Original message:> I understand that there would be technical issues to resolve in implementation, but, are there no fundamental errors?
Unfortunately your proposal is really fundamentally broken, on a few levels. I think you might need to do a bit more research into how bitcoin works before coming up with such improvements =)
But just some quick notes:
* Every node has a (potentially) different mempool, you can't use it to decide consensus values like the max block size.
* Increasing the entropy in a block to make it more unpredictable doesn't really make sense.
* Bitcoin should be roughly incentive compatible. Your proposal explicits asks miners to ignore their best interests, and confirm transactions by "priority". What are you going to do if a "malicious" miner decides to go after their profits and order by what makes them the most money. Add "ordered by priority" as a consensus requirement? And even if you miners can still sort their mempool by fee, and then order the top 1MB by priority.
If you could find a good solution that would allow you to know if miners were following your rule or not (and thus ignore it if it doesn't) then you wouldn't even need bitcoin in the first place.
-Ryan
> -------- Original Message --------
> Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks
> Local Time: December 15, 2017 3:42 AM
> UTC Time: December 15, 2017 9:42 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
> I should not take it that the lack of critical feedback to this revised proposal is a glowing endorsement. I understand that there would be technical issues to resolve in implementation, but, are there no fundamental errors?
>
> I suppose that it if is difficult to determine how long a transaction has been waiting in the pool then, each node could simply keep track of when a transaction was first seen. This may have implications for a verify routine, however, for example, if a node was offline, how should it differentiate how long each transaction was waiting in that case? If a node was restarted daily would it always think that all transactions had been waiting in the pool less than one day If each node keeps the current transaction pool in a file and updates it, as transactions are included in blocks and, as new transactions appear in the pool, then that would go some way to alleviate the issue, apart from entirely new nodes. There should be no reason the contents of a transaction pool files cannot be shared without agreement as to the transaction pool between nodes, just as nodes transmit new transactions freely.
>
> It has been questioned why miners could not cheat. For the question of how many transactions to include in a block, I say it is a standoff and miners will conform to the proposal, not wanting to leave transactions with valid fees standing, and, not wanting to shrink the transaction pool. In any case, if miners shrink the transaction pool then I am not immediately concerned since it provides a more efficient service. For the question of including transactions according to the proposal, I say if it is possible to keep track of how long transactions are waiting in the pool so that they can be included on a probability curve then it is possible to verify that blocks conform to the proposal, since the input is a probability, the output should conform to a probability curve.
>
> If someone has the necessary skill, would anyone be willing to develop the math necessary for the proposal?
>
> Regards,
> Damian Williamson
>
> ---------------------------------------------------------------
>
> From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Damian Williamson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Friday, 8 December 2017 8:01 AM
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks
>
> Good afternoon,
>
> The need for this proposal:
>
> We all must learn to admit that transaction bandwidth is still lurking as a serious issue for the operation, reliability, safety, consumer acceptance, uptake and, for the value of Bitcoin.
>
> I recently sent a payment which was not urgent so; I chose three-day target confirmation from the fee recommendation. That transaction has still not confirmed after now more than six days - even waiting twice as long seems quite reasonable to me. That transaction is a valid transaction; it is not rubbish, junk or, spam. Under the current model with transaction bandwidth limitation, the longer a transaction waits, the less likely it is ever to confirm due to rising transaction numbers and being pushed back by transactions with rising fees.
>
> I argue that no transactions are rubbish or junk, only some zero fee transactions might be spam. Having an ever-increasing number of valid transactions that do not confirm as more new transactions with higher fees are created is the opposite of operating a robust, reliable transaction system.
>
> Business cannot operate with a model where transactions may or may not confirm. Even a business choosing a modest fee has no guarantee that their valid transaction will not be shuffled down by new transactions to the realm of never confirming after it is created. Consumers also will not accept this model as Bitcoin expands. If Bitcoin cannot be a reliable payment system for confirmed transactions then consumers, by and large, will simply not accept the model once they understand. Bitcoin will be a dirty payment system, and this will kill the value of Bitcoin.
>
> Under the current system, a minority of transactions will eventually be the lucky few who have fees high enough to escape being pushed down the list.
>
> Once there are more than x transactions (transaction bandwidth limit) every ten minutes, only those choosing twenty-minute confirmation (2 blocks) will have initially at most a fifty percent chance of ever having their payment confirm. Presently, not even using fee recommendations can ensure a sufficiently high fee is paid to ensure transaction confirmation.
>
> I also argue that the current auction model for limited transaction bandwidth is wrong, is not suitable for a reliable transaction system and, is wrong for Bitcoin. All transactions must confirm in due time. Currently, Bitcoin is not a safe way to send payments.
>
> I do not believe that consumers and business are against paying fees, even high fees. What is required is operational reliability.
>
> This great issue needs to be resolved for the safety and reliability of Bitcoin. The time to resolve issues in commerce is before they become great big issues. The time to resolve this issue is now. We must have the foresight to identify and resolve problems before they trip us over. Simply doubling block sizes every so often is reactionary and is not a reliable permanent solution. I have written a BIP proposal for a technical solution but, need your help to write it up to an acceptable standard to be a full BIP.
>
> I have formatted the following with markdown which is human readable so, I hope nobody minds. I have done as much with this proposal as I feel that I am able so far but continue to take your feedback.
>
> # BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks
>
> ## The problem:
> Everybody wants value. Miners want to maximize revenue from fees (and we presume, to minimize block size). Consumers need transaction reliability and, (we presume) want low fees.
>
> The current transaction bandwidth limit is a limiting factor for both. As the operational safety of transactions is limited, so is consumer confidence as they realize the issue and, accordingly, uptake is limited. Fees are artificially inflated due to bandwidth limitations while failing to provide a full confirmation service for all transactions.
>
> Current fee recommendations provide no satisfaction for transaction reliability and, as Bitcoin scales, this will worsen.
>
> Bitcoin must be a fully scalable and reliable service, providing full transaction confirmation for every valid transaction.
>
> The possibility to send a transaction with a fee lower than one that is acceptable to allow eventual transaction confirmation should be removed from the protocol and also from the user interface.
>
> ## Solution summary:
> Provide each transaction with an individual transaction priority each time before choosing transactions to include in the current block, the priority being a function of the fee paid (on a curve), and the time waiting in the transaction pool (also on a curve) out to n days (n=60 ?). The transaction priority to serve as the likelihood of a transaction being included in the current block, and for determining the order in which transactions are tried to see if they will be included.
>
> Use a target block size. Determine the target block size using; current transaction pool size x ( 1 / (144 x n days ) ) = number of transactions to be included in the current block. Broadcast the next target block size with the current block when it is solved so that nodes know the next target block size for the block that they are building on.
>
> The curves used for the priority of transactions would have to be appropriate. Perhaps a mathematician with experience in probability can develop the right formulae. My thinking is a steep curve. I suppose that the probability of all transactions should probably account for a sufficient number of inclusions that the target block size is met although, it may not always be. As a suggestion, consider including some zero fee transactions to pad, highest BTC value first?
>
> **Explanation of the operation of priority:**
>> If transaction priority is, for example, a number between one (low) and one-hundred (high) it can be directly understood as the percentage chance in one-hundred of a transaction being included in the block. Using probability or likelihood infers that there is some function of random. If random (100) < transaction priority then the transaction is included.
>
>>To break it down further, if both the fee on a curve value and the time waiting on a curve value are each a number between one and one-hundred, a rudimentary method may be to simply multiply those two numbers, to find the priority number. For example, a middle fee transaction waiting thirty days (if n = 60 days) may have a value of five for each part (yes, just five, the values are on a curve). When multiplied that will give a priority value of twenty-five, or, a twenty-five percent chance at that moment of being included in the block; it will likely be included in one of the next four blocks, getting more likely each chance. If it is still not included then the value of time waiting will be higher, making for more probability. A very low fee transaction would have a value for the fee of one. It would not be until near sixty-days that the particular low fee transaction has a high likelihood of being included in the block.
>
> I am not concerned with low (or high) transaction fees, the primary reason for addressing the issue is to ensure transactional reliability and scalability while having each transaction confirm in due time.
>
> ## Pros:
> * Maximizes transaction reliability.
> * Fully scalable.
> * Maximizes possibility for consumer and business uptake.
> * Maximizes total fees paid per block without reducing reliability; because of reliability, in time confidence and overall uptake are greater; therefore, more transactions.
> * Market determines fee paid for transaction priority.
> * Fee recommendations work all the way out to 30 days or greater.
> * Provides additional block entropy; greater security since there is less probability of predicting the next block.
>
> ## Cons:
> * Could initially lower total transaction fees per block.
> * Must be first be programmed.
>
> ## Solution operation:
> This is a simplistic view of the operation. The actual operation will need to be determined in a spec for the programmer.
>
> 1. Determine the target block size for the current block.
> 2. Assign a transaction priority to each transaction in the pool.
> 3. Select transactions to include in the current block using probability in transaction priority order until the target block size is met.
> 5. Solve block.
> 6. Broadcast the next target block size with the current block when it is solved.
> 7. Block is received.
> 8. Block verification process.
> 9. Accept/reject block based on verification result.
> 10. Repeat.
>
> ## Closing comments:
> It may be possible to verify blocks conform to the proposal by showing that the probability for all transactions included in the block statistically conforms to a probability distribution curve, *if* the individual transaction priority can be recreated. I am not that deep into the mathematics; however, it may also be possible to use a similar method to do this just based on the fee, that statistically, the blocks conform to a fee distribution. Any zero fee transactions would have to be ignored. This solution needs a clever mathematician.
>
> I implore, at the very least, that we use some method that validates full transaction reliability and enables scalability of block sizes. If not this proposal, an alternative.
>
> Regards,
> Damian Williamson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171215/4158a992/attachment-0001.html>

2023-06-07 18:03:46 UTC

- reply

📅 Original date posted:2017-07-02
📝 Original message:==Abstract==
BIP125 allows transactions to opt into replaceability with a primary use case
of allowing users to increase the fees of unconfirming transactions, helping create
a more efficient fee market place.
However this goal is hindered when the receiver of a transaction spends from the
unconfirmed output, which exposes the sender to the awkward position of needing
to pick between needing to pay an effectively unbounded amount of money as per the BIP125 rules, or not fee bump at all.
This is especially problematic in the case of batched sends in which there are
multiple independent receivers. In practice this means wallets and services can not effectively low ball the fee of transactions, with the intention of fee bumping due to the risk of the receiver spending or sweeping it before it confirms.
In order to support a healthy fee marketplace, this proposal aims to increase
the utility of bip125 by making transactions that spend an unconfirmed BIP125
output non-standard.
==Summary==
This policy specifies a max chain depth of 1 for any BIP125 transactions.
==Impact==
Receivers of BIP125 transactions will need to wait until the transaction
has confirmed before spending from it. This will not be significantly different
than it is currently as they receivers need to be monitoring for replacements.
If senders want to make further transactions before the BIP125 transaction confirms,
and need to utilize the change of the transaction: they will need to replace the
transaction with a one that makes the other send in "pass through" style or first
finalize the BIP125 transaction and then chain from the spend normally.
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170702/4e901484/attachment.html>