Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

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  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

>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@lists.linuxfoundation.org> wrote:
>>On Tue, Jan 23, 2018 at 10:49:34PM +, Gregory Maxwell via bitcoin-dev 
>>wrote:
>> > On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>> > <bitcoin-dev@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@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 2 step confirmation system

[Rhavar via bitcoin-dev]

1. Bitcoin addresses contain a "checksum", which means it's pretty much 
impossible to fat finger any address. (Note: most altcoins don't seem to do 
this, so fat-fingering is very much a risk). If you can send to an address, you 
can be sure there is no mistake.

However, there is a real risk of malware. I see on a daily basis people who 
send to the *wrong* address, because for example they have malware on their 
computer which replaces a the intended address with one controlled by the 
malware author. So verifying you are sending to the correct address is very 
much still a concern, but there's no risk you type a 2 instead of 3 and send to 
the wrong place.

2.  Google "bitcoin multisig" and "bitcoin escrow". In the core bitcoin 
protocol there's a lot of support that enables stuff like that -- but nothing 
that is really commonly used. I've done some very large deals with bitcoin, 
with the use of "2 of 3 multisig" (basically 2 of: me, counter-party, 
arbitrator)  need to sign off on it. However it's a big pain in the ass, with 
poor tooling and expensive transactions. Unless you're dealing with 100+ 
bitcoin, it's a lot easier for everyone to just use a trusted (single party) 
escrow.

-Ryan

 Original Message 
On January 23, 2018 7:42 PM, rmcc via bitcoin-dev 
 wrote:

> I know from speaking to my friends not involved with Bitcoin that two of 
> their major concerns are as follows:
>
> 1. They are afraid if they fat finger the address there is nothing they can 
> do about it and not get their Bitcoin back.
>
> and/or
>
> 2. They would like to at least have the option to use some sort of 2 step 
> confirmation system when dealing ith people they do not know. For example, 
> after sending the Bitcoin to a seller they would like to be able to do a 
> final approval of the tm transaction. If the 2 people involved in the 
> transaction approve of it within X hours, the coin returns to the original 
> person. This system would basically act as an escrow.
>
> This 2 step system could work with both of these.
>
> I apologize if this is the incorrect place to post this. I did not know where 
> else to share these thoughts.
>
> Thanks for your time.
>
> --
>
> ** This message was likely sent using voice to text. Please ignore any 
> typos.**___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

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.scrup...@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@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 <p...@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 
>&

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

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 <p...@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

> 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 <p...@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

> 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.scrup...@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@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 <thealanev...@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@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 
>&g

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

> 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 <thealanev...@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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

[Rhavar via bitcoin-dev]

I think you're under-appreciating how useful the "plausible deniability". 
Someone I know was (solo) traveling to the United States when a border agent 
asked her to unlocked her phone; thumbed through her apps, ended up finding 
tinder and went through all her recent conversations to make sure she wasn't 
involved in any "pay for sex things".

In the same light, I travel frequently and constantly have my trezor on me. If 
I am asked to unlock it, I will have no problems doing so (as refusal will no 
doubt lead to deportation) and showing my personal wallet (which sadly hasn't 
had much use since fees became ridiculous).

And by doing so, I won't be revealing the half a dozen other accounts I keep. 
Which is the other big of such "plausible deniability" schemes, they make it 
trivial to create multiple wallets that are all firewalled away from each other.

I will hypothesize that if one of my wallets was for something like buying 
stuff on dark markets there's simply no way anyone is going to ever know way 
you're going to be to tell short of some movie-plot level police effort. 



​-Ryan

​

> Original Message 
>Subject: Re: [bitcoin-dev] Satoshilabs secret shared private key scheme
>Local Time: January 8, 2018 5:47 PM
>UTC Time: January 8, 2018 11:47 PM
>From: bitcoin-dev@lists.linuxfoundation.org
>To: Pavol Rusnak 
>Bitcoin Protocol Discussion 
>
>On Mon, Jan 8, 2018 at 12:39 PM, Pavol Rusnak st...@satoshilabs.com wrote:
>>On 08/01/18 05:22, Gregory Maxwell wrote:
https://github.com/satoshilabs/slips/blob/master/slip-0039.md
Hey Gregory!
>>Thanks for looking into the scheme. I appreciate your time!
>>>This specification forces the key being used through a one way
>>> function, -- so you cannot take a pre-existing key and encode it with
>>> this scheme.
>>>Originally, we used a bi-directional function to be able to encode and
>> decode the key in both directions using the passphrase. We stretched the
>> passphrase using KDF and then applied AES or other symmetric cipher
>>We found the following (theoretical) problem:
>>If an attacker has knowledge of few words from the beginning of shares,
>> they are able to reconstruct the beginning of the master secret and if
>> the size of the reconstruced master secret is bigger then the cipher
>> blocksize (for block ciphers; for stream ciphers 1 bit is enough), then
>> they can reconstruct the beginning of the seed.
>>Can you find a scheme which does not have this problem? Or you think
>> this problem is not worth solving?
>>
> You can use a large block cipher. E.g. CMC cipher mode.
>
> Though I am doubtful that this is a very relevant concern: What
> consequence is it if someone with partial access to more than a
> threshold of the shares can recover part of the seed?  This doesn't
> seem like a very interesting threat.   A large block mode would be
> more complete, but this isn't something that would keep me up at night
> in the slightest.
>
> Perhaps I'm missing something, -- but the only real attack I see here
> is that a enduser mistakenly shows the first or couple words of all
> their shares on national television or what not... but doing so would
> not really harm their security unless they showed almost all of them,
> and in that case an attacker could simply search the remaining couple
> words.
>
> Also, if we are going to assume that users will leak parts, the
> mnemonic encoding ends up being pretty bad... since just leaking a
> letter or two of each word would quite likely give the whole thing
> away.
>
> In any case, to whatever extent partial leaks are a concern, using a
> large block cipher would be the obvious approach.
>
>>Yes. We want this to be possible to be computed on TREZOR-like devices
>> on boot, similarly how we compute BIP39 on boot right now.
>>
> Under this constraint it might be arguably to just eliminate the KDF.
> I think it provides false security and makes the implementation much
> more complicated.
>
> Have you considered using blind host-delegated KDFs, where the KDF
> runs on the user's computer instead of the hardware wallet, but the
> computer doesn't learn anything about they keys?
>
>>Again, this is by design and it is main point why plausible deniability
>> is achieved both in BIP39 and SLIP39. If we used a different
>> construction we'd loose plausible deniability.
>>
> I don't believe you can justify this design decision with any kind of
> rigorous threat model.
>
> The probability that a user loses funds because they have at some
> point recovered with the wrong key and don't know it would almost
> certainly dwarf the probability that the user face some kind of
> movie-plot threat where someone is attempting to forcibly extract a
> key and yet somehow has no information about the user's actual
> wallet-- through, for example, leaked data on the users computers, the
> users past payments to online accounts, or through a compromise or

Re: [bitcoin-dev] Single signature for all transactions in a block?

[Rhavar via bitcoin-dev]

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@lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion 
>
> -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: can...@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination

[Rhavar via bitcoin-dev]

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@lists.linuxfoundation.org
> To: Marcel Jamin , Bitcoin Protocol Discussion 
> 
>
>>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 
>  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  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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list

Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

[Rhavar via bitcoin-dev]

> 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@lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion 
>
> 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-boun...@lists.linuxfoundation.org 
>  on behalf of Damian 
> Williamson via bitcoin-dev 
> Sent: Friday, 8 December 2017 8:01 AM
> To: bitcoin-dev@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 

Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions

[Rhavar via bitcoin-dev]

Thanks Andreas, that's actually a pretty good use-case I didn't think of.
Perhaps you could make the rule: "To spend from an unconfirmed BIP125 output, 
the transaction feerate needs to be higher than its unconfirmed parent's 
effective feerate."
It doesn't totally solve the problem, but I think in practice would do a good 
job (most of the problematic descendants tends to be low feerate sweeps). It 
would also preserve the ability for receivers to use CPFP if they wish.

-Ryan

>  Original Message 
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable 
> transactions
> Local Time: July 4, 2017 6:50 AM
> UTC Time: July 4, 2017 11:50 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
> Your BIP would take away the only way the *receiver* has to raise the
> fee: CPFP. And the receiver is arguably the more important party in this
> question. After all the sender has no real incentive for his payment to
> be confirmed; it"s receiver who has.
> On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote:
>> ==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
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions

[Rhavar via bitcoin-dev]

> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.

It actually doesn't really matter much.
Let's say I want to pay Alice and Bob (unrelated entities), so I send it to 
them (together) with a low-fee transaction of paying 50 sat/byte. After an hour 
it's obvious that it's not confirmed (maybe there was a big backlog, or no 
blocks mined), so I want to replace my small transaction with one that pays 70 
sat/byte.
But in the mean time, Alice has swept her wallet (or used a service that has 
done so) and generated 50KB of descendant transactions paying 40 sat/byte (i.e. 
total fees of 0.02 BTC or $50).
According to the BIP125 rules, I would need to pay for the cost of invalidating 
all the transactions (an absolute higher amount of fee) along with the replay 
cost of the descendant transactions.
So in this case, for me to fee bump the transaction I'm looking at throwing 
away $50 because of descendant transactions that were totally out of my 
control. If I don't fee bump, I violate my promise to Bob to pay in a timely 
manner (and also probably Alice, as it wasn't in her control she was using an 
exchange that did this).
If I guarantee to fee bump, the amount I risk is effectively unbounded. And 
even if the descendant transactions have a higher fee rate, and are assisting 
by CPFP boosting my transaction -- it very well might not be enough.
--
The idea of this proposal comes from the problems *in practice* of trying to 
low-ball fee estimation with scheduled continuous fee bumps until it confirms. 
At the moment it's not viable, but if this proposal was adopted then it would 
be.
Personally I think it's of critical piece of having a stable fee market. Fee 
estimation is a fools game, even the new and improved fee estimation in master 
today was suggesting x30 fees to what was required (and I successfully made 
transactions with). People (and especially services) being able to be able to 
dynamically increase their fees sanely when dealing with withdrawals (and 
especially batched ones) will go a long way to helping the overall ecosystem.

-Ryan

>  Original Message 
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable 
> transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> From: g...@xiph.org
> To: Rhavar 
> bitcoin-dev@lists.linuxfoundation.org 
> On Sun, Jul 2, 2017 at 9:01 PM, Rhavar  wrote:
>> That"s not really realistic. In practice some receivers do big sweeps and
>> include unconfirmed inputs. Replacing the transaction means you need to pay
>> the cost of the sweep, which you probably don"t want to do (can be in the
>> order of $100s of dollars).
> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: No chaining off replaceable transactions

[Rhavar via bitcoin-dev]

> I don"t really see how this is desirable: Just replace it-
That's not really realistic. In practice some receivers do big sweeps and 
include unconfirmed inputs. Replacing the transaction means you need to pay the 
cost of the sweep, which you probably don't want to do (can be in the order of 
$100s of dollars).
> Beyond being paternalistic the issue I see with your proposal is thatits 
> contrary to miner income
This applies to pretty much all non-standard transactions.

-Ryan

>  Original Message 
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable 
> transactions
> Local Time: July 2, 2017 3:56 PM
> UTC Time: July 2, 2017 8:56 PM
> From: g...@xiph.org
> To: Rhavar <rha...@protonmail.com>
> bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linuxfoundation.org>
> On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> ==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.
> I don"t really see how this is desirable: Just replace it-- the
> receiver foolishly spent it at its own peril, spending a unconfirmed
> payment from a third party is something that Core never does, it"s
> reckless unless you"re doing something like CPFPing it to yourself,
> which is harmless (either it"ll work, or it"ll fail and you"ll be fine
> with that).
> Beyond being paternalistic the issue I see with your proposal is that
> its contrary to miner income-- you"re asking miners to ignore these
> spends that otherwise they could accept. This seems unstable-- some
> people would ignore your rule even if it were otherwise widely
> adopted, leading to the network behavior having higher volatility.
> Instead, perhaps a BIP that very strongly advises parties to not spend
> unconfirmed outputs from third parties while making a payment to third
> parties would achieve your end?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP proposal: No chaining off replaceable transactions

[Rhavar via bitcoin-dev]

==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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev