[bitcoin-dev] CTV Meeting #9 Reminder + Agenda (Tuesday, May 17th, 12:00 PT / 7PM UTC)

[Jeremy Rubin via bitcoin-dev]

Developers,

A reminder that the regularly scheduled CTV Meeting is tomorrow at 12:00
Pacific Time in ##ctv-bip-review in Libera.

In terms of agenda, we'll keep it as an open forum for discussion guided by
the participants. We'll try to go over, minimally:

- Rusty's OP_TX
- Adding OP_CAT / CSFS

Feel free to propose meeting topics in the IRC in advance of the meeting to
aid in allocating time to things that you would like to have discussed.

Best,

Jeremy

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

Re: [bitcoin-dev] Improving chaumian ecash and sidechains with fidelity bond federations

[ZmnSCPxj via bitcoin-dev]

Good morning Chris,

> I don't know yet exactly the details of how such a scheme would work,
> maybe something like each fidelity bond owner creates a key in the
> multisig scheme, and transaction fees from the sidechain or ecash server
> are divided amongst the fidelity bonds in proportion to their fidelity
> bond value.

Such a scheme would probably look a little like my old ideas about "mainstake", 
where you lock up funds on the mainchain and use that as your right to 
construct new sidechain blocks, with your share of the sideblocks proportional 
to the value of the mainstake you locked up.

Of note is that it need not operate as a sidechain or chaumian bank, anything 
that requires a federation can use this scheme as well.
For instance, statechains are effectively federation-guarded CoinPools, and 
could use a similar scheme for selecting federation members.
Smart contracts unchained can also have users be guided by fidelity bonds in 
order to select federation members.

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

[bitcoin-dev] Improving chaumian ecash and sidechains with fidelity bond federations

[Chris Belcher via bitcoin-dev]

Hello list,

Fidelity bonds could be used to help create trust-minimized federations 
that are needed for things like chaumian ecash servers or sidechains.


From what I've seen until now, people working on chaumian ecash or 
sidechains say that the federation controlling the multisig keys will be 
based on some kind of reputation. Perhaps it will be some pseudonymous 
nyms that have built up a good reputation over a long time. I suggest 
another option is to use fidelity bonds to decide who gets to control 
the multisig keys.


Fidelity bonds are a way to deliberately sacrifice bitcoin value in a 
way that can be proven to a third party. In practice this is done by 
sending bitcoins to an address which is time-locked using the 
OP_CHECKTIMELOCKVERIFY opcode. The redeemscript and UTXO, along with a 
signature, can be shown to anyone to prove that the sacrifice happened. 
This system has already been deployed in JoinMarket since August 2021, 
and at the time of writing about 600 btc have been locked up, some for 
several years. The whole scheme is similar in some ways to PoW that 
bitcoin itself uses to avoid sybil attacks when solving the double spend 
problem.


It's important to understand what is the value-add of fidelity bonds and 
what it isn't. Fidelity bonds don't solve the trust issue, as someone 
with a big fidelity bond could still steal funds from the ecash server 
or sidechain using multisig keys they control. Such systems will always 
be custodial.


Rather, fidelity bonds strongly incentivize that the different fidelity 
bond owners are actually different people. That might be exactly the 
kind of thing needed for distributing the keys of big multisigs, 
especially now that taproot allows us to create very big multisig 
schemes. This happens because the value of a fidelity bond is calculated 
as a greater-than-linear power of the bitcoin sacrifice. So for example 
if the power was 2, and someone sacrificed 5 bitcoins of value, their 
fidelity bond would be worth 5 x 5 = 25. If instead they sacrificed 6 
bitcoins their fidelity bond would be worth 6 x 6 = 36. This superlinear 
power is what creates a strong incentive for the different fidelity 
bonds to actually be controlled by different people, because anyone 
behaving rationally will put all their bitcoins into just one fidelity, 
not split them up over many bonds. As a sybil attacker needs to 
distribute their bitcoins over many different bonds, they are 
mathematically punished. The fidelity bond system achieves this without 
revealing anything much about those people's identities.


Another value-add of fidelity bonds is they are very much in keeping 
with the cypherpunk ethos, as anyone can create a fidelity bond and 
advertise it in the market. As the bitcoins can be mixed with coinjoin 
before and after sending to the timelocked address, the scheme doesn't 
have to be linked to any identity. Only money talks; not reputation, 
political power or geographical power.


I don't know yet exactly the details of how such a scheme would work, 
maybe something like each fidelity bond owner creates a key in the 
multisig scheme, and transaction fees from the sidechain or ecash server 
are divided amongst the fidelity bonds in proportion to their fidelity 
bond value.


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

[bitcoin-dev] A small tweak to TLUV to enable off-chain cancellation of payment pool transactions

[Antoine Riard via bitcoin-dev]

Hi,

Proposing a small tweak to TLUV to enable cancellation of an off-chain
transaction among a set of pool participants. Namely, to give the index of
the constrained output as an opcode item.

Using CoinPool terminology, the Withdraw phase happens by a participant
publishing an Update transaction and her own Withdraw transaction, freeing
her balance from the pool control. From then, any participant can
recursively and unilaterally publish a Withdraw transaction. Or the
consensus of the remaining participants can agree to stay in the pool by
cancelling the non-published Withdraw transactions with a Snapshot one
spending the pool output. This transaction implies a rotation of the
tapscripts, effectively cancelling the Withdraws.

The presence of this latest transaction is a bit artificial and could be
removed by cancelling the non-published Withdraw transactions. This
cancellation would be manifested by producing a group signature spending
any non-published Withdraw transaction `pool_output` and `balance_output`.

If the SIGHASH_ANYPREVOUTANYSCRIPT semantic is used, this re-lifting Update
transaction could be attached on any Withdraw transaction, even if the user
balances are not equal, as the amounts are not committed. To enable
rebinding on multiple cancelled Withdraw
transactions, I think SIGHASH_ANYONECANPAY could be used.

However, the group producing the signature to spend any cancelled output
should reflect the new set of pool participants after the withdrawals have
been played out. Any withdrawing user should have been removed, as there is
no interest anymore to
contribute to the signature. We would like to avoid a former participant
with nothing at stake in the pool to block the pool operations.

E,g let's say you have Alice, Bob, Caroll and Dave as pool participants.
Each of them owns a Withdraw transaction to exit their individual balances
at any time. Alice publishes her Withdraw transaction. Bob, Caroll and Dave
would like to cancel their non-published ones to pursue the pool
operations. To cancel the non-published transactions, only Bob, Caroll and
Dave should be part of the group of signers encumbering the non-published
Withdraw transactions outputs.

That said, the composition of this group of signers is a function of the
Withdraw transactions order, and as thus is unknown at pool state
generation. Therefore, it should be constrained leveraging some covenant
mechanism.

I believe this is achievable using TLUV semantics, at the condition to add
an output index to target the second output. Currently, a Withdraw
transaction `balance_output` is only the owner pubkey. The update internal
pubkey should also be inherited there to make the output cancellable. The
owner withdrawing capability could be moved as a timelock + a key inside a
tapscript.

A tapscript from a CoinPool Withdraw transaction currently looks like this
"0 A MERKLESUB P CHECKSIGVERIFY" [0]

The new tapscript would duplicate TLUV with an output index to constrain
the spending transactions both outputs, and therefore make them cancellable:

"TLUV
   TLUV
 CHECKSIGVERIFY"

I think it is a really slight modification of TLUV and it might serve other
use-cases, beyond the payment pool one ?

Thoughts ?

[0] While it could be argue to split TLUV in two smaller opcodes like
OP_MERKLESUB or a hypothesis OP_MERKLEADD to save few bytes when only the
subtraction or the addition feature is used, I'm not sure it's worthy the
complexity increased. In the context of payment pools, the usage of a TLUV
opcode should only happen in case of "pessimistic" non-cooperative
publication...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev