Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ via bitcoin-dev]

> I suppose ultimately this brings up the question of the scope of this BIP. 
> The abstract points out that the BIP contains both a definition of address 
> derivation, but also how to sign fidelity bond certificates.
>
> My feeling is that the latter might be better not included? I note that the 
> 'Motivation' section gives motivation for standardisation of derivation (this 
> includes things like time schedule), but not the second area - certificate 
> signing. I think the second area is much more tricky, but much more to the 
> point is, isn't it the case that that second area, can be interpreted without 
> consensus between wallet developers? So say you were a hardware wallet 
> provider, or a "node in a box" provider - your customers want you to provide 
> the ability move funds around, including e.g. moving funds out of an old 
> Joinmarket wallet (in which say there is a now expired timelock address utxo) 
> by just entering its BIP39 seed. If this BIP addresses that, it should be 
> enough.
>
> I don't doubt that there's gains to be had from a broader community 
> discussing and agreeing the details of how to create a fidelity bond 
> certificate, but it's a separate, and more difficult, task.
>
> Cheers,
> waxwing/AdamISZ

Further to that last point, as the BIP draft currently says:

" Almost all wallets implementing this standard can use their
already-existing "Sign Message" function to sign the certificate
message. As the certificate message itself is always an ascii string,
the wallet may not need to specially implement this section at all but
just rely on users copypasting their certificate message into the
already-existing "Sign Message" user interface. This works as long as
the wallet knows how to use the private key of the timelocked address
for signing messages."

So, isn't that an argument that we don't need to specify the certificate 
message format here?

On the other hand, I can hardly disagree that it's worth presenting a kind of 
'default' way of doing it. But I fear it is not at all simple to decide what a 
secure, general format should be (as per the discussion we started having here 
about domain separation tags).

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

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ via bitcoin-dev]

--- Original Message ---
On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev 
 wrote:


> Good morning waxwing,

>
> Ah, yes, now I remember.
> I discussed this with Tamas as well in the past and that is why we concluded 
> that in defiads, each UTXO can host at most one advertisement at any one time.
> In the case of defiads there would be a sequence counter where a 
> higher-sequenced advertisement would replace lower-sequenced advertisement, 
> so you could update, but at any one time, for a defiads node, only one 
> advertisement per UTXO could be used.
> This assumed that there would be a defiads network with good gossip 
> propagation so our thinking at the time was that a higher-sequenced 
> advertisement would quickly replace lower-sequenced ones on the network.
> But it is simpler if such replacement would not be needed, and you could then 
> commit to the advertisement directly on the UTXO via a tweak.
>
> Each advertisement would also have a specific application ID that it applied 
> to, and applications on top of defiads would ask the local defiads node to 
> give it the ads that match a specific application ID, so a UTXO could only be 
> used for one application at a time.
> This would be equivalent to domain separation tags that waxwing mentions.
>
> Regards,
> ZmnSCPxj
>

I suppose ultimately this brings up the question of the scope of this BIP. The 
abstract points out that the BIP contains both a definition of address 
derivation, but also how to sign fidelity bond certificates.

My feeling is that the latter might be better not included? I note that the 
'Motivation' section gives motivation for standardisation of derivation (this 
includes things like time schedule), but not the second area - certificate 
signing. I think the second area is much more tricky, but much more to the 
point is, isn't it the case that that second area, can be interpreted without 
consensus between wallet developers? So say you were a hardware wallet 
provider, or a "node in a box" provider - your customers want you to provide 
the ability move funds around, including e.g. moving funds out of an old 
Joinmarket wallet (in which say there is a now expired timelock address utxo) 
by just entering its BIP39 seed. If this BIP addresses that, it should be 
enough.

I don't doubt that there's gains to be had from a broader community discussing 
and agreeing the details of how to create a fidelity bond certificate, but it's 
a separate, and more difficult, task.

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

[bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

[Greg Sanders via bitcoin-dev]

Hello devs,

I've had this thought rattling around and thought it was worth putting to a
wider audience since
I haven't really seen it in other contexts. I've been working on eltoo
designs for Elements and
eventual inclusion into Bitcoin. With that in mind there's been a
reasonable amount of discussion
on the remaining unknowns on how well eltoo could work. To me the biggest
issue is BIP125 rule#3.

To quote:"The replacement transaction pays an absolute fee of at least the
sum paid by the original
transactions."

In the ANYONECANPAY-like scenarios like eltoo that require "bring your own
fees", this essentially
means the counterparty(or anyone, if you don't include chaperone sigs[0])
can post a series of low
feerate update transactions, or the final update, with bloated
inputs/outputs(depending on flags),
and this results in illicit HTLC timeouts as the channel is unable to be
settled in time, unless you fork
over quite a few sats. This is a problem in both "vanilla" eltoo[1] from
the original paper, as well as the
"layered commitments" style of eltoo[2]. This problem is highly reminiscent
of the ANYONECANPAY
pinning that others have discussed for vaults and other usecases, in that
anyone can include new
inputs(and sometimes outputs) to make the overall feerate lower. To
promptly get the final transactions
settled, you are forced to over-pay, and essentially refund your griefing
counterparty by knocking their
inputs out of the mempool.

Fixing BIP125 rule#3 would be great. It's also a while out at a minimum.

There are thoughts on how to mitigate some cases[3] of this pinning using
policy, and could be extended
to cover this particular pinning case(restrict both transaction weight AND
the weight of the descendant
package, or maybe just include the txns weight in the original idea?). This
might be the simplest idea,
if it ends up being deemed incentive compatible and deployed.

In case the above is not incentive compatible, we can use more drastic
measures. Another tactic would
be to use transaction introspection opcodes to smooth around these policy
issues.

Elements has its own set of transaction introspection codes[4], but fairly
standard introspection codes
seem to be sufficient.

This example is using Rusty's quite recent OP_TX proposal[5] with a single
extension but as mentioned
before it's all fairly standard. The actual eltoo-enabling opcode
implementation is basically orthogonal
to this problem, so I'm simply focusing on restricting the size of the
transaction package being
submitted to mempools.

For simplicity of a working example, we'll assume a set of "state" outputs
that are continuously being spent
off-chain and sent to a committed set of outputs. In vanilla eltoo case
this corresponds to the first
input and output you typically see in diagrams. The state transitions
include no fees themselves,
sending inputs of sum value N to outputs that sum to the value of N.
Vanilla eltoo uses SIGHASH_SINGLE
to bind just the first input/ouput pair. To post on-chain, we will need to
include at least one input,
and likely an output for change.

We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to the
proposal) to the "state" input's script.
This is used in the update transaction to set the upper bound on the final
transaction weight.
In this same input, for each contract participant, we also conditionally
commit to the change output's scriptpubkey
via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2. This
means any participant can send change back
to themselves, but with a catch. Each change output script possibility in
that state input also includes a 1 block
CSV to avoid mempool spending to reintroduce pinning. This allows the
change value to be anything, contra to
what SIGHASH_ALL would give you instead.

With this setup, you can't CPFP-spend the fee change outputs you create,
but you can RBF as much as
you'd like by RBFing at higher feerates, using any number of inputs you'd
like provided the total tx
weight doesn't exceed the OPTX_SELECT_WEIGHT argument.

With more engineering we can re-enable CPFP of this change output as well.
Handwaves here, but we could
encumber change outputs to either the aformentioned 1 block CSV encumbered
outputs or one to another
OPTX_SELECT_WEIGHT, recursively. This would allow each counterparty to CPFP
N times, each transaction
a maximum weight, and use the 1 block CSV as an "escape hatch" to get their
fee output back out from
the covenant structure. We could mix and match strategies here as well
allowing bigger transactions at
each step, or more steps. I suspect you'd want a single weight-bound CPFP
that can later be RBF'd any
number of times under this same weight limit.

TL;DR: Mempool is hard, let's use transaction weight, output count, and
output scriptpubkey,
and ??? introspection to avoid solving life's hard problems.

0:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001994.html
1: https://blockstream.com/eltoo.pdf
2:

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj via bitcoin-dev]

Good morning waxwing,

> --- Original Message ---
> On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hello ZmnSCPxj,
> > This is an intended feature. I'm thinking that the same fidelity bond
> > can be used to running a JoinMarket maker as well as a Teleport
> > (Coinswap) maker.
> > I don't believe it's abusable. It would be a problem if the same
> > fidelity bond is used by two makers in the same application, but
> > JoinMarket takers are already coded to check for this, and Teleport
> > takers will soon as well. Using the same bond across different
> > applications is fine.
> > Best,
> > CB
>
> Hi Chris, Zmn, list,
> I've noodled about this a few times in the past (especially when trying to 
> figure out an LSAG style ring sig based FB for privacy, but that does not 
> seem workable), and I can't decide the right perspective on it.
>
> A user sacrifices X amount of time-value-of-money (henceforth TVOM) by 
> committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, 
> let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z 
> in Teleport, then presumably he'll only do it if (probabilistically) he 
> thinks Y+Z > X.
>
> But as an assessor of FB1 in Joinmarket, I don't know if it's also being used 
> for Teleport, and more importantly, if it's being used somewhere else I'm not 
> even aware of. Now I'm not an economist I admit, so I might not be intuit-ing 
> this situation right, but it fees to me like the right answer is "It's fine 
> for a closed system, but not an open one." (i.e. if the set of possible 
> usages is not something that all participants have fixed in advance, then 
> there is an effective Sybilling problem, like I'm, as an assessor, thinking 
> that sacrificed value 100 is there, whereas actually it's only 15, or 
> whatever.)
>
> As I mentioned in 
> https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/993#issuecomment-1110784059
>  , I did wonder about domain separation tags because of this, and as I 
> vaguely alluded to there, I'm really not sure about it.
>
> If it was me I'd want to include domain separation via part of the signed 
> message, since I don't see how it hurts? For scenarios where reuse is fine, 
> reuse can still happen.

Ah, yes, now I remember.
I discussed this with Tamas as well in the past and that is why we concluded 
that in defiads, each UTXO can host at most one advertisement at any one time.
In the case of defiads there would be a sequence counter where a 
higher-sequenced advertisement would replace lower-sequenced advertisement, so 
you could update, but at any one time, for a defiads node, only one 
advertisement per UTXO could be used.
This assumed that there would be a defiads network with good gossip propagation 
so our thinking at the time was that a higher-sequenced advertisement would 
quickly replace lower-sequenced ones on the network.
But it is simpler if such replacement would not be needed, and you could then 
commit to the advertisement directly on the UTXO via a tweak.

Each advertisement would also have a specific application ID that it applied 
to, and applications on top of defiads would ask the local defiads node to give 
it the ads that match a specific application ID, so a UTXO could only be used 
for one application at a time.
This would be equivalent to domain separation tags that waxwing mentions.

Regards,
ZmnSCPxj

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

Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

[ZmnSCPxj via bitcoin-dev]

Good morning Billy,


> Very interesting exploration. I think you're right that there are issues with 
> the kind of partitioning you're talking about. Lightning works because all 
> participants sign all offchain states (barring data loss). If a participant 
> can be excluded from needing to agree to a new state, there must be an 
> additional mechanism to ensure the relevant state for that participant isn't 
> changed to their detriment. 
>
> To summarize my below email, the two techniques I can think for solving this 
> problem are:
>
> A. Create sub-pools when the whole group is live that can be used by the sub- 
> pool participants later without the whole group's involvement. The whole 
> group is needed to change the whole group's state (eg close or open 
> sub-pools), but sub-pool states don't need to involve the whole group.

Is this not just basically channel factories?

To reduce the disruption if any one pool participant is down, have each 
sub-pool have only 2 participants each.
More participants means that the probability that one of them is offline is 
higher, so you use the minimum number of participants in the sub-pool: 2.
This makes any arbitrary sub-pool more likely to be usable.

But a 2-participant pool is a channel.
So a large multiparticipant pool with sub-pools is just a channel factory for a 
bunch of channels.

I like this idea because it has good tradeoffs, so channel factories ho.

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

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

[Billy Tetrud via bitcoin-dev]

I think this is a useful proposal. There are certainly things about BIP9
that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
a BIP spec was never produced for it afaik. A possibly unhelpful comment:

> minimum_activation_height

I think a minor improvement would be to specify this as
minimum_activation_blocks, ie a number of blocks passed the start_height.
Slightly easier to reason about and change when necessary. I proposed
semantics like that here

.

In any case, I'll give this a concept ACK. I would very much like future
soft forks to use a previously specified activation mechanism rather than
rolling out a rushed unspeced thing as part of the (very orthogonal) soft
fork implementation.

On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/144bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram: https://i.imgur.com/dj4bFVK.png
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail  secure email.
> ___
> 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] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY

[Brandon Black via bitcoin-dev]

Hi Rusty,

Thanks for this. Seems like a productive direction to explore.

To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow
a single script to be reused. Given that potential, I wonder if
OPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set
of flags.

With that addition, a small script can be constructed for a relocatable,
batchable construction (eg. as a building block for vaults):

OPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP

OPTX_SELECT_VERSION|
OPTX_SELECT_LOCKTIME|
OPTX_SELECT_INPUT_SINGLE|
OPTX_SELECT_INPUT_SCRIPT|
OPTX_SELECT_INPUT_NSEQUENCE|
OPTX_SELECT_OUTPUT_SINGLE|
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY|
OPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX  OP_EQUAL

* Additional inputs and change outputs can be added
  * Could commit to 0 fee and still be useful
* Arbitrary amounts can be sent to the same script
* There is no txid predictability (unlike CTV)
  * Anyone could rearrange such input/output pairs after broadcast
* Not suitable for some uses
* Potentially helpful for others

Best,

--Brandon

On 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev wrote:
> Hi all,
> 
>   TL;DR: a v1 tapscript opcode for generic covenants, but
> OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY.  This gives an
> obvious use case, with clean future expansion.  OP_NOP4 can be
> repurposed in future as a shortcut, if experience shows that to be a
> useful optimization.
> 
> (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony
> Towns' modification via extending the opcode[2]; I also notice on
> re-reading that James Lu had a similar restriction idea[3]).
> 
> Details
> ---
> 
> OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
> Unknown flag patterns are OP_SUCCESS, though for thoroughness some future
> potential uses are documented here.  Note that pushing more than 1000
> elements on the stack or an element more than 512 bytes will hit the
> BIP-342 resource limits and fail.
> 
> Defined bits
> 
> 
> (Only those marked with * have to be defined for this soft fork; the
>  others can have semantics later).
> 
> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
> 
> - The first nicely sidesteps the lack of OP_CAT, and the latter allows
>   OP_TXHASH semantics (and avoid stack element limits).
> 
> OPTX_SELECT_VERSION*: version
> OPTX_SELECT_LOCKTIME*: nLocktime
> OPTX_SELECT_INPUTNUM*: current input number
> OPTX_SELECT_INPUTCOUNT*: number of inputs
> OPTX_SELECT_OUTPUTCOUNT*: number of outputs
> 
> OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
>   OPTX_SELECT_INPUT_*, otherwise iterate through all.
> OPTX_SELECT_INPUT_TXID: txid
> OPTX_SELECT_INPUT_OUTNUM: txout index
> OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
> OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
> OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
> OPTX_SELECT_INPUT_TAPBRANCH: ?
> OPTX_SELECT_INPUT_TAPLEAF: ?
> 
> OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
>   OPTX_SELECT_OUTPUT_*, otherwise iterate through all.
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey
> 
> OPTX_SELECT_19...OPTX_SELECT_31: future expansion.
> 
> OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
>   OPTX_SELECT_VERSION
>   OPTX_SELECT_LOCKTIME
>   OPTX_SELECT_INPUTCOUNT
>   OPTX_SELECT_INPUT_SCRIPT
>   OPTX_SELECT_INPUT_NSEQUENCE
>   OPTX_SELECT_OUTPUTCOUNT
>   OPTX_SELECT_OUTPUT_AMOUNT32x2
>   OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
>   OPTX_SELECT_INPUTNUM
> 
> All other flag combinations result in OP_SUCCESS.
> 
> Discussion
> --
> 
> By enumerating exactly what can be committed to, it's absolutely clear
> what is and isn't committed (and what you need to think about!).
> 
> The bits which separate concatenation and hashing provide a simple
> mechanism for template-style (i.e. CTV-style) commitments, or for
> programatic treatment of individual elements (e.g. amounts, though the
> two s31 style is awkward: a 64-bit push flag could be added in future).
> 
> The lack of double-hashing of scriptsigs and other fields means we
> cannot simply re-use hashing done for SIGHASH_ALL.
> 
> The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
> allow covenants for v0 segwit or pre-segwit inputs.  If covenants prove
> useful, dedicated opcodes can be provided for those cases (a-la
> OP_CHECKTEMPLATEVERIFY).
> 
> Cheers,
> Rusty.
> 
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [2] 
> 

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Billy Tetrud via bitcoin-dev]

>  So if you don't want to receive restricted coins, just don't generate an
address with those restrictions embedded.

This is an interesting point that I for some reason haven't thought of
before. However...

> Unless governments can mandate that you generate these addresses AND
force you to accept funds bound by them for your services**, I don't
actually see how this is a real concern.

Actually, I think only the second is necessary. For example, if there was a
law that compelled giving a good or service if payment of a publicly
advertised amount was paid, and someone pays to an address that can be
shown is spendable by the merchant's keys in a way that the government
accepts, it doesn't matter whether the recipient can or has generated the
address.

Regardless I do think its still important to note that a government could
do that today using multisig.

> This is a reason to oppose legal tender laws for Bitcoin imo.

I agree.

On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <
keagan.mcclell...@gmail.com> wrote:

> > > > To me the most scary one is visacoin, specially seeing what happened
> in canada and other places lately and the general censorship in the west,
> the supposed war on "misinformation" going on (really a war against truth
> imo, but whatever) it's getting really scary. But perhaps someone else can
> be more scared about a covenant to add demurrage fees to coins or
> something, I don't know.
> > > > https://bitcointalk.org/index.php?topic=278122
>
> > > This requires *recursive* covenants.
>
> > Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants.
>
> There's actually also a very straight forward defense for those who do not
> want to receive "tainted" coins. In every covenant design I've seen to date
> (including recursive designs) it requires that the receiver generate a
> script that is "compliant" with the covenant provisions to which the sender
> is bound. The consequence of this is that you can't receive coins that are
> bound by covenants you weren't aware of*. So if you don't want to receive
> restricted coins, just don't generate an address with those restrictions
> embedded. As long as you can specify the spend conditions upon the receipt
> of your funds, it really doesn't matter how others are structuring their
> own spend conditions. So long as the verification of those conditions can
> be predictably verified by the rest of the network, all risk incurred is
> quarantined to the receiver of the funds. Worst case scenario is that no
> one wants to agree to those conditions and the funds are effectively burned.
>
> It's not hard to make the case that any time funds are being transferred
> between organizations with incompatible interests (external to a firm),
> that they will want to be completely free to choose their own spend
> conditions and will not wish to inherit the conditions of the spender.
> Correspondingly, any well implemented covenant contract will include
> provisions for escaping the recursion loop if some sufficiently high bar is
> met by the administrators of those funds. Unless governments can mandate
> that you generate these addresses AND force you to accept funds bound by
> them for your services**, I don't actually see how this is a real concern.
>
> *This requires good wallet tooling and standards but that isn't materially
> different than wallets experimenting with non-standard recovery policies.
>
> **This is a reason to oppose legal tender laws for Bitcoin imo.
>
> Keagan
>
> On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> >  This requires *recursive* covenants.
>>
>> Actually, for practical use, any walled-garden requires *dynamic*
>> covenants, not recursive covenants. CTV can get arbitrarily close to
>> recursive covenants, because you can have an arbitrarily long string of
>> covenants. But this doesn't help someone implement visacoin because CTV
>> only allows a specific predefined iteration of transactions, meaning that
>> while "locked" into the covenant sequence, the coins can't be used in any
>> way like normal coins - you can't choose who you pay, the sequence is
>> predetermined.
>>
>> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
>> )
>> don't automatically allow for practical walled gardens. Recursion
>> definitely allows creating walled gardens, but those gardens would be
>> impractically static. You could add millions of potential addresses to send
>> to, which would "only" quadruple the size of your transactions, but if
>> anyone creates a new address you want to send to, you wouldn't be able to.
>> Everyone would have to have a single address whitelisted into every
>> government-bitcoin output. If someone lost their key and needs to create a
>> new wallet, suddenly no one would be able to pay 

[bitcoin-dev] Improving BIP 8 soft fork activation

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

There were some disagreements with speedy trial activation method recently and 
BIP 8 became controversial because of LOT earlier. I have tried to solve these 
two problems after reading some arguments for/against different activation 
methods by removing LOT from BIP 8 and calculating MUST_SIGNAL state based on 
threshold reached.

BIP draft with no code and some changes in BIP 8: 
https://gist.github.com/144bytes/5e58cad7ba9d9c1a7000d304920fe6f1

State transitions diagram: https://i.imgur.com/dj4bFVK.png

This proposal removes lockinontimeout flag, activation never fails although 
MUST_SIGNAL can be longer if miners signaling does not reach the threshold. 
Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_IN was 
not reached.

MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and blocks 
that fail to signal in MUST_SIGNAL phase are invalid.

Example:

- This activation method is used for a soft fork
- Only 60% miners signaled readiness and timeout height was reached
- MUST_SIGNAL phase starts and will last for 4*2016 blocks
- LOCKED_IN and ACTIVE states remain same as BIP 8
- Soft fork is activated with a delay of 2 months

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[AdamISZ via bitcoin-dev]

--- Original Message ---
On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev 
 wrote:


> Hello ZmnSCPxj,
>
> This is an intended feature. I'm thinking that the same fidelity bond
> can be used to running a JoinMarket maker as well as a Teleport
> (Coinswap) maker.
>
> I don't believe it's abusable. It would be a problem if the same
> fidelity bond is used by two makers in the same application, but
> JoinMarket takers are already coded to check for this, and Teleport
> takers will soon as well. Using the same bond across different
> applications is fine.
>
> Best,
> CB
>

Hi Chris, Zmn, list,
I've noodled about this a few times in the past (especially when trying to 
figure out an LSAG style ring sig based FB for privacy, but that does not seem 
workable), and I can't decide the right perspective on it.

A user sacrifices X amount of time-value-of-money (henceforth TVOM) by 
committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's 
say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in 
Teleport, then presumably he'll only do it if (probabilistically) he thinks Y+Z 
> X.

But as an assessor of FB1 in Joinmarket, I don't know if it's also being used 
for Teleport, and more importantly, if it's being used somewhere else I'm not 
even aware of. Now I'm not an economist I admit, so I might not be intuit-ing 
this situation right, but it fees to me like the right answer is "It's fine for 
a closed system, but not an open one." (i.e. if the set of possible usages is 
not something that all participants have fixed in advance, then there is an 
effective Sybilling problem, like I'm, as an assessor, thinking that sacrificed 
value 100 is there, whereas actually it's only 15, or whatever.)

As I mentioned in 
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/993#issuecomment-1110784059
 , I did wonder about domain separation tags because of this, and as I vaguely 
alluded to there, I'm really not sure about it.

If it was me I'd want to include domain separation via part of the signed 
message, since I don't see how it hurts? For scenarios where reuse is fine, 
reuse can still happen.

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

[bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY

[Rusty Russell via bitcoin-dev]

Hi all,

TL;DR: a v1 tapscript opcode for generic covenants, but
OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY.  This gives an
obvious use case, with clean future expansion.  OP_NOP4 can be
repurposed in future as a shortcut, if experience shows that to be a
useful optimization.

(This proposal builds on Russell O'Connor's TXHASH[1], with Anthony
Towns' modification via extending the opcode[2]; I also notice on
re-reading that James Lu had a similar restriction idea[3]).

Details
---

OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
Unknown flag patterns are OP_SUCCESS, though for thoroughness some future
potential uses are documented here.  Note that pushing more than 1000
elements on the stack or an element more than 512 bytes will hit the
BIP-342 resource limits and fail.

Defined bits


(Only those marked with * have to be defined for this soft fork; the
 others can have semantics later).

OPTX_SEPARATELY: treat fields separately (vs concatenating)
OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)

- The first nicely sidesteps the lack of OP_CAT, and the latter allows
  OP_TXHASH semantics (and avoid stack element limits).

OPTX_SELECT_VERSION*: version
OPTX_SELECT_LOCKTIME*: nLocktime
OPTX_SELECT_INPUTNUM*: current input number
OPTX_SELECT_INPUTCOUNT*: number of inputs
OPTX_SELECT_OUTPUTCOUNT*: number of outputs

OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
OPTX_SELECT_INPUT_*, otherwise iterate through all.
OPTX_SELECT_INPUT_TXID: txid
OPTX_SELECT_INPUT_OUTNUM: txout index
OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
OPTX_SELECT_INPUT_TAPBRANCH: ?
OPTX_SELECT_INPUT_TAPLEAF: ?

OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
OPTX_SELECT_OUTPUT_*, otherwise iterate through all.
OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey

OPTX_SELECT_19...OPTX_SELECT_31: future expansion.

OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
OPTX_SELECT_VERSION
OPTX_SELECT_LOCKTIME
OPTX_SELECT_INPUTCOUNT
OPTX_SELECT_INPUT_SCRIPT
OPTX_SELECT_INPUT_NSEQUENCE
OPTX_SELECT_OUTPUTCOUNT
OPTX_SELECT_OUTPUT_AMOUNT32x2
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
OPTX_SELECT_INPUTNUM

All other flag combinations result in OP_SUCCESS.

Discussion
--

By enumerating exactly what can be committed to, it's absolutely clear
what is and isn't committed (and what you need to think about!).

The bits which separate concatenation and hashing provide a simple
mechanism for template-style (i.e. CTV-style) commitments, or for
programatic treatment of individual elements (e.g. amounts, though the
two s31 style is awkward: a 64-bit push flag could be added in future).

The lack of double-hashing of scriptsigs and other fields means we
cannot simply re-use hashing done for SIGHASH_ALL.

The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
allow covenants for v0 segwit or pre-segwit inputs.  If covenants prove
useful, dedicated opcodes can be provided for those cases (a-la
OP_CHECKTEMPLATEVERIFY).

Cheers,
Rusty.

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
[3] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Wallet policies for descriptor wallets

[Salvatore Ingala via bitcoin-dev]

Hi Antoine and Billy,

Thank you for your comments and for looking into the proposal.

On Mon, 9 May 2022 at 12:36, darosior  wrote:

> 1. The `` optimization for the common usecase of using 2
> descriptors at different derivation indices
>for receive and change. [1]
> 2. The `/**` optimization for the common usecase of `/<0;1>` for point 1).
>
> [...]
>
> I'm not so sure about the second point. Is another deviation from the
> standard worth it just for saving 3
> characters?
>

I agree with the concerns of both you and Billy on the `\**` syntax, and it
is certainly not a crucial part of the proposal, as it is arguably
redundant once `\<0;1>` is available.
I have been using it since before the `\<0;1>` syntax was proposed (afaik),
and I thought I would leave it mostly for the sake of optimizing the UX in
the most common use cases. I think that

sh(sortedmulti(2,@0/**,@1/**,@2/**))

is quite a lot more readable (especially on a small screen) than

sh(sortedmulti(2,@0/<0;1>/*,@1/<0;1>/*,@2/<0;1>/*))

Apart from the additional 5 characters *per placeholder*, there are a lot
more numbers to parse for the user.

Yet, I'm not too attached to the feature as it is probably not very useful
in taptrees. For the future, I expect further improvements will come from
the hardware wallets analyzing the wallet policy and recognizing the
commonly used patterns. No reason to show the full taptree of a complex
3-of-5 multisig setup − you can just say "Taproot 3-of-5 multisig". Show
the full taptree policy should be reserved for the 1% of advanced use-cases
that are not in the catalogue.

Slightly off-topic, but my impression is that descriptors are outgrowing
their original scope (probably the reason for sipa's comments[1] on the
early proposals for multiple derivation paths in one descriptor).
I think there is a case to be made for keeping the language of descriptors
limited to represent either (1) a single output, or (2) a list of outputs
with the `/*` syntax; in this interpretation, the `/` syntax would
entirely be on a separate layer (the `combo` descriptor[2] would also be
extraneous in this interpretation).
I tried to design the policy wallet language in a way that is agnostic to
these details of descriptor specs (since I target a _subset_ of
descriptors, it will work either way).

However, why does it need to be a change to the descriptor language? It
> looks a lot like something that needs
> to be handled at the application level with key aliasing.


Key aliasing is not part of descriptors; therefore, "descriptors with key
aliasing" are still a language on top of descriptors.

Adding key aliases will indeed be a great UX improvement, but in my opinion
it is better built on top of wallet policies, rather than within the
language itself.
Note that by separating the *wallet descriptor template* from the keys
themselves, such a feature is already facilitated. Moreover, wallet
policies separate the KEY expressions of descriptors into two semantically
relevant parts: only the xpub and its origin info goes into the "vector of
key information", while the receive/change part of the derivation is kept
in the placeholder (therefore in the descriptor template). Adding
restrictions is also useful: `xpub/1/2/3/4/<0;1>/5/6/*` might be valid
miniscript, but supporting this kind of thing would be (arguably)
unreasonable and a lot more complicated for hardware wallets; therefore,
placeholders and key informations are a lot more limited in the wallet
policy language than their miniscript counterpart.

While I understand that descriptors are designed with a maximum flexibility
mindset, a minimized feature set is very valuable for hardware wallets, and
I believe it can be done with little to no practical loss of use cases.
Restrictions can be lifted in future versions when the need arises.

I think to better suit the needs of both hardware and software wallets, you
need both the *extensions* and the *restrictions*. That's why I propose to
keep them separated, rather than suggesting changes to descriptors.

Unrelated question, since you mentioned `musig2` descriptors in this
> context. I thought Musig2 wasn't really
> feasible for hardware signing devices, especially stateless ones. Do you
> think/know whether it is actually
> possible for a HW to take part in a Musig2?
>

I certainly have some more homework to do on musig2, and for this proposal
I was only concerned with making sure the wallet policy language won't
break with future upgrades to descriptors.
Yet, as far as I understand , the complications for hardware wallets are
(1) possible lack of good quality randomness, and (2) need to keep state
during a signing session. Ledger signers have a hardware TRNG, and while
the design is generally stateless, there is flash memory that can be used
to store the secret nonce during a signing session (or, more likely, a few
parallel signing sessions). Therefore, I don't think there are technical
blockers for musig2.

Salvatore