Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

[Peter Todd via bitcoin-dev]

On Thu, Jan 20, 2022 at 11:23:30AM -0800, Bram Cohen via bitcoin-dev wrote:
> > Nodes currently aren't required to keep around the whole blockchain, but
> > your proposal sounds like it would require them to. I think this could be
> > pretty detrimental to future scalability. Monero, for example, has a
> > situation where its UTXO set is the whole blockchain because you can't
> > generally know what has been spent and what hasn't been. Allowing
> > references to old blocks would pull in all this old block data into the
> > UTXO set. So unless you're very careful about how or when you can reference
> > old blocks, this could cause issues.
> >
> 
> Don't full nodes by definition have to have the whole chain? This does make
> pruned nodes difficult, but it could also have rules like you can only
> point back so far.

"you can only point back so far" leads to transactions becoming invalid, which
is something we've always strictly avoided because it can result in huge
problems during reorgs with transactions being unable to be included in a new
change. That's exactly why transaction expiry proposals have been shot down
over and over again.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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] CTV BIP review

[Eric Voskuil via bitcoin-dev]

> BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor 
> BIP9, so characterization one way or another is moot IMO.

 

For a selective definition of “based” you can draw any conclusion you desire. 
However I was very clear, as was Luke, and the history on this issue is equally 
clear, that the *only* material distinction (and the one that we are 
discussing) is activation with or without majority hash power support. BIP9/ST 
requires this support, BIP8 does not. The characterization is not moot. It is 
the central issue and always has been. There was no compromise on this question 
made in Taproot.

 

e

 

From: Billy Tetrud  
Sent: Thursday, January 20, 2022 7:23 AM



Thank you Eric for pointing out the factual errors in LukeJr's mention and 
implications around BIP8. The fact is that the ST pull request was described as 
  "BIP9-based". TBH BIP8 is also 
BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so 
characterization one way or another is moot IMO. In any case, I also agree with 
Michael that this isn't the place to have a long discussion about activation 
method. That discussion should be kept separate. I'd go so far to say that BIPs 
should not advocate for any particular activation method, but should only go so 
far as to mention what types of activation methods are possible (if some types 
aren't possible for some reason). Separation of concerns would be very useful 
on that front to reduce noise in conversations.

 

Thanks,

BT

 

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

Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

[Bram Cohen via bitcoin-dev]

On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud  wrote:

> > 'assert that my parent has a scriptpubkey of X'... That way you can, for
> example, have a UTXO which only allows itself to be absorbed by a
> transaction also involving a UTXO with a particular capability
>
> I'm not sure I fully follow. I usually think about covenants as having the
> reverse form, that a parent would assert "my children must have a script of
> the form XYZ". Are you saying you want to be able to specify that a UTXO
> can only be spent if the resulting outputs of that transaction all share
> the same script? I see this page
>  but i don't understand
> how those concepts relate to covenants.
>

Two concepts here. First of all Bitcoin doesn't have a strong single
concept of a 'parent', it just has transactions where all the parents lead
to all the children. For this sort of trickery to work more information
needs to be added to specify which of the inputs is the parent of each of
the outputs.

Second what in practice happens is that a coin can check what its own id
is, then verify the secure hash chain from its parent to itself so that it
knows what the parent looked like. For a Singleton it can then rely on the
fact that its ancestors enforced that they each only had one child to know
that it's the only descendant. In some sense this is like covenants which
point backwards in time although that information is already there in
principle because of the secure hash chain but hard to parse.


>
> >  allow references to old blocks so code snippets can be pulled out of
> them
>
> Nodes currently aren't required to keep around the whole blockchain, but
> your proposal sounds like it would require them to. I think this could be
> pretty detrimental to future scalability. Monero, for example, has a
> situation where its UTXO set is the whole blockchain because you can't
> generally know what has been spent and what hasn't been. Allowing
> references to old blocks would pull in all this old block data into the
> UTXO set. So unless you're very careful about how or when you can reference
> old blocks, this could cause issues.
>

Don't full nodes by definition have to have the whole chain? This does make
pruned nodes difficult, but it could also have rules like you can only
point back so far.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP review

[Anthony Towns via bitcoin-dev]

On Tue, Jan 18, 2022 at 03:54:21PM -0800, Jeremy via bitcoin-dev wrote:
> Some of it's kind of annoying because
> the legal definition of covenant is [...]
> so I do think things like CLTV/CSV are covenants

I think that in the context of Bitcoin, the most useful definition of
covenant is that it's when the scriptPubKey of a utxo restricts the
scriptPubKey in the output(s) of a tx spending that utxo.

CTV, TLUV, etc do that; CSV, CLTV don't. ("checksig" per se doesn't
either, though of course the signature that checksig uses does -- if that
signature is in the scriptPubKey rather than the scriptSig or witness,
that potentially becomes a covenant too)

Cheers,
aj

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

Re: [bitcoin-dev] CTV BIP review

[Billy Tetrud via bitcoin-dev]

I'm curious to hear clarification on most of Luke's non-activation related
comments.

> I would ideally like to see fully implemented BIPs for at least one of
these

While that would be interesting, I think that's a heavy burden to be placed
on this BIP. More in depth exploration would be helpful, but a fully
implemented BIP I think is more than necessary.

> Why is it a problem for them to use an Eltoo-like protocol?

I think he was saying it is a problem *unless* its an eltoo-like protocol.
Why I'm not sure. Maybe you can clarify Jeremy?

> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
added.

Even were these opcodes to be implemented in bitcoin, a script writer could
choose to not use them, making it still possible to use CTV to create
covenant chains with a finite number of steps.

>  w.r.t. the language cleanups... the legal definition of covenant ... I
do think things like CLTV/CSV are covenants

Maybe it would be useful to specify that these are "child covenants" or
"inherited covenants" or something like that, since unlike things like
CLTV, CTV and similar proposed opcodes place restrictions on the child
output of the output containing the opcode call, which is the interesting
unique behavior. Tho I don't think we need to be bound to the legal or
dictionary definition in usage of the word covenant in the realm of bitcoin
- its gonna have its own definition in this context anyway.

Thank you Eric for pointing out the factual errors in LukeJr's mention and
implications around BIP8. The fact is that the ST pull request was
described as "BIP9-based" .
TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8
nor BIP9, so characterization one way or another is moot IMO. In any case,
I also agree with Michael that this isn't the place to have a long
discussion about activation method. That discussion should be kept
separate. I'd go so far to say that BIPs should not advocate for any
particular activation method, but should only go so far as to mention what
types of activation methods are possible (if some types aren't possible for
some reason). Separation of concerns would be very useful on that front
to reduce noise in conversations.

Thanks,
BT


On Wed, Jan 19, 2022 at 6:37 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Eric, Luke
>
> Can I request that you don't discuss activation methods for future soft
> forks on a thread for CTV BIP review? I (and a number of others [0]) do not
> support an upcoming activation attempt of standalone OP_CTV. If you want to
> discuss activation methods for soft forks generally it would be much better
> if you set up a separate thread. OP_CTV is not the only current soft fork
> proposal and there will likely be more.
>
> The activation discussion for Taproot was deliberately kept separate from
> the review of the Taproot BIPs and implementation. It only commenced once
> there was overwhelming community consensus for the soft fork to be
> activated (months after in fact). Though you are free to discuss whatever
> topics you wish (obviously) discussing soft fork activation methods on a
> OP_CTV thread might give the mistaken impression that OP_CTV is the next
> soft fork to be activated which is mere speculation at this point. In an
> ideal world the promoters of OP_CTV would follow the strong precedent set
> by the authors and contributors to the Taproot BIPs but regrettably that
> seems to have gone out the window at this point.
>
> Thanks
> Michael
>
> [0]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ‐‐‐ Original Message ‐‐‐
>
> On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > -Original Message-
> >
> > From: Luke Dashjr l...@dashjr.org
> >
> > Sent: Tuesday, January 18, 2022 2:10 PM
> >
> > To: e...@voskuil.org
> >
> > Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org
> >
> > Subject: Re: [bitcoin-dev] CTV BIP review
> >
> > On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote:
> >
> > > The only material distinction between BIP9 and BIP8 is that the latter
> > >
> > > may activate without signaled support of hash power enforcement.
> > >
> > > As unenforced soft forks are not "backward compatible" they produce a
> > >
> > > chain split.
> >
> > Enforcement of the Bitcoin consensus protocol is by users, not miners.
>
> Given that I stated "hash power enforcement" it is quite clear that this is
>
> in fact only produced by mining. You are misrepresenting my statement to
>
> make an emotional appeal. Without "hash power enforcement", a soft fork is
>
> NOT backward compatible.
>
> "[enforcement of] consensus protocol" is of course by merchants, 

[bitcoin-dev] Highlighting Taproot implementation gotchas

[Michael Folkson via bitcoin-dev]

Hi

I'd just like to bring some attention to this blog post from the Suredbits team 
who when implementing Taproot in bitcoin-s found a mainnet output that did not 
conform to the BIP 340 specification [0] (invalid x coordinate) and hence were 
burned.

https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/

To be clear this is was an error made by an unknown developer rather than a bug 
in the Taproot BIPs or Core implementation.

I'd certainly encourage the community to share with this list mistakes they 
make or things they find confusing (i.e. stump them for long periods of time) 
when re-implementing Taproot or supporting Taproot in wallets. I suspect things 
like eliminating the key path [1] or eliminating the script path [2] will end 
up being common sources of confusion for wallets.

I'm also open to ideas on how there can be greater information sharing so 
Taproot implementers don't end up making the same mistakes or spending hours 
confused over the same things.

I've heard some feedback on a number of occasions now that the Taproot BIPs 
although thorough and exhaustive aren't geared directly towards implementers 
and adopters. We discussed this at an online Socratic last year [3] with Craig 
Raw an early Taproot adopter with Sparrow Wallet. The transcript of that links 
to a bunch of existing resources (StackExchange posts, the Optech series 
"Preparing for Taproot", Optech workshop etc) that may be useful for 
implementers.

wumpus also suggested that a new informational BIP might be a good idea as a 
first port of call for Taproot implementers who find BIP 340-342 dense and 
difficult to parse. This is certainly something we can do once it becomes 
clearer what that informational BIP should contain.

Of course the Libera IRC channels #bitcoin-dev (for general Bitcoin 
development) and #bitcoin-core-dev (for Core related development) are there for 
discussion and questions. And as many will already know Murch is tracking P2TR 
support on the Bitcoin wiki [4].

Thanks
Michael

[0]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
[1]: 
https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path
[2]: 
https://bitcoin.stackexchange.com/questions/99325/how-do-i-construct-a-p2tr-address-if-i-just-want-to-use-the-key-path
[3]: 
https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/
[4]: https://en.bitcoin.it/wiki/Bech32_adoption

-- Michael Folkson Email: michaelfolkson at 
[protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud via bitcoin-dev]

Thanks for the info.

> you could "sponsor yourself" directly or through a cycle involving > 1
txn.

Ah I see, because the sighash flags aren't used to create the TXID. I don't
really see the problem with cycles tho. Could a cycle cause problems for
anyone? Seems like it would be a harmless waste of bytes. The
fee-sponsoring OP_VER looks good too tho.

On Wed, Jan 19, 2022 at 2:08 PM Jeremy  wrote:

> SIGHASH_BUNDLE
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html
>
> By cycles I meant that if you commit to the sponsors by TXID from the
> witness, you could "sponsor yourself" directly or through a cycle involving
> > 1 txn.
>
> With OP_VER I was talking about the proposal I linked here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is
> in the output space, and uses TXIDs, it is cycle-free.
>
>
> --
> @JeremyRubin 
> 
>
>
> On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud 
> wrote:
>
>> Hmm, I don't know anything about  SIGHASH_BUNDLE. The only references
>> online I can find are just mentions (mostly from you). What is
>> SIGHASH_BUNDLE?
>>
>> > unless you're binding a WTXID
>>
>> That could work, but it would exclude cases where you have a transaction
>> that has already been partially signed and someone wants to, say, only sign
>> that transaction if some 3rd party signs a transaction paying part of the
>> fee for it. Kind of a niche use case, but it would be nice to support it if
>> possible. If the transaction hasn't been signed at all yet, a new
>> transaction can just be created that includes the prospective fee-payer,
>> and if the transaction is fully signed then it has a WTXID to use.
>>
>> > then you can have fee bumping cycles
>>
>> What kind of cycles do you mean? You're saying these cycles would make it
>> less robust to reorgs?
>>
>> > OP_VER
>>
>> I assume you mean something other than pushing the version onto the stack
>> ?
>> Is that related to your fee account idea?
>>
>>
>> On Wed, Jan 19, 2022 at 1:32 AM Jeremy  wrote:
>>
>>> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
>>> like proposals.
>>>
>>> For what you're discussing, I previously proposed
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>> which is similar.
>>>
>>> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue
>>> that unless you're binding a WTXID (which is maybe too specific?) then you
>>> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that
>>> you are acyclic.
>>>
>>> The difference between a fee account and this approach basically boils
>>> down to the impact on e.g. reorg stability, where the deposit/withdraw
>>> mechanism is a bit more "robust" for reorderings in reorgs than the in-band
>>> transaction approach, although they are very similar.
>>>
>>> --
>>> @JeremyRubin 
>>> 
>>>
>>>
>>> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud 
>>> wrote:
>>>
 >  because you make transactions third party malleable it becomes
 possible to bundle and unbundle transactions.

 What I was suggesting doesn't make it possible to malleate someone
 else's transaction. I guess maybe my proposal of using a sighash flag
 might have been unclear. Imagine it as a script opcode that just says "this
 transaction must be mined with this other transaction" - the only
 difference being that you can use any output with any encumberance as an
 input for fee bumping. It doesn't prevent the original transaction from
 being mined on its own. So adding junk inputs would be no more of a problem
 than dust attacks already are. It would be used exactly like cpfp, except
 it doesn't spend the parent.

 I don't think what I was suggesting is as different from your proposal.
 All the problems of fee revenue optimization and feerate rules that you
 mentioned seem like they'd also exist for your proposal, or for cpfp. Let
 me know if I should clarify further.

 On Tue, Jan 18, 2022 at 8:51 PM Jeremy  wrote:

> The issue with sighash flags is that because you make transactions
> third party malleable it becomes possible to bundle and unbundle
> transactions.
>
> This means there are circumstances where an attacker could e.g. see
> your txn, and then add a lot of junk change/inputs + 25 descendants and
> strongly anchor your transaction to the bottom of the mempool.
>
> because of rbf rules requiring more fee and feerate, this means you
> have to bump across the whole package and that can get really messy.
>
> more generally speaking, yo