Re: [bitcoin-dev] More uses for CTV

[ZmnSCPxj via bitcoin-dev]

Good morning Greg,


> Hi James,
> Could you elaborate on a L2 contract where speedy
> settlement of the "first part" can be done, while having the rest
> take their time? I'm more thinking about time-out based protocols.
> 
> Naturally my mind drifts to LN, where getting the proper commitment
> transaction confirmed in a timely fashion is required to get the proper
> balances back. The one hitch is that for HTLCs you still need speedy
> resolution otherwise theft can occur. And given today's "layered
> commitment" style transaction where HTLCs are decoupled from
> the balance output timeouts, I'm not sure this can save much.

As I understand it, layered commitments can be modified to use `OP_CTV`, which 
would be slightly smaller (need only to reveal a 32-byte `OP_CTV` hash on the 
witness instead of a 64-byte Taproot signature, or 73-byte classical 
pre-Taproot ECDSA signature), and is in fact precisely an example of the speedy 
settlement style.

> CTV style commitments have popped up in a couple places in my
> work on eltoo(emulated via APO sig-in-script), but mostly in the
> context of reducing interactivity in protocols, not in byte savings per se.

In many offchain cases, all channel participants would agree to some 
pre-determined set of UTXOs, which would be implemented as a transaction 
spending some single UTXO and outputting the pre-determined set of UTXOs.

The single UTXO can be an n-of-n of all participants, so that all agree by 
contributing their signatures:

* Assuming Taproot, the output address itself is 33 bytes (x4 weight).
* The n-of-n multisignature is 64 witness bytes (x1 weight). 

Alternatly the single UTXO can be a P2WSH that reveals an `OP_CTV`:

* The P2WSH is 33 bytes (x4 weight) --- no savings here.
* The revelation of the ` OP_CTV` is 33 witness bytes (x1 weight).

Thus, as I understand it, `OP_CTV` can (almost?) always translate to a small 
weight reduction for such "everyone agrees to this set of UTXOs" for all 
offchain protocols that would require it.


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

Re: [bitcoin-dev] More uses for CTV

[Jeremy Rubin via bitcoin-dev]

Presigned transactions have to use a N-of-N (2-2 for ln, more for pools)
multisignature which is computed over the network whereas in-script
commitments can be done 1 key that is a non-secret point (e.g., just the
generator I think works).

For large protocol trees (e.g., of size N) the savings can be substantial!
It also reduces the amount of state that needs to be stored since the
in-script sigs can be deterministic.

Rene has some nice work demonstrating that latency in generating state
transitions has a very substantial cost to the efficiency of routing, maybe
he can chime in further.


You can also do a "back-filling" where you get the best of both, by (after
you commit to the quick to generate in-script version) lazily backfilling
with an equivalent p2wpkh version. If you have a channel, when you are in
"burst mode", you can cancel the longer to generate p2wpkh version when
newer states come in. (data hazard/ bypass).


With respect to mining pools and size constraints,
https://rubin.io/bitcoin/2021/12/12/advent-15/ shows how paying into
batches of channels can be used to trustlessly compress payouts without
custodial relationship.


--
@JeremyRubin 

On Fri, Aug 19, 2022 at 11:53 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:
> > Multiple parties could
> > trustlessly collaborate to settle into a single CTV output using
> > SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
> > similar to coinjoins.
>
> Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that
> any of the parties can subsequently RBF fee bump the transaction?
>
> > Conceptually, CTV is the most parsimonious way to do such a scheme,
> > since you can't really get smaller than a SHA256 commitment
>
> What's the advantage of CTV here compared to presigned transactions?  If
> multiple parties need to interact to cooperatively sign a transaction,
> no significant overhead is added by having them simultaneously sign a
> second transaction that spends from the output of the first transaction.
>   Presigned transactions actually have two small benefits I can think of:
>
> 1. The payment from the first transaction (containing the spends from
> the channel setup transactions) can be sent to a P2WPKH output, which is
> actually smaller than a SHA256 commitment.  Though this probably does
> require an extra round of communication for commit-and-reveal to prevent
> a collision attack on the P2WPKH address.[1]
>
> 2. Having the first transaction pay a either a P2WPKH or bech32m output
> and the second transaction spend from that UTXO may blend in better with
> other transactions, enhancing privacy.  This advantage probably isn't
> compatible with SH_ALL|SH_ACP, though, and it would require other
> privacy upgrades to LN.
>
> > direct-from-coinbase payouts seem like a
> > desirable feature which avoids some trust in pools.
> > [...]
> > If the payout was instead a single OP_CTV output, an arbitrary number
> > of pool participants could be paid out "atomically" within a single
> > coinbase.  One limitation is
> > the size of the coinbase outputs owed to constituent miners; this
> > limits the number of participants in the pool.
>
> I'm confused by this.  What is the size limitation on coinbase outputs,
> how does it limit the number of participants in a pool, and how does CTV
> fix that?
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about-collision-attack-risks-on-two-party-ecdsa
> ___
> 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] More uses for CTV

[David A. Harding via bitcoin-dev]

On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:

Multiple parties could
trustlessly collaborate to settle into a single CTV output using
SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
similar to coinjoins.


Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that 
any of the parties can subsequently RBF fee bump the transaction?



Conceptually, CTV is the most parsimonious way to do such a scheme,
since you can't really get smaller than a SHA256 commitment


What's the advantage of CTV here compared to presigned transactions?  If 
multiple parties need to interact to cooperatively sign a transaction, 
no significant overhead is added by having them simultaneously sign a 
second transaction that spends from the output of the first transaction. 
 Presigned transactions actually have two small benefits I can think of:


1. The payment from the first transaction (containing the spends from 
the channel setup transactions) can be sent to a P2WPKH output, which is 
actually smaller than a SHA256 commitment.  Though this probably does 
require an extra round of communication for commit-and-reveal to prevent 
a collision attack on the P2WPKH address.[1]


2. Having the first transaction pay a either a P2WPKH or bech32m output 
and the second transaction spend from that UTXO may blend in better with 
other transactions, enhancing privacy.  This advantage probably isn't 
compatible with SH_ALL|SH_ACP, though, and it would require other 
privacy upgrades to LN.



direct-from-coinbase payouts seem like a
desirable feature which avoids some trust in pools.
[...]
If the payout was instead a single OP_CTV output, an arbitrary number
of pool participants could be paid out "atomically" within a single
coinbase.  One limitation is
the size of the coinbase outputs owed to constituent miners; this
limits the number of participants in the pool.


I'm confused by this.  What is the size limitation on coinbase outputs, 
how does it limit the number of participants in a pool, and how does CTV 
fix that?


Thanks,

-Dave

[1] 
https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about-collision-attack-risks-on-two-party-ecdsa

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

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[aliashraf.btc At protonmail via bitcoin-dev]

Hi Peter, everyone
This issue has been discussed thoroughly in bitcointalk, general discussions 
are more suited to forums, I believe, still 

First and foremost, it is more than obvious that bitcoin block subsidy 
algorithm is a total disaster, not just for the zero subsidy security 
consequences, but also for the overly rewarding scheme that favors (few) 
first-runners against (masses of) people who join later, a policy that looks to 
be a cheap marketing trick rather than a decent strategic monetary, system 
design, no matter how natural it is presumed nowadays, after being implemented 
by Bitcoin.

For now, the brilliance of the idea behind Bitcoin and the enthusiasm have 
compensated for its bizzar, upside-down inflation policy, in practice as 
newcomers have been paying the price to lucky first-runners and adopting anyway.
Is it happening for low block subsidy? Is it going to be solved somehow? I 
don't think so.

With subsidy still being the major (like 90%) portion of the block reward, 
there is an equalizer factor pushing equilibrium by paying security costs on 
behalf of current coin owners.Note that every single new bitcoin paid as 
subsidy is actually paid by the rest of the wallets proportional to their 
balance.
Other than its direct contribution to security, once understood as a 
ballance-based taxing scheme, it is a crucial mechanism for re-distribution of 
wealth because to compensate for their costs, unlike speculators (who are among 
the worst adopters of Bitcoin, and unfortunately the most influencers), miners 
are used to dumping their coins, providing more fair opportunities for people 
to join.
So, halving and the hard cap, put both adoption and security as risk, It is 
why, unlike "believers", I'm deeply concerned about a future with low block 
subsidy because it puts both security and adoption in an awkward situation.

Additionally, It is not considered an engineering practice by any measure to 
speculate about the security of a system that we abundantly recommend to 
friends, family for joining.
We need proofs, security proof, ease of adaptation proof, etc.,
Fantasies are not proofs, having faith in a magical incentive mechanism that 
fixes everything is not an argument, let alone being a proof.
Incentives are irrelevant, rules, schemes, projects, and so fort, matter. There 
are always incentives in games, but rules are in charge of determining the fate.
Without rules, there is no game, flawed schemes and rules move the game behind 
its equilibrium to fail eventually.

I've not to mention the unfeasibility of tempering Bitcoin's basic consensus 
rules, Bitcoin rules are not subject to change specially when it comes to 
something that is widely considered a basic characteristic, a Schelling point, 
and so forth.

So, it is the paradoxical situation: we are exposed to, on one hand, it is a 
deficiency and on the other hand it is inevitable because is critically 
hard-code to Bitcoin, advertised more than any feature as its identity.
But it is our job, isn't it? Dealing with the impossible and taking care of it, 
but I think before reaching to that point we have to settle the basics.:

- There is a problem with long term security and adoption consequences.
- It is built deeply to bitcoin consensus rules, and considered a critical
- It is not going to disappear magically, neither it will be addressed by 
whales, etc.
- The 21M cap, halving, and generally, Bitcoin consensus, is not subject to 
change.

Don't panic, it is not exactly a catch-22 situation. Tip:
It is always possible to help a system without aggressive intervention, either 
by smart tweaks or by supporting it using other system(s).

Cheers, Ali Ashraf

--- Original Message ---
On Tuesday, August 16th, 2022 at 8:35 PM, Peter via bitcoin-dev 
 wrote:

> Hi Jaroslaw,

> In the Prisoner's Dilemma the prisoners cannot communicate. In Bitcoin large 
> holders are able to communicate with each other. Also, prisoners need not 
> make an all or nothing decision in Bitcoin. Miners can join and leave the 
> network freely over time. You can change your decision based on the decision 
> of others.
>
> The Bitcoin design is such that security is volatile but the issuance of 
> blocks is timely and evened out to a 10 minutes average even after the reward 
> is exhausted.
>
> The existing incentive that miners earn money for including transactions is 
> enough to motivate human nature. Transaction initiators have an incentive to 
> mine and run full nodes for personal interest.
>
>>Noone will waste his renewable energy on unprofitable Antminer while he/she 
>>can sell this energy for the market price.
>
> The law in most jurisdictions prevents the resale of spare electricity unless 
> an expensive license is obtained (and in most cases no license is available 
> as the government maintains a monopoly). Mining with waste electricity is 
> reducing losses. Another incentive to motivate human nature.
>
> Bitcoin holders can be 

Re: [bitcoin-dev] More uses for CTV

[Greg Sanders via bitcoin-dev]

Hi James,

Could you elaborate on a L2 contract where speedy
settlement of the "first part" can be done, while having the rest
take their time? I'm more thinking about time-out based protocols.

Naturally my mind drifts to LN, where getting the proper commitment
transaction confirmed in a timely fashion is required to get the proper
balances back. The one hitch is that for HTLCs you still need speedy
resolution otherwise theft can occur. And given today's "layered
commitment" style transaction where HTLCs are decoupled from
the balance output timeouts, I'm not sure this can save much.

I don't know enough about vault designs to judge.

CTV style commitments have popped up in a couple places in my
work on eltoo(emulated via APO sig-in-script), but mostly in the
context of reducing interactivity in protocols, not in byte savings per se.

Thanks!

Greg

On Fri, Aug 19, 2022 at 12:34 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Over the past few months there have been a few potential uses of
> OP_CHECKTEMPLATEVERIFY (BIP-119)
> (https://github.com/bitcoin/bitcoin/pull/21702) that I've found
> interesting.
>
> # Congestion control redux
>
> When I first heard of CTV, a presentation Jeremy did at Chaincode back
> in 2018 or '19, he cited congestion control as one of its main use
> cases.
>
> The pitch went something like
>
> > When there is a high demand for blockspace it becomes very expensive
> > to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume
> > payment processor may aggregate all their payments into a single O(1)
> > transaction for purposes of confirmation. Then, some time later, the
> > payments can be expanded out of that UTXO when the demand for
> > blockspace is decreased.
>
> (from https://utxos.org/uses/scaling/)
>
> At the time that didn't particularly grab me; the idea of smoothing fee
> rates seemed nice but marginal.
>
> But recently, two particular cases have made me reassess the value of
> congestion control.
>
> The first stems from the necessity of L2 protocols (payment channels,
> vaults, etc.) to, under certain circumstances, settle to the chain in a
> timely way in order to prevent abuse of the protocol. If some
> unexpected condition (a protocol exploit, large network disconnect, en
> masse vault breach, etc.) creates a situation where a large number of
> contracts need to settle to the chain in short order, mempools could
> fill up and protocol failures could happen for want of mempool/block
> space
> (
> https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all
> ).
>
> In such a case, CTV could be used effectively to "compress" settlement
> commitments, get them on-chain, and then facilitate later unpacking of
> the CTV ouputs into the contract's true end state.
>
> This amounts to `n` contract-control outputs (e.g. a lightning funding
> transaction outputs) being spent into a single CTV output, which
> commits to the final settlement state. Multiple parties could
> trustlessly collaborate to settle into a single CTV output using
> SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
> similar to coinjoins.
>
> Put simply, CTV allows deferring the chainspace required for the final
> settlement outputs, but still immediately requires space for the
> inputs. This might sound like a temporary reprieve from half-ish of the
> space required to settle, but in many (most?) cases the outputs require
> substantially more space than the inputs, given that often we're
> settling a single UTXO into multiple payouts per party. A 2, 3, or
> 4-fold increase (depending on the contracting pattern) in capacity
> isn't a silver bullet, but it could ameliorate the damage of unexpected
> settlement "tidal waves."
>
> Conceptually, CTV is the most parsimonious way to do such a scheme,
> since you can't really get smaller than a SHA256 commitment, and that's
> essentially all CTV is.
>
> The second congestion control case is related to a recent post Bram
> made about stability under a no-block-subsidy regime. He posted
>
> > If transaction fees came in at an even rate over time all at the
> > exact same level then they work fine for security, acting similarly
> > to fixed block rewards. Unfortunately that isn't how it works in the
> > real world. There's a very well established day/night cycle with fees
> > going to zero overnight and even longer gaps on weekends and
> > holidays. If in the future Bitcoin is entirely dependent on fees for
> > security (scheduled very strongly) and this pattern keeps up
> > (overwhelmingly likely) then this is going to become a serious
> > problem.
>
> (from
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
> )
>
> Ryan Grant points out that CTV's congestion control use could help to
> smooth fees, creating a less spiky incentive to mine
> (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
> ).
>
> Admittedly the original 

[bitcoin-dev] More uses for CTV

[James O'Beirne via bitcoin-dev]

Over the past few months there have been a few potential uses of
OP_CHECKTEMPLATEVERIFY (BIP-119)
(https://github.com/bitcoin/bitcoin/pull/21702) that I've found
interesting.

# Congestion control redux

When I first heard of CTV, a presentation Jeremy did at Chaincode back
in 2018 or '19, he cited congestion control as one of its main use
cases.

The pitch went something like

> When there is a high demand for blockspace it becomes very expensive
> to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume
> payment processor may aggregate all their payments into a single O(1)
> transaction for purposes of confirmation. Then, some time later, the
> payments can be expanded out of that UTXO when the demand for
> blockspace is decreased.

(from https://utxos.org/uses/scaling/)

At the time that didn't particularly grab me; the idea of smoothing fee
rates seemed nice but marginal.

But recently, two particular cases have made me reassess the value of
congestion control.

The first stems from the necessity of L2 protocols (payment channels,
vaults, etc.) to, under certain circumstances, settle to the chain in a
timely way in order to prevent abuse of the protocol. If some
unexpected condition (a protocol exploit, large network disconnect, en
masse vault breach, etc.) creates a situation where a large number of
contracts need to settle to the chain in short order, mempools could
fill up and protocol failures could happen for want of mempool/block
space
(
https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all
).

In such a case, CTV could be used effectively to "compress" settlement
commitments, get them on-chain, and then facilitate later unpacking of
the CTV ouputs into the contract's true end state.

This amounts to `n` contract-control outputs (e.g. a lightning funding
transaction outputs) being spent into a single CTV output, which
commits to the final settlement state. Multiple parties could
trustlessly collaborate to settle into a single CTV output using
SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
similar to coinjoins.

Put simply, CTV allows deferring the chainspace required for the final
settlement outputs, but still immediately requires space for the
inputs. This might sound like a temporary reprieve from half-ish of the
space required to settle, but in many (most?) cases the outputs require
substantially more space than the inputs, given that often we're
settling a single UTXO into multiple payouts per party. A 2, 3, or
4-fold increase (depending on the contracting pattern) in capacity
isn't a silver bullet, but it could ameliorate the damage of unexpected
settlement "tidal waves."

Conceptually, CTV is the most parsimonious way to do such a scheme,
since you can't really get smaller than a SHA256 commitment, and that's
essentially all CTV is.

The second congestion control case is related to a recent post Bram
made about stability under a no-block-subsidy regime. He posted

> If transaction fees came in at an even rate over time all at the
> exact same level then they work fine for security, acting similarly
> to fixed block rewards. Unfortunately that isn't how it works in the
> real world. There's a very well established day/night cycle with fees
> going to zero overnight and even longer gaps on weekends and
> holidays. If in the future Bitcoin is entirely dependent on fees for
> security (scheduled very strongly) and this pattern keeps up
> (overwhelmingly likely) then this is going to become a serious
> problem.

(from
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
)

Ryan Grant points out that CTV's congestion control use could help to
smooth fees, creating a less spiky incentive to mine
(
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html
).

Admittedly the original concern is speculative and a ways off from now,
as others in the thread pointed out. But having CTV-based fee smoothing
as an option certainly doesn't seem like a bad thing.


# Atomic mining pool payouts

Laurentia is a mining pool design that pays participants out directly
from the coinbase of found blocks.

> Block solve reward is distributed directly from the block to each
> user, meaning each user gets a 'mined' transaction directly into
> their wallet as soon as the block is solved so there is no wait to
> get paid and no pool wallet storing user's rewards.

(from
https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf
)

I'm not a mining expert and so I can't speak to the efficacy of the
paper as a whole, but direct-from-coinbase payouts seem like a
desirable feature which avoids some trust in pools. One limitation is
the size of the coinbase outputs owed to constituent miners; this
limits the number of participants in the pool.

If the payout was instead a single OP_CTV output, an arbitrary number
of pool participants could be paid out "atomically" within a single
coinbase.

---

CTV 

Re: [bitcoin-dev] A method for BIP322 signing delegation

[Ali Sherief via bitcoin-dev]

Since I mailed the original scheme, some people have suggested to me that this 
delegation scheme can be written in TapScript, to avoid revealing the unspent 
public keys. I think that is a good idea.

Here is a very helpful slideshow about implementing Multisig scripts in Taproot 
by Jimmy Song[1] - specifically, I have looked into "Single leaf k-of-n 
multisig" and "Multi-leaf k-of-k multisig". I have not considered the approach 
with MuSig, considering there is not even a BIP for that.

To my understanding, Single leaf k-of-n multisig is functionally identical to 
"Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, 
which itself has nearly all of the properties of the original CHECKMULTISIG 
opcode[2]. In other words, it won't hide the non-signing public keys (the 
TapScript is literally " OP_CHECKSIG ...  OP_CHECKSIGADD 
OP_ OP_NUMEQUAL", so it doesn't solve the privacy problem.

That leaves Multi-leaf k-of-k multisig. Now to my understanding, in every 
TapLeaf/Branch, there is going to be a K-of-K TapScript similar to the one 
constructed above. In each leaf there will be a combination of K public keys, 
so the number of leaves is going to be equal to nCr(n,k).

No wonder why BIP 342 says that it's only cost-effective for small values of k, 
because the number of leaves and thus the transaction size swells as k 
increases.

Fortuantely, for the purposes of delegation, K will always be 1, because we 
only utilize 1-n multisig signatures as per my previous message. Thus the fee 
rate will be economical for all values of N i.e. number of delegatees. This 
enables this scheme to have a wider use case than just BIP322 (even here 
though, decreasing the raw transaction size of 'to_sign' is a net positive for 
space reasons).

In other words, every TapScript is just  OP_CHECKSIG OP_1 OP_NUMEQUAL, 
which can be simplified to just  OP_CHECKSIG since OP_CHECKSIG failure 
in a TapScript returns the empty vector (false) on failure, and 1 (true) on 
success. I wrote the longer script merely because it's consistent with the 
script format in [2], but since it's by no means a standardness requirement, we 
can save 2*N bytes in the entire transaction.

So, for small numbers of delegates, these savings are not very eye-watering, 
but if fees become larger then every byte will matter. After all, I envision 
uses for delegation beyond BIP 322 anyway.

At this point, the witness stack of 'to_sign' will have one of these 
TapScripts, and an appropriately constructed BIP 341 control block. Obviously 
'to_spend''s output scriptPubKey will push the SHA256 hash of the witness 
program.

Use cases:
- BIP 322 (obviously)
- Any L2 protocol where participants' funds must be delegated to a comittee 
e.g. LN channels - which, in fact, are still using OP_CHECKMULTISIG.
-- Where such a protocol requires the joint consensus of all participants, such 
as an LN channel closing gracefully, K can be modified appropriately, but this 
is beyond the scope of this scheme. Make a BOLT or the appropriate standard 
proposal if this affects your L2 network.

Advantages where they are relevant for BIP 322 :

- Signature fraud is still impossible to carry out (the entire to_sign 
transaction still has to be verified, but now Address can be empty since the 
public key is in the control block which is in the 'to_sign' witness, and the 
spent TapScript is also in the 'to_sign' witness).
- Delegated signers still use standard address type (Bech32m Taproot addresses).
- No new opcodes are introduced, and no existing ones are redefined so no 
soft-forks are necessary.

Advantages for all applications of this BIP :

- Only the delegatee who actually signs the message has a revealed public key, 
the others' are hidden - a major privacy advantage.
- Signers must be determined beforehand. Jimmy Song actually lists this as a 
disadvantage, but I disagree. For L2 delegation, it is necessary to know the 
other parties to avoid a MITM attack where one of the signers is replaced by a 
rogue signer - through non-cryptographic methods of course (e.g. a computer 
hack).

Disadvantages :

- Taproot is not widely deployed in applications yet?
- I can't think of any others, unless you consider the signer's public key 
being revealed a disadvantage [I wouldn't, because if it were hidden, it would 
defeat the whole purpose of signing by making it vulnerable to the 
aforementioned "signature fraud"].

My grasp on Taproot constructs is not 100%. So feel free to point out any 
errors in my reasoning for this scheme if you spot any.

- Ali

[1] - https://jimmysong.github.io/taproot-multisig
[2] - 
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_ref-5-0

On Tue Aug 16 04:38:47 UTC 2022, a...@notatether.com wrote:
>(Note: I'm going to stick with this thread for all proposals for BIP322 
>polishing, not just delegation - unless the subject matter changes radically 
>as other people discuss it.)
>
>Instead of the admittingly 

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[vjudeu via bitcoin-dev]

> If we actually wanted to solve the potential problem of not-enough-fees to 
> upkeep mining security, there are less temporary ways to solve that. For 
> example, if fees end up not being able to support sufficient mining, we could 
> add emission based on a constant fraction of fees in the block. For example, 
> every block could emit new bitcoin amounting to 10% of the fees collected in 
> that block. This would tie coinbase rewards to the real world (since the fee 
> market is tied to the real economy) and ensure higher block revenue 
> indefinitely - ie not just for another 50 years.

Miners can game this system by moving their own coins in 100% fees 
transactions, just to produce more coins. You have one million BTC? No problem, 
just move them as fees, and you just created 100k BTC out of thin air, just 
because you are a wealthy miner. And even if that amount will be stolen, when 
some other miner will reorg your block, then still, miners will keep creating 
coins by moving them as fees, and the strongest miner will get the whole pot. 
And guess what: 100 blocks later you can reuse newly created 100k BTC to make 
another 10k BTC, so it will exponentially explode as (amountOfCoins*(1+0.1))^n 
function. And guess what: (1.1)^8 is 2.14358881. That means, after eight moves, 
you can double your coins, if you are a wealthy miner. And you can start with 
smaller amounts, to play it safe, but eventually, this system will degrade into 
"coin doubler after 800 blocks" or something similar.


On 2022-08-18 18:45:43 user Billy Tetrud via bitcoin-dev 
 wrote:
While constant tail emission does in fact converge to 0 inflation over time 
(which bitcoin's halvings do as well mind you), tail emission does *not* solve 
the potential problem of mining rewards, it only delays it. A tail emission of 
200,000 btc/year (~1% of the current supply) would be equivalent to halvings 
every ~50 years rather than every 4 years. Were we to implement this kind of 
thing right after the last non-" destructive" halving, it would buy us 46 years 
of extra time. Nothing more, nothing less.


While its mildly interesting to know that tail emission converges to a stable 
point, while no inflation implies monetary deflation at the rate of loss, this 
feels very likely to be an insignificant problem. I think 1% loss rate per year 
is an absurdly high estimate these days, and the loss rate is likely to 
decrease as methods of storing bitcoin mature. Imagine bitcoin was worth $1 
trillion (not so hard, since it was not too long ago), then try imagining 
people losing $10 billion of bitcoin every year. Highly unlikely IMO. A rate of 
loss of 0.01%/year might be more realistic for a near-future mature bitcoin. 
That's not going to be enough to make a significant difference even over 100s 
of years. 


If we actually wanted to solve the potential problem of not-enough-fees to 
upkeep mining security, there are less temporary ways to solve that. For 
example, if fees end up not being able to support sufficient mining, we could 
add emission based on a constant fraction of fees in the block. For example, 
every block could emit new bitcoin amounting to 10% of the fees collected in 
that block. This would tie coinbase rewards to the real world (since the fee 
market is tied to the real economy) and ensure higher block revenue 
indefinitely - ie not just for another 50 years. 


But its also worth saying that blockchain security (which mining revenue 
correlates with) does *not* need to increase indefinitely. There is some amount 
of security (and therefore some amount of mining revenue) that is sufficient, 
beyond which additional security is simply unnecessary, unwarranted, and 
wasteful (you wouldn't buy a $1000 safe to store $1000 of valuables). Do we, as 
the bitcoin community, have some good idea how much security we need? Do we 
have some idea how costly a 51% attack must be where we can be comfortable it 
will never happen? I'm curious to hear what people think about that. Because 
without having some kind of estimates of what "enough security" is, there's 
absolutely no way of evaluating whether or not its likely that bitcoin fees 
alone will be able to sustain enough security. 






On Wed, Aug 17, 2022 at 9:31 AM Jaroslaw via bitcoin-dev 
 wrote:

On one scale you puts the Trust to the large stakeholders (why we avoid plenty 
of small stakeholders, btw),
and on the other side I put game theory and well defined Prisoner's Dilemma.

Again: large stakeholders WILL NOT incentivised to mine, they will have the 
hundreds excuses why not to switch-on Antminers back.
That's how it simply works.  Bitcoin would fail miserably if Satoshi was based 
his concept mainly on existence of idealists.

If we will observe lack of hashrate recovery four years after some halving and 
still unprepared like today
- means the trust in large stakeholders was a very costly mistake.


Superiority of Proof of Work against Proof of Stake has been discussed