Re: [bitcoin-dev] bitcoin scripting and lisp

[Anthony Towns via bitcoin-dev]

On Tue, Mar 08, 2022 at 06:54:56PM -0800, Bram Cohen via bitcoin-dev wrote:
> On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns  wrote:
> > One way to match the way bitcoin do things, you could have the "list of
> > extra conditions" encoded explicitly in the transaction via the annex,
> > and then check the extra conditions when the script is executed.
> The conditions are already basically what's in transactions. I think the
> only thing missing is the assertion about one's own id, which could be
> added in by, in addition to passing the scriptpubkey the transaction it's
> part of, also passing in the index of inputs which it itself is.

To redo the singleton pattern in bitcoin's context, I think you'd have
to pass in both the full tx you're spending (to be able to get the
txid of its parent) and the full tx of its parent (to be able to get
the scriptPubKey that your utxo spent) which seems klunky but at least
possible (you'd be able to drop the witness data at least; without that
every tx would be including the entire history of the singleton).

> > > A nice side benefit of sticking with the UTXO model is that the soft fork
> > > hook can be that all unknown opcodes make the entire thing automatically
> > > pass.
> > I don't think that works well if you want to allow the spender (the
> > puzzle solution) to be able to use opcodes introduced in a soft-fork
> > (eg, for graftroot-like behaviour)?
> This is already the approach to soft forking in Bitcoin script and I don't
> see anything wrong with it.

It's fine in Bitcoin script, because the scriptPubKey already commits to
all the opcodes that can possibly be used for any particular output. With
a lisp approach, however, you could pass in additional code fragments
to execute. For example, where you currently say:

  script: [pubkey] CHECKSIG
  witness: [64B signature][0x83]

(where 0x83 is SINGLE|ANYONECANPAY) you might translate that to:

  script: (checksig pubkey (bip342-txmsg 3) 2)
  witness: signature 0x83

where "3" grabs the sighash byte, and "2" grabs the signature. But you
could also translate it to:

  script: (checksig pubkey (sha256 3 (a 3)) 2)
  witness: signature (bip342-txmsg 0x83)

where "a 3" takes "(bip342-txmsg 0x83)" then evaluates it, and (sha256
3 (a 3)) makes sure you've signed off on both how the message was
constructed as well as what the message was. The advantage there is that
the spender can then create their own signature hashes however they like;
even ones that hadn't been thought of when the output was created.

But what if we later softfork in a bip118-txmsg for quick and easy
ANYPREVOUT style-signatures, and want to use that instead of custom
lisp code? You can't just stick (softfork C (bip118-txmsg 0xc3)) into
the witness, because it will evaluate to nil and you won't be signing
anything. But you *could* change the script to something like:

  script: (softfork C (q checksigverify pubkey (a 3) 2))
  witness: signature (bip118-txmsg 0xc3)

But what happens if the witness instead has:

  script: (softfork C (q checksigverify pubkey (a 3) 2))
  witness: fake-signature (fakeopcode 0xff)

If softfork is just doing a best effort for whatever opcodes it knows
about, and otherwise succeeding, then it has to succeed, and your
script/output has become anyone-can-spend.

On the other hand, if you could tell the softfork op that you only wanted
ops up-to-and-including the 118 softfork, then it could reject fakeopcode
and fail the script, which I think gives the desirable behaviour.

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

Re: [bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT)

[ZmnSCPxj via bitcoin-dev]

Good morning Billy,

> Hi ZmnSCPxj,
>
> >  Just ask a bunch of fullnodes to add this 1Mb of extra ignored data in 
> >this tiny 1-input-1-output transaction so I pay only a small fee
>
> I'm not suggesting that you wouldn't have to pay a fee for it. You'd pay a 
> fee for it as normal, so there's no DOS vector. Doesn't adding extra witness 
> data do what would be needed here? Eg simply adding extra data onto the 
> witness script that will remain unconsumed after successful execution of the 
> script?

I think we would want to have a cleanstack rule at some point (do not remember 
out-of-hand if Taproot already enforces one).

So now being nice to the network is *more* costly?
That just *dis*incentivizes jet usage.

> > how do new jets get introduced?
>
> In scenario A, new jets get introduced by being added to bitcoin software as 
> basically relay rules. 
>
> > If a new jet requires coordinated deployment over the network, then you 
> > might as well just softfork and be done with it.
>
> It would not need a coordinated deployment. However, the more nodes that 
> supported that jet, the more efficient using it would be for the network. 
>
> > If a new jet can just be entered into some configuration file, how do you 
> > coordinate those between multiple users so that there *is* some benefit for 
> > relay?
>
> When a new version of bitcoin comes out, people generally upgrade to it 
> eventually. No coordination is needed. 100% of the network need not support a 
> jet. Just some critical mass to get some benefit. 

How large is the critical mass needed?

If you use witness to transport jet information across non-upgraded nodes, then 
that disincentivizes use of jets and you can only incentivize jets by softfork, 
so you might as well just get a softfork.

If you have no way to transport jet information from an upgraded through a 
non-upgraded back to an upgraded node, then I think you need a fairly large 
buy-in from users before non-upgraded nodes are rare enough that relay is not 
much affected, and if the required buy-in is large enough, you might as well 
softfork.

> > Having a static lookup table is better since you can pattern-match on 
> > strings of specific, static length
>
> Sorry, better than what exactly? 

Than using a dynamic lookup table, which is how I understood your previous 
email about "scripts in the 1000 past blocks".

> > How does the unupgraded-to-upgraded boundary work?
> 
> When the non-jet aware node sends this to a jet-aware node, that node would 
> see the extra items on the stack after script execution, and would interpret 
> them as an OP_JET call specifying that OP_JET should replace the witness 
> items starting at index 0 with `1b5f03cf  OP_JET`. It does this and then 
> sends that along to the next hop.

It would have to validate as well that the SCRIPT sub-section matches the jet, 
else I could pretend to be a non-jet-aware node and give you a SCRIPT 
sub-section that does not match the jet and would cause your validation to 
diverge from other nodes.

Adler32 seems a bit short though, it seems to me that it may lead to two 
different SCRIPT subsections hashing to the same hash.

Suppose I have two different node softwares.
One uses a particular interpretation for a particular Adler32 hash.
The other uses a different interpretation.
If we are not careful, if these two jet-aware software talk to each other, they 
will ban each other from the network and cause a chainsplit.
Since the Bitcoin software is open source, nothing prevents anyone from using a 
different SCRIPT subsection for a particular Adler32 hash if they find a 
collision and can somehow convince people to run their modified software.

> In order to support this without a soft fork, this extra otherwise 
> unnecessary data would be needed, but for jets that represent long scripts, 
> the extra witness data could be well worth it (for the network). 
>
> However, this extra data would be a disincentive to do transactions this way, 
> even when its better for the network. So it might not be worth doing it this 
> way without a soft fork. But with a soft fork to upgrade nodes to support an 
> OP_JET opcode, the extra witness data can be removed (replaced with 
> out-of-band script fragment transmission for nodes that don't support a 
> particular jet). 

Which is why I pointed out that each individual jet may very well require a 
softfork, or enough buy-in that you might as well just softfork.

> One interesting additional thing that could be done with this mechanism is to 
> add higher-order function ability to jets, which could allow nodes to add 
> OP_FOLD or similar functions as a jet without requiring additional soft 
> forks.  Hypothetically, you could imagine a jet script that uses an OP_LOOP 
> jet be written as follows:
>
> 5             # Loop 5 times
> 1             # Loop the next 1 operation
> 3c1g14ad 
> OP_JET
> OP_ADD  # The 1 operation to loop
>
> The above would sum up 5 numbers from the 

Re: [bitcoin-dev] Decentralized BIP 47 payment code directory

[Prayank via bitcoin-dev]

Hi Peter,

> Regarding to BIP47 there's a newer version (v3 and v4) proposed here: 
> https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki

> Now the notification from Alice to Bob is a transaction from Alice to Alice 
> as a bare 1 of 3 multisig. The other 2 pubkeys represent Alice's payment code 
> and Bob's payment identifier. Eliminating the toxic change issue.

Thanks for sharing the link. Removing toxic change sounds good and certainly an 
improvement.

> An xpub doesn't accomplish this because if you have your xpub in a 
> crowdfunding platform the platform or anyone who hacks it can identify your 
> payments. With the payment code you can associate yourself publicly with your 
> payment code and no one (who is not the sender) will know if you received 
> funds as your payment code is not visible in the blockchain.

Crowdfunding platform can also be self hosted like BTCPay server. In this case 
XPUB is not shared with anyone as long as machine running BTCPay is secure. 
Problem with this setup is users need to setup BTCPay, running all the time and 
manage gap limit. No such thing is required in using BIP 47 payment codes.

There is also a [rust library][1] to use BIP 47 and I found the link on twitter 
yesterday. I think this can be helpful for application developers to implement 
BIP 47 payment codes in different bitcoin projects.

[1]: https://github.com/rust-bitcoin/rust-bip47


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Wasabi Wallet 2.0 Testnet Release

[Prayank via bitcoin-dev]

Hi Max,

> Whenever the user wants to spend bitcoin to an address, the wallet 
> automatically selects those private coins with sufficient sats, coin control 
> is displayed to the user.

1.There are no 'private' coins. Every coin is public in Bitcoin.

2.Since, the wallet assumes some coins as 'private' based on certain things it 
can be misleading for the user. Privacy depends on the things users want to 
share with others.

3.There is no coin control in Wasabi Wallet 2. 

> However, when the private balance is insufficient to make the payment, the 
> user has the option to adjust the coin selection with the help of the 
> previously provided contact labels.

User does not select coins because they are never shared with the user in the 
first place.

[Selecting some labels][1] with misleading text 'who can see this transaction' 
does not look helpful.

> Wasabi also suggests the user to slightly adjust the payment amount so as to 
> avoid the creation of a change utxo, decreasing fees and improving future 
> privacy.

Privacy involved in using a change or not using it is debatable. Not using a 
change address makes it easier to understand who might be the recipient in a 
transaction whereas using a change address same as other outputs would be 
difficult to analyze for possible recipients.

Wasabi wallet does not have different types of addresses to use for a change 
however [Bitcoin Core][2] recently made some related improvement which would 
improve privacy.

> We kindly ask for your help testing the completely new UI/UX

As WW2 is not developed for power users (mentioned by developers working on 
Wasabi), I am not sure if bitcoin dev mailing list would be the best place to 
look for newbies. As far as issues are concerned, there are several things not 
fixed and shared in different GitHub issues or discussions. These include 
privacy, security and other things.


[1]: https://i.imgur.com/Gxjmhau.png
[2]: https://github.com/bitcoin/bitcoin/pull/23789


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving RBF Policy

[Gloria Zhao via bitcoin-dev]

Hi RBF friends,

Posting a summary of RBF discussions at coredev (mostly on transaction
relay rate-limiting), user-elected descendant limit as a short term
solution to unblock package RBF, and mining score, all open for feedback:

One big concept discussed was baking DoS protection into the p2p level
rather than policy level. TLDR: The fees are not paid to the node operator,
but to the miner. While we can use fees to reason about the cost of an
attack, if we're ultimately interested in preventing resource exhaustion,
maybe we want to "stop the bleeding" when it happens and bound the amount
of resources used in general. There were two main ideas:

1. Transaction relay rate limiting (i.e. the one you proposed above or some
variation) with a feerate-based priority queue
2. Staggered broadcast of replacement transactions: within some time
interval, maybe accept multiple replacements for the same prevout, but only
relay the original transaction.

Looking to solicit feedback on these ideas and the concept in general. Is
it a good idea (separate from RBF) to add rate-limiting in transaction
relay? And is it the right direction to think about RBF DoS protection this
way?

A lingering concern that I have about this idea is it would then be
possible to impact the propagation of another person’s transaction, i.e.,
an attacker can censor somebody’s transaction from ever being announced by
a node if they send enough transactions to fill up the rate limit.
Obviously this would be expensive since they're spending a lot on fees, but
I imagine it could be profitable in some situations to spend a few thousand
dollars to prevent anyone from hearing about a transaction for a few hours.
This might be a non-issue in practice if the rate limit is generous and
traffic isn’t horrendous, but is this a problem?

And if we don't require an increase in (i.e. addition of "new") absolute
fees, users are essentially allowed to “recycle” fees. In the scenario
where we prioritize relay based on feerate, users could potentially be
placed higher in the queue, ahead of other users’ transactions, multiple
times, without ever adding more fees to the transaction. Again, maybe this
isn’t a huge deal in practice if we set the parameters right, but it seems…
not great, in principle.

-

It's probably also a good idea to point out that there's been some
discussion happening on the gist containing my original post on this thread
(https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff).

Suhas and Matt [proposed][0] adding a policy rule allowing users to specify
descendant limits on their transactions. For example, some nth bit of
nSequence with nVersion 3 means "this transaction won't have more than X
vbytes of descendants" where X = max(1000, vsizeof(tx)) or something. It
solves the pinning problem with package RBF where the attacker's package
contains a very large and high-fee descendant.

We could add this policy and deploy it with package RBF/package relay so
that LN can use it by setting the user-elected descendant limit flag on
commitment transactions. (Otherwise package RBF is blocked until we find a
more comprehensive solution to the pinning attack).

It's simple to [implement][1] as a mempool policy, but adds some complexity
for wallets that use it, since it limits their use of UTXOs from
transactions with this bit set.

-

Also, coming back to the idea of "we can't just use {individual, ancestor}
feerate," I'm interested in soliciting feedback on adding a “mining score”
calculator. I've implemented one [here][2] which takes the transaction in
question, grabs all of the connected mempool transactions (including
siblings, coparents, etc., as they wouldn’t be in the ancestor nor
descendant sets), and builds a “block template” using our current mining
algorithm. The mining score of a transaction is the ancestor feerate at
which it is included.

This would be helpful for something like ancestor-aware funding and
fee-bumping in the wallet: [3], [4]. I think if we did the rate-limited
priority queue for transaction relay, we'd want to use something like this
as the priority value. And for RBF, we probably want to require that a
replacement have a higher mining score than the original transactions. This
could be computationally expensive to do all the time; it could be good to
cache it but that could make mempool bookkeeping more complicated. Also, if
we end up trying to switch to a candidate set-based algorithm for mining,
we'd of course need a new calculator.

[0]:
https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4058140#gistcomment-4058140
[1]: https://github.com/glozow/bitcoin/tree/2022-02-user-desclimit
[2] https://github.com/glozow/bitcoin/tree/2022-02-mining-score
[3]: https://github.com/bitcoin/bitcoin/issues/9645
[4]: https://github.com/bitcoin/bitcoin/issues/15553

Best,
Gloria

On Tue, Feb 8, 2022 at 4:58 AM Anthony Towns  wrote:

> On Mon, Feb 07, 2022 at 11:16:26AM +, 

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[ZmnSCPxj via bitcoin-dev]

Good morning Jorge,

> What is ST? If it may be a reason to oppose CTV, why not talk about it more 
> explicitly so that others can understand the criticisms?

ST is Speedy Trial.
Basically, a short softfork attempt with `lockinontimeout=false` is first done.
If this fails, then developers stop and think and decide whether to offer a 
UASF `lockinontimeout=true` version or not.

Jeremy showed a state diagram of Speedy Trial on the IRC, which was complicated 
enough that I ***joked*** that it would be better to not implement `OP_CTV` and 
just use One OPCODE To Rule Them All, a.k.a. `OP_RING`.

If you had actually read the IRC logs you would have understood it, I even 
explicitly asked "ST ?=" so that the IRC logs have it explicitly listed as 
"Speedy Trial".


> It seems that criticism isn't really that welcomed and is just explained away.

It seems that you are trying to grasp at any criticism and thus fell victim to 
a joke.

> Perhaps it is just my subjective perception.
> Sometimes it feels we're going from "don't trust, verify" to "just trust 
> jeremy rubin", i hope this is really just my subjective perception. Because I 
> think it would be really bad that we started to blindly trust people like 
> that, and specially jeremy.

Why "specially jeremy"?
Any particular information you think is relevant?

The IRC logs were linked, you know, you could have seen what was discussed.

In particular, on the other thread you mention:

> We should talk more about activation mechanisms and how users should be able 
> to actively resist them more.

Speedy Trial means that users with mining hashpower can block the initial 
Speedy Trial, and the failure to lock in ***should*** cause the developers to 
stop-and-listen.
If the developers fail to stop-and-listen, then a counter-UASF can be written 
which *rejects* blocks signalling *for* the upgrade, which will chainsplit from 
a pro-UASF `lockinontimeout=true`, but clients using the initial Speedy Trial 
code will follow which one has better hashpower.

If we assume that hashpower follows price, then users who want for / against a 
particular softfork will be able to resist the Speedy Trial, and if developers 
release a UASF `lockinontimeout=true` later, will have the choice to reject 
running the UASF and even running a counter-UASF.


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

Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

[Michael Folkson via bitcoin-dev]

Hi Jorge

> Since this has meetings like taproot, it seems it's going to end up being 
> added in bitcoin core no matter what.

Anyone can set up a IRC channel, anyone can organize a IRC meeting, anyone can 
announce meetings on the mailing list. Just because an individual is 
enthusiastic for a soft fork proposal does not imply it has community consensus 
or that it is likely to be merged into Core in the short term or long term. It 
is true that other soft fork proposal authors/contributors are not taking the 
approach Jeremy is taking and are instead working quietly in the background. I 
prefer the latter approach so soon after Taproot activation but I look forward 
to hearing about the progress made on other proposals in due course.

> Should we start the conversation on how to resist it when that happens?
We should talk more about activation mechanisms and how users should be able to 
actively resist them more.

I can only speak for myself but if activation was being pursued for a soft fork 
that didn't have community consensus I would seek to join you in an effort to 
resist that activation. Taproot (pre-activation discussion) set a strong 
precedent in terms of community outreach and patiently building community 
consensus over many years. If that precedent was thrown out I think we are in 
danger of creating the chaos that most of us would seek to avoid. You are free 
to start whatever conversation you want but personally until Jeremy or whoever 
else embarks on an activation attempt I'd rather forget about activation 
discussions for a while.

> What is ST? If it may be a reason to oppose CTV, why not talk about it more 
> explicitly so that others can understand the criticisms?

ST is short for Speedy Trial, the activation mechanism used for Taproot. I have 
implored people on many occasions now to not mix discussion of a soft fork 
proposal with discussion of an activation mechanism. Those discussions can 
happen in parallel but they are entirely independent topics of discussion. 
Mixing them is misleading at best and manipulative at worst.

> It seems that criticism isn't really that welcomed and is just explained away.
Perhaps it is just my subjective perception. Sometimes it feels we're going 
from "don't trust, verify" to "just trust jeremy rubin", i hope this is really 
just my subjective perception. Because I think it would be really bad that we 
started to blindly trust people like that, and specially jeremy.

I think we should generally avoid getting personal on this mailing list. 
However, although I agree that Jeremy has done some things in the past that 
have been over-exuberant to put it mildly, as long as he listens to community 
feedback and doesn't try to force through a contentious soft fork earlier than 
the community is comfortable with I think his work can add material value to 
the future soft fork discussion. I entirely agree that we can't get into a 
situation where any one individual can push through a soft fork without getting 
community consensus and deep technical review from as many qualified people as 
possible. That can take a long time (the demands on long term contributors' 
time are vast) and hence anyone without serious levels of patience should 
probably exclusively work on sidechains, altcoins etc (or non-consensus changes 
in Bitcoin) rather than Bitcoin consensus changes.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Timón via bitcoin-dev 
 wrote:

> Since this has meetings like taproot, it seems it's going to end up being 
> added in bitcoin core no matter what.
>
> Should we start the conversation on how to resist it when that happens?
> We should talk more about activation mechanisms and how users should be able 
> to actively resist them more.
>
> On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev 
>  wrote:
>
>> * Tuesday, March 8th.
>>
>> I think Noon PT == 8pm UTC?
>>
>> but dont trust me i cant even tell what day is what.
>> --
>> [@JeremyRubin](https://twitter.com/JeremyRubin)
>>
>> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin  wrote:
>>
>>> Hi all,
>>>
>>> There will be a CTV meeting tomorrow at noon PT. Agenda below:
>>>
>>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
>>> - Experimental support for Taproot merged on master 
>>> https://github.com/sapio-lang/sapio
>>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
>>> - 
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>>> - 
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
>>> - 
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
>>> 4) What the heck is everyone talking about on the mailing 

Re: [bitcoin-dev] bitcoin scripting and lisp

[ZmnSCPxj via bitcoin-dev]

Good morning Bram,

> On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj  wrote:
>
> > But cross-input signature aggregation is a nice-to-have we want for 
> > Bitcoin, and, to me, cross-input sigagg is not much different from 
> > cross-input puzzle/solution compression.
>
> Cross-input signature aggregation has a lot of headaches unless you're using 
> BLS signatures, in which case you always aggregate everything all the time 
> because it can be done after the fact noninteractively. In that case it makes 
> sense to have a special aggregated signature which always comes with a 
> transaction or block. But it might be a bit much to bundle both lisp and BLS 
> support into one big glop.

You misunderstand my point.

I am not saying "we should add sigagg and lisp together!"

I am pointing out that:

* We want to save bytes by having multiple inputs of a transaction use the same 
single signature (i.e. sigagg).

is not much different from:

* We want to save bytes by having multiple inputs of a transaction use the same 
`scriptPubKey` template.

> > For example you might have multiple HTLCs, with mostly the same code except 
> > for details like who the acceptor and offerrer are, exact hash, and 
> > timelock, and you could claim multiple HTLCs in a single tx and feed the 
> > details separately but the code for the HTLC is common to all of the HTLCs.
> > You do not even need to come from the same protocol if multiple protocols 
> > use the same code for implementing HTLC.
>
> HTLCs, at least in Chia, have embarrassingly little code in them. Like, so 
> little that there's almost nothing to compress.

In Bitcoin at least an HTLC has, if you remove the `OP_PUSH`es, by my count, 13 
bytes.
If you have a bunch of HTLCs you want to claim, you can reduce your witness 
data by 13 bytes minus whatever number of bytes you need to indicate this.
That amounts to about 3 vbytes per HTLC, which can be significant enough to be 
worth it (consider that Taproot moving away from encoded signatures saves only 
9 weight units per signature, i.e. about 2 vbytes).

Do note that PTLCs remain more space-efficient though, so forget about HTLCs 
and just use PTLCs.

>
> > This does not apply to current Bitcoin since we no longer accept a SCRIPT 
> > from the spender, we now have a witness stack.
>
> My mental model of Bitcoin is to pretend that segwit was always there and the 
> separation of different sections of data is a semantic quibble.

This is not a semantic quibble --- `witness` contains only the equivalent of 
`OP_PUSH`es, while `scriptSig` can in theory contain non-`OP_PUSH` opcodes.
xref. `1 RETURN`.

As-is, with SegWit the spender no longer is able to provide any SCRIPT at all, 
but new opcodes may allow the spender to effectively inject any SCRIPT they 
want, once again, because `witness` data may now become code.

> But if they're fully baked into the scriptpubkey then they're opted into by 
> the recipient and there aren't any weird surprises.

This is really what I kinda object to.
Yes, "buyer beware", but consider that as the covenant complexity increases, 
the probability of bugs, intentional or not, sneaking in, increases as well.
And a bug is really "a weird surprise" --- xref TheDAO incident.

This makes me kinda wary of using such covenant features at all, and if stuff 
like `SIGHASH_ANYPREVOUT` or `OP_CHECKTEMPLATEVERIFY` are not added but must be 
reimplemented via a covenant feature, I would be saddened, as I now have to 
contend with the complexity of covenant features and carefully check that 
`SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were implemented correctly.
True I also still have to check the C++ source code if they are implemented 
directly as opcodes, but I can read C++ better than frikkin Bitcoin SCRIPT.
Not to mention that I now have to review both the (more complicated due to more 
general) covenant feature implementation, *and* the implementation of 
`SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` in terms of the covenant feature.

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

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[Jorge Timón via bitcoin-dev]

What is ST? If it may be a reason to oppose CTV, why not talk about it more
explicitly so that others can understand the criticisms?
It seems that criticism isn't really that welcomed and is just explained
away.
Perhaps it is just my subjective perception.
Sometimes it feels we're going from "don't trust, verify" to "just trust
jeremy rubin", i hope this is really just my subjective perception. Because
I think it would be really bad that we started to blindly trust people like
that, and specially jeremy.


On Wed, Mar 9, 2022, 00:37 Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Logs here: https://gnusha.org/ctv-bip-review/2022-03-08.log
>
> Notes:
>
> 1) Sapio Updates
>
> Sapio has Experimental Taproot Support now.
> See logs for how to help.
> Rust-bitcoin can also use your help reviewing, e.g.
> https://github.com/rust-bitcoin/rust-miniscript/pull/305
> Adding MuSig support for the oracle servers would be really cool, if
> someone wants a challenge.
>
> 2) Transaction Sponsors
>
> What sponsors are vs. RBF/CPFP.
> Why there's not a BIP # assigned (despite it being written up as a
> BIP+impl in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html,
> should only get a number if it seems like people agree).
>
> 3) James' Vaults Post
>
> James' vaults are similar to prior art on recursive CTV vaults (Kanzure's
> / Jeremy's), where the number of steps = 1.
> Actually ends up being a very good design for many custody purposes, might
> be a good "80% of the benefit 20% of the work" type of thing.
> People maybe want different things out of vaults... how customizable must
> it be?
>
> 4) Mailing list be poppin'
>
> Zmn shared a prepared remark which spurred a nice conversation.
> General sentiment that we should be careful adding crazy amounts of power,
> with great power comes great responsibility...
> Maybe we shouldn't care though -- don't send to scripts you don't like?
> Math is scary -- you can do all sorts of bizarre stuff with more power
> (e.g., what if you made an EVM inside a bitcoin output).
> Things like OP_EVICT should be bounded by design.
> Problem X: Infrastructure issue for all more flexible covenants:
>1) generate a transition function you would like
>2) compile it into a script covenant
>3) request the transition/txn you want to have happen
> 4) produce a satisifaction of the script covenant for that transaction
>5) prove the transition function *is* what you wanted/secure
> Quantifying how hard X is for a given proposal is a good idea.
> You can prototype covenants with federations in Sapio pretty easily...
> more people should try this!
>
> 5) General discuss
> People suck at naming things... give things more unique names for
> protocols!
> Jeremy will name something the Hot Tub Coin Machine
> Some discussion on forking, if theres any kind of consensus forming,
> doing things like
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html
> How much does a shot-on-goal cost / unforced errors of not making an
> activating client available precluding being able to activate
> luke-jr: never ST; ST is a reason enough to oppose CTV
> jamesob:  OP_DOTHETHING
>
> best,
>
> Jeremy
>
> --
> @JeremyRubin 
> ___
> 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] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

[Jorge Timón via bitcoin-dev]

Since this has meetings like taproot, it seems it's going to end up being
added in bitcoin core no matter what.

Should we start the conversation on how to resist it when that happens?
We should talk more about activation mechanisms and how users should be
able to actively resist them more.


On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> * Tuesday, March 8th.
>
> I think Noon PT == 8pm UTC?
>
> but dont trust me i cant even tell what day is what.
> --
> @JeremyRubin 
>
>
> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin 
> wrote:
>
>> Hi all,
>>
>> There will be a CTV meeting tomorrow at noon PT. Agenda below:
>>
>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
>> - Experimental support for Taproot merged on master
>> https://github.com/sapio-lang/sapio
>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
>> -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>> -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
>> -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
>> 4) What the heck is everyone talking about on the mailing list all of the
>> sudden (30 minutes)
>> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
>> 5) Q (30 mins)
>>
>> Best,
>>
>> Jeremy
>>
>>
>> --
>> @JeremyRubin 
>>
> ___
> 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] bitcoin scripting and lisp

[Bram Cohen via bitcoin-dev]

On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj  wrote:

>
> But cross-input signature aggregation is a nice-to-have we want for
> Bitcoin, and, to me, cross-input sigagg is not much different from
> cross-input puzzle/solution compression.
>

Cross-input signature aggregation has a lot of headaches unless you're
using BLS signatures, in which case you always aggregate everything all the
time because it can be done after the fact noninteractively. In that case
it makes sense to have a special aggregated signature which always comes
with a transaction or block. But it might be a bit much to bundle both lisp
and BLS support into one big glop.



>
> For example you might have multiple HTLCs, with mostly the same code
> except for details like who the acceptor and offerrer are, exact hash, and
> timelock, and you could claim multiple HTLCs in a single tx and feed the
> details separately but the code for the HTLC is common to all of the HTLCs.
> You do not even need to come from the same protocol if multiple protocols
> use the same code for implementing HTLC.
>

HTLCs, at least in Chia, have embarrassingly little code in them. Like, so
little that there's almost nothing to compress.


> This does not apply to current Bitcoin since we no longer accept a SCRIPT
> from the spender, we now have a witness stack.
>

My mental model of Bitcoin is to pretend that segwit was always there and
the separation of different sections of data is a semantic quibble.


> So this seems to be more like "do not write broken SCRIPTs"?
>

In general if people footgun that's their own fault. The resistance to
covenants and capabilities in the past has largely been around what would
happen if you had opt-out covenants which acted as riders and could monkey
around in later spends which were none of their business. But if they're
fully baked into the scriptpubkey then they're opted into by the recipient
and there aren't any weird surprises.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[Bram Cohen via bitcoin-dev]

On Mon, Mar 7, 2022 at 2:56 PM ZmnSCPxj  wrote:

>
> > while in the coin set model each puzzle (scriptpubkey) gets run and
> either assert fails or returns a list of extra conditions it has, possibly
> including timelocks and creating new coins, paying fees, and other things.
>
> Does this mean it basically gets recursive covenants?
> Or is a condition in this list of conditions written a more restrictive
> language which itself cannot return a list of conditions?
>

The conditions language is extremely restrictive but does allow for
recursive covenants through the route of specifying output
scriptpubkeys/puzzles, which Bitcoin already sort of in principle supports
except that Bitcoin script's ability to generate and parse transactions
isn't quite up to the task.


> > A lot of this is because there's a hook for doing compression at the
> consensus layer which isn't being used aggressively yet. That one has the
> downside that the combined cost of transactions can add up very
> nonlinearly, but when you have constantly repeated bits of large
> boilerplate it gets close and there isn't much of an alternative. That said
> even with that form of compression maxxed out it's likely that gzip could
> still do some compression but that would be better done in the database and
> in wire protocol formats rather than changing the format which is hashed at
> the consensus layer.
>
> How different is this from "jets" as proposed in Simplicity?
>

My vague impression is that Simplicity jets are meant to be for things like
Sha3 rather than shared library code. It might be that the way to use it
would be to implement CLVM opcodes be a bunch of Simplicity jets. Whether
that would be making the CLVM irrelevant or going through a pointless bit
of theatre to be based on Simplicity under the hood I don't know.

The compression hook is that in each block instead of there being a list of
puzzle reveals and solutions there's a generator written in CLVM which
outputs that list, and it can be passed the generators of old blocks from
which it can pull out code snippits.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[Bram Cohen via bitcoin-dev]

On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns  wrote:

> One way to match the way bitcoin do things, you could have the "list of
> extra conditions" encoded explicitly in the transaction via the annex,
> and then check the extra conditions when the script is executed.
>

The conditions are already basically what's in transactions. I think the
only thing missing is the assertion about one's own id, which could be
added in by, in addition to passing the scriptpubkey the transaction it's
part of, also passing in the index of inputs which it itself is.


>
> > If you're doing everything from scratch it's cleaner to go with the coin
> > set model, but retrofitting onto existing Bitcoin it may be best to leave
> > the UTXO model intact and compensate by adding a bunch more opcodes which
> > are special to parsing Bitcoin transactions. The transaction format
> itself
> > can be mostly left alone but to enable some of the extra tricks (mostly
> > implementing capabilities) it's probably a good idea to make new
> > conventions for how a transaction can have advisory information which
> > specifies which of the inputs to a transaction is the parent of a
> specific
> > output and also info which is used for communication between the UTXOs
> in a
> > transaction.
>
> I think the parent/child coin relationship is only interesting when
> "unrelated" spends can assert that the child coin is being created -- ie
> things along the lines of the "transaction sponsorship" proposal. My
> feeling is that complicates the mempool a bit much, so is best left for
> later, if done at all.
>

The parent/child relationship is mostly about implementing capabilities.
There's this fundamental trick, sort of the ollie of UTXO programming,
where to make a coin have a capability you have a wrapper around an inner
puzzle for it where the wrapper asserts 'my parent must either be the
unique originator of this capability or also have this same wrapper' and it
enforces that by being given a reveal of its parent and told/asserting its
own id which it can derive from that parent. The main benefit of the coin
set approach over UTXO is that it reduces the amount of stuff to be
revealed and string mangling involved in the parentage check.


>
> (I think the hard part of managing the extra conditions is mostly
> in keeping it efficient to manage the mempool and construct the most
> profitable blocks/bundles, rather than where the data goes)
>

Not sure what you mean by this. Conditions map fairly closely with what's
in Bitcoin transactions and are designed so to be monotonic and so the
costs and fees are known up front. The only way two transactions can
conflict with each other is if they both try to spend the same coin.


> > They're radically different approaches and
> > it's hard to see how they mix. Everything in lisp is completely
> sandboxed,
> > and that functionality is important to a lot of things, and it's really
> > normal to be given a reveal of a scriptpubkey and be able to rely on your
> > parsing of it.
>
> The above prevents combining puzzles/solutions from multiple coin spends,
> but I don't think that's very attractive in bitcoin's context, the way
> it is for chia. I don't think it loses much else?
>

Making something lisp-based be a completely alternative script type would
also be my preferred approach.


> > A nice side benefit of sticking with the UTXO model is that the soft fork
> > hook can be that all unknown opcodes make the entire thing automatically
> > pass.
>
> I don't think that works well if you want to allow the spender (the
> puzzle solution) to be able to use opcodes introduced in a soft-fork
> (eg, for graftroot-like behaviour)?
>

This is already the approach to soft forking in Bitcoin script and I don't
see anything wrong with it. You shouldn't write scripts using previously
unrecognized opcodes until after they've been soft forked into having real
functionality, and if you do that and accidentally write an anyonecanspend
that's your own fault.


> Having third parties be able to link their spends to yours complicates
> mempool behaviour a fair bit (see the discussions on pinning wrt
> lightning txs -- and that's only with direct participants being able to
> link transactions).


Bitcoin already has that with spending of transaction outputs, and Chia's
mempool doesn't currently let transactions depend on other transactions in
the mempool. If you do have that sort of dependency, you should have to
smush both transactions together to make a single larger transaction and
make it have enough of a fee to replace the smaller one.

I'm pretty skeptical about having a database of large script snippets
> that will hopefully be reused in the future.
>

That database is just the list of old blocks which can be dredged up to
have code pulled out of them.


> In chia the "scriptPubKey" is the hash of a lisp program, and when you
> create a new coin, the "scriptPubKey" of the newly generated coin is
> also the output of a lisp