Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

[Matt Corallo via bitcoin-dev]

On 9/7/21 09:07, 0xB10C via bitcoin-dev wrote:

Hello,

tl;dr: We want to make reorgs on SigNet a reality and are looking for
feedback on approach and parameters.


Awesome!


AJ proposed to allow SigNet users to opt-out of reorgs in case they
explicitly want to remain unaffected. This can be done by setting a
to-be-reorged version bit flag on the blocks that won't end up in the
most work chain. Node operators could choose not to accept to-be-reorged
SigNet blocks with this flag set via a configuration argument.


Why bother with a version bit? This seems substantially more complicated than the original proposal 
that surfaced many times before signet launched to just have a different reorg signing key. Thus, 
users who wish to follow reorgs can use a 1-of-2 (or higher multisig) and users who wish to not 
follow reorgs would use a 1-of-1 (or higher multisig), simply marking the reorg blocks as invalid 
without touching any header bits that non-full clients will ever see.



The reorg-interval X very much depends on the user's needs. One could
argue that there should be, for example, three reorgs per day, each 48
blocks apart. Such a short reorg interval allows developers in all time
zones to be awake during one or two reorgs per day. Developers don't
need to wait for, for example, a week until they can test their reorgs
next. However, too frequent reorgs could hinder other SigNet users.


I see zero reason whatsoever to not simply reorg ~every block, or as often as is practical. If users 
opt in to wanting to test with reorgs, they should be able to test with reorgs, not wait a day to 
test with reorgs.



We propose that the reorg depth D is deterministically random between a
minimum and a maximum based on, e.g., the block hash or the nonce of the
last block before the reorg. Compared to a local randint() based
implementation, this allows reorg-handling tests and external tools to
calculate the expected reorg depth.

# Scenario 1: Race between two chains

For this scenario, at least two nodes and miner scripts need to be
running. An always-miner A continuously produces blocks and rejects
blocks with the to-be-reorged version bit flag set. And a race-miner R
that only mines D blocks at the start of each interval and then waits X
blocks. A and R both have the same hash rate. Assuming both are well
connected to the network, it's random which miner will first mine and
propagate a block. In the end, the A miner chain will always win the race.

# Scenario 2: Chain rollback

This scenario only requires one miner and Bitcoin Core node but also
works in a multiminer setup. The miners mine D blocks with the
to-be-reorged version bit flag set at the start of the interval. After
allowing the block at height X+D to propagate, they invalidate the block
at height X+1 and start mining on block X again. This time without
setting the to-be-reorged version bit flag. Non-miner nodes will reorg
to the new tip at height X+D+1, and the first-seen branch stalls.


Both seem reasonable. I'm honestly not sure what software cases would be hit differently between one 
or the other, as long as reorgs happen regularly and at random depth. Nodes should presumably only 
ever be following one chain.



# Questions

     1. How do you currently test your applications reorg handling? Do
the two discussed scenarios (race and chain rollback) cover your
needs? Are we missing something you'd find helpful?

     2. How often should reorgs happen on the default SigNet? Should
there be multiple reorgs a day (e.g., every 48 or 72 blocks
assuming 144 blocks per day) as your engineers need to be awake?
Do you favor less frequent reorgs (once per week or month)? Why?

 3. How deep should the reorgs be on average? Do you want to test
deeper reorgs (10+ blocks) too?


6 is the "standard" confirmation window for mainnet. Its arguably much too low, but for testing 
purposes we've gotta pick something, so that seems reasonable?


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

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

[Jeremy via bitcoin-dev]

I'm a bit skeptical of the safety of the control byte. Have you considered
the following issues?



> The low bit of C indicates the parity of X; if it's 0, X has even y,
> if it's 1, X has odd y.
>
> The next bit of C indicates whether the current script is dropped from
> the merkle path, if it's 0, the current script is kept, if it's 1 the
> current script is dropped.
>
> The remaining bits of C (ie C >> 2) are the number of steps in the merkle
> path that are dropped. (If C is negative, behaviour is to be determined
> -- either always fail, or always succeed and left for definition via
> future soft-fork)
>
> For example, suppose we have a taproot utxo that had 5 scripts
> (A,B,C,D,E), calculated as per the example in BIP 341 as:
>
> AB = H_TapBranch(A, B)
> CD = H_TapBranch(C, D)
> CDE = H_TapBranch(CD, E)
> ABCDE = H_TapBranch(AB, CDE)
>
> And we're spending using script E, in that case the control block includes
> the script E, and the merkle path to it, namely (AB, CD).
>
> So here's some examples of what you could do with TLUV to control how
> the spending scripts can change, between the input sPK and the output sPK.
>
> At it's simplest, if we used the script "0 0 0 TLUV", then that says we
> keep the current script, keep all steps in the merkle path, don't add
> any new ones, and don't change the internal public key -- that is that
> we want to resulting sPK to be exactly the same as the one we're spending.
>
> If we used the script "0 F 0 TLUV" (H=F, C=0) then we keep the current
> script, keep all the steps in the merkle path (AB and CD), and add
> a new step to the merkle path (F), giving us:
>
> EF = H_TapBranch(E, F)
> CDEF =H_TapBranch(CD, EF)
> ABCDEF = H_TapBranch(AB, CDEF)
>
> If we used the script "0 F 2 TLUV" (H=F, C=2) then we drop the current
> script, but keep all the other steps, and add a new step (effectively
> replacing the current script with a new one):
>
> CDF = H_TapBranch(CD, F)
> ABCDF = H_TapBranch(AB, CDF)
>

If we recursively apply this rule, would it not be possible to repeatedly
apply it and end up burning out path E beyond the 128 Taproot depth limit?

Suppose we protect against this by checking that after adding F the depth
is not more than 128 for E.

The E path that adds F could also be burned for future use once the depth
is hit, and if adding F is necessary for correctness, then we're burned
anyways.

I don't see a way to protect against this generically.

Perhaps it's OK: E can always approve burning E?




>
> If we used the script "0 F 4 TLUV" (H=F, C=4) then we keep the current
> script, but drop the last step in the merkle path, and add a new step
> (effectively replacing the *sibling* of the current script):
>
> EF = H_TapBranch(E, F)
> ABEF = H_TapBranch(AB, EF)


> If we used the script "0 0 4 TLUV" (H=empty, C=4) then we keep the current
> script, drop the last step in the merkle path, and don't add anything new
> (effectively dropping the sibling), giving just:
>
> ABE = H_TapBranch(AB, E)
>
>
>
Is C = 4 stable across all state transitions? I may be missing something,
but it seems that the location of C would not be stable across transitions.


E.g., What happens when, C and E are similar scripts and C adds some
clauses F1, F2, F3, then what does this sibling replacement do? Should a
sibling not be able to specify (e.g., by leaf version?) a NOREPLACE flag
that prevents siblings from modifying it?

What happens when E adds a bunch of F's F1 F2 F3, is C still in the same
position as when E was created?

Especially since nodes are lexicographically sorted, it seems hard to
create stable path descriptors even if you index from the root downwards.

Identifying nodes by Hash is also not acceptable because of hash cycles,
unless you want to restrict the tree structure accordingly (maybe OK
tradeoff?).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Clarification on the use of getblocktemplate RPC method.

[Luke Dashjr via bitcoin-dev]

https://github.com/bitcoin/libblkmaker/blob/master/blkmaker.c#L172

On Thursday 09 September 2021 12:54:18 Mike Rosset via bitcoin-dev wrote:
> Hello all,
>
> I recently went down the bitcoin protocol rabbit hole. I wanted to use
> GNU guile scheme to experiment with bitcoin. I initially started by
> creating a toy bitcoin miner but I've run into some inconsistencies with
> the documentation found on
> https://en.bitcoin.it/wiki/Getblocktemplate. Namely with creating the
> templates merkle root.
>
> From my understanding a coinbase transaction should have the
> transactions data concatenated before creating the merkle root. But
> getblocktemplate does not have a json cointbasetxn field. So I'm not
> sure how to create a coinbase transaction without that.
>
> I have a test template response data found here.
> https://raw.githubusercontent.com/mrosset/prospect/master/test-suite/data.j
>son and using a modified version of the merkle python reference script found
> on the wiki page. see
> https://github.com/mrosset/prospect/blob/master/scripts/merkle.py . I'm
> able to create a merkle root with the hash
> c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a but
> that's minus the coinbase transaction.
>
> So far I'm able to replicate this hash using the test data in guile. But
> I'd like to sanitize this so that I'm using a coinbase transaction and
> making sure the python and guile merkle roots match.
>
> In short how do I get the coinbase transaction without the coinbasetxn
> field existing?
>
> Mike
> ___
> 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

[bitcoin-dev] Clarification on the use of getblocktemplate RPC method.

[Mike Rosset via bitcoin-dev]

Hello all,

I recently went down the bitcoin protocol rabbit hole. I wanted to use
GNU guile scheme to experiment with bitcoin. I initially started by
creating a toy bitcoin miner but I've run into some inconsistencies with
the documentation found on
https://en.bitcoin.it/wiki/Getblocktemplate. Namely with creating the
templates merkle root.

>From my understanding a coinbase transaction should have the
transactions data concatenated before creating the merkle root. But
getblocktemplate does not have a json cointbasetxn field. So I'm not
sure how to create a coinbase transaction without that.

I have a test template response data found here.
https://raw.githubusercontent.com/mrosset/prospect/master/test-suite/data.json
and using a modified version of the merkle python reference script found
on the wiki page. see
https://github.com/mrosset/prospect/blob/master/scripts/merkle.py . I'm
able to create a merkle root with the hash
c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a but
that's minus the coinbase transaction.

So far I'm able to replicate this hash using the test data in guile. But
I'd like to sanitize this so that I'm using a coinbase transaction and
making sure the python and guile merkle roots match.

In short how do I get the coinbase transaction without the coinbasetxn
field existing?

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

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

[Jeremy via bitcoin-dev]

I like this proposal, I think it has interesting use cases! I'm quick to
charitably Matt's comment, "I’ve been saying we need more covenants
research and proposals before we move forward with one", as before we move
forward with *any.* I don't think that these efforts are rival -- different
opcodes for different nodes as they say.

I've previously done some analysis comparing Coin / Payment Pools with CTV
to TapLeafUpdate which make CTV out favorably in terms of chain load and
privacy.

On the "anyone can withdraw themselves in O(1) transactions" front, is that
if you contrast a CTV-style tree, the withdraws are O(log(n)) but E[O(1)]
for all participants, e.g. summing over the entire tree as it splits to
evict a bad actor ends up being O(N) total work over N participants, so you
do have to look at the exact transactions that come out w.r.t. script size
to determine which Payment Pool has overall less chain work to trustlessly
withdraw. This is compounded by the fact that a Taproot for N participants
uses a O(log N) witness.


Let's do out that basic math. First, let's assume we have 30 participants.
The basic script for each node would be:

TLUV: Taproot(Tweaked Key, { DUP "" 1 TLUV
CHECKSIGVERIFY
IN_OUT_AMOUNT SUB  GREATERTHANOREQUAL, ...})

Under this, the first withdraw for TLUV would require in witnesses stack:
Assume average amount is 0.005BTC, so we have 4.2 B users = 18.9 bits =3
bytes

1 signature (1+64 bytes) + (1 Script = (+ 1 1 32 1 1 1 1 1 1 1 3 1 1) = 46
bytes) + (1 taproot path = 2 + 33 + log2(N)*32)
= 146+log2(N)*32.

now, because we delete the key, we need to sum this from N=0 to N=30:

>>> sum([65+46+35+math.log(N,2)*32 for N in range(1, 31)])
7826.690154943152 bytes of witness data

Each transaction should have 1 input (40 bytes), 2 outputs (2* (34+8) =
84), 4 bytes locktime, 4 bytes version, 2 byte witness flag, 1 byte in
counter 1 byte out counter  = 136 bytes (we already count witnesses above)


136 * 30 + 7827 = 11907 bytes to withdraw all trustlessly

Now for CTV:
-CTV: Taproot(MuSigKey(subparties),  CTV)

*sidebar: **why radix 4? A while ago, I did the math out and a radix of 4
or 5 was optimal for bare script... assuming this result holds with
taproot.*


balance holders: 0..30
you have a base set of transactions paying out: 0..4 4..8 8..12 12..16
16..20 20..24 24..27 27..30
interior nodes covering: 0..16 16..30
root node covering: 0..30

The witness for each of these looks like:

(Taproot Script = 1+1+32+1) + (Taproot Control = 33) = 68 bytes

A transaction with two outputs should have 1 input (40 bytes), 2 outputs
(2* (34+8) = 84), 4 bytes locktime, 4 bytes version, 2 byte witness flag, 1
byte in counter 1 byte out counter  = 136 bytes + 68 bytes witness = 204
A transaction with three outputs should have 1 input (40 bytes), 3 outputs
(3* (34+8) = 126), 4 bytes locktime, 4 bytes version, 2 byte witness flag,
1 byte in counter 1 byte out counter  = 178 bytes + 68 bytes witness = 246
A transaction with 4 outputs should have 1 input (40 bytes), 4 outputs (4*
(34+8) = 126), 4 bytes locktime, 4 bytes version, 2 byte witness flag, 1
byte in counter 1 byte out counter  = 220 bytes + 68 bytes witness = 288

204 + 288*6 + 246*2 = 2424 bytes

Therefore the CTV style pool is, in this example, about 5x more efficient
in block space utilization as compared to TLUV at trustlessly withdrawing
all participants. This extra space leaves lots of headroom to e.g.
including things like OP_TRUE anchor outputs (12*10) = 120 bytes total for
CPFP; an optional script path with 2 inputs for a gas-paying input (cost is
around 32 bytes for taproot?). The design also scales beyond 30
participants, where the advantage grows further (iirc, sum i = 0 to n log i
is relatively close to n log n).

In the single withdrawal case, the cost to eject a single participant with
CTV is 204+288 = 492 bytes, compared to 65+46+35+math.log(30,2)*32+136 =
439 bytes. The cost to eject a second participant in CTV is much smaller as
it amortizes -- worst case is 288, best case is 0 (already expanded),
whereas in TLUV there is limited amortization so it would be about 438
bytes.

The protocols are identical in the cooperative case.

In terms of privacy, the CTV version is a little bit worse. At every
splitting, radix of the root nodes total value gets broadcast. So to eject
a participant, you end up leaking a bit more information. However, it might
be a reasonable assumption that if one of your counterparties is
uncooperative, they might dox you anyways. CTV trees are also superior
during updates for privacy in the cooperative case. With the TLUV pool, you
must know all tapleafs and the corresponding balances. Whereas in CTV
trees, you only need to know the balances of the nodes above you. E.g., we
can update the balances

from: [[1 Alice, 2 Bob], [3 Carol, 4 Dave]]
to: [[2.5 Alice, 0.5 Bob], [3 Carol, 4 Dave]]

without informing Carol or Dave about the updates in our subtree, just that
our slice of participants signed off o

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

[darosior via bitcoin-dev]

Hi Anthony,


This post is a follow-up to your insight on Twitter [0], sent here for better
posterity, accessibility and readability than Twitter. And also to motivate this
idea by giving another concrete [1] usecase for it.

Revault [2] is a multi-party "vault" protocol. It involves 2 sets of 
participants
that may or may not intersect (although i expect the second one to often be a 
subset
of the first one). The stakeholders, analogous to the "cold keys", receive 
coins on
a (large) N-of-N multisig and presign an Unvault transaction which creates an 
Unvault
output which pays to either the (small) K-of-M multisig of the managers after a 
timelock
or to the N-of-N immediately (allowing for a Cancel transaction).

This allows for partial delegation of the funds, and some automated policies 
(can't
broadcast the Unvault outside business hours, can't unvault more than  
BTC a
week, etc..) that can be enforced by watchtowers. That's nice, but it would be 
even
nicer if we could have policies on the Spend transaction (the one created by the
managers to spend the Unvault output) itself to further restrict how the coin 
can move [3].

But in order to do so, you'd need the managers to disclaim the Spend 
transaction they
are going to use before broadcasting the Unvault and somehow commit to it at 
unvaulting
time. Apart from stupid hacks [4] i could not find a reasonable covenant design 
as a
solution to this issue.
It think TLUV fixes this.

The idea (your idea, actually) is to receive coins not to a N-of-N anymore but 
to a
Taproot with a branch which contains the manager multisig + a TLUV which would 
replace
the current branch being executed by a CSV + CTV which input hash value will be 
taken
from the witness stack at Unvault broadcast. Therefore chosen by the managers 
at spending
time, and available for the entire duration of the timelock.

So, the scripts would be something like (assuming CAT, CTV, TLUV):
V = max acceptable fees
D = "CTV  CSV DROP 1"
C = "<32 bytes> D"
B = "
 CHECKSIG  CHECKSIGADD ...  CHECKSIGADD  
EQUALVERIFY
IN_OUT_AMOUNT SUB  LESSTHANOREQUAL DUP VERIFY
SIZE 32 EQUALVERIFY <0xc0 | len(D) + 32 + 1 | 0x20> SWAP CAT "Tapleaf" SHA256 
DUP CAT SWAP CAT SHA256 0 SWAP 2 TLUV
"
A = " CHECKSIGVERIFY  CHECKSIGVERIFY ...  
CHECKSIG"

The deposit output ScriptPubKey would be Taproot(A, B) [5].
The unvault output ScriptPubKey would be Taproot(A, C).
This also allows for a lot more flexibility (batching at the Unvault level [7], 
use RBF
instead of more wasteful CPFP, etc..) and creates a number of problems [6] on 
which
i won't expand on. But it does the most important part: it enables it.

Looking forward to more feedback on your proposal!


Thanks,
Antoine



[0] https://twitter.com/ajtowns/status/1435884659146059776?s=20
[1] we've proposed Revault a year and a half ago, have been building it since. 
We
should have a first version released soon (tm).
[2] https://github.com/revault
[3] technically we do optionally offer this at the moment, but at the expense 
of a
reduction of security and a pretty ugly hack: by using "anti-replay" oracles
(cosigning servers that are only going to sign only once for a given 
prevout)
[4] the last bad idea to date is "have ANYPREVOUT, presign the Unvault with
SIGHASH_SINGLE, enforce that the Unvault output is only spent with a 
transaction
spending :1 and have managers append an output to the Unvault 
enforcing
a covenant just before broadcast"
[5] as a branch because i don't know how to use the keypath spend for a 
multisig with
cold keys (yet).
[6] as such you'd need a sig for canceling but not for unvaulting, so it 
reverses the
security model from "can't do anything til everyone signed" to "can steal 
until
everyone has signed" so you'd need a TLUV for the cancel spending path as 
well, but
then how to make this covenant non-replayable, flexible enough to feebump 
but not
enough be vulnerable to pining, etc..
[7] Note that this means all Cancel must be confirmed to recover the funds but 
a single
one needs to in order to prevent a spending.

‐‐‐ Original Message ‐‐‐

Le jeudi 9 septembre 2021 à 8:53 AM, Anthony Towns via bitcoin-dev 
 a écrit :

> On Thu, Sep 09, 2021 at 04:41:38PM +1000, Anthony Towns wrote:
>
> > I'll split this into two emails, this one's the handwavy overview,
> >
> > the followup will go into some of the implementation complexities.
>
> (This is informed by discussions with Greg, Matt Corallo, David Harding
>
> and Jeremy Rubin; opinions and mistakes my own, of course)
>
> First, let's talk quickly about IN_OUT_AMOUNT. I think the easiest way to
>
> deal with it is just a single opcode that pushes two values to the stack;
>
> however it could be two opcodes, or it could even accept a parameter
>
> letting you specify which input (and hence which corresponding output)
>
> you're talking about (-1 meaning the current input perhaps).
>
> Anyway, a big complication here is that amounts in

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

[Matt Corallo via bitcoin-dev]

Thanks for taking the time to write this up!

To wax somewhat broadly here, I’m very excited about this as a direction for 
bitcoin covenants. Other concrete proposals seem significantly more limited, 
which worries me greatly. Further, this feels very “taproot-native” in a way 
that encourages utilizing taproot’s features fully while building covenants, 
saving fees on chain and at least partially improving privacy.

I’ve been saying we need more covenants research and proposals before we move 
forward with one and this is a huge step in that direction, IMO. With Taproot 
activating soon, I’m excited for what coming forks bring.

Matt

> On Sep 8, 2021, at 23:42, Anthony Towns via bitcoin-dev 
>  wrote:
> 
> Hello world,
> 
> A couple of years ago I had a flight of fancy [0] imagining how it
> might be possible for everyone on the planet to use bitcoin in a
> mostly decentralised/untrusted way, without requiring a block size
> increase. It was a bit ridiculous and probably doesn't quite hold up,
> and beyond needing all the existing proposals to be implemented (taproot,
> ANYPREVOUT, CTV, eltoo, channel factories), it also needed a covenant
> opcode [1]. I came up with something that I thought fit well with taproot,
> but couldn't quite figure out how to use it for anything other than my
> ridiculous scheme, so left it at that.
> 
> But recently [2] Greg Maxwell emailed me about his own cool idea for a
> covenant opcode, which turned out to basically be a reinvention of the
> same idea but with more functionality, a better name and a less fanciful
> use case; and with that inspiration, I think I've also now figured out
> how to use it for a basic vault, so it seems worth making the idea a
> bit more public.
> 
> I'll split this into two emails, this one's the handwavy overview,
> the followup will go into some of the implementation complexities.
> 
> 
> 
> The basic idea is to think about "updating" a utxo by changing the
> taproot tree.
> 
> As you might recall, a taproot address is made up from an internal public
> key (P) and a merkle tree of scripts (S) combined via the formula Q=P+H(P,
> S)*G to calculate the scriptPubKey (Q). When spending using a script,
> you provide the path to the merkle leaf that has the script you want
> to use in the control block. The BIP has an example [3] with 5 scripts
> arranged as ((A,B), ((C,D), E)), so if you were spending with E, you'd
> reveal a path of two hashes, one for (AB), then one for (CD), then you'd
> reveal your script E and satisfy it.
> 
> So that makes it relatively easy to imagine creating a new taproot address
> based on the input you're spending by doing some or all of the following:
> 
> * Updating the internal public key (ie from P to P' = P + X)
> * Trimming the merkle path (eg, removing CD)
> * Removing the script you're currently executing (ie E)
> * Adding a new step to the end of the merkle path (eg F)
> 
> Once you've done those things, you can then calculate the new merkle
> root by resolving the updated merkle path (eg, S' = MerkleRootFor(AB,
> F, H_TapLeaf(E))), and then calculate a new scriptPubKey based on that
> and the updated internal public key (Q' = P' + H(P', S')).
> 
> So the idea is to do just that via a new opcode "TAPLEAF_UPDATE_VERIFY"
> (TLUV) that takes three inputs: one that specifies how to update the
> internal public key (X), one that specifies a new step for the merkle path
> (F), and one that specifies whether to remove the current script and/or
> how many merkle path steps to remove. The opcode then calculates the
> scriptPubKey that matches that, and verifies that the output corresponding
> to the current input spends to that scriptPubKey.
> 
> That's useless without some way of verifying that the new utxo retains
> the bitcoin that was in the old utxo, so also include a new opcode
> IN_OUT_AMOUNT that pushes two items onto the stack: the amount from this
> input's utxo, and the amount in the corresponding output, and then expect
> anyone using TLUV to use maths operators to verify that funds are being
> appropriately retained in the updated scriptPubKey.
> 
> 
> 
> Here's two examples of how you might use this functionality.
> 
> First, a basic vault. The idea is that funds are ultimately protected
> by a cold wallet key (COLD) that's inconvenient to access but is as
> safe from theft as possible. In order to make day to day transactions
> more convenient, a hot wallet key (HOT) is also available, which is
> more vulnerable to theft. The vault design thus limits the hot wallet
> to withdrawing at most L satoshis every D blocks, so that if funds are
> stolen, you lose at most L, and have D blocks to use your cold wallet
> key to re-secure the funds and prevent further losses.
> 
> To set this up with TLUV, you construct a taproot output with COLD as
> the internal public key, and a script that specifies:
> 
> * The tx is signed via HOT
> *  CSV -- there's a relative time lock since the last spend
> * If the input am

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

[Antoine Riard via bitcoin-dev]

Hi Jeremy,

Answering here from #22871 discussions.

I agree on the general principle to not blur mempool policies signaling in
committed transaction data. Beyond preserving upgradeability, another good
argument is to let L2 nodes update the mempool policies signaling their
pre-signed transactions non-interactively. If one of the transaction fields
is assigned mempool semantics, in case of tightening policy changes, you
will need to re-sign or bear the risks of having non-propagating
transactions which opens the door for exploitation by a malicious
counterparty. I think this point is kinda relevant if we have future
cross-layer coordinated safety fixes to deal with a la CVE-2021-31876.

Even further, a set of L2 counterparties would like to pick up divergent
tx-relay/mempool policies, having the signaling fields as part of the
signature force them to come to consensus.

I think we can take the opportunity of p2p packages to introduce a new
field to signal policy. Of course, a malicious tx-relay peer could modify
its content to jam your transaction's propagation but in that case it is
easier to just drop it.

One issue with taking back the `nSequence` field for consensus-semantic
sounds is depriving the application-layer from a discrete, zero-cost
payload (e.g the LN obfuscated commitment number watermark). This might be
controversial as we'll increase the price of such applications if they're
still willingly to relay application specific data through the p2p network
(e.g force them to use a costly OP_RETURN output or payer/payee
interactions to setup a pay-to-contract)

W.r.t flag day activation to smooth policy deployment, I think that's
something we might rely on in the future though we could distinguish few
types of policy deployments :
1) loosening changes (e.g full-rbf/dust threshold removal), a transaction
which was relaying under
the former policy should relay under the new one
2) tightening changes (e.g #22871), a transaction which was relaying under
the former policy
might not relay under the new one
3) new feature introduced (e.g packages), a transaction is offered a new
mode of relay

I think 1) doesn't need that level of ecosystem coordination as
applications/second-layers should always benefit from such changes. Maybe
with the exception of full-rbf, where we have historical 0-conf softwares,
with (broken) security assumptions made on the opt-out RBF mechanism. Same
with 3), better to have new features deployed gradually, a flag day
activation day in this case won't mean that all higher stacks will jump to
use package-relay ?

Where a flag day might make sense would be for 2) ? It would create a
higher level of commitment by the base layer software instead of a pure
communication on the ML/GH, which might not be concretized in the announced
release due to slow review process/feature freeze/rebase conflicts...
Reversing the process and asking for Bitcoin applications/higher layers to
update first might get us in the trap of never doing the change, as someone
might have a small use-case in the corner relying on a given policy
behavior.

That said, w.r.t to the proposed policy change in #22871, I think it's
better to deploy full-rbf first, then give a time buffer to higher
applications to free up the `nSequence` field and finally start to
discourage the usage. Otherwise, by introducing new discouragement waivers,
e.g not rejecting the usage of the top 8 bits, I think we're moving away
from the policy design principle we're trying to establish (separation of
mempool policies signaling from consensus data)

Le ven. 3 sept. 2021 à 23:32, Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hi Bitcoin Devs,
>
> I recently noticed a flaw in the Sequence lock implementation with respect
> to upgradability. It might be the case that this is protected against by
> some transaction level policy (didn't see any in policy.cpp, but if not,
> I've put up a blogpost explaining the defect and patching it
> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>
> I've proposed patching it here
> https://github.com/bitcoin/bitcoin/pull/22871, it is proper to widely
> survey the community before patching to ensure no one is depending on the
> current semantics in any live application lest this tightening of
> standardness rules engender a confiscatory effect.
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev