Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun via bitcoin-dev]

Hi Hiroki,

(inserting the bitcoin-dev mailing list as this question is mainly
concerning on-chain interaction)

Thanks for taking the time to really dig into things!

> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs without gaps from
> the genesis transaction of the asset to the current location

> It is necessary to prove and verify that “the UTXO has not changed” at
> that point.

Correct!

> As far as I can see, the specs don't mention it.

You're correct that today the main BIP draft focuses mainly on transfers [1]
to specify how exactly an asset moves from one output to another. The
requirement that a "no-op" state transition also be created/verified is an
implicit assumption in the current spec that we aim to remedy. The current
alpha code [2] is a bit ahead of the spec, but we aim to start to catch up
the spec, and also begin to add test vectors now that we have a working
implementation.

> The proofs for directly proving that a UTXO has not changed are its
> inclusion proof in the input asset tree and its inclusion and
> non-inclusion proofs in each of the output asset trees

Correct, the set of inclusion and non-inclusion proofs necessary for a valid
state transition are currently documented in `bip-taro-proof-file.md` [3].
We've also made a few updates to the proof file format to properly include a
field for the inclusion proof of a split asset's _root_ asset. This allows
verifiers to properly verify the authenticity of the split (root is in the
transaction, uniquely, which commits to the split, which has a proof
anchored in that spit root).

> Instead, it's better to set a constraint that no part of the asset tree
> except the explicitly changed UTXOs should change, and verify that.

Interesting, so rather than present/maintain a distinct state transition for
each asset unaffected, you propose that instead we present a _single_ proof
for all non-modified assets that shows that a sub-tree/branch is unchanged?
That's a very cool idea.

Generally we have a lot of low hanging fruits re optimizing the proof file
format itself. As an example, all assets in a tree will share the same
Bitcoin-level proof prefix (merkle proof and block header of the anchor
transaction), but the spec/implementation will currently duplicate those
values several times over for each asset. If we go down another level, then
the main inclusion proof for an asset ID tree is also duplicated for each
asset sharing that asset ID.

Restating things a bit: right now proofs are oriented from the PoV of an
asset leaf in question. Instead, if we zoom out a bit and orient them at the
_taproot output_ level, then we can remove a lot of redundant data in the
current proof format, then sort of "prune" the output level proof to
generate a proof for a single leaf.

-- Laolu

[1]:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki#asset-transfers
[2]: https://github.com/lightninglabs/taro
[3]:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki#specification

On Fri, Oct 7, 2022 at 2:33 AM Hiroki Gondo  wrote:

> Hi Laolu,
>
> I've read Taro's specs, but I'm afraid there's not enough verification of
> the provenance of the asset UTXOs.
>
> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs without gaps from
> the genesis transaction of the asset to the current location. At some point
> in the transaction, the target UTXO itself may not change (only changes to
> other assets or other UTXOs in the asset tree). It is necessary to prove
> and verify that “the UTXO has not changed” at that point. As far as I can
> see, the specs don't mention it.
>
> Without this validation, asset inflation (double spending) is possible. In
> a transaction, there is a UTXO in the input asset tree. If this UTXO does
> not change in this transaction, it will remain in the output asset tree.
> However, if a full copy of this UTXO is illicitly created in the asset tree
> of another output, the asset will be inflated (even duplicating the lowest
> MS-SMT entirely). Both UTXOs will arbitrarily claim to be the same as the
> input UTXO.
>
> The proofs for directly proving that a UTXO has not changed are its
> inclusion proof in the input asset tree and its inclusion and non-inclusion
> proofs in each of the output asset trees. However, generating these proofs
> for every unchanging UTXO present in the input asset tree when a
> transaction occurs may not be very practical. Instead, it's better to set a
> constraint that no part of the asset tree except the explicitly changed
> UTXOs should change, and verify that.
>
> Please let me know if I'm wrong or have overlooked any specs. Also, let me
> know if there's anything about this that hasn't been mentioned in the specs
> yet.
>
> –
> Hiroki Gondo
>
>
> 2022年4月6日(水) 0:06 Olaoluwa Osuntokun :
>
>> Hi y'all,
>>
>> I'm excited 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning

[Antoine Riard via bitcoin-dev]

Hi Greg,

Thanks for proposing forward the "ephemeral anchors" policy change.

> In Gloria's proposal for ln-penalty, this is worked
> around by reducing the number of anchors per commitment transaction to 1,
> and each version of the commitment transaction has a unique party's key on
> it. The honest participant can spend their version with their anchor and
> package RBF the other commitment transaction safely.

IIRC, here I think we also need _package relay_ in strict addition of
_package RBF_, otherwise if your Lightning transactions are still relayed
and accepted one by one, your version of the commitment transaction won't
succeed to replace the other counterparties's commitments sleeping in
network mempools. The presence of a remote anchor output on the
counterparty commitment still offers an ability to fee-bump, albeit in
practice more a lucky shot as you might have partitioned network mempools
between your local commitment and the remote commitment disputing the spend
of the same funding UTXO.

> 1) Expand a carveout for "sibling eviction", where if the new child is
> paying "enough" to bump spends from the same parent, it knocks its sibling
> out of the mempool and takes the one child slot. This would solve it, but
> is a new eviction paradigm that would need to be carefully worked through.

Note, I wonder about the robustness of such a "sibling eviction" mechanism
in the context of multi-party construction. E.g, a batching payout, where
the participants are competing to each other in a blind way, as they do
want their CPFPs paying back to them to confirm first, enforcing their
individual liquidity preferences. I would think it might artificially lead
the participants to overbid far beyond the top mempool block fees.

>  If we allow non-zero value in ephemeral outputs, does this open up a MEV
>  we are worried about? Wallets should toss all the value directly to fees,
>  and add their own additional fees on top, otherwise miners have incentive
>  to make the smallest utxo burn transaction to claim those funds. They
just
>  confirmed your parent transaction anyways, so do we care?

If we allow non-zero value in ephemeral outputs, I think we're slightly
modifying the incentives games of the channels counterparties, in the sense
if you have a link Alice-Bob, Bob could circular loop a bunch of dust
offered HTLC deduced from Alice balance and committed as fees in the
ephemeral output value, then break the channel on-chain to pocket in the
trimmed value sum (in the limit of your Lightning implementation dust
exposure). Note, this is already possible today if your counterparty is a
miner however iiuc the proposal, here we're lowering the bar.

>  SIGHASH_GROUP like constructs would allow uncommitted ephemeral anchors
>  to be added at spend time, depending on spending requirements.
>  SIGHASH_SINGLE already allows this.

Note, with SIGHASH_GROUP, you're still allowed to aggregate in a single
bundle multiple ln-penalty commitments or eltoo settlement transactions,
with only one fee-bumping output. It's a cool space performance trick, but
a) I think this is still more a whiteboard idea than a sound proposal and
b) sounds more a long-term, low-hanging fruit optimization of blockspace
consumption.

Best,
Antoine

Le mar. 18 oct. 2022 à 09:53, Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hello Everyone,
>
> Following up on the "V3 Transaction" discussion here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
> , I would like to elaborate a bit further on some potential follow-on work
> that would make pinning severely constrained in many setups].
>
> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
> some constraints[0]. This means that when a replacement is to be made and
> propagated, it costs the expected amount of fees to do so. This is a great
> start. What's left in this subset of pinning is *package limit* pinning. In
> other words, a fee-paying transaction cannot enter the mempool due to the
> existing mempool package it is being added to already being too large in
> count or vsize.
>
> Zooming into the V3 simplified scenario for sake of discussion, though
> this problem exists in general today:
>
> V3 transactions restrict the package limit of a V3 package to one parent
> and one child. If the parent transaction includes two outputs which can be
> immediately spent by separate parties, this allows one party to disallow a
> spend from the other. In Gloria's proposal for ln-penalty, this is worked
> around by reducing the number of anchors per commitment transaction to 1,
> and each version of the commitment transaction has a unique party's key on
> it. The honest participant can spend their version with their anchor and
> package RBF the other commitment transaction safely.
>
> What if there's only one version of the commitment transaction, such as in
> other protocols like duplex payment channels, eltoo? 

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[rot13maxi via bitcoin-dev]

Hello Andrew and Bryan,

> No, as I understand the proposal, the "public key" held by the wallet is 
> simply
> a signing key used to authenticate addresses, and never leaves the wallet. 

That's right (or at least, that's the intent). Think of importing someone's GPG 
key and then using it to validate future signed messages from them. In this 
case, the public key stays in your "address book" entry for a person and then 
whenever you need to fetch a fresh address for them from the Address Server, 
your wallet can validate that it's for their wallet. 

Making sure that you import a legitimate/authentic public key is a problem, but 
you only need to do it once per recipient, instead of doing it every time you 
need to transact with that person. Maybe that's something you solve in UI (i.e. 
Signal has you compare strings with your counter-party), or something you can 
solve through other metadata (GPG had WoT, or if you're already using an 
address server maybe there's some PKI scheme that's appropriate, etc.). 


Rubin, I think you responded on another branch of the thread, but thanks for 
the podcast link. I'll check it out!

Cheers,

Rijndael

--- Original Message ---
On Tuesday, October 18th, 2022 at 8:42 AM, Andrew Poelstra 
 wrote:


> On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
>
> > Isn't this the same problem but now for copy-pasting pubkeys instead of an
> > address?
>
>
> No, as I understand the proposal, the "public key" held by the wallet is 
> simply
> a signing key used to authenticate addresses, and never leaves the wallet. 
> Yes,
> if the wallet's own memory is compromised, it can be tricked into accepting 
> bad
> addresses, but this is much much harder than compromising data on the 
> clipboard,
> which basically any application can do without any "real" exploits or special
> permissions.
>
> As an extreme, this proposal could be run on a hardware wallet which had some
> out-of-band way to obtain and authenticate public keys (similar to Signal QR
> codes).
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[yancy via bitcoin-dev]

not sure if this is helpful, but when i'm code reviewing a change to
an existing, functioning and very complex system, i rarely go back to
"first principles" to analyze that change independently, and instead
try to decide if it's better or worse than what we have now


I agree that it's important to not be too dogmatic, which includes 
Satoshi and the white paper. It's fun to look back and read to try to 
find inspiration, although, it seems to me, a lot has been learned since 
then.  And a lot will be learned in the future.  I was thinking to 
myself, what if in the distant future, quantum entanglement could be 
used to update all nodes simultaneously across any distance in space? 
How cool would that be?  How might that change from the original vision? 
 Well, if we ever get that far, I'm sure Satoshi could not have planned 
for that, or maybe they could have.. :)


On 2022-10-18 19:33, Erik Aronesty via bitcoin-dev wrote:


not sure if this is helpful, but when i'm code reviewing a change to
an existing, functioning and very complex system, i rarely go back to
"first principles" to analyze that change independently, and instead
try to decide if it's better or worse than what we have now

you can introduce a new feature, for example, that has a bunch of
noncritical bugs, especially in ux, and then you can weigh in on
whether its better to get it out now for the people that need it, or
bikeshed ux for another 2 releases

i'm often a fan of the former

if someone proposes a change to bitcoin, we should probably review it
as "better or worse than what we have", rather than "has perfectly
aligned incentives promoting honest behavior even among selfish
actors"

we know bitcoin functions now with a complex series of incentives,
especially regarding node operators

in other words, does the change "improve what we have" is a better bar
than "stands on its own"

in that way the system can slowly improve over time, rather than be
stuck

On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev
 wrote:

I think the issue with

I still think it is misguided to think that the "honest" (i.e.
rule following) majority is to just be accepted as an axiom and if
it is violated, well, then sorry.  The rules need to be incentive
compatible for the system to be functional.  The honest majority
is only considered an assumption because even if following the
rules were clearly the 100% dominant strategy, this doesn't prove
that the majority is honest, since mathematics cannot say what is
happening in the real world at any given time.  Still, we must
have a reason to think that the majority would be honest, and that
reasoning should come from an argument that the rule set is
incentive compatible.
epistemically is that even within the game that you prove the
dominant strategy, you can't be certain that you've captured (except
maybe through clever use of exogenous parameters, which reduces to
the same thing as % honest) the actual incentives of all players.
For example, you would need to capture the existence of large
hegemonic governments defending their legacy currencies by attacking
bitcoin.

I think we may be talking past each other if it is a concern /
valuable exercise to decrease the assumptions that Bitcoin rests on
to make it more secure than it is as defined in the whitepaper.
That's an exercise of tremendous value. I think my point is that
those things are aspirational (aspirations that perhaps we should
absolutely achieve?) but to the extent that we need to fix things
like the fee market, selfish mining, mind the gap, etc, those are
modifying Bitcoin to be secure (or more fair is perhaps another way
to look at it) in the presence of deviations from a hypothesized
"incentive compatible Bitcoin", which is a different thing that
"whitepaper bitcoin". I think that I largely fall in the camp -- as
evidenced by some past conversations I won't rehash -- that all of
Bitcoin should be incentive compatible and we should fix it if not.
But from those conversations I also learned that there are large
swaths of the community who don't share that value, or only share it
up to a point, and do feel comfortable resting on honest majority
assumptions at one layer of the stack or another. And I think that
prior / axiom is a pretty central one to debug or comprehend when
dealing with, as is happening now, a fight over something that seems
obviously not incentive compatible.

--
@JeremyRubin [1 [1]]

On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor
 wrote:

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev
 wrote:

However, what *is* important about what Satoshi wrote is that it is
sort of the "social contract" of what Bitcoin is that we can all
sort of minimally agree to. This makes it clear, when we try to
describe Bitcoin with differing assumptions than in the whitepaper,
what the changes are and why we think the system might support those
claims. But if we can't prove the new description sound, such as
showing tip 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

> (see https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
UTXO")

I think I remember you trying to explain this to me a long time ago. Thanks
for the callback!

> One question I have is if V3 is designed for lightning, and this is
designed for lightning, is there any sense in requiring these outputs for
v3? That might help with e.g. anonymity set, as well as potentially keep
the v3 surface smaller.

The fingerprinting angle is yet another thing to consider. There are
definitely uses of V3 that do not require ephemeral anchors, and you can
save a healthy amount of bytes not requiring them. I think in the cases
where RBF of the parent is possible, at least.

f.e., I think V3 alone makes splicing robust even in the presence of
external inputs, since the commitment tx(s) can (package) RBF the splice at
any point. V3 may have enough value-add by itself where the additional
bytes and inability to opt out of "transaction sponsor" style bumps may be
undesirable.

Lastly this would tie deployments of these improvements together. Something
to consider.

Cheers,
Greg

On Tue, Oct 18, 2022 at 12:41 PM Jeremy Rubin  wrote:

> Excellent proposal and I agree it does capture much of the spirit of
> sponsors w.r.t. how they might be used for V3 protocols.
>
> The only drawbacks I see is they don't work for lower tx version
> contracts, so there's still something to be desired there, and that the
> requirement to sweep the output must be incentive compatible for the miner,
> or else they won't enforce it (pass the buck onto the future bitcoiners).
> The Ephemeral UTXO concept can be a consensus rule (see
> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate UTXO")
> we add later on in lieu of managing them by incentive, so maybe it's a
> cleanup one can punt.
>
> One question I have is if V3 is designed for lightning, and this is
> designed for lightning, is there any sense in requiring these outputs for
> v3? That might help with e.g. anonymity set, as well as potentially keep
> the v3 surface smaller.
>
> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > does that effectively mark output B as unspendable once the child gets
>> confirmed?
>>
>> Not at all. It's a normal spend like before, since the parent has been
>> confirmed. It's completely unrestricted, not being bound to any
>> V3/ephemeral anchor restrictions on size, version, etc.
>>
>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Greg,
>>>
>>> Thank you very much for sharing your proposal!
>>>
>>> I think there's one thing about the second part of your proposal that
>>> I'm missing. Specifically, assuming the scenario of a v3 transaction with
>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>> transaction spends A and OP_TRUE, does that effectively mark output B as
>>> unspendable once the child gets confirmed? If so, isn't the implication
>>> therefore that to safely spend a transaction with an ephemeral anchor, all
>>> outputs must be spent? Thanks!
>>>
>>> Best,
>>> Arik
>>>
>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>>
>>> Hello Everyone,
>>>
>>> Following up on the "V3 Transaction" discussion here
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>>> , I would like to elaborate a bit further on some potential follow-on work
>>> that would make pinning severely constrained in many setups].
>>>
>>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
>>> some constraints[0]. This means that when a replacement is to be made and
>>> propagated, it costs the expected amount of fees to do so. This is a great
>>> start. What's left in this subset of pinning is *package limit* pinning. In
>>> other words, a fee-paying transaction cannot enter the mempool due to the
>>> existing mempool package it is being added to already being too large in
>>> count or vsize.
>>>
>>> Zooming into the V3 simplified scenario for sake of discussion, though
>>> this problem exists in general today:
>>>
>>> V3 transactions restrict the package limit of a V3 package to one parent
>>> and one child. If the parent transaction includes two outputs which can be
>>> immediately spent by separate parties, this allows one party to disallow a
>>> spend from the other. In Gloria's proposal for ln-penalty, this is worked
>>> around by reducing the number of anchors per commitment transaction to 1,
>>> and each version of the commitment transaction has a unique party's key on
>>> it. The honest participant can spend their version with their anchor and
>>> package RBF the other commitment transaction safely.
>>>
>>> What if there's only one version of the commitment transaction, such as
>>> in other protocols like duplex payment channels, eltoo? What about multi
>>> party payments?
>>>
>>> In the package RBF proposal, 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Erik Aronesty via bitcoin-dev]

not sure if this is helpful, but when i'm code reviewing a change to an
existing, functioning and very complex system, i rarely go back to "first
principles" to analyze that change independently, and instead try to decide
if it's better or worse than what we have now

you can introduce a new feature, for example, that has a bunch of
noncritical bugs, especially in ux, and then you can weigh in on whether
its better to get it out now for the people that need it, or bikeshed ux
for another 2 releases

i'm often a fan of the former

if someone proposes a change to bitcoin, we should probably review it as
"better or worse than what we have", rather than "has perfectly aligned
incentives promoting honest behavior even among selfish actors"

we know bitcoin functions now with a complex series of incentives,
especially regarding node operators

in other words, does the change "improve what we have" is a better bar than
"stands on its own"

in that way the system can slowly improve over time, rather than be stuck


On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think the issue with
>
> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive compatible for
>> the system to be functional.  The honest majority is only considered an
>> assumption because even if following the rules were clearly the 100%
>> dominant strategy, this doesn't prove that the majority is honest, since
>> mathematics cannot say what is happening in the real world at any given
>> time.  Still, we must have a reason to think that the majority would be
>> honest, and that reasoning should come from an argument that the rule set
>> is incentive compatible.
>
>
> epistemically is that even within the game that you prove the dominant
> strategy, you can't be certain that you've captured (except maybe through
> clever use of exogenous parameters, which reduces to the same thing as %
> honest) the actual incentives of all players. For example, you would need
> to capture the existence of large hegemonic governments defending their
> legacy currencies by attacking bitcoin.
>
>
> I think we may be talking past each other if it is a concern / valuable
> exercise to decrease the assumptions that Bitcoin rests on to make it more
> secure than it is as defined in the whitepaper. That's an exercise of
> tremendous value. I think my point is that those things are aspirational
> (aspirations that perhaps we should absolutely achieve?) but to the extent
> that we need to fix things like the fee market, selfish mining, mind the
> gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps
> another way to look at it) in the presence of deviations from a
> hypothesized "incentive compatible Bitcoin", which is a different thing
> that "whitepaper bitcoin". I think that I largely fall in the camp -- as
> evidenced by some past conversations I won't rehash -- that all of Bitcoin
> should be incentive compatible and we should fix it if not. But from those
> conversations I also learned that there are large swaths of the community
> who don't share that value, or only share it up to a point, and do feel
> comfortable resting on honest majority assumptions at one layer of the
> stack or another. And I think that prior / axiom is a pretty central one to
> debug or comprehend when dealing with, as is happening now, a fight over
> something that seems obviously not incentive compatible.
>
> --
> @JeremyRubin 
>
>
> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor <
> rocon...@blockstream.com> wrote:
>
>> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> However, what *is* important about what Satoshi wrote is that it is sort
>>> of the "social contract" of what Bitcoin is that we can all sort of
>>> minimally agree to. This makes it clear, when we try to describe Bitcoin
>>> with differing assumptions than in the whitepaper, what the changes are and
>>> why we think the system might support those claims. But if we can't prove
>>> the new description sound, such as showing tip mining to be rational in a
>>> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
>>> since all that was promised originally is functioning under an honest
>>> majority. Caveat Emptor!
>>>
>>
>> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive compatible for
>> the system to be functional.  The honest majority is only considered an
>> assumption because even if following the rules were clearly the 100%
>> dominant strategy, this doesn't prove that the majority is honest, since
>> mathematics 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Jeremy Rubin via bitcoin-dev]

Excellent proposal and I agree it does capture much of the spirit of
sponsors w.r.t. how they might be used for V3 protocols.

The only drawbacks I see is they don't work for lower tx version contracts,
so there's still something to be desired there, and that the requirement to
sweep the output must be incentive compatible for the miner, or else they
won't enforce it (pass the buck onto the future bitcoiners). The Ephemeral
UTXO concept can be a consensus rule (see
https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate UTXO")
we add later on in lieu of managing them by incentive, so maybe it's a
cleanup one can punt.

One question I have is if V3 is designed for lightning, and this is
designed for lightning, is there any sense in requiring these outputs for
v3? That might help with e.g. anonymity set, as well as potentially keep
the v3 surface smaller.

On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > does that effectively mark output B as unspendable once the child gets
> confirmed?
>
> Not at all. It's a normal spend like before, since the parent has been
> confirmed. It's completely unrestricted, not being bound to any
> V3/ephemeral anchor restrictions on size, version, etc.
>
> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Greg,
>>
>> Thank you very much for sharing your proposal!
>>
>> I think there's one thing about the second part of your proposal that I'm
>> missing. Specifically, assuming the scenario of a v3 transaction with three
>> outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction
>> spends A and OP_TRUE, does that effectively mark output B as unspendable
>> once the child gets confirmed? If so, isn't the implication therefore that
>> to safely spend a transaction with an ephemeral anchor, all outputs must be
>> spent? Thanks!
>>
>> Best,
>> Arik
>>
>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>
>> Hello Everyone,
>>
>> Following up on the "V3 Transaction" discussion here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>> , I would like to elaborate a bit further on some potential follow-on work
>> that would make pinning severely constrained in many setups].
>>
>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
>> some constraints[0]. This means that when a replacement is to be made and
>> propagated, it costs the expected amount of fees to do so. This is a great
>> start. What's left in this subset of pinning is *package limit* pinning. In
>> other words, a fee-paying transaction cannot enter the mempool due to the
>> existing mempool package it is being added to already being too large in
>> count or vsize.
>>
>> Zooming into the V3 simplified scenario for sake of discussion, though
>> this problem exists in general today:
>>
>> V3 transactions restrict the package limit of a V3 package to one parent
>> and one child. If the parent transaction includes two outputs which can be
>> immediately spent by separate parties, this allows one party to disallow a
>> spend from the other. In Gloria's proposal for ln-penalty, this is worked
>> around by reducing the number of anchors per commitment transaction to 1,
>> and each version of the commitment transaction has a unique party's key on
>> it. The honest participant can spend their version with their anchor and
>> package RBF the other commitment transaction safely.
>>
>> What if there's only one version of the commitment transaction, such as
>> in other protocols like duplex payment channels, eltoo? What about multi
>> party payments?
>>
>> In the package RBF proposal, if the parent transaction is identical to an
>> existing transaction in the mempool, the parent will be detected and
>> removed from the package proposal. You are then left with a single V3 child
>> transaction, which is then proposed for entry into the mempool. In the case
>> of another parent output already being spent, this is simply rejected,
>> regardless of feerate of the new child.
>>
>> I have two proposed solutions, of which I strongly prefer the latter:
>>
>> 1) Expand a carveout for "sibling eviction", where if the new child is
>> paying "enough" to bump spends from the same parent, it knocks its sibling
>> out of the mempool and takes the one child slot. This would solve it, but
>> is a new eviction paradigm that would need to be carefully worked through.
>>
>> 2) Ephemeral Anchors (my real policy-only proposal)
>>
>> Ephemeral Anchors is a term which means an output is watermarked as an
>> output that MUST be spent in a V3 package. We mark this anchor by being the
>> bare script `OP_TRUE` and of course make these outputs standard to relay
>> and spend with empty witness data.
>>
>> Also as a simplifying assumption, we require the parent transaction with
>> such an output to be 0-fee. This makes mempool 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin via bitcoin-dev]

I think the issue with

I still think it is misguided to think that the "honest" (i.e. rule
> following) majority is to just be accepted as an axiom and if it is
> violated, well, then sorry.  The rules need to be incentive compatible for
> the system to be functional.  The honest majority is only considered an
> assumption because even if following the rules were clearly the 100%
> dominant strategy, this doesn't prove that the majority is honest, since
> mathematics cannot say what is happening in the real world at any given
> time.  Still, we must have a reason to think that the majority would be
> honest, and that reasoning should come from an argument that the rule set
> is incentive compatible.


epistemically is that even within the game that you prove the dominant
strategy, you can't be certain that you've captured (except maybe through
clever use of exogenous parameters, which reduces to the same thing as %
honest) the actual incentives of all players. For example, you would need
to capture the existence of large hegemonic governments defending their
legacy currencies by attacking bitcoin.


I think we may be talking past each other if it is a concern / valuable
exercise to decrease the assumptions that Bitcoin rests on to make it more
secure than it is as defined in the whitepaper. That's an exercise of
tremendous value. I think my point is that those things are aspirational
(aspirations that perhaps we should absolutely achieve?) but to the extent
that we need to fix things like the fee market, selfish mining, mind the
gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps
another way to look at it) in the presence of deviations from a
hypothesized "incentive compatible Bitcoin", which is a different thing
that "whitepaper bitcoin". I think that I largely fall in the camp -- as
evidenced by some past conversations I won't rehash -- that all of Bitcoin
should be incentive compatible and we should fix it if not. But from those
conversations I also learned that there are large swaths of the community
who don't share that value, or only share it up to a point, and do feel
comfortable resting on honest majority assumptions at one layer of the
stack or another. And I think that prior / axiom is a pretty central one to
debug or comprehend when dealing with, as is happening now, a fight over
something that seems obviously not incentive compatible.

--
@JeremyRubin 


On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor 
wrote:

> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> However, what *is* important about what Satoshi wrote is that it is sort
>> of the "social contract" of what Bitcoin is that we can all sort of
>> minimally agree to. This makes it clear, when we try to describe Bitcoin
>> with differing assumptions than in the whitepaper, what the changes are and
>> why we think the system might support those claims. But if we can't prove
>> the new description sound, such as showing tip mining to be rational in a
>> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
>> since all that was promised originally is functioning under an honest
>> majority. Caveat Emptor!
>>
>
> I still think it is misguided to think that the "honest" (i.e. rule
> following) majority is to just be accepted as an axiom and if it is
> violated, well, then sorry.  The rules need to be incentive compatible for
> the system to be functional.  The honest majority is only considered an
> assumption because even if following the rules were clearly the 100%
> dominant strategy, this doesn't prove that the majority is honest, since
> mathematics cannot say what is happening in the real world at any given
> time.  Still, we must have a reason to think that the majority would be
> honest, and that reasoning should come from an argument that the rule set
> is incentive compatible.
>
> The stability of mining, i.e. the incentives to mine on the most work
> chain, is actually a huge concern, especially in a future low subsidy
> environment.  There is actually much fretting about this issue, and rightly
> so.  We don't actually know that Bitcoin can function in a low subsidy
> environment because we have never tested it.  Bitcoin could still end up a
> failure if that doesn't work out.  My current understanding/guess is that
> with a "thick mempool" (that is lots of transactions without large gaps in
> fee rates between them) and/or miners rationally leaving behind
> transactions to encourage mining on their block (after all it is in a
> miner's own interest not to have their block orphaned), that mining will be
> stable.  But I don't know this for sure, and we cannot know with certainty
> that we are going to have a "thick mempool" when it is needed.
>
> It is most certainly the case that one can construct situations where not
> mining on the tip is going to be the prefered strategy.  But 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Greg Sanders via bitcoin-dev]

> does that effectively mark output B as unspendable once the child gets
confirmed?

Not at all. It's a normal spend like before, since the parent has been
confirmed. It's completely unrestricted, not being bound to any
V3/ephemeral anchor restrictions on size, version, etc.

On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Greg,
>
> Thank you very much for sharing your proposal!
>
> I think there's one thing about the second part of your proposal that I'm
> missing. Specifically, assuming the scenario of a v3 transaction with three
> outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction
> spends A and OP_TRUE, does that effectively mark output B as unspendable
> once the child gets confirmed? If so, isn't the implication therefore that
> to safely spend a transaction with an ephemeral anchor, all outputs must be
> spent? Thanks!
>
> Best,
> Arik
>
> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>
> Hello Everyone,
>
> Following up on the "V3 Transaction" discussion here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
> , I would like to elaborate a bit further on some potential follow-on work
> that would make pinning severely constrained in many setups].
>
> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
> some constraints[0]. This means that when a replacement is to be made and
> propagated, it costs the expected amount of fees to do so. This is a great
> start. What's left in this subset of pinning is *package limit* pinning. In
> other words, a fee-paying transaction cannot enter the mempool due to the
> existing mempool package it is being added to already being too large in
> count or vsize.
>
> Zooming into the V3 simplified scenario for sake of discussion, though
> this problem exists in general today:
>
> V3 transactions restrict the package limit of a V3 package to one parent
> and one child. If the parent transaction includes two outputs which can be
> immediately spent by separate parties, this allows one party to disallow a
> spend from the other. In Gloria's proposal for ln-penalty, this is worked
> around by reducing the number of anchors per commitment transaction to 1,
> and each version of the commitment transaction has a unique party's key on
> it. The honest participant can spend their version with their anchor and
> package RBF the other commitment transaction safely.
>
> What if there's only one version of the commitment transaction, such as in
> other protocols like duplex payment channels, eltoo? What about multi party
> payments?
>
> In the package RBF proposal, if the parent transaction is identical to an
> existing transaction in the mempool, the parent will be detected and
> removed from the package proposal. You are then left with a single V3 child
> transaction, which is then proposed for entry into the mempool. In the case
> of another parent output already being spent, this is simply rejected,
> regardless of feerate of the new child.
>
> I have two proposed solutions, of which I strongly prefer the latter:
>
> 1) Expand a carveout for "sibling eviction", where if the new child is
> paying "enough" to bump spends from the same parent, it knocks its sibling
> out of the mempool and takes the one child slot. This would solve it, but
> is a new eviction paradigm that would need to be carefully worked through.
>
> 2) Ephemeral Anchors (my real policy-only proposal)
>
> Ephemeral Anchors is a term which means an output is watermarked as an
> output that MUST be spent in a V3 package. We mark this anchor by being the
> bare script `OP_TRUE` and of course make these outputs standard to relay
> and spend with empty witness data.
>
> Also as a simplifying assumption, we require the parent transaction with
> such an output to be 0-fee. This makes mempool reasoning simpler in case
> the child-spend is somehow evicted, guaranteeing the parent will be as well.
>
> Implications:
>
> a) If the ephemeral anchor MUST be spent, we can allow *any* value, even
> dust, even 0, without worrying about bloating the utxo set. We relax this
> policy for maximum smart contract flexibility and specification simplicity..
>
> b) Since this anchor MUST be spent, any spending of other outputs in the
> same parent transaction MUST directly double-spend prior spends of the
> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
> removed in these situations. This greatly magnifies composability of smart
> contracts, as now we can do things like safely splice directly into new
> channels, into statechains, your custodial wallet account, your cold
> wallet, wherever, without requiring other wallets to support arbitrary
> scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript
> compatible to begin with...
>
> c) *Anyone* can bump the transaction, without any transaction key
> material. This is 

Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning

[Arik Sosman via bitcoin-dev]

Hi Greg,

Thank you very much for sharing your proposal!

I think there's one thing about the second part of your proposal that I'm 
missing. Specifically, assuming the scenario of a v3 transaction with three 
outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction spends 
A and OP_TRUE, does that effectively mark output B as unspendable once the 
child gets confirmed? If so, isn't the implication therefore that to safely 
spend a transaction with an ephemeral anchor, all outputs must be spent? Thanks!

Best,
Arik

On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
> Hello Everyone,
> 
> 
> Following up on the "V3 Transaction" discussion here 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>  , I would like to elaborate a bit further on some potential follow-on work 
> that would make pinning severely constrained in many setups].
> 
> 
> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under some 
> constraints[0]. This means that when a replacement is to be made and 
> propagated, it costs the expected amount of fees to do so. This is a great 
> start. What's left in this subset of pinning is *package limit* pinning. In 
> other words, a fee-paying transaction cannot enter the mempool due to the 
> existing mempool package it is being added to already being too large in 
> count or vsize.
> 
> 
> Zooming into the V3 simplified scenario for sake of discussion, though this 
> problem exists in general today:
> 
> 
> V3 transactions restrict the package limit of a V3 package to one parent and 
> one child. If the parent transaction includes two outputs which can be 
> immediately spent by separate parties, this allows one party to disallow a 
> spend from the other. In Gloria's proposal for ln-penalty, this is worked 
> around by reducing the number of anchors per commitment transaction to 1, and 
> each version of the commitment transaction has a unique party's key on it. 
> The honest participant can spend their version with their anchor and package 
> RBF the other commitment transaction safely.
> 
> 
> What if there's only one version of the commitment transaction, such as in 
> other protocols like duplex payment channels, eltoo? What about multi party 
> payments?
> 
> 
> In the package RBF proposal, if the parent transaction is identical to an 
> existing transaction in the mempool, the parent will be detected and removed 
> from the package proposal. You are then left with a single V3 child 
> transaction, which is then proposed for entry into the mempool. In the case 
> of another parent output already being spent, this is simply rejected, 
> regardless of feerate of the new child.
> 
> 
> I have two proposed solutions, of which I strongly prefer the latter:
> 
> 
> 1) Expand a carveout for "sibling eviction", where if the new child is paying 
> "enough" to bump spends from the same parent, it knocks its sibling out of 
> the mempool and takes the one child slot. This would solve it, but is a new 
> eviction paradigm that would need to be carefully worked through.
> 
> 
> 2) Ephemeral Anchors (my real policy-only proposal)
> 
> 
> Ephemeral Anchors is a term which means an output is watermarked as an output 
> that MUST be spent in a V3 package. We mark this anchor by being the bare 
> script `OP_TRUE` and of course make these outputs standard to relay and spend 
> with empty witness data.
> 
> 
> Also as a simplifying assumption, we require the parent transaction with such 
> an output to be 0-fee. This makes mempool reasoning simpler in case the 
> child-spend is somehow evicted, guaranteeing the parent will be as well.
> 
> 
> Implications:
> 
> 
> a) If the ephemeral anchor MUST be spent, we can allow *any* value, even 
> dust, even 0, without worrying about bloating the utxo set. We relax this 
> policy for maximum smart contract flexibility and specification simplicity..
> 
> 
> b) Since this anchor MUST be spent, any spending of other outputs in the same 
> parent transaction MUST directly double-spend prior spends of the ephemeral 
> anchor. This causes the 1 block CSV timelock on outputs to be removed in 
> these situations. This greatly magnifies composability of smart contracts, as 
> now we can do things like safely splice directly into new channels, into 
> statechains, your custodial wallet account, your cold wallet, wherever, 
> without requiring other wallets to support arbitrary scripts. Also it hurts 
> that 1 CSV time locked scripts may not be miniscript compatible to begin 
> with...
> 
> 
> c) *Anyone* can bump the transaction, without any transaction key material. 
> This is essentially achieving Jeremy's Transaction Sponsors 
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html)
>  proposal without consensus changes. As long as someone gets a fully signed 
> parent, they can execute a bump with minimal wallet tooling. If a transaction 
> author doesn’t 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Russell O'Connor via bitcoin-dev]

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> However, what *is* important about what Satoshi wrote is that it is sort
> of the "social contract" of what Bitcoin is that we can all sort of
> minimally agree to. This makes it clear, when we try to describe Bitcoin
> with differing assumptions than in the whitepaper, what the changes are and
> why we think the system might support those claims. But if we can't prove
> the new description sound, such as showing tip mining to be rational in a
> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
> since all that was promised originally is functioning under an honest
> majority. Caveat Emptor!
>

I still think it is misguided to think that the "honest" (i.e. rule
following) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive compatible for
the system to be functional.  The honest majority is only considered an
assumption because even if following the rules were clearly the 100%
dominant strategy, this doesn't prove that the majority is honest, since
mathematics cannot say what is happening in the real world at any given
time.  Still, we must have a reason to think that the majority would be
honest, and that reasoning should come from an argument that the rule set
is incentive compatible.

The stability of mining, i.e. the incentives to mine on the most work
chain, is actually a huge concern, especially in a future low subsidy
environment.  There is actually much fretting about this issue, and rightly
so.  We don't actually know that Bitcoin can function in a low subsidy
environment because we have never tested it.  Bitcoin could still end up a
failure if that doesn't work out.  My current understanding/guess is that
with a "thick mempool" (that is lots of transactions without large gaps in
fee rates between them) and/or miners rationally leaving behind
transactions to encourage mining on their block (after all it is in a
miner's own interest not to have their block orphaned), that mining will be
stable.  But I don't know this for sure, and we cannot know with certainty
that we are going to have a "thick mempool" when it is needed.

It is most certainly the case that one can construct situations where not
mining on the tip is going to be the prefered strategy.  But even if that
happens on occasion, it's not like the protocol immediately collapses,
because mining off the tip is indistinguishable from being a high latency
miner who simply didn't receive the most work block in time.  So it is more
of a question of how rare does it need to be, and what can we do to reduce
the chances of such situations arising (e.g. updating our mining policy to
leave some transactions out based on current (and anticipated) mempool
conditions, or (for a sufficiently capitalized miner) leave an explicit,
ANYONECANSPEND transaction output as a tip for the next miner to build upon
mined blocks.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning

[Greg Sanders via bitcoin-dev]

Hello Everyone,

Following up on the "V3 Transaction" discussion here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
, I would like to elaborate a bit further on some potential follow-on work
that would make pinning severely constrained in many setups].

V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under
some constraints[0]. This means that when a replacement is to be made and
propagated, it costs the expected amount of fees to do so. This is a great
start. What's left in this subset of pinning is *package limit* pinning. In
other words, a fee-paying transaction cannot enter the mempool due to the
existing mempool package it is being added to already being too large in
count or vsize.

Zooming into the V3 simplified scenario for sake of discussion, though this
problem exists in general today:

V3 transactions restrict the package limit of a V3 package to one parent
and one child. If the parent transaction includes two outputs which can be
immediately spent by separate parties, this allows one party to disallow a
spend from the other. In Gloria's proposal for ln-penalty, this is worked
around by reducing the number of anchors per commitment transaction to 1,
and each version of the commitment transaction has a unique party's key on
it. The honest participant can spend their version with their anchor and
package RBF the other commitment transaction safely.

What if there's only one version of the commitment transaction, such as in
other protocols like duplex payment channels, eltoo? What about multi party
payments?

In the package RBF proposal, if the parent transaction is identical to an
existing transaction in the mempool, the parent will be detected and
removed from the package proposal. You are then left with a single V3 child
transaction, which is then proposed for entry into the mempool. In the case
of another parent output already being spent, this is simply rejected,
regardless of feerate of the new child.

I have two proposed solutions, of which I strongly prefer the latter:

1) Expand a carveout for "sibling eviction", where if the new child is
paying "enough" to bump spends from the same parent, it knocks its sibling
out of the mempool and takes the one child slot. This would solve it, but
is a new eviction paradigm that would need to be carefully worked through.

2) Ephemeral Anchors (my real policy-only proposal)

Ephemeral Anchors is a term which means an output is watermarked as an
output that MUST be spent in a V3 package. We mark this anchor by being the
bare script `OP_TRUE` and of course make these outputs standard to relay
and spend with empty witness data.

Also as a simplifying assumption, we require the parent transaction with
such an output to be 0-fee. This makes mempool reasoning simpler in case
the child-spend is somehow evicted, guaranteeing the parent will be as well.

Implications:

a) If the ephemeral anchor MUST be spent, we can allow *any* value, even
dust, even 0, without worrying about bloating the utxo set. We relax this
policy for maximum smart contract flexibility and specification simplicity..

b) Since this anchor MUST be spent, any spending of other outputs in the
same parent transaction MUST directly double-spend prior spends of the
ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
removed in these situations. This greatly magnifies composability of smart
contracts, as now we can do things like safely splice directly into new
channels, into statechains, your custodial wallet account, your cold
wallet, wherever, without requiring other wallets to support arbitrary
scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript
compatible to begin with...

c) *Anyone* can bump the transaction, without any transaction key material.
This is essentially achieving Jeremy's Transaction Sponsors (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html)
proposal without consensus changes. As long as someone gets a fully signed
parent, they can execute a bump with minimal wallet tooling. If a
transaction author doesn’t want a “sponsor”, do not include the output.

d) Lightning Carve-out(
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html)
is superseded by this logic, as we are not restricted to two immediately
spendable output scenarios. In its place, robust multi-party fee bumping is
possible.

e) This also benefits more traditional wallet scenarios, as change outputs
can no longer be pinned, and RBF/CPFP becomes robust. Payees in simple
spends cannot pin you. Batched payouts become a lot less painful. This was
one of the motivating use cases that created the term “pinning” in the
first place(
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html),
even if LN/L2 discussion has largely overtaken it due to HTLC theft risks.

Open Question(s):


   1.

   If we allow non-zero value in ephemeral 

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin)

[Murch via bitcoin-dev]

Hello John,

On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:

Simply, 0conf acceptance can be monitored and enforced by the merchant and 
exposure to doublespends can be both mitigated and limited in size per block. 
It is less expensive to be double-spent occasionally than to have a delayed 
checkout experience. Responsible 0conf acceptance is both rational and trusting.


29% of all transactions explicitly signal replaceability (see 
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/), trend 
rising. If ignoring risk is an acceptable approach now, why would it no 
longer work when the remaining 71% of transactions also became subject 
to replaceability?


On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:

Now RBF just kinda haunts us as the establishment keeps baking it deeper and 
deeper into Bitcoin, despite almost no one using it, and despite it having 
negative consequences on more popular use cases.


How can RBF at the same time be hardly used as well as an incalculable risk?

Fact of the matter is that one can neither rely on having seen all 
transactions that miners are considering for their block templates, nor 
that a replacement be received by the miners before the original is 
picked into a block.
We're between seats: first-seen is an unstable gentlemen's agreement, 
inevitable to fail eventually once a few defect. Meanwhile propping up 
the illusion of "reliable payment promises" is hampering price discovery 
of blockspace and complicating protocol development. By converging on 
the inevitable outcome and facilitating replaceability for all 
transactions, we can rip off the band-aid rather than suffer uncertainty 
indefinitely—even if it requires some to honestly reassess their 
business approach in light of the natural modus operandi of Bitcoin's 
gossip system.


Cheers,
Murch


OpenPGP_0xACFDB93A9175DCAB_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Ruben Somsen via bitcoin-dev]

Hi Rijndael,

I think your thoughts are pretty much compatible with this proposal, as
what I'm describing (the recipient signing their keys) is also essentially
a form of authentication.

It's a good observation that in general this makes the communication of
addresses more secure. I do wish to re-emphasize Bryan's remark that you
still need to ensure the pubkey itself is securely communicated.

>depending on the setup, this could be that the address server also has the
Address Authentication privkey for bob, or it could be that bob gets some
callback or notification, or that bob has pre-signed a batch of addresses

In my opinion the only meaningful distinction is whether Bob runs the
Trustless Address Server himself (full privacy) or not. In either case I
see no reason to diverge from the model where Bob deposits a batch of
signed keys to the server, ensuring that no malicious addresses can be
handed out.

Note I discussed the Trustless Address Server design in the first 20
minutes of this podcast:
https://twitter.com/bitcoinoptech/status/1580573594656333825

And I also brought it up in my presentation at Tabconf last Saturday, but
that video isn't online yet.

Cheers,
Ruben



On Tue, Oct 18, 2022 at 2:07 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Unbeknownst to them, the clipboard contents have been replaced with an
>> address controlled by some bad actor.
>>
> [snip]
>
>> Now imagine instead that the wallet has some address book with a pubkey
>> for each recipient the user wants to send bitcoin to.
>>
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
> - Bryan
> https://twitter.com/kanzure
> ___
> 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] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Andrew Poelstra via bitcoin-dev]

On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
> 
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>

No, as I understand the proposal, the "public key" held by the wallet is simply
a signing key used to authenticate addresses, and never leaves the wallet. Yes,
if the wallet's own memory is compromised, it can be tricked into accepting bad
addresses, but this is much much harder than compromising data on the clipboard,
which basically any application can do without any "real" exploits or special
permissions.

As an extreme, this proposal could be run on a hardware wallet which had some
out-of-band way to obtain and authenticate public keys (similar to Signal QR
codes).

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
-Justin Lewis-Webster



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

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Anthony Towns via bitcoin-dev]

On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> >  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > payments indefinitely
> >  2) Draw a line in the sand now, but give people who are currently
> > accepting unconfirmed txs time to update their software and business
> > model
> >  3) Encourage mainnet miners and relay nodes to support unconditional
> > RBF immediately, no matter how much that increases the risk to
> > existing businesses that are still accepting unconfirmed txs
> To give more context, the initial approach of enabling full RBF through
> #25353 + #25600 wasn't making the assumption the enablement itself would
> reach agreement of the economic majority or unanimity. 

Full RBF doesn't need a majority or unanimity to have an impact; it needs
adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
a 10MvB mempool can be replaced before being mined naturally), and some
way of finding a working path to relay txs to that hashrate.

Having a majority of nodes/hashrate support it makes the upsides better,
but doesn't change the downsides to the people who are relying on it
not being available.

> Without denying that such equilibrium would be unstable, it was designed to
> remove the responsibility of the Core project itself to "draw a hard line"
> on the subject.

Removing responsibility from core developers seems like it's very much
optimising for the wrong thing to me.

I mean, I guess I can understand wanting to reduce that responsibility
for maintainers of the github repo, even if for no other reason than to
avoid frivolous lawsuits, but where do you expect people to find better
advice about what things are a good/bad idea if core devs as a whole
are avoiding that responsibility?

Core devs are supposedly top technical experts at bitcoin -- which means
they're the ones that should have the best understanding of all the
implications of policy changes like this. Is opt-in RBF only fine? If
you look at the network today, it sure seems like it; it takes a pretty
good technical understanding to figure out what problems it has, and
an even better one to figure out whether those problems can be solved
while keeping an opt-in RBF regime, or if full RBF is needed.

At that point, the technical experts *should* be coming up with a
specific recommendation, and, personally, I think that's exactly what
happened with [0] [1] and [2].

[0] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://github.com/bitcoin/bitcoin/pull/25353
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

That did draw hard line in the sand: it said "hey, opt-in RBF had a good
run, but it's time to switch over to full RBF, for these reasons".

It's a bit disappointing that the people that's a problem for didn't
engage earlier -- though looking back, I guess there wasn't all that
much effort made to reach out, either. There were two mentions in the
optech newsletter [3] [4] but it wasn't called out as an "action item"
(maybe those aren't a thing anymore), so it may have been pretty missable,
especially given RBF has been discussed on and off for so long. And the
impression I got from the PR review club discussion more seemed like
devs making assumptions about businesses rather than having talked to
them (eg "[I] think there are fewer and fewer businesses who absolutely
cannot survive without relying on zeroconf. Or at least hope so").

[3] https://bitcoinops.org/en/newsletters/2022/06/22/
[4] https://bitcoinops.org/en/newsletters/2022/07/13/

If we're happy to not get feedback until we start doing rcs, that's fine;
but if we want to say "oops, we're into release candidates, you should
have something earlier, it's too late now", that's a pretty closed-off
way of doing things.

And I mean: all this is only about drawing a line in *sand*; if people
think core devs are wrong, they can still let that line blow away in
the wind, by running different software, configuring core differently,
patching core, or whatever else.

> Moreover, relying on node operators turning on the setting
> provides a smoother approach offering time to zero-conf services to react
> in consequence.

I don't think that's remotely true: take a look at taproot activation:
it took two months between releasing code that supported signalling and
having 98% of hashrate signalling; with 40% of blocks signalling within
the first two weeks.

> So the current path definitely belongs more to a 3) approach.

> >  3) Encourage mainnet miners and relay nodes to support unconditional
> > RBF immediately, no matter how much that increases the risk to
> > existing businesses that are still accepting unconfirmed txs

Yes, that's how it appears to me, too. It's not my preference (giving
people clear warning of changes seems much better to me), but I can
certainly live with it.

But if the line in the sand is "we're