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

[Jeremy via bitcoin-dev]

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, you could imagine a future where mempools track
>> many alternative things that might want to be in a transaction.
>>
>> suppose there are N inputs each with a weight and an amount of fee being
>> added and the sighash flags let me pick any subset of them. However, for a
>> txn to be standard it must be < 100k bytes and for it to be consensus <
>> 1mb. Now it is possible you have to solve a knapsack problem in order to
>> rationally bundle this transaction out of all possibilities.
>>
>> This problem can get even thornier, suppose that the inputs I'm adding
>> themselves are the outputs of another txn in the mempool, now i have to
>> track and propagate the feerates of that child back up to the parent txn
>> and track all these dependencies.
>>
>> perhaps with very careful engineering these issues can be tamed. however
>> it seems with sponsors or fee accounts, by separating the pays-for from the
>> participates-in concerns we can greatly simplify it to something like:
>> compute effective feerate for a txn, including all sponsors that pay more
>> than the feerate of the base txn. Mine that txn and it's subsidies using
>> the normal algo. If you run out of space, all subsidies are same-sized so
>> just take the ones that pay the highest amount up until the added marginal
>> feerate is less than the next eligible txn.
>>
>>
>> --
>> @JeremyRubin 
>> 
>>
>>
>> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud 
>> wrote:
>>
>>> I see, its not primarily to make it cheaper to append fees, but also
>>> allows appending fees in cases that aren't possible now. Is that right? I
>>> can certainly see the benefit of a more general way to add a fee to any
>>> transaction, regardless of whether you're related to that transaction or
>>> not.
>>>
>>> How would you compare the pros and cons of your account-based approach
>>> to something like a new sighash flag? Eg a sighash flag that says "I'm
>>> signing this transaction, but the signature is only valid if mined in the
>>> same block as transaction X (or maybe transactions LIST)". This could be
>>> named SIGHASH_EXTERNAL. Doing this would be a lot more similar to other
>>> bitcoin transactions, and no special account would need to be created. Any
>>> transaction could specify this. At least that's the first thought I would
>>> have in designing a way to arbitrarily bump fees. Have you compared your
>>> solution to something more familiar like that?
>>>
>>> On Tue, 

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

[Jeremy via bitcoin-dev]

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, you could imagine a future where mempools track
many alternative things that might want to be in a transaction.

suppose there are N inputs each with a weight and an amount of fee being
added and the sighash flags let me pick any subset of them. However, for a
txn to be standard it must be < 100k bytes and for it to be consensus <
1mb. Now it is possible you have to solve a knapsack problem in order to
rationally bundle this transaction out of all possibilities.

This problem can get even thornier, suppose that the inputs I'm adding
themselves are the outputs of another txn in the mempool, now i have to
track and propagate the feerates of that child back up to the parent txn
and track all these dependencies.

perhaps with very careful engineering these issues can be tamed. however it
seems with sponsors or fee accounts, by separating the pays-for from the
participates-in concerns we can greatly simplify it to something like:
compute effective feerate for a txn, including all sponsors that pay more
than the feerate of the base txn. Mine that txn and it's subsidies using
the normal algo. If you run out of space, all subsidies are same-sized so
just take the ones that pay the highest amount up until the added marginal
feerate is less than the next eligible txn.


--
@JeremyRubin 



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

> I see, its not primarily to make it cheaper to append fees, but also
> allows appending fees in cases that aren't possible now. Is that right? I
> can certainly see the benefit of a more general way to add a fee to any
> transaction, regardless of whether you're related to that transaction or
> not.
>
> How would you compare the pros and cons of your account-based approach to
> something like a new sighash flag? Eg a sighash flag that says "I'm signing
> this transaction, but the signature is only valid if mined in the same
> block as transaction X (or maybe transactions LIST)". This could be named
> SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin
> transactions, and no special account would need to be created. Any
> transaction could specify this. At least that's the first thought I would
> have in designing a way to arbitrarily bump fees. Have you compared your
> solution to something more familiar like that?
>
> On Tue, Jan 18, 2022 at 11:43 AM Jeremy  wrote:
>
>> Can you clarify what you mean by "improve the situation"?
>>
>> There's a potential mild bytes savings, but the bigger deal is that the
>> API should be much less vulnerable to pinning issues, fix dust leakage for
>> eltoo like protocols, and just generally allow protocol designs to be fully
>> abstracted from paying fees. You can't easily mathematically quantify API
>> improvements like that.
>> --
>> @JeremyRubin 
>> 
>>
>>
>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud 
>> wrote:
>>
>>> Do you have any back-of-the-napkin math on quantifying how much this
>>> would improve the situation vs existing methods (eg cpfp)?
>>>
>>>
>>>
>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Happy new years devs,

 I figured I would share some thoughts for conceptual review that have
 been bouncing around my head as an opportunity to clean up the fee paying
 semantics in bitcoin "for good". The design space is very wide on the
 approach I'll share, so below is just a sketch of how it could work which
 I'm sure could be improved greatly.

 Transaction fees are an integral part of bitcoin.

 However, due to quirks of Bitcoin's transaction design, fees are a part
 of the transactions that they occur in.

 While this works in a "Bitcoin 1.0" world, where all transactions are
 simple on-chain transfers, real world use of Bitcoin requires support for
 things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
 and other long lived Smart Contracts that can't predict future fee rates.
 Having the fees paid in band makes writing these contracts much more
 difficult as you can't merely express the logic you want for the
 transaction, but also the fees.

 Previously, I proposed a special type of transaction called a "Sponsor"
 which has some special consensus + mempool rules to allow arbitrarily
 

Re: [bitcoin-dev] CTV BIP review

[Jeremy via bitcoin-dev]

Thanks for the detailed review.

I'll withhold comment around activation logic and leave that for others to
discuss.

w.r.t. the language cleanups I'll make a PR that (I hope) clears up the
small nits later today or tomorrow. Some of it's kind of annoying because
the legal definition of covenant is "A formal agreement or promise, usually
included in a contract or deed, to do or not do a particular act; a compact
or stipulation made in writing or by parol." so I do think things like
CLTV/CSV are covenants since it's a binding promise to not spend before a
certain time... it might be out of scope for the BIP to fully define these
terms because it doesn't really matter what a covenant could be as much as
it matters what CTV is specifically.

On the topic of drafting BIPs for specific use cases, I agree that would be
valuable and can consider it.

However, I'm a bit skeptical of that approach overall as I don't
necessarily think that the applications *must be* standard, and I view BIPs
as primarily for standardization whereas part of the flexibility of
CTV/Sapio allows users to figure out how they want to use it.

E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot,
although there are some papers and example implementations but nothing
formal yet
https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors).
Perhaps this is an opportunity for CTV to lead on the amount of formal
application designs available before 'release'.

As a starting point, maybe you could review some of the application focused
posts in rubin.io/advent21 and let me know where they seem deficient?

Also a BIP describing how to build something like Sapio (and less so Sapio
itself, since it's still early days for that) might help for folks to be
able to think through how to compile to CTV contracts? But again, I'm
skeptical of the value of a BIP v.s. the documentation and examples
available in the code and https://learn.sapio-lang.org.

I think it's an interesting discussion too because as we've just seen the
LN ecosystem start the BLIP standards, would an example of non-interactive
channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing
list post?

--
@JeremyRubin 



On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> tl;dr: I don't think CTV is ready yet (but probably close), and in any
> case
> definitely not worth reviving BIP 9 with its known flaws and vulnerability.
>
> My review here is based solely on the BIP, with no outside context (aside
> from
> current consensus rules, of course). In particular, I have _not_ looked at
> the CTV code proposed for Bitcoin Core yet.
>
> >Covenants are restrictions on how a coin may be spent beyond key
> ownership.
>
> nit: Poorly phrased. Even simple scripts can do that already.
>
> >A few examples are described below, which should be the subject of future
> non-consensus standardization efforts.
>
> I would ideally like to see fully implemented BIPs for at least one of
> these
> (preferably the claimed CoinJoin improvements) before we move toward
> activation.
>
> >Congestion Controlled Transactions
>
> I think this use case hasn't been fully thought through yet. It seems like
> it
> would be desirable for this purpose, to allow any of the recipients to
> claim
> their portion of the payment without footing the fee for every other
> payment
> included in the batch. This is still a covenant-type solution, but one
> that
> BIP 119 cannot support as-is.
>
> (I realise this may be a known and accepted limitation, but I think it
> should
> be addressed in the BIP)
>
> >Payment Channels
>
> Why batch mere channel creation? Seems like the spending transaction
> should
> really be the channel closing.
>
> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins
> than
> previously because participants agree on a single output which pays all
> participants, which will be lower fee than before.
>
> I don't see how. They still have to agree in advance on the outputs, and
> the
> total fees will logically be higher than not using CTV...?
>
> >Further Each participant doesn't need to know the totality of the outputs
> committed to by that output, they only have to verify their own sub-tree
> will
> pay them.
>
> I don't see any way to do this with the provided implementation.
>
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
>
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should
> never be used again.
>
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed prior
> to
> or in parallel), but using BIP 9 would 

Re: [bitcoin-dev] CTV BIP review

[Prayank via bitcoin-dev]

Hi Luke,

This is the first competent review for CTV based on my understanding. I would 
not mention controversial things in this email but nobody cares about scammers 
and we will review everything irrespective of personal or legal attacks on 
developers because some people are prepared for it and capable, competent and 
healthy.

> nit: Poorly phrased. Even simple scripts can do that already.

Agree

> I would ideally like to see fully implemented BIPs for at least one of these 
> (preferably the claimed CoinJoin improvements) before we move toward 
> activation.

Agree

> Hard NACK on this. BIP 9 at this point represents developers attempting to 
> disregard and impose their will over community consensus, as well as an 
> attempt to force a miner veto backdoor/vulnerability on deployment. It should 
> never be used again.

Agree

Other technical comments on BIP are appreciated however they would be better 
answered by Jeremy at this point or other as I am still researching and not 
confident to comment.

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

[Eric Voskuil via bitcoin-dev]

> -Original Message-
> From: Luke Dashjr 
> Sent: Tuesday, January 18, 2022 2:10 PM
> To: e...@voskuil.org
> Cc: 'Bitcoin Protocol Discussion' 
> 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, but that is
not the question at hand. The question is explicitly compatibility. Anyone
can activate a soft fork at any time, but without "hash power enforcement"
soft forks are NOT backward compatible.

> Softforks never produce a chain split. Miners can, and might try to do it
to cause disruption in retaliation, but the softfork itself does not.

Maybe you are trying to split hairs given the fact that blocks are produced
only by miners, so only miners can "cause" a split.

But through not intention ("disruption in retaliation") whatsoever by
mining, a soft fork will result in those activating the rule being split off
the original chain unless majority hash power enforces the rule. The fact
that doing nothing apart from deploying the rule will result in a split is
the very definition of NOT compatible.

I assume you will argue that the original chain is not "valid" and therefore
irrelevant (as if no chain split occurred). But again the point is about
compatibility. The appearance of multiple chains, which appear valid
according to either the previous or new rules, is obviously the
incompatibility.

I shouldn't have to point this out, but observed chain splits have occurred
in more the one large scale soft fork deployment. These splits have only
been resolved through hash power enforcement. In 2010 it took 51 blocks
before the current chain took the lead. In 2012 minority chains persisted
for months. The deployment of soft forks caused these splits, NOT the
actions of miners. And unless majority hash power eventually enforces it,
the soft fork branch necessarily dies.

> > It was for this reason alone that BIP8 never gained sufficient
> > support.
> 
> BIP 8 in fact achieved consensus for Taproot activation.

Please define "achieved consensus", because by any definition I can imagine,
this is simply untrue.

> > This is one of the most misleading statements I've seen here. It's not
> > technically a lie, because it states what "should" happen. But it is
> > clearly intended to lead people to believe that BIP8 was actually used
> > ("again") - it was not. ST was some technical tweaks to BIP9.
> 
> BIP 8 was used to activate Taproot.

No, it wasn't. I find it hard to imaging how you rationalize such grossly
misleading statements.

> > The outright deception around this one topic has led to significant
> > unnecessary conflict in the community. Make your argument, but make it
> > honestly.
> 
> You are the one attempting to deceive here.

That is for others to decide. I appreciate your responses above, since they
certainly help clarify what is happening here.

e

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

Re: [bitcoin-dev] CTV BIP review

[Luke Dashjr via bitcoin-dev]

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.

Softforks never produce a chain split. Miners can, and might try to do it to 
cause disruption in retaliation, but the softfork itself does not.

> It was for this reason alone that BIP8 never gained sufficient 
> support.

BIP 8 in fact achieved consensus for Taproot activation.

> This is one of the most misleading statements I've seen here. It's not
> technically a lie, because it states what "should" happen. But it is
> clearly intended to lead people to believe that BIP8 was actually used
> ("again") - it was not. ST was some technical tweaks to BIP9.

BIP 8 was used to activate Taproot.

> The outright deception around this one topic has led to significant
> unnecessary conflict in the community. Make your argument, but make it
> honestly.

You are the one attempting to deceive here.

Luke
___
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]

I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.

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. It was for this reason alone that BIP8 never gained sufficient
support.

Taproot activation was in no way a compromise between enforced and
unenforced activation. Unenforced activation was wholly rejected.

> BIP 9 at this point represents developers attempting to disregard and
impose their will over community consensus, as well as an attempt to force a
miner veto backdoor/vulnerability on deployment. It should never be used
again."

This appears to be the start of another marketing campaign, an attempt to
reclaim Taproot activation as some sort of "win" over the "miner backdoor".
The same sort of misleading campaign was waged in the wake of segwit, and
led directly to the conflict around Taproot activation.

The differences between ST and BIP9 are inconsequential in this regard. The
criticism you are making of BIP9 above applies equally to ST.

> As with Taproot, any future deployments should use BIP 8 again

This is one of the most misleading statements I've seen here. It's not
technically a lie, because it states what "should" happen. But it is clearly
intended to lead people to believe that BIP8 was actually used ("again") -
it was not. ST was some technical tweaks to BIP9.

I am making no statement whatsoever on what "should" happen. My interest is
in providing accurate information so that people can make informed
decisions.

The outright deception around this one topic has led to significant
unnecessary conflict in the community. Make your argument, but make it
honestly.

e

> -Original Message-
> From: bitcoin-dev  On
Behalf
> Of Luke Dashjr via bitcoin-dev
> Sent: Tuesday, January 18, 2022 1:19 PM
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] CTV BIP review
> 
> tl;dr: I don't think CTV is ready yet (but probably close), and in any
case
> definitely not worth reviving BIP 9 with its known flaws and
vulnerability.
...
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
> 
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should never be used again.
> 
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed
> prior to or in parallel), but using BIP 9 would destroy this.
> 
> As with Taproot, any future deployments should use BIP 8 again, until a
better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
> 
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to get released as "Bitcoin Core", makes it all the more important that
the
> community firmly rejects any further action to force this regression.
> 
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all

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

[bitcoin-dev] CTV BIP review

[Luke Dashjr via bitcoin-dev]

tl;dr: I don't think CTV is ready yet (but probably close), and in any case 
definitely not worth reviving BIP 9 with its known flaws and vulnerability.

My review here is based solely on the BIP, with no outside context (aside from 
current consensus rules, of course). In particular, I have _not_ looked at 
the CTV code proposed for Bitcoin Core yet.

>Covenants are restrictions on how a coin may be spent beyond key ownership. 

nit: Poorly phrased. Even simple scripts can do that already.

>A few examples are described below, which should be the subject of future 
non-consensus standardization efforts.

I would ideally like to see fully implemented BIPs for at least one of these 
(preferably the claimed CoinJoin improvements) before we move toward 
activation.

>Congestion Controlled Transactions

I think this use case hasn't been fully thought through yet. It seems like it 
would be desirable for this purpose, to allow any of the recipients to claim 
their portion of the payment without footing the fee for every other payment 
included in the batch. This is still a covenant-type solution, but one that 
BIP 119 cannot support as-is.

(I realise this may be a known and accepted limitation, but I think it should 
be addressed in the BIP)

>Payment Channels

Why batch mere channel creation? Seems like the spending transaction should 
really be the channel closing.

>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than 
previously because participants agree on a single output which pays all 
participants, which will be lower fee than before.

I don't see how. They still have to agree in advance on the outputs, and the 
total fees will logically be higher than not using CTV...?

>Further Each participant doesn't need to know the totality of the outputs 
committed to by that output, they only have to verify their own sub-tree will 
pay them.

I don't see any way to do this with the provided implementation.

>Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.

Hard NACK on this. BIP 9 at this point represents developers attempting to 
disregard and impose their will over community consensus, as well as an 
attempt to force a miner veto backdoor/vulnerability on deployment. It should 
never be used again.

Speedy Trial implemented with BIP 8 made sense* as a possible neutral 
compromise between LOT=True and LOT=False (which could be deployed prior to 
or in parallel), but using BIP 9 would destroy this.

As with Taproot, any future deployments should use BIP 8 again, until a better 
solution is developed. Reverting back to a known flawed and vulnerable 
activation method should not be done, and it would be better not to deploy 
CTV at all at such an expense.

The fact that certain developers attempted to deploy a BIP 9 alternative 
activation for Taproot against community consensus, and that even managed to 
get released as "Bitcoin Core", makes it all the more important that the 
community firmly rejects any further action to force this regression.

* it is my opinion a BIP 8 ST would be an okay compromise under those 
circumstances; others do disagree that ST is acceptable at all

> This ensures that for a given known input, the TXIDs can also be known ahead 
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched 
Channel Creation constructions as the redemption TXID could be malleated and 
pre-signed transactions invalidated, unless the channels are built using an 
Eltoo-like protocol.

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

Why not just commit to the txid itself if that's the goal?

>P2SH is incompatible with CHECKTEMPLATEVERIFY 

Maybe the CTV opcode should only be defined/enforced within witness scripts?

>nLockTime should generally be fixed to 0 (in the case of a payment tree, only 
the *first* lock time is needed to prevent fee-sniping the root)

Your "Congestion Controlled Transactions" example would only make sense with 
the spending transaction much later than the "root", and so could benefit 
from fee sniping malleability. (In fact, in that example, it would be better 
not to commit to locktime at all.)

>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to 
simple templates. The structure of CHECKTEMPLATEVERIFY template is such that 
the outputs must be known exactly at the time of construction. Based on a 
destructuring argument, it is only possible to create templates which expand 
in a finite number of steps.

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

>For example, a exchange's hot wallet might use an address which can 
automatically be moved to a cold storage address after a relative timeout.

Wouldn't it make more sense to just have a UTXO both cold+hot can spend, then 
throw away the hot key?

>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scripts 
valid for policy until the new rule is active.

Policy isn't validity, and 

Re: [bitcoin-dev] On the regularity of soft forks

[Prayank via bitcoin-dev]

> We should strive to one day get to a point where the bitcoin consensus isn't 
> updating at all.

That day is nowhere near IMO and maybe we won't see it in my lifetime.

> Perhaps we should come to a consensus as a consensus as a community what the 
> minimum time between soft forks should be, and just as importantly, what the 
> minimum time between finalized consensus-change implementation and when we 
> decide community consensus has been achieved.

This is not possible in a decentralized network like Bitcoin and makes no 
sense. Soft forks can/should be done as and when required. This does not mean 
we do them often but if a change makes sense, looks ready, got enough 
consensus, reviewed properly etc. then timing doesn't really matter in every 
case.

> Activating multiple consensus changes in a bundle is far safer than having 
> multiple separate in-flight soft forks at once.

This is not true. More changes bundled require more review and still more 
probability to have bugs. Security is always about keeping things simple.

> One solution is that we could be a lot more direct about how decisions are 
> made. There's been a lot of rhetoric around UASF and how the economic 
> majority is really who's running the show.

BIP 8 with LOT=TRUE was a better activation mechanism option in Taproot but 
some influential developers wrote its misleading, unsafe etc. on social media 
so you can call me negative at this moment however I have realized the truth is 
really sad and we can't blindly follow some people. There are lot of people who 
will tell you bad things about UASF and how speedy trial is the best thing 
Bitcoin has ever experienced.

Michael Folkson also had some opinion in activation mechanism IIRC,


-- 
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] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

[Billy Tetrud via bitcoin-dev]

@vjudeu
>  If you introduce signing into mining, then you will have cases, where
someone is powerful enough to produce blocks, but cannot, because signing
is needed..  your consensus is no longer "the heaviest chain"

You've misunderstood my suggestion. This would not be possible with what I
suggested. Why do you think of the signature as some kind of barrier? What
I was suggesting was that, when a miner participating in this protocol
mines a valid bitcoin block, they then sign a superblock with a public key
that can be verified alongside the coinbase output (eg say with data in the
first tapleaf of the output address). The block is still connected to
something secured by PoW. You really made a lot of incorrect assumptions
about what I suggested.

On Thu, Dec 23, 2021 at 1:05 PM Jeremy  wrote:

> If you introduce signing into mining, then you will have cases, where
>> someone is powerful enough to produce blocks, but cannot, because signing
>> is needed. Then, your consensus is no longer "the heaviest chain", but "the
>> heaviest signed chain". That means, your computing power is no longer
>> enough by itself (as today), because to make a block, you also need some
>> kind of "permission to mine", because first you sign things (like in
>> signet) and then you mine them. That kind of being "reliably unreliable"
>> may be ok for testing, but not for the main network.
>
>
> this is a really great point worth underscoring. this is the 'key
> ingredient' for DCFMP, which is that there is no signing or other network
> system that is 'in the way' of normal bitcoin mining, just an opt-in set of
> rules for sharing the bounties of your block in exchange for future shares.
>
___
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 7:10 AM Billy Tetrud  wrote:

> >  Since scriptpubkeys/scriptsigs continue to run ephemerally at
> validation time full turing completeness is much less dangerous than people
> fear.
>
> The covenant proposals I've seen that might give bitcoin turing
> completeness require a turing complete process to be stepped such that each
> step is a transaction paid for with a usual fee. This fact I think makes
> the turing completeness a lot less scary. No single transaction would be
> turing complete, while a sequence of them could be. But importantly, each
> transaction has a strictly limited runtime and every script could continue
> to have a calculable number of maximum runtime steps.
>

This flows naturally out of the UTXO model. In ETH you don't know how much
transactions will cost in advance because things don't declare their state
up front, but with all dependencies declared up front execution can be made
completely deterministic.

 > It would also probably be a good idea to add in a bunch of special
purpose opcodes for making coherent statements about transactions since in
Bitcoin they're a very complex and hard to parse format.

>
> What are some examples you're thinking of?
>

What's needed from a programming perspective is the ability to say '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 ('pay to singleton' is a term
for this) and that capability can be enforced by the scriptpubkey asserting
that either its parent is the originator of it or that its parent also has
the same type of scriptpubkey. This allows capabilities to be added without
gunking up on chain state with things other than UTXOs.



>
> > Once you start implementing complex general purpose functionality it
> tends to get very expensive very fast and is likely impractical unless
> there's a way to compress or at least de-duplicate snippets of code which
> are repeated on chain.
>
> I like this idea. If there was a way to dedupe scripts in some way, it
> could save a lot of bandwidth which would help bitcoin scale better. One
> thing we could do is have a specific set of pre-ordained script snippets
> that are given a shorthand that's stored in the software and explicitly
> shouldn't be transmitted long-hand. That would help for very standard
> widespread things. We could even add in a consensus rule where short-handed
> scripts pay for their expanded vbytes, not the vbytes of the compressed
> version. This would mean the incentives wouldn't be changed by this
> approach.
>

One approach is to allow references to old blocks so code snippets can be
pulled out of them. That avoids having to define the 'common sections' up
front. Charging for virtual vbytes unfortunately keeps smart functionality
very expensive and the point is to make it not so expensive.


> > For a payment to someone to come with a rider where they could accept it
> and think their system was working properly for a while until you exercised
> some kind of retroactive veto on new action or even clawback would
> obviously be unacceptable behavior.
>
> I definitely agree. A payment's covenant should be completely knowable to
> the recipient, and recipients shouldn't accept random covenants they
> haven't explicitly accepted on their own.
>
> > for payments to come with covenants but the recipient not even be able
> to parse them unless they're fully buying into that behavior is much more
> reasonable.
>
> The recipient not being able to parse them? Couldn't that result in
> exactly the situation above you said was not acceptable? The recipient must
> be able to know all the possibilities of the covenant or there might be
> some secret retroactive clawback in there waiting to bite them.
>

Not sure what you're saying. If the recipient can't parse a UTXO the
defined behavior should be that they assume it's bricked.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

Can you clarify what you mean by "improve the situation"?

There's a potential mild bytes savings, but the bigger deal is that the API
should be much less vulnerable to pinning issues, fix dust leakage for
eltoo like protocols, and just generally allow protocol designs to be fully
abstracted from paying fees. You can't easily mathematically quantify API
improvements like that.
--
@JeremyRubin 



On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud  wrote:

> Do you have any back-of-the-napkin math on quantifying how much this would
> improve the situation vs existing methods (eg cpfp)?
>
>
>
> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Happy new years devs,
>>
>> I figured I would share some thoughts for conceptual review that have
>> been bouncing around my head as an opportunity to clean up the fee paying
>> semantics in bitcoin "for good". The design space is very wide on the
>> approach I'll share, so below is just a sketch of how it could work which
>> I'm sure could be improved greatly.
>>
>> Transaction fees are an integral part of bitcoin.
>>
>> However, due to quirks of Bitcoin's transaction design, fees are a part
>> of the transactions that they occur in.
>>
>> While this works in a "Bitcoin 1.0" world, where all transactions are
>> simple on-chain transfers, real world use of Bitcoin requires support for
>> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
>> and other long lived Smart Contracts that can't predict future fee rates.
>> Having the fees paid in band makes writing these contracts much more
>> difficult as you can't merely express the logic you want for the
>> transaction, but also the fees.
>>
>> Previously, I proposed a special type of transaction called a "Sponsor"
>> which has some special consensus + mempool rules to allow arbitrarily
>> appending fees to a transaction to bump it up in the mempool.
>>
>> As an alternative, we could establish an account system in Bitcoin as an
>> "extension block".
>>
>> *Here's how it might work:*
>>
>> 1. Define a special anyone can spend output type that is a "fee account"
>> (e.g. segwit V2). Such outputs have a redeeming key and an amount
>> associated with them, but are overall anyone can spend.
>> 2. All deposits to these outputs get stored in a separate UTXO database
>> for fee accounts
>> 3. Fee accounts can sign only two kinds of transaction: A: a fee amount
>> and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address
>> 4. These transactions are committed in an extension block merkle tree.
>> While the actual signature must cover the TXID/Outpoint, the committed data
>> need only cover the index in the block of the transaction. The public key
>> for account lookup can be recovered from the message + signature.
>> 5. In any block, any of the fee account deposits can be: released into
>> fees if there is a corresponding tx; consolidated together to reduce the
>> number of utxos (this can be just an OP_TRUE no metadata needed); or
>> released into fees *and paid back* into the requested withdrawal key
>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>> 6. Mempool logic is updated to allow attaching of account fee spends to
>> transactions, the mempool can restrict that an account is not allowed more
>> spend more than it's balance.
>>
>> *But aren't accounts "bad"?*
>>
>> Yes, accounts are bad. But these accounts are not bad, because any funds
>> withdrawn from the fee extension are fundamentally locked for 100 blocks as
>> a coinbase output, so there should be no issues with any series of reorgs.
>> Further, since there is no "rich state" for these accounts, the state
>> updates can always be applied in a conflict-free way in any order.
>>
>>
>> *Improving the privacy of this design:*
>>
>> This design could likely be modified to implement something like
>> Tornado.cash or something else so that the fee account paying can be
>> unlinked from the transaction being paid for, improving privacy at the
>> expense of being a bit more expensive.
>>
>> Other operations could be added to allow a trustless mixing to be done by
>> miners automatically where groups of accounts with similar values are
>> trustlessly  split into a common denominator and change, and keys are
>> derived via a verifiable stealth address like protocol (so fee balances can
>> be discovered by tracing the updates posted). These updates could also be
>> produced by individuals rather than miners, and miners could simply honor
>> them with better privacy. While a miner generating an update would be able
>> to deanonymize their mixes, if you have your account mixed several times by
>> independent miners that could potentially add sufficient privacy.
>>
>> The LN can also be used with PTLCs to, in theory, have another individual
>> paid to sponsor a transaction on your behalf only if they 

Re: [bitcoin-dev] bip39

[Billy Tetrud via bitcoin-dev]

I agree removing any ambiguity would be good. I'd also like to see removal
of words that are a strict subset of another word. Words like add (which is
a subset of addict and address).

As far as entropy loss, I think even with an 1000 word list and a 12 word
seed, it would be unlikely in a time far longer than the age of the
universe to expect to come across one duplicate randomly generated seed.
Even if every person on the planet generated 1000 seeds per second. So I
don't really see this as a concern.

On Mon, Jan 17, 2022 at 4:45 PM Pavol Rusnak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Trezor recovery cards look like this what addresses the issue:
>
> https://wiki.trezor.io/images/Seed_card_example.jpg
>
> 1. Each word has a box around it.
> 2. You write the words one under the other, not next to each other.
>
>
> On Mon, 17 Jan 2022 at 23:38, Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is a good point, but can be addressed by having a non-void
>> whitespace character (e.g., win x estate).
>>
>> changing BIP39 would be hard since software expects a standard list; it
>> would also be possible to rejection sample for seeds that do not contain
>> these pairs, unclear how much entropy would be lost from that.
>> --
>> @JeremyRubin 
>> 
>>
>>
>> On Mon, Jan 17, 2022 at 2:26 PM Erik Aronesty via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> really don't like that art, work, and artwork are 3 different words
>>>
>>> would be nice to clean up adjacent ambiguity
>>>
>>> it's not a big deal, but it can lead to confusion when writing things
>>> down
>>>
>>>
>>> dup: ('canal', 'arm') ('can', 'alarm')
>>> dup: ('canal', 'one') ('can', 'alone')
>>> dup: ('canal', 'ready') ('can', 'already')
>>> dup: ('card', 'anger') ('car', 'danger')
>>> dup: ('card', 'ice') ('car', 'dice')
>>> dup: ('card', 'inner') ('car', 'dinner')
>>> dup: ('card', 'raw') ('car', 'draw')
>>> dup: ('cart', 'able') ('car', 'table')
>>> dup: ('cart', 'ask') ('car', 'task')
>>> dup: ('cart', 'hat') ('car', 'that')
>>> dup: ('cart', 'hen') ('car', 'then')
>>> dup: ('cart', 'issue') ('car', 'tissue')
>>> dup: ('cart', 'one') ('car', 'tone')
>>> dup: ('cart', 'own') ('car', 'town')
>>> dup: ('cart', 'rack') ('car', 'track')
>>> dup: ('cart', 'rain') ('car', 'train')
>>> dup: ('cart', 'win') ('car', 'twin')
>>> dup: ('catch', 'air') ('cat', 'chair')
>>> dup: ('erase', 'arch') ('era', 'search')
>>> dup: ('fatal', 'arm') ('fat', 'alarm')
>>> dup: ('fatal', 'one') ('fat', 'alone')
>>> dup: ('fatal', 'ready') ('fat', 'already')
>>> dup: ('feed', 'anger') ('fee', 'danger')
>>> dup: ('feed', 'ice') ('fee', 'dice')
>>> dup: ('feed', 'inner') ('fee', 'dinner')
>>> dup: ('feed', 'raw') ('fee', 'draw')
>>> dup: ('feel', 'earn') ('fee', 'learn')
>>> dup: ('feel', 'end') ('fee', 'lend')
>>> dup: ('gasp', 'act') ('gas', 'pact')
>>> dup: ('gasp', 'age') ('gas', 'page')
>>> dup: ('gasp', 'air') ('gas', 'pair')
>>> dup: ('gasp', 'ill') ('gas', 'pill')
>>> dup: ('gasp', 'raise') ('gas', 'praise')
>>> dup: ('gasp', 'rice') ('gas', 'price')
>>> dup: ('gasp', 'ride') ('gas', 'pride')
>>> dup: ('gasp', 'roof') ('gas', 'proof')
>>> dup: ('kite', 'merge') ('kit', 'emerge')
>>> dup: ('kite', 'motion') ('kit', 'emotion')
>>> dup: ('kite', 'state') ('kit', 'estate')
>>> dup: ('lawn', 'arrow') ('law', 'narrow')
>>> dup: ('lawn', 'either') ('law', 'neither')
>>> dup: ('lawn', 'ice') ('law', 'nice')
>>> dup: ('legal', 'arm') ('leg', 'alarm')
>>> dup: ('legal', 'one') ('leg', 'alone')
>>> dup: ('legal', 'ready') ('leg', 'already')
>>> dup: ('seat', 'able') ('sea', 'table')
>>> dup: ('seat', 'ask') ('sea', 'task')
>>> dup: ('seat', 'hat') ('sea', 'that')
>>> dup: ('seat', 'hen') ('sea', 'then')
>>> dup: ('seat', 'issue') ('sea', 'tissue')
>>> dup: ('seat', 'one') ('sea', 'tone')
>>> dup: ('seat', 'own') ('sea', 'town')
>>> dup: ('seat', 'rack') ('sea', 'track')
>>> dup: ('seat', 'rain') ('sea', 'train')
>>> dup: ('seat', 'win') ('sea', 'twin')
>>> dup: ('skin', 'arrow') ('ski', 'narrow')
>>> dup: ('skin', 'either') ('ski', 'neither')
>>> dup: ('skin', 'ice') ('ski', 'nice')
>>> dup: ('tent', 'able') ('ten', 'table')
>>> dup: ('tent', 'ask') ('ten', 'task')
>>> dup: ('tent', 'hat') ('ten', 'that')
>>> dup: ('tent', 'hen') ('ten', 'then')
>>> dup: ('tent', 'issue') ('ten', 'tissue')
>>> dup: ('tent', 'one') ('ten', 'tone')
>>> dup: ('tent', 'own') ('ten', 'town')
>>> dup: ('tent', 'rack') ('ten', 'track')
>>> dup: ('tent', 'rain') ('ten', 'train')
>>> dup: ('tent', 'win') ('ten', 'twin')
>>> dup: ('used', 'anger') ('use', 'danger')
>>> dup: ('used', 'ice') ('use', 'dice')
>>> dup: ('used', 'inner') ('use', 'dinner')
>>> dup: ('used', 'raw') ('use', 'draw')
>>> dup: ('wine', 'merge') ('win', 'emerge')
>>> dup: ('wine', 'motion') ('win', 'emotion')
>>> dup: ('wine', 'state') ('win', 'estate')
>>> dup: ('wing', 'host') ('win', 'ghost')

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

[Billy Tetrud via bitcoin-dev]

Do you have any back-of-the-napkin math on quantifying how much this would
improve the situation vs existing methods (eg cpfp)?



On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Happy new years devs,
>
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space is very wide on the
> approach I'll share, so below is just a sketch of how it could work which
> I'm sure could be improved greatly.
>
> Transaction fees are an integral part of bitcoin.
>
> However, due to quirks of Bitcoin's transaction design, fees are a part of
> the transactions that they occur in.
>
> While this works in a "Bitcoin 1.0" world, where all transactions are
> simple on-chain transfers, real world use of Bitcoin requires support for
> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
> and other long lived Smart Contracts that can't predict future fee rates.
> Having the fees paid in band makes writing these contracts much more
> difficult as you can't merely express the logic you want for the
> transaction, but also the fees.
>
> Previously, I proposed a special type of transaction called a "Sponsor"
> which has some special consensus + mempool rules to allow arbitrarily
> appending fees to a transaction to bump it up in the mempool.
>
> As an alternative, we could establish an account system in Bitcoin as an
> "extension block".
>
> *Here's how it might work:*
>
> 1. Define a special anyone can spend output type that is a "fee account"
> (e.g. segwit V2). Such outputs have a redeeming key and an amount
> associated with them, but are overall anyone can spend.
> 2. All deposits to these outputs get stored in a separate UTXO database
> for fee accounts
> 3. Fee accounts can sign only two kinds of transaction: A: a fee amount
> and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an address
> 4. These transactions are committed in an extension block merkle tree.
> While the actual signature must cover the TXID/Outpoint, the committed data
> need only cover the index in the block of the transaction. The public key
> for account lookup can be recovered from the message + signature.
> 5. In any block, any of the fee account deposits can be: released into
> fees if there is a corresponding tx; consolidated together to reduce the
> number of utxos (this can be just an OP_TRUE no metadata needed); or
> released into fees *and paid back* into the requested withdrawal key
> (encumbering a 100 block timeout). Signatures must be unique in a block.
> 6. Mempool logic is updated to allow attaching of account fee spends to
> transactions, the mempool can restrict that an account is not allowed more
> spend more than it's balance.
>
> *But aren't accounts "bad"?*
>
> Yes, accounts are bad. But these accounts are not bad, because any funds
> withdrawn from the fee extension are fundamentally locked for 100 blocks as
> a coinbase output, so there should be no issues with any series of reorgs.
> Further, since there is no "rich state" for these accounts, the state
> updates can always be applied in a conflict-free way in any order.
>
>
> *Improving the privacy of this design:*
>
> This design could likely be modified to implement something like
> Tornado.cash or something else so that the fee account paying can be
> unlinked from the transaction being paid for, improving privacy at the
> expense of being a bit more expensive.
>
> Other operations could be added to allow a trustless mixing to be done by
> miners automatically where groups of accounts with similar values are
> trustlessly  split into a common denominator and change, and keys are
> derived via a verifiable stealth address like protocol (so fee balances can
> be discovered by tracing the updates posted). These updates could also be
> produced by individuals rather than miners, and miners could simply honor
> them with better privacy. While a miner generating an update would be able
> to deanonymize their mixes, if you have your account mixed several times by
> independent miners that could potentially add sufficient privacy.
>
> The LN can also be used with PTLCs to, in theory, have another individual
> paid to sponsor a transaction on your behalf only if they reveal a valid
> sig from their fee paying account, although under this model it's hard to
> ensure that the owner doesn't pay a fee and then 'cancel' by withdrawing
> the rest. However, this could be partly solved by using reputable fee
> accounts (reputation could be measured somewhat decentralized-ly by
> longevity of the account and transactions paid for historically).
>
> *Scalability*
>
> This design is fundamentally 'decent' for scalability because adding fees
> to a transaction does not require adding inputs or outputs and does not
> require tracking substantial amounts of new state.
>
> Paying 

Re: [bitcoin-dev] On the regularity of soft forks

[Billy Tetrud via bitcoin-dev]

I agree with you Michael, there is a risk to soft forks and we shouldn't do
them too often. We should do them as infrequently as practical. We should
strive to one day get to a point where the bitcoin consensus isn't updating
at all.

Perhaps we should come to a consensus as a consensus as a community what
the minimum time between soft forks should be, and just as importantly,
what the minimum time between finalized consensus-change implementation and
when we decide community consensus has been achieved.

How long do you think these minimums should be? I'm curious to know
everyone's answer to this. I would think of these like I think about
changes to how I think national law should be changed: slowly and
carefully. There should be sufficient time for everyone to have a chance in
their busy lives to take the time to look at it, if they care, so they can
raise objections. I think the minimum time between a soft fork
implementation finalization and determining consensus should be maybe a
year. And the minimum time between soft forks should probably be something
like 5 years. This would mean that people only have to worry about paying
attention to what might happen with bitcoin consensus once every 5 years,
and would get a year-long window to do it. And if there isn't sufficient
consensus, or people bring up objections at the last minute, that should be
acceptable and it should further delay the deployment.

I think a lot of folks on here are rightly concerned about compromise
bundles where multiple mediocre proposals are put together
to basically incentivize some people to accept something they don't want
in order to receive something they do want (eg what Jeremy quoted Matt
Corallo about). But I don't think that's what Michael was suggesting at
all. That kind of compromise happens in the *decision making process*. My
understanding of what Michael was saying is that releasing a soft fork
should *not* be within the decision making process at all. The decision
making process should have already happened.

If you have consensus changes A and B, Michael was saying that each
consensus change proposal should go through a community vetting process
that determines that there is widespread supermajority support for it
*before* it is even merged into the code (ie master, or some equivalent
this-will-be-deployed branch). It should have a final implementation that
has been tested at all levels *before* its merged to master. And only then
should it potentially be bundled. After all testing has already been done,
after sufficient consensus has already been determined.

@Keagan
> When we start to bundle things, we amplify the community resources needed
to do review, not reduce them.

I think my above 2 paragraphs address this. I agree we don't want to review
these proposals together, they should be reviewed separately. And I don't
think Michael was suggesting otherwise.

> the protocol itself adopting a tendency to activate unrelated proposals
in bundles is a recipe for disaster.

Activating multiple consensus changes in a bundle is far safer than having
multiple separate in-flight soft forks at once. With multiple in-flight
soft forks, you have many combinations of what might happen (and therefore
what needs to be tested beforehand). Just 3 in-flight soft forks means 9
cases: nine orders of what might happen. All those combinations must be
exhaustively tested as all consensus changes must be. This is far more
work, more complicated, and more error prone than bundling them together in
one soft fork.

@Prayank
> However I am sure there are lot of people who still think miners vote
during signaling. ... I could not think of any solution to solve this
problem.

One solution is that we could be a lot more direct about how decisions are
made. There's been a lot of rhetoric around UASF and how the economic
majority is really who's running the show. If that's the case, why not make
that explicitly? Why not actually ask users to sign a petition saying they
support a particular consensus change? This could be done with actual
signatures by keys connected to UTXOs so we can see the economic weight of
the petition. We would probably need to have a new address format to
prevent problems related to public key exposure (eg by having addresses
containing two public keys: `hash(hash(spendingkey)+hash(votingkey))` where
you can expose the voting key without exposing your spending key). Perhaps
this could be another tapleaf.

Doing this could make it very clear how much of the bitcoin world supports
a particular change without needing to put anything extra on chain. This
clarity would also help the actual miner activation of the software in
cases where miners might have incentives not to activate. If it were clear
that an overwhelming supermajority wants it activated, miners would be less
likely to play games that play off uncertainty. It would also dispel the
idea that miners or developers decide how bitcoin changes.


On Sat, Jan 1, 2022 

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

[Billy Tetrud via bitcoin-dev]

>  Since scriptpubkeys/scriptsigs continue to run ephemerally at validation
time full turing completeness is much less dangerous than people fear.

The covenant proposals I've seen that might give bitcoin turing
completeness require a turing complete process to be stepped such that each
step is a transaction paid for with a usual fee. This fact I think makes
the turing completeness a lot less scary. No single transaction would be
turing complete, while a sequence of them could be. But importantly, each
transaction has a strictly limited runtime and every script could continue
to have a calculable number of maximum runtime steps.

> The main thing missing from what's expressed in transactions themselves
is a coherent notion of a single parent of each output instead of the
all-inputs-lead-to-all-outputs approach of transactions currently.

I'm curious to hear more about specifically what you mean by this. I think
there are covenant proposals that do that. TLUV has the concept of
specifying which output should have a script that's "modified" in a
particular way. CTV basically specifies a specific output set. My own
OP_CONSTRAINDESTINATION

also specifies what outputs the value of the input is transferred to. Is
this what you mean?

> It would also probably be a good idea to add in a bunch of special
purpose opcodes for making coherent statements about transactions since in
Bitcoin they're a very complex and hard to parse format.

What are some examples you're thinking of?

> Once you start implementing complex general purpose functionality it
tends to get very expensive very fast and is likely impractical unless
there's a way to compress or at least de-duplicate snippets of code which
are repeated on chain.

I like this idea. If there was a way to dedupe scripts in some way, it
could save a lot of bandwidth which would help bitcoin scale better. One
thing we could do is have a specific set of pre-ordained script snippets
that are given a shorthand that's stored in the software and explicitly
shouldn't be transmitted long-hand. That would help for very standard
widespread things. We could even add in a consensus rule where short-handed
scripts pay for their expanded vbytes, not the vbytes of the compressed
version. This would mean the incentives wouldn't be changed by this
approach.

We could also imagine a more dynamic approach, where nodes keep an index of
scripts or script snippets in some way, and keep around ones that it sees
most often. I'm not sure how this would work, since a script can contain a
lot of unique values and there's no clear way to split a script into
pieces. Perhaps script segments could be committed to the chain and nodes
could attempt to only store and reuse these paid-for segments, maybe only
the X most paid-for scripts (the scripts committed with the largest fee,
potentially across multiple explicit standalone commitments). However, this
dynamic approach would also have some scalability benefits, tho it would be
a bit more chaotic. Any node transmitting transactions would only need to
send the script segments when the node they're transmitting to requests
them. However, the extra script references also take up space, and so if
the ratio of how often the node has a script segment to how often they
don't is bad enough, this could a net negative scalability wise.

> For a payment to someone to come with a rider where they could accept it
and think their system was working properly for a while until you exercised
some kind of retroactive veto on new action or even clawback would
obviously be unacceptable behavior.

I definitely agree. A payment's covenant should be completely knowable to
the recipient, and recipients shouldn't accept random covenants they
haven't explicitly accepted on their own.

> for payments to come with covenants but the recipient not even be able to
parse them unless they're fully buying into that behavior is much more
reasonable.

The recipient not being able to parse them? Couldn't that result in exactly
the situation above you said was not acceptable? The recipient must be able
to know all the possibilities of the covenant or there might be some secret
retroactive clawback in there waiting to bite them.



On Fri, Dec 31, 2021 at 6:41 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a few different approaches to adding covenants and capabilities
> to the UTXO model with varying tradeoffs. It turns out that it can be done
> while making very few but not quite zero compromises to practices Bitcoin
> has been following so far.
>
> First, the good news: Full support for both capabilities and covenants can
> be added without changing the UTXO model whatsoever by adding some more
> programmatic capabilities to the language and doing some programmatic
> tricks. Since scriptpubkeys/scriptsigs continue to run ephemerally at
> 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

Hi Peter,

> that current lacks compelling use-cases clearly beneficial to all users

All the use cases shared in below links look compelling enough to me and we can 
do anything that a programmer could think of using such restrictions:

 https://utxos.org/uses/

https://rubin.io/archive/

> I don't think CTV in its current form makes that case sufficiently, and the 
> technical details are lacking.
CTV cannot be compared to segwit or taproot. We are expecting different things 
in that case. CTV is trying to do add basic covenants in Bitcoin that would 
help all Bitcoin users. Most important thing missing in lot of conversations is 
the low demand for block space which affects everyone who understands 
importance of fees in long term. Right now fee rates only spike during peak 
bull markets which indicate the only use case is speculation and this can be 
improved if developers could do better things with Bitcoin smart contracts.

This would also ensure that we don't end up with something really contentious 
in future that changes supply.

> DoS Attacks

I think this was already answered by Jeremy and pull request to add related 
information is also merged:

https://github.com/bitcoin/bips/pull/1272


-- 
Prayank

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