Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Russell O'Connor via bitcoin-dev]

On Fri, May 13, 2022 at 5:43 PM Anthony Towns  wrote:

> For any specific opcode proposal, I think you still want to consider
>
>  1) how much you can do with it
>  2) how efficient it is to validate (and thus how cheap it is to use)
>  3) how easy it is to make it do what you want
>  4) how helpful it is at preventing bugs
>  5) how clean and maintainable the validation code is
>
> I guess to me CTV and APO are weakest at (1); CAT/CSFS falls down on
> (3) and (4); OP_TX is probably weakest at (5) and maybe not as good as
> we'd like at (3) and (4)?
>

FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
messages and pubkey delegation.  The ability to covenants would be
secondary and would mostly serve to get us some real user data about what
sort of covenants users find especially valuable.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Anthony Towns via bitcoin-dev]

On Thu, May 12, 2022 at 06:48:44AM -0400, Russell O'Connor via bitcoin-dev 
wrote:
> On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj  wrote:
> > So really: are recursive covenants good or...?
> My view is that recursive covenants are inevitable.  It is nearly
> impossible to have programmable money without it because it is so difficult
> to avoid.

I think my answer is that yes they are good: they enable much more
powerful contracting.

Of course, like any cryptographic tool they can also be harmful to you if
you misuse them, and so before you use them yourself you should put in the
time to understand them well enough that you *don't* misuse them. Same as
using a kitchen knife, or riding a bicycle, or swimming. Can be natural
to be scared at first, too.

> Given that we cannot have programmable money without recursive covenants
> and given all the considerations already discussed regarding them, i.e. no
> worse than being compelled to co-sign transactions, and that user generated
> addresses won't be encumbered by a covenant unless they specifically
> generate it to be, I do think it makes sense to embrace them.

I think that's really the easy way to be sure *you* aren't at risk
from covenants: just follow the usual "not your keys, not your coins"
philosophy.

The way you currently generate an address from a private key already
guarantees that *your* funds won't be encumbered by any covenants; all
you need to do is to keep doing that. And generating the full address
yourself is already necessary with taproot: if you don't understand
all the tapscript MAST paths, then even though you can spend the coin,
one of those paths you don't know about might already allow someone to
steal your funds. But if you generated the address, you (or at least your
software) will understand everything and not include anything dangerous,
so your funds really are safu.

It may be that some people will refuse to send money to your address
because they have some rule that says "I'll only send money to people who
encumber all their funds with covenant X" and you didn't encumber your
address in that way -- but that just means they're refusing to pay you,
just as people who say "I'll only pay you off-chain via coinbase" or
"I'll only pay you via SWIFT" won't send funds to your bitcoin address.

Other examples might include "we only support segwit-v0 addresses not
taproot ones", or "you're on an OFAC sanctions list so I can't send
to you or the government will put me in prison" or "my funds are in a
multisig with the government who won't pay to anyone who isn't also in
a multisig with them".

It does mean you still need people with the moral fortitude to say "no,
if you can't pay me properly, we can't do business" though.

Even better: in so far as wallet software will just ignore any funds
sent to addresses that they didn't generate themselves according to the
rules you selected, you can already kind of outsource that policy to
your wallet. And covenants, recursive or otherwise, don't change that.


For any specific opcode proposal, I think you still want to consider

 1) how much you can do with it
 2) how efficient it is to validate (and thus how cheap it is to use)
 3) how easy it is to make it do what you want
 4) how helpful it is at preventing bugs
 5) how clean and maintainable the validation code is

I guess to me CTV and APO are weakest at (1); CAT/CSFS falls down on
(3) and (4); OP_TX is probably weakest at (5) and maybe not as good as
we'd like at (3) and (4)?

Cheers,
aj

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

[bitcoin-dev] Soliciting more discussion for OP_CONSTRAINDESTINATION (a covenant opcode)

[Billy Tetrud via bitcoin-dev]

Hi all,

Since there's recently been a lot more interest in discussing covenants and
alternative covenant proposals because of CTV, I figured I'd bring up my
own proposed covenant opcode again while the urge is still fresh.

To be clear upfront, this opcode has a spec, but nothing else. No tests. No
implementation. No signet. No tooling. While this is a serious proposal
that I think has a lot of benefits over any other covenant opcode proposal,
I am not suggesting that this should supplant CTV. I also don't have any
plans to work on an implementation of OP_CONSTRAINDESTINATION, and I
certainly wouldn't without more interest and an equal partner on a project
like this.  I think CTV is a quite useful opcode that is simple and
incremental. OP_CD on the other hand is significantly more powerful, which
would be likely to lead to even more contention than what CTV has had.

To the opcode itself, there is already plenty of exposition about it in the
spec:

https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md

So I wanted to discuss it from the perspective of what it enables, pros and
cons, and key considerations:

*OP_CONSTRAINDESTINATION alone*

   - Like OP_CTV
  - Is fully enumerated (not open ended)
   - Unlike OP_CTV
  - Enables infinitely recursive covenants
  - Does not and cannot prevent malleability on its own

The wallet vaults that can be created

using this are more flexible than ones that can be created with OP_CTV:

   - Spends from a wallet vault can spend arbitrary amounts, and send the
   rest back to a change address, just like a normal transaction.
   - Arbitrary amounts of coins can be sent directly to any of the
   addresses involved in the wallet vault without any risk of loss of funds.
   - Anchor outputs are not (necessarily) necessary for fee bumping. A user
   can have the option of creating a transaction that includes other inputs
   that can contribute to the fee. Those inputs can also send to other
   outputs, allowing one to basically attach an anchor output at
   transaction-creation-time if they think they want it for CPFP fee bumping.

One less-than-ideal property shared with CTV wallet vaults:

   - If the hot wallet / intermediate wallet key is stolen, the attacker
   can steal funds after the owner initiates a normal spend.

The opcode requires some mechanism for fee limiting:

   - As currently specified, an attacker who gets access to the hot key can
   fee-grief the owner of the vault by spending all the coins as fees. The
   proposed solution to this is to add an addition opcode to limit the fees,
   called OP_LIMITFEECONTRIBUTION
   
.
   Another solution would be to require 100% of the output values go to the
   destinations passed to OP_CONSTRAINDESTINATION, and rely on CPFP on an
   anchor output to pay the fees, which seems less than ideal. A third
   solution would be to include sponsor transactions alongside the opcode and
   rely on those instead of CPFP. While I think sponsor transactions would be
   very useful, always relying on an external wallet to pay the fees is IMO
   not super great since it allows for inconvenient scenarios if all your
   money is in this secure vault, in which case you simply wouldn't be able to
   get it out without either first acquiring more bitcoin in a hotter wallet,
   or doing a full recovery transaction with all your wallet vault keys.

The downsides compared to CTV:

   - Increased implementation complexity and complexity of the possibility
   space. The opcode's main purpose of ensuring that only certain addresses
   are sent to might be simpler than CTV, but the aspect of counting output
   values pushes it into more complex territory. And when you consider the
   solutions to fee-griefing, that adds additional implementation and
   possibility-space complexity (depending on how its done).
   - txid malleability


*OP_CONSTRAINDESTINATION + OP_PUSHOUTPUTSTACK*
OP_PUSHOUTPUTSTACK

is
an opcode that allows a script to dynamically add local state to an output
being created.

   - Unlike OP_CTV
   - Also enables infinitely recursive covenants and does not prevent
  malleability.
  - Can be open ended (not fully enumerated)
  - Can produce dynamic state.

The wallet vaults that can be created with this combination of opcodes is a
bit better than ones with just OP_CD on its own:

   - Even if the hot wallet key is stolen, the attacker cannot steal funds
   without compromising all the seeds that make up the wallet vault.

However, the complexity is substantially higher:

   - Being able to push dynamic state onto transactions substantially
   increases the possibility 

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

[ZmnSCPxj via bitcoin-dev]

Good morning Chris,

> Hello waxwing,
>
> > 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.)
>
>
> I don't entirely agree with this. The value of the sacrifice doesn't
> change if the fidelity bond owner starts using it for Teleport as well
> as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run
> any maker at all the sacrifice would still be 100, because it only
> depends on the bitcoin value and locktime. In your equation Y+Z > X,
>
> using a fidelity bond for more applications increases the
> left-hand-side, while the right-hand-side X remains the same. As
> protection from a sybil attack is calculated using only X, it makes no
> difference what Y and Z are, the takers can still always calculate that
> "to sybil attack the coinjoin I'm about to make, it costs A btc locked
> up for B time".

I think another perspective here is that a maker with a single fidelity bond 
between both Teleport and Joinmarket has a single identity in both systems.

Recall that not only makers can be secretly surveillors, but takers can also be 
secretly surveillors.

Ideally, the maker should not tie its identity in one system to its identity in 
another system, as that degrades the privacy of the maker as well.

And the privacy of the maker is the basis of the privacy of its takers.
It is the privacy of the coins the maker offers, that is being purchased by the 
takers.


A taker can be a surveillor as well, and because the identity between 
JoinMarket and Teleport is tied via the single shared fidelity bond, a taker 
can perform partial-protocol attacks (i.e. aborting at the last step) to 
identify UTXOs of particular makers.
And it can perform attacks on both systems to identify the ownership of maker 
coins in both systems.

Since the coins in one system are tied to that system, this increases the 
information available to the surveillor: it is now able to associate coins in 
JoinMarket with coins in Teleport, via the shared fidelity bond identity.
It would be acceptable for both systems to share an identity if coins were 
shared between the JoinMarket and Teleport maker clients, but at that point 
they would arguably be a single system, not two separate systems, and that is 
what you should work towards.


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]

@alicexbt
>  I think 'support' and 'opposition' can be replaced with readiness.
Miners should not consider signaling as voting.

I agree that it isn't voting, its signaling. But whether or not you call it
'readiness' or 'support', some miners will use it to signal 'support' and
will refuse to become ready if they do not support the change. Regardless,
I'm open to calling it "readiness" instead.

@Russell
>  I'm sure there are lots of design choices available better than a
MUST_SIGNAL state that does not risk potentially taking a large fraction of
mining hardware offline for a protracted period of time.

I tend to agree. The case where the fork has not locked in, but some miners
are beginning to orphan other miners' blocks, seems like a rather chaotic
state to program into an activation mechanism. I do like the idea of using
orphaning to ensure that miners are alerted to the fact that a fork has
*already* locked in, but such a thing should be done at a low level (eg
orphan <10% of their blocks) - just high enough so the drop in revenue
makes them investigate, but as minimal as possible to avoid lots of orphans
and loss of hashpower.


On Wed, May 11, 2022 at 10:15 AM alicexbt  wrote:

> Hi Billy,
>
> Thanks for the feedback. I agree with everything
> and bip-trinary-version-signaling looks interesting.
>
> > A primary difference from both BIP8 and BIP9 is that this proposal uses
> tri-state version signaling (rather than binary version bits) that can
> encode both active support as well as active opposition to an active soft
> fork.
>
>
> I think 'support' and 'opposition' can be replaced with readiness. Miners
> should not consider signaling as voting.
>
> > The meaning for each ternary value is as follows:
>
>
> 0 - No signal
> 1 - Ready for new consensus rules
> 2 - Not ready for new consensus rules
>
> The concept of a minimum and maximum threshold sounds intriguing, and I'm
> interested to read what other developers have to say about it.
>
> Concept ACK on removing LOT, using tri-state version signaling, min/max
> threshold and required threshold calculation.
>
>
> /dev/fd0
>
> Sent with ProtonMail secure email.
> --- Original Message ---
> On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tet...@gmail.com
> wrote:
>
>
>
> > 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] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher via bitcoin-dev]

Hello waxwing,

> 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.)



I don't entirely agree with this. The value of the sacrifice doesn't 
change if the fidelity bond owner starts using it for Teleport as well 
as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run 
any maker at all the sacrifice would still be 100, because it only 
depends on the bitcoin value and locktime. In your equation Y+Z > X, 
using a fidelity bond for more applications increases the 
left-hand-side, while the right-hand-side X remains the same. As 
protection from a sybil attack is calculated using only X, it makes no 
difference what Y and Z are, the takers can still always calculate that 
"to sybil attack the coinjoin I'm about to make, it costs A btc locked 
up for B time".


Regarding fidelity bonds being used for both, I expect that most 
fidelity bond owners will use their bonds with both Joinmarket and 
Teleport, to not do that is just leaving money on the table.


If an attacker locks up the 100k btc or whatever the requirement is now, 
and actually does a successful sybil attack against Joinmarket, then 
they could at the same time do a successful sybil attack against 
teleport with little added cost. So both markets form a single fidelity 
bond ecosystem. This is a similar situation to merge-mining bitcoin with 
an altcoin that also uses SHA256^2 for proof of work. The two or more 
coins form one mining ecosystem. This results in the users of the small 
altcoin benefiting from having their transactions protected by bitcoin's 
massive hashrate. In this analogy the new small Teleport system can very 
quickly benefit from the large amount of fidelity bonds already used in 
Joinmarket.


Yes the hypothetical attacker can attack all systems at once, but the 
defenders can defend all systems at once (and we can say not just that 
they "can" do it, but that they "will" do it, or else they leave money 
on the table). The mathematics which gives a huge advantage to the 
defender still applies.




You've convinced me that specifying the exact form of the fidelity bond 
certificate is a bad idea. I'll leave it more general, saying just that 
wallets should be able to do SignMessage using the timelocked privkey. 
And I'll leave the example signature in the test vectors.


I've made edits to this effect on the gist:
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e/revisions#diff-4f1f364f340b78bdfe9dca2ff50784bd312d49be220e5e5c2e4675447f79c6e8

It's worth noting that even if the certificate message is different 
across the two systems, a fidelity bond owner can still create two 
signatures over two different messages (e.g. 
"fidelity-bond-cert||" and 
"fidelity-bond-cert-teleport||").




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