Alex Schoof [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-06-18 to 2022-05-11
💬 Posted a total of 10 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, PROPOSAL
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:05:45

- reply

📅 Original date posted:2022-04-07
📝 Original message:
Hey Laolu,
Really interesting protocol. I'm not all the way through all of the docs
yet, but had a few questions/comments:
- The top-level doc (
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks
about embedding overlay metadata in the taproot script tree. From my
reading, it seems like what gets committed is the root of the taro MS-SMT
tree, while leaves of the tree itself are off-chain in a proof file. If
that's the case, did you look at other mechanisms to commit to a merkle
root? For example, I believe mainstay[1] uses a
pay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to
p2pkh/p2sh addresses with signature tweaks. Are there other interesting (to
taro) spend-paths that need to be allowed that led to the taproot script
tree being particularly helpful?
- It appears that the transfer proofs are kept off-chain in another file
which is passed between users, where the receiver can validate the transfer
according to whatever semantics the taro-vm has at that moment and refuse
to credit the sender if the transfer breaks some business logic or
validation rules. This reminds me a lot of single-use-seals[3]. Is that the
right way to think about what's going on here? If it is, then it looks like
a Universe/Multiverse is an offload/aggregation mechanism that can keep
track of asset lineages on behalf of users, which would be useful for light
clients of heavily-used asset types (so your mobile client doesnt have to
traverse the transfer lineage of some high-liquidity stablecoin or
something).
- Rubin made a good point above about how something like a conditional
transfer in a taro asset won't necessarily cause the conditional bitcoin
transfer to fail. My first thought was to have the "carrier utxo" for a
taro asset be really small, like dust + some buffer. The thought being that
I'm basically just paying gas and if I lose `dust+buffer` amount of bitcoin
but not a lot of some token, then that's not great but not terrible. Where
it gets bad is if the value of the taro asset that you're trying to
transfer is close to or less than the value of the bitcoin that's being
used to do the transfer.
- There's been a lot of talk lately on the bitcoin-dev list about
covenants, and I wonder if some of those designs (specifically TLUV or CTV)
might be useful with Taro, to "lift" some of the taro conditions into
covenants that encumber the underlying bitcoin. I don't have a design or
anything, wondering if you've given this any thought.
- was this originally named CMYK?
Thanks,
Alex
[1]
https://cloudflare-ipfs.com/ipns/ipfs.commerceblock.com/commerceblock-whitepaper-mainstay.pdf
[2] https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki
[3] https://petertodd.org/2016/commitments-and-single-use-seals
On Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen <rsomsen at gmail.com> wrote:
> Hi Laolu,
>
> Nice work. This is an interesting protocol, in my opinion.
>
> Seeing as there's a large amount of overlap with RGB, a protocol which I
> have examined quite extensively, I believe some of the issues I uncovered
> in that project also apply here.
>
> The biggest issue revolves around the scripting expectations for this
> protocol. Taro is described as being able to have its own scripting
> capabilities that will initially be similar to Bitcoin and eventually be
> made to do more. I'm afraid this is fundamentally impossible. Conditional
> scripts (and thus most scripts that could potentially be of interest) won't
> be possible if the satisfaction of the condition is not recorded publicly
> on-chain.
>
> The core problem here is that you have two levels of scripting. At the
> Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the
> Taro level you have yet another script. This may seem similar at first
> glance to how taproot has a key path and a script path, but there are a few
> key differences. In taproot only one of the two needs to be satisfied,
> while here you need to satisfy both. Furthermore, the Taro script is not
> enforced by Bitcoin, meaning those who control the Bitcoin script can
> always choose to ignore the Taro script and destroy the Taro assets as a
> result.
>
> I'll describe an example. Imagine Alice wants to send Bob a payment inside
> Taro, but she wants to make it conditional. Bob gets the Taro tokens if he
> reveals a pre-image, while Alice can claim the tokens back after the
> timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice
> starts by locking up coins in a 2-of-2 multisig on the mainchain with some
> Taro tokens inside. She then gives Bob a pre-signed transaction that only
> requires him to reveal the pre-image in order to claim the tokens. The
> issue here is that from Bitcoin's perspective, you're giving Bob a valid
> transaction, regardless of whether he reveals the pre-image. If Bob
> maliciously broadcasts it without the pre-image, he will have destroyed
> your tokens.
>
> Of course this was a contrived example, as these conditions could simply
> take place entirely in Bitcoin script, but it demonstrates that Taro script
> fundamentally cannot handle conditional payments, which is the basis for
> any meaningful script other than self-encumbering covenants (i.e. if you
> send your Taro tokens in any way other than specified, the tokens will be
> destroyed). Luckily this has no effect on whether Taro can function over
> Lightning, because solely relying on Bitcoin's scripting capabilities
> should be sufficient for that use case.
>
> As a side note, it may be worth pointing out that it *is* possible to
> create conditional payments if the satisfaction of the condition is
> recorded publicly on the mainchain (e.g. in an op_return), making it sort
> of a hybrid on-chain/off-chain model, but it would increase complexity
> considerably. I can explain this model in more detail, if it happens to
> interest you.
>
> Now there's a second issue I want to bring up, but unfortunately my
> understanding of how exactly you made assets divisible is not complete
> enough to know how this problem might have manifested in Taro. Nonetheless,
> I'll try to describe it.
>
> One of the core concepts of Taro/RGB is that the sender of the token has
> to reveal the history to the recipient. In case of an NFT the history is
> simply every prior owner and grows linearly, but in the case of fungible
> tokens things are more complicated. Let's say Carol receives 2 fungible
> Taro tokens from Alice and 3 fungible Taro tokens from Bob. Now Carol wants
> to send 4 of them to Dave and keep 1. There are two possible designs here:
>
> a.) The token history remains separate – Dave receives Alice's 2 tokens,
> Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice).
>
> b.) The token history gets merged – Dave receives 4 tokens (linking the
> new output with both Alice and Bob's history).
>
> The issue with a.) is that you're only ever fragmenting tokens, so
> eventually you end up with lots of tiny but separate amounts. This will
> cause making large payments to involve sending lots of tokens, each with
> their own history. Under this model, I suspect the fixed value token model
> (e.g. 1, 2, 4, 8) might be preferable, as this prevents the entire supply
> from getting split into tiny fragments.
>
> The issue with b.) is that you end up with a linked transaction graph,
> just like in Bitcoin. If you pick a random Bitcoin UTXO and try to trace it
> back to a coinbase, you'll quickly find that it could have come from many
> of them. The graph that you'd traverse to get to all of these coinbases is
> equivalent to the amount of history that a recipient of a Taro token has to
> validate in order to accept it, which I suspect quickly becomes a
> bottleneck that is not unlike that of a regular blockchain.
>
> It'd probably be wise to make a model of the potential transaction flow,
> and simulate how it affects the size of the history in order to determine
> what's the best approach and to generally get a better idea of how it
> affects scaling. Also, the repeated sharing of history makes me skeptical
> about the privacy this protocol may provide. If large amounts of history
> moved through the hands of a large number of people, it wouldn't be very
> private.
>
> There's a third third smaller issue I want to point out, which is easily
> fixable and perhaps was just a typo. In your slides, you showed a
> screenshot of a taproot tree containing the Taro tree as the third element
> of four. This implies the location of the Taro tree inside the taproot tree
> is not fixed. What needs to be prevented here is that a taproot tree
> contains more than one Taro tree, as that would enable the owner of the
> commitment to show different histories to different people.
>
> Finally, let me conclude with two questions. Could you clarify the purpose
> of the sparse merkle tree in your design? I suppose you want to be able to
> open a commitment and show it contains a certain asset without having to
> reveal any of the other assets and simultaneously guarantee that you
> haven't committed to the same asset twice (i.e. the SMT guarantees each
> asset gets a specific location in the tree)? Or is there another reason?
>
> And the second question – when transferring Taro token ownership from one
> Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do
> you support the ability to "teleport" the tokens to an existing UTXO like
> how RGB does it? If the latter, have you given consideration to timing
> issues that might occur when someone sends tokens to an existing UTXO that
> simultaneously happens to get spent by the owner?
>
> In any case, I hope this email was useful. Feel free to reach out if I can
> clarify anything.
>
> Good luck with the protocol.
>
> Best regards,
> Ruben
>
> On Tue, Apr 5, 2022 at 5:06 PM Olaoluwa Osuntokun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi y'all,
>>
>> I'm excited to publicly publish a new protocol I've been working on over
>> the
>> past few months: Taro. Taro is a Taproot Asset Representation Overlay
>> which
>> allows the issuance of normal and also collectible assets on the main
>> Bitcoin
>> chain. Taro uses the Taproot script tree to commit extra asset structured
>> meta
>> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree
>> or
>> MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
>> sparse
>> merkle tree, enabling things like easily verifiable asset supply proofs
>> and
>> also efficient proofs of non existence (eg: you prove to me you're no
>> longer
>> committing to the 1-of-1 holographic beefzard card during our swap). Taro
>> asset
>> transfers are then embedded in a virtual/overlay transaction graph which
>> uses a
>> chain of asset witnesses to provably track the transfer of assets across
>> taproot outputs. Taro also has a scripting system, which allows for
>> programmatic unlocking/transfer of assets. In the first version, the
>> scripting
>> system is actually a recursive instance of the Bitcoin Script Taproot VM,
>> meaning anything that can be expressed in the latest version of Script
>> can be
>> expressed in the Taro scripting system. Future versions of the scripting
>> system
>> can introduce new functionality on the Taro layer, like covenants or other
>> updates.
>>
>> The Taro design also supports integration with the Lightning Network
>> (BOLTs) as
>> the scripting system can be used to emulate the existing HTLC structure,
>> which
>> allows for multi-hop transfers of Taro assets. Rather than modify the
>> internal
>> network, the protocol proposes to instead only recognize "assets at the
>> edges",
>> which means that only the sender+receiver actually need to know about and
>> validate the assets. This deployment route means that we don't need to
>> build up
>> an entirely new network and liquidity for each asset. Instead, all asset
>> transfers will utilize the Bitcoin backbone of the Lightning Network,
>> which
>> means that the internal routers just see Bitcoin transfers as normal, and
>> don't
>> even know about assets at the edges. As a result, increased demand for
>> transfers of these assets as the edges (say like a USD stablecoin), which
>> in
>> will turn generate increased demand of LN capacity, result in more
>> transfers, and
>> also more routing revenue for the Bitcoin backbone nodes.
>>
>> The set of BIPs are a multi-part suite, with the following breakdown:
>> * The main Taro protocol:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
>> * The MS-SMT structure:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
>> * The Taro VM:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
>> * The Taro address format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
>> * The Taro Universe concept:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
>> * The Taro flat file proof format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
>>
>> Rather than post them all in line (as the text wouldn't fit in the
>> allowed size
>> limit), all the BIPs can be found above.
>>
>> -- Laolu
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220407/9dd3bd33/attachment-0001.html>

2023-06-09 13:04:34

- reply

📅 Original date posted:2021-12-09
📝 Original message:
The multisig scheme is interesting. From my understanding of Single Use
Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
you would want to pick some common aggregation service provider ahead of
time and if that provider disappears, you’re stuck and cant close the next
seal. If instead you say “this seal commits to three of the five of these
next seals” then you mitigate both availability and censorship risk. Am I
getting that right?
Alex
On Thu, Dec 9, 2021 at 5:23 AM Peter Todd <pete at petertodd.org> wrote:
> On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> > pete at petertodd.org, so single use seals require an onchain transaction
> to
> > post the proof of publication to the ledger (assuming bitcoin is used as
> > the ledger) when an asset is transferred, but it can scale because you
> can
> > batch many proofs (transfer of ownerships) into a merkle tree and just
> add
> > the merkle root into the single tx going into the ledger?
>
> Exactly. And since the aggregation is trustless with respect to validity,
> users
> can choose what kind of censorship risk they're willing to take (as well as
> mitigate it with "multisig" schemes that use multiple aggregators in
> parallel).
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/0a9cde55/attachment.html>

2023-06-07 23:09:30

- reply

📅 Original date posted:2022-05-11
📝 Original message:Hi Rusty,
One of the common sentiments thats been expressed over the last few months
is that more people want to see experimentation with different applications
using covenants. I really like this proposal because in addition to
offering a cleaner upgrade/extension path than adding “CTV++” as a new
opcode in a few years, it also seems like it would make it very easy to
create prototype applications to game out new ideas:
If the “only this combination of fields are valid, otherwise OP_SUCCESS”
check is just comparing with a list of bitmasks for permissible field
combinations (which right now is a list of length 1), it seems like it
would be *very* easy for people who want to play with other covenant field
sets to just add the relevant bitmasks and then go spin up a signet to
build applications.
Being able to make a very targeted change like that to enable
experimentation is super cool. Thanks for sharing!
Alex
On Tue, May 10, 2022 at 6:37 AM Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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]
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/03fcb3bf/attachment.html>

2023-06-07 23:06:56

- reply

📅 Original date posted:2022-04-07
📝 Original message:Hey Laolu,
Really interesting protocol. I'm not all the way through all of the docs
yet, but had a few questions/comments:
- The top-level doc (
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki) talks
about embedding overlay metadata in the taproot script tree. From my
reading, it seems like what gets committed is the root of the taro MS-SMT
tree, while leaves of the tree itself are off-chain in a proof file. If
that's the case, did you look at other mechanisms to commit to a merkle
root? For example, I believe mainstay[1] uses a
pay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to
p2pkh/p2sh addresses with signature tweaks. Are there other interesting (to
taro) spend-paths that need to be allowed that led to the taproot script
tree being particularly helpful?
- It appears that the transfer proofs are kept off-chain in another file
which is passed between users, where the receiver can validate the transfer
according to whatever semantics the taro-vm has at that moment and refuse
to credit the sender if the transfer breaks some business logic or
validation rules. This reminds me a lot of single-use-seals[3]. Is that the
right way to think about what's going on here? If it is, then it looks like
a Universe/Multiverse is an offload/aggregation mechanism that can keep
track of asset lineages on behalf of users, which would be useful for light
clients of heavily-used asset types (so your mobile client doesnt have to
traverse the transfer lineage of some high-liquidity stablecoin or
something).
- Rubin made a good point above about how something like a conditional
transfer in a taro asset won't necessarily cause the conditional bitcoin
transfer to fail. My first thought was to have the "carrier utxo" for a
taro asset be really small, like dust + some buffer. The thought being that
I'm basically just paying gas and if I lose `dust+buffer` amount of bitcoin
but not a lot of some token, then that's not great but not terrible. Where
it gets bad is if the value of the taro asset that you're trying to
transfer is close to or less than the value of the bitcoin that's being
used to do the transfer.
- There's been a lot of talk lately on the bitcoin-dev list about
covenants, and I wonder if some of those designs (specifically TLUV or CTV)
might be useful with Taro, to "lift" some of the taro conditions into
covenants that encumber the underlying bitcoin. I don't have a design or
anything, wondering if you've given this any thought.
- was this originally named CMYK?
Thanks,
Alex
[1]
https://cloudflare-ipfs.com/ipns/ipfs.commerceblock.com/commerceblock-whitepaper-mainstay.pdf
[2] https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki
[3] https://petertodd.org/2016/commitments-and-single-use-seals
On Thu, Apr 7, 2022 at 1:14 PM Ruben Somsen <rsomsen at gmail.com> wrote:
> Hi Laolu,
>
> Nice work. This is an interesting protocol, in my opinion.
>
> Seeing as there's a large amount of overlap with RGB, a protocol which I
> have examined quite extensively, I believe some of the issues I uncovered
> in that project also apply here.
>
> The biggest issue revolves around the scripting expectations for this
> protocol. Taro is described as being able to have its own scripting
> capabilities that will initially be similar to Bitcoin and eventually be
> made to do more. I'm afraid this is fundamentally impossible. Conditional
> scripts (and thus most scripts that could potentially be of interest) won't
> be possible if the satisfaction of the condition is not recorded publicly
> on-chain.
>
> The core problem here is that you have two levels of scripting. At the
> Bitcoin level the UTXO is encumbered by the Bitcoin script, then at the
> Taro level you have yet another script. This may seem similar at first
> glance to how taproot has a key path and a script path, but there are a few
> key differences. In taproot only one of the two needs to be satisfied,
> while here you need to satisfy both. Furthermore, the Taro script is not
> enforced by Bitcoin, meaning those who control the Bitcoin script can
> always choose to ignore the Taro script and destroy the Taro assets as a
> result.
>
> I'll describe an example. Imagine Alice wants to send Bob a payment inside
> Taro, but she wants to make it conditional. Bob gets the Taro tokens if he
> reveals a pre-image, while Alice can claim the tokens back after the
> timelock expires (i.e. the minimum scripting requirements for HTLCs). Alice
> starts by locking up coins in a 2-of-2 multisig on the mainchain with some
> Taro tokens inside. She then gives Bob a pre-signed transaction that only
> requires him to reveal the pre-image in order to claim the tokens. The
> issue here is that from Bitcoin's perspective, you're giving Bob a valid
> transaction, regardless of whether he reveals the pre-image. If Bob
> maliciously broadcasts it without the pre-image, he will have destroyed
> your tokens.
>
> Of course this was a contrived example, as these conditions could simply
> take place entirely in Bitcoin script, but it demonstrates that Taro script
> fundamentally cannot handle conditional payments, which is the basis for
> any meaningful script other than self-encumbering covenants (i.e. if you
> send your Taro tokens in any way other than specified, the tokens will be
> destroyed). Luckily this has no effect on whether Taro can function over
> Lightning, because solely relying on Bitcoin's scripting capabilities
> should be sufficient for that use case.
>
> As a side note, it may be worth pointing out that it *is* possible to
> create conditional payments if the satisfaction of the condition is
> recorded publicly on the mainchain (e.g. in an op_return), making it sort
> of a hybrid on-chain/off-chain model, but it would increase complexity
> considerably. I can explain this model in more detail, if it happens to
> interest you.
>
> Now there's a second issue I want to bring up, but unfortunately my
> understanding of how exactly you made assets divisible is not complete
> enough to know how this problem might have manifested in Taro. Nonetheless,
> I'll try to describe it.
>
> One of the core concepts of Taro/RGB is that the sender of the token has
> to reveal the history to the recipient. In case of an NFT the history is
> simply every prior owner and grows linearly, but in the case of fungible
> tokens things are more complicated. Let's say Carol receives 2 fungible
> Taro tokens from Alice and 3 fungible Taro tokens from Bob. Now Carol wants
> to send 4 of them to Dave and keep 1. There are two possible designs here:
>
> a.) The token history remains separate – Dave receives Alice's 2 tokens,
> Bob's tokens are split and he receives 2 (or 3 from Bob 1 from Alice).
>
> b.) The token history gets merged – Dave receives 4 tokens (linking the
> new output with both Alice and Bob's history).
>
> The issue with a.) is that you're only ever fragmenting tokens, so
> eventually you end up with lots of tiny but separate amounts. This will
> cause making large payments to involve sending lots of tokens, each with
> their own history. Under this model, I suspect the fixed value token model
> (e.g. 1, 2, 4, 8) might be preferable, as this prevents the entire supply
> from getting split into tiny fragments.
>
> The issue with b.) is that you end up with a linked transaction graph,
> just like in Bitcoin. If you pick a random Bitcoin UTXO and try to trace it
> back to a coinbase, you'll quickly find that it could have come from many
> of them. The graph that you'd traverse to get to all of these coinbases is
> equivalent to the amount of history that a recipient of a Taro token has to
> validate in order to accept it, which I suspect quickly becomes a
> bottleneck that is not unlike that of a regular blockchain.
>
> It'd probably be wise to make a model of the potential transaction flow,
> and simulate how it affects the size of the history in order to determine
> what's the best approach and to generally get a better idea of how it
> affects scaling. Also, the repeated sharing of history makes me skeptical
> about the privacy this protocol may provide. If large amounts of history
> moved through the hands of a large number of people, it wouldn't be very
> private.
>
> There's a third third smaller issue I want to point out, which is easily
> fixable and perhaps was just a typo. In your slides, you showed a
> screenshot of a taproot tree containing the Taro tree as the third element
> of four. This implies the location of the Taro tree inside the taproot tree
> is not fixed. What needs to be prevented here is that a taproot tree
> contains more than one Taro tree, as that would enable the owner of the
> commitment to show different histories to different people.
>
> Finally, let me conclude with two questions. Could you clarify the purpose
> of the sparse merkle tree in your design? I suppose you want to be able to
> open a commitment and show it contains a certain asset without having to
> reveal any of the other assets and simultaneously guarantee that you
> haven't committed to the same asset twice (i.e. the SMT guarantees each
> asset gets a specific location in the tree)? Or is there another reason?
>
> And the second question – when transferring Taro token ownership from one
> Bitcoin UTXO to another, do you generate a new UTXO for the recipient or do
> you support the ability to "teleport" the tokens to an existing UTXO like
> how RGB does it? If the latter, have you given consideration to timing
> issues that might occur when someone sends tokens to an existing UTXO that
> simultaneously happens to get spent by the owner?
>
> In any case, I hope this email was useful. Feel free to reach out if I can
> clarify anything.
>
> Good luck with the protocol.
>
> Best regards,
> Ruben
>
> On Tue, Apr 5, 2022 at 5:06 PM Olaoluwa Osuntokun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi y'all,
>>
>> I'm excited to publicly publish a new protocol I've been working on over
>> the
>> past few months: Taro. Taro is a Taproot Asset Representation Overlay
>> which
>> allows the issuance of normal and also collectible assets on the main
>> Bitcoin
>> chain. Taro uses the Taproot script tree to commit extra asset structured
>> meta
>> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree
>> or
>> MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
>> sparse
>> merkle tree, enabling things like easily verifiable asset supply proofs
>> and
>> also efficient proofs of non existence (eg: you prove to me you're no
>> longer
>> committing to the 1-of-1 holographic beefzard card during our swap). Taro
>> asset
>> transfers are then embedded in a virtual/overlay transaction graph which
>> uses a
>> chain of asset witnesses to provably track the transfer of assets across
>> taproot outputs. Taro also has a scripting system, which allows for
>> programmatic unlocking/transfer of assets. In the first version, the
>> scripting
>> system is actually a recursive instance of the Bitcoin Script Taproot VM,
>> meaning anything that can be expressed in the latest version of Script
>> can be
>> expressed in the Taro scripting system. Future versions of the scripting
>> system
>> can introduce new functionality on the Taro layer, like covenants or other
>> updates.
>>
>> The Taro design also supports integration with the Lightning Network
>> (BOLTs) as
>> the scripting system can be used to emulate the existing HTLC structure,
>> which
>> allows for multi-hop transfers of Taro assets. Rather than modify the
>> internal
>> network, the protocol proposes to instead only recognize "assets at the
>> edges",
>> which means that only the sender+receiver actually need to know about and
>> validate the assets. This deployment route means that we don't need to
>> build up
>> an entirely new network and liquidity for each asset. Instead, all asset
>> transfers will utilize the Bitcoin backbone of the Lightning Network,
>> which
>> means that the internal routers just see Bitcoin transfers as normal, and
>> don't
>> even know about assets at the edges. As a result, increased demand for
>> transfers of these assets as the edges (say like a USD stablecoin), which
>> in
>> will turn generate increased demand of LN capacity, result in more
>> transfers, and
>> also more routing revenue for the Bitcoin backbone nodes.
>>
>> The set of BIPs are a multi-part suite, with the following breakdown:
>> * The main Taro protocol:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
>> * The MS-SMT structure:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
>> * The Taro VM:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
>> * The Taro address format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
>> * The Taro Universe concept:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
>> * The Taro flat file proof format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
>>
>> Rather than post them all in line (as the text wouldn't fit in the
>> allowed size
>> limit), all the BIPs can be found above.
>>
>> -- Laolu
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220407/9dd3bd33/attachment-0001.html>

2023-06-07 23:02:42

- reply

📅 Original date posted:2022-01-28
📝 Original message:> CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.
This is super interesting. I think that would make it easier to do
multi-party DLCs. With a "normal" DLC, you need to have N parties
exchanging and signing CETs and you end up with a combinatorial explosion
of signing operations to perform. It sounds like if you did it with CTV,
then each party could compute all the outcomes on their own in parallel (to
be able to generate commitments for each tapleaf) and then just exchange
and sign the single opening transaction for the DLC. Or for devices with
limited resources, you could have a coordinator compute the whole TR tree
and publish a ZKP to the other signers.
Cheers,
Alex
On Fri, Jan 28, 2022 at 12:21 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Lloyd,
>
> This is an excellent write up, the idea and benefits are clear.
>
> Is it correct that in the case of a 3/5th threshold it is a total 10x *
> 30x = 300x improvement? Quite impressive.
>
> I have a few notes of possible added benefits / features of DLCs with CTV:
>
> 1) CTV also enables a "trustless timeout" branch, whereby you can have a
> failover claim that returns funds to both sides.
>
> There are a few ways to do this:
>
> A) The simplest is just an oracle-free <STH(timeout tx)> CTV whereby the
> timeout transaction has an absolute/relative timelock after the creation of
> the DLC in question.
>
> B) An alternative approach I like is to have the base DLC have a branch
> `<STH(begin timeout)> CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with `<STH(timeout
> tx)> CTV` which contains a relative timelock R for the desired amount of
> time to resolve. This has the advantage of always guaranteeing at least R
> amount of time since the Oracles have been claimed to be non-live to
> "return funds" to parties participating
>
>
> 2) CTV DLCs are non-interactive asynchronously third-party unilaterally
> creatable.
>
> What I mean by this is that it is possible for a single party to create a
> DLC on behalf of another user since there is no required per-instance
> pre-signing or randomly generated state. E.g., if Alice wants to create a
> DLC with Bob, and knows the contract details, oracles, and a key for Bob,
> she can create the contract and pay to it unilaterally as a payment to Bob.
>
> This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
> also be constructed and then sent (along with a specific amount) to a third
> party service (such as an exchange or Lightning node) to create DLCs
> without requiring the third party service to do anything other than make
> the payment as requested.
>
>
> 3) CTV DLCs can be composed in interesting ways
>
> Options over DLCs open up many exciting types of instrument where Alice
> can do things like:
> A) Create a Option expiring in 1 week where Bob can add funds to pay a
> premium and "Open" a DLC on an outcome closing in 1 year
> B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
> premium (on-chain DEX?).
>
> See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete
> stuff around this.
>
> There are also opportunities for perpetual-like contracts where you could
> combine into one logical DLC 12 DLCs closing 1 per month that can either be
> payed out all at once at the end of the year, or profit pulled out
> partially at any time earlier.
>
> 4) This satisfies (I think?) my request to make DLCs expressible as Sapio
> contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/
>
> 5) An additional performance improvement can be had for iterative DLCs in
> Lightning where you might trade over a fixed set of attestation points with
> variable payout curves (e.g., just modifying some set of the CTV points).
> Defer to you on performance, but this could help enable some more HFT-y
> experiences for DLCs in LN
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi dlc-dev and bitcoin-dev,
>>
>> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.
>>
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/95d5f0c6/attachment-0001.html>

2023-06-07 23:02:36

- reply

📅 Original date posted:2022-01-18
📝 Original message:Hey Jeremy,
> On the topic of drafting BIPs for specific use cases, I agree that would
be valuable and can consider it.
> However, I'm a bit skeptical of that approach overall as I don't
necessarily think that the applications *must be* standard, and I view BIPs
as primarily for standardization whereas part of the flexibility of
CTV/Sapio allows users to figure out how they want to use it.
Electronic components (think an integrated circuit or a capacitor) usually
have both a "data sheet" and a set of "application notes". The data sheet
is like a spec or the formal documentation: how the thing works (or is
intended to work), precise dimensions and tolerances, etc. On the other
hand, the Application Notes are either a separate document or an appendix
to the data sheet with specific details about using that component in a
specific application: things like schematics for an example implementation,
things to watch out for (edge cases or unexpected application-specific
behavior, etc.). I appreciate the balance you're trying to strike between
having the BIP for CTV have enough details about how you think it might be
used and having it exclusively be a spec to help drive standardization.
Maybe the solution here is to have some explicit application notes that
have enough details to give people a sense of how these uses could be built
out, but still have it be clear that they are a use of, not a part of CTV
itself by having it either in a linked document or an appendix or
something.
Just a suggestion.
Cheers,
Alex
On Tue, Jan 18, 2022 at 6:54 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for the detailed review.
>
> I'll withhold comment around activation logic and leave that for others to
> discuss.
>
> w.r.t. the language cleanups I'll make a PR that (I hope) clears up the
> small nits later today or tomorrow. Some of it's kind of annoying because
> the legal definition of covenant is "A formal agreement or promise,
> usually included in a contract or deed, to do or not do a particular act; a
> compact or stipulation made in writing or by parol." so I do think things
> like CLTV/CSV are covenants since it's a binding promise to not spend
> before a certain time... it might be out of scope for the BIP to fully
> define these terms because it doesn't really matter what a covenant could
> be as much as it matters what CTV is specifically.
>
> On the topic of drafting BIPs for specific use cases, I agree that would
> be valuable and can consider it.
>
> However, I'm a bit skeptical of that approach overall as I don't
> necessarily think that the applications *must be* standard, and I view BIPs
> as primarily for standardization whereas part of the flexibility of
> CTV/Sapio allows users to figure out how they want to use it.
>
> E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot,
> although there are some papers and example implementations but nothing
> formal yet
> https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors).
> Perhaps this is an opportunity for CTV to lead on the amount of formal
> application designs available before 'release'.
>
> As a starting point, maybe you could review some of the application
> focused posts in rubin.io/advent21 and let me know where they seem
> deficient?
>
> Also a BIP describing how to build something like Sapio (and less so Sapio
> itself, since it's still early days for that) might help for folks to be
> able to think through how to compile to CTV contracts? But again, I'm
> skeptical of the value of a BIP v.s. the documentation and examples
> available in the code and https://learn.sapio-lang.org.
>
> I think it's an interesting discussion too because as we've just seen the
> LN ecosystem start the BLIP standards, would an example of non-interactive
> channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing
> list post?
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> tl;dr: I don't think CTV is ready yet (but probably close), and in any
>> case
>> definitely not worth reviving BIP 9 with its known flaws and
>> vulnerability.
>>
>> My review here is based solely on the BIP, with no outside context (aside
>> from
>> current consensus rules, of course). In particular, I have _not_ looked
>> at
>> the CTV code proposed for Bitcoin Core yet.
>>
>> >Covenants are restrictions on how a coin may be spent beyond key
>> ownership.
>>
>> nit: Poorly phrased. Even simple scripts can do that already.
>>
>> >A few examples are described below, which should be the subject of
>> future
>> non-consensus standardization efforts.
>>
>> I would ideally like to see fully implemented BIPs for at least one of
>> these
>> (preferably the claimed CoinJoin improvements) before we move toward
>> activation.
>>
>> >Congestion Controlled Transactions
>>
>> I think this use case hasn't been fully thought through yet. It seems
>> like it
>> would be desirable for this purpose, to allow any of the recipients to
>> claim
>> their portion of the payment without footing the fee for every other
>> payment
>> included in the batch. This is still a covenant-type solution, but one
>> that
>> BIP 119 cannot support as-is.
>>
>> (I realise this may be a known and accepted limitation, but I think it
>> should
>> be addressed in the BIP)
>>
>> >Payment Channels
>>
>> Why batch mere channel creation? Seems like the spending transaction
>> should
>> really be the channel closing.
>>
>> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins
>> than
>> previously because participants agree on a single output which pays all
>> participants, which will be lower fee than before.
>>
>> I don't see how. They still have to agree in advance on the outputs, and
>> the
>> total fees will logically be higher than not using CTV...?
>>
>> >Further Each participant doesn't need to know the totality of the
>> outputs
>> committed to by that output, they only have to verify their own sub-tree
>> will
>> pay them.
>>
>> I don't see any way to do this with the provided implementation.
>>
>> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
>> Trial.
>>
>> Hard NACK on this. BIP 9 at this point represents developers attempting
>> to
>> disregard and impose their will over community consensus, as well as an
>> attempt to force a miner veto backdoor/vulnerability on deployment. It
>> should
>> never be used again.
>>
>> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
>> compromise between LOT=True and LOT=False (which could be deployed prior
>> to
>> or in parallel), but using BIP 9 would destroy this.
>>
>> As with Taproot, any future deployments should use BIP 8 again, until a
>> better
>> solution is developed. Reverting back to a known flawed and vulnerable
>> activation method should not be done, and it would be better not to
>> deploy
>> CTV at all at such an expense.
>>
>> The fact that certain developers attempted to deploy a BIP 9 alternative
>> activation for Taproot against community consensus, and that even managed
>> to
>> get released as "Bitcoin Core", makes it all the more important that the
>> community firmly rejects any further action to force this regression.
>>
>> * it is my opinion a BIP 8 ST would be an okay compromise under those
>> circumstances; others do disagree that ST is acceptable at all
>>
>> > This ensures that for a given known input, the TXIDs can also be known
>> ahead
>> of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched
>> Channel Creation constructions as the redemption TXID could be malleated
>> and
>> pre-signed transactions invalidated, unless the channels are built using
>> an
>> Eltoo-like protocol.
>>
>> Why is it a problem for them to use an Eltoo-like protocol?
>>
>> Why not just commit to the txid itself if that's the goal?
>>
>> >P2SH is incompatible with CHECKTEMPLATEVERIFY
>>
>> Maybe the CTV opcode should only be defined/enforced within witness
>> scripts?
>>
>> >nLockTime should generally be fixed to 0 (in the case of a payment tree,
>> only
>> the *first* lock time is needed to prevent fee-sniping the root)
>>
>> Your "Congestion Controlled Transactions" example would only make sense
>> with
>> the spending transaction much later than the "root", and so could benefit
>> from fee sniping malleability. (In fact, in that example, it would be
>> better
>> not to commit to locktime at all.)
>>
>> >In the CHECKTEMPLATEVERIFY approach, the covenants are severely
>> restricted to
>> simple templates. The structure of CHECKTEMPLATEVERIFY template is such
>> that
>> the outputs must be known exactly at the time of construction. Based on a
>> destructuring argument, it is only possible to create templates which
>> expand
>> in a finite number of steps.
>>
>> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
>> added.
>>
>> >For example, a exchange's hot wallet might use an address which can
>> automatically be moved to a cold storage address after a relative timeout.
>>
>> Wouldn't it make more sense to just have a UTXO both cold+hot can spend,
>> then
>> throw away the hot key?
>>
>> >In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make
>> scripts
>> valid for policy until the new rule is active.
>>
>> Policy isn't validity, and cannot be dictated by BIPs (or
>> anyone/anything, for
>> that matter).
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220118/942a40cd/attachment.html>

2023-06-07 23:02:14

- reply

📅 Original date posted:2022-01-13
📝 Original message:> I also don't see why Alex or anyone should be denied the opportunity to
comment on future soft forks or anything about bitcoin. Alex should have no
more or less right to participate and his comments should be judged on
their merit, just like yours and mine.
I think the concern is something like: "I disagree with a board member of
the defense fund about [insert contentious issue]. If I disagree with them
publicly (especially if there are clear economic implications in that
disagreement), am I putting myself at risk in the future where I won't be
able to get support from the fund because I spoke out against a board
member?" That kind of concern can be mitigated through policy and
governance, but is the kind of thing you want to tackle before it becomes
an issue.
Cheers,
(a different) Alex
On Thu, Jan 13, 2022 at 1:49 PM Steve Lee via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think the word "The" is important. The title of the email and the name
> of the fund is Bitcoin Legal Defense Fund. It is "a" legal defense fund;
> not THE Bitcoin Legal Defense Fund. There is room for other funds and
> strategies and anyone is welcome to create alternatives.
>
> I also don't see why Alex or anyone should be denied the opportunity to
> comment on future soft forks or anything about bitcoin. Alex should have no
> more or less right to participate and his comments should be judged on
> their merit, just like yours and mine.
>
> On Thu, Jan 13, 2022 at 9:37 AM Prayank via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Jack,
>>
>>
>> > The main purpose of this Fund is to defend developers from lawsuits
>> regarding their activities in the Bitcoin ecosystem, including finding and
>> retaining defense counsel, developing litigation strategy, and paying legal
>> bills. This is a free and voluntary option for developers to take advantage
>> of if they so wish. The Fund will start with a corps of volunteer and
>> part-time lawyers. The board of the Fund will be responsible for
>> determining which lawsuits and defendants it will help defend.
>>
>> Thanks for helping the developers in legal issues. Appreciate your
>> efforts and I understand your intentions are to help Bitcoin in every
>> possible way.
>>
>>
>> Positives that I see in this initiative:
>>
>> 1.Developers don't need to worry about rich scammers and can focus on
>> development.
>>
>> 2.Financial help for developers as legal issues can end up in wasting lot
>> of time and money.
>>
>> 3.People who have misused courts to affect bitcoin developers will get
>> better response that they deserve.
>>
>>
>> I had few suggestions and feel free to ignore them if they do not make
>> sense:
>>
>> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense
>> Fund' can be confusing or misleading for newbies. There is nothing official
>> in Bitcoin however people believe things written in news articles and some
>> of them might consider it as an official bitcoin legal fund.
>>
>> 2.It would be better if people involved in such important funds do not
>> comment/influence soft fork related discussions. Example: Alex Morcos had
>> some opinions about activation mechanism during Taproot soft fork IIRC.
>>
>>
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220113/dbfb6d62/attachment.html>

2023-06-07 23:00:53

- reply

📅 Original date posted:2021-12-09
📝 Original message:The multisig scheme is interesting. From my understanding of Single Use
Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
you would want to pick some common aggregation service provider ahead of
time and if that provider disappears, you’re stuck and cant close the next
seal. If instead you say “this seal commits to three of the five of these
next seals” then you mitigate both availability and censorship risk. Am I
getting that right?
Alex
On Thu, Dec 9, 2021 at 5:23 AM Peter Todd <pete at petertodd.org> wrote:
> On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> > pete at petertodd.org, so single use seals require an onchain transaction
> to
> > post the proof of publication to the ledger (assuming bitcoin is used as
> > the ledger) when an asset is transferred, but it can scale because you
> can
> > batch many proofs (transfer of ownerships) into a merkle tree and just
> add
> > the merkle root into the single tx going into the ledger?
>
> Exactly. And since the aggregation is trustless with respect to validity,
> users
> can choose what kind of censorship risk they're willing to take (as well as
> mitigate it with "multisig" schemes that use multiple aggregators in
> parallel).
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211209/0a9cde55/attachment.html>

2023-06-07 22:55:01

- reply

📅 Original date posted:2021-06-28
📝 Original message:Hey Raymo,
Here’s a scenario:
Alice has one UTXO.
Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives whatever
goods and services to Alice.
Alice then goes and spends that UTXO to Charlie with a higher fee than the
GT she sent to Bob. Charlie has no idea that Bob exists, because he gets a
valid UTXO. Bob can try to publish the GT, but if Alice crafts the fees
right, the TX to Charlie will be confirmed first. Alice now has goods from
both Bob and Charlie, and has only paid one of them. She has is able to
double spend because: (1) the gossip network you describe for sabu only
protects people if everyone is on sabu and playing by the rules, it does
not prevent spending outside of sabu; and (2) there is nothing encumbering
the onchain UTXO and preventing it from being spent outside of a sabu
payment.
The reason people keep brining up Lightning is because Lightning solves
this problem by having a channel-open involve locking funds in a 2-of-2
multisig, preventing them from being spent outside of lightning until the
channel is torn down.
If there is nothing stopping someone from spending onchain funds outside of
the context of your system, then your system does not prevent double spends.
Hope that explanation helps.
Alex
On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > What prevents the creditor from signing a transaction that is neither a
> valid MT nor a GT?
> Please stop comparing Sabu and Lightning. Otherwise, it won't let you
> true understanding of Sabu.
> In Sabu protocol, only the issuer (the UTXO owner) can sign the
> transaction and decide how much money goes to whom. The engaged UTXO(s)
> belonged to issuer and the creditor never put UTXO in transaction, thus
> never can sign the transaction because he has no ownership on the used
> UTXOs.
> As I already wrote in paper, the issuer creates and signs a transaction
> and delivers it to creditor(s). If a creditor intends to send all or
> part of his money to another person (AKA spending his money), he will
> ask for a new signed transaction from issuer, in which a part of his
> credit will transfer to another creditor.
>
> The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of
> doc-watchers which maybe it was the cause you always compare it to
> Lightning.
> I am not presenting lightning neither condemning it.
> I am presenting Sabu protocol.
> Please let concentrate on how Sabu works or not works.
>
>
>
> On 2021-06-28 15:28, ZmnSCPxj wrote:
> > Good morning Raymo,
> >
> >> Hi ZmnSCPxj,
> >>
> >> Why you get the signal “trust the Gazin wallet”?
> >> Sabu is a protocol and the Gazin wallet will be an implementation of
> >> that protocol. We will implement it in react-native language to support
> >> both Android and iPhone. Of course it will be open source and GPL3.
> >> Here is the repository and yet is empty :)
> >> https://github.com/raymaot/Gazin
> >>
> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu
> >> will be far better than Lightning.
> >> Can’t you see the fact that in Sabu you do not need open and close
> >> channels ever? Can you imagine only this feature how dramatically
> >> decrease the transactions cost and how increase the distribution of
> >> nodes and improve privacy level? it makes every mobile wallet act like a
> >> lightning network.
> >> Did you note the fact that in Sabu protocol there is no routing? And the
> >> only people knew about a transaction are issuer and creditor? No one
> >> else won’t be aware of transactions and million transactions per second
> >> can be sent and received and repeal dynamically without any footprint on
> >> any DLT?
> >>
> >> The English is not my mother language and probably my paper is not a
> >> smooth and easy to read paper, but these are not good excuse to not even
> >> reading a technical paper carefully and before understanding it or at
> >> least trying to understanding it start to complaining.
> >
> >
> > What prevents the creditor from signing a transaction that is neither
> > a valid MT nor a GT?
> >
> > Nothing.
> >
> > In Lightning, sure one side can sign a transaction that is not a valid
> > commitment transaction, but good luck getting the other side to *also*
> > sign the transaction; it will not.
> > Thus, you need n-of-n.
> >
> > 1-of-1 is simply not secure, full stop, you need to redesign the whole
> > thing to use *at least* 2-of-2.
> > At which point you will have reinvented Lightning.
> >
> > Otherwise, you are simply trusting that the wallet is implemented
> > correctly, and in particular, that any creditor will not simply insert
> > code in your open-source software to sign invalid transactions.
> >
> > With a 1-of-1, any invalid-in-Sabu transaction can still be valid in
> > the Bitcoin blockchain layer, thus the scheme is simply insecure.
> >
> > Features are meaningless without this kind of basic trust-minimization
> security.
> >
> > Regards,
> > ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210628/2de6601e/attachment-0001.html>

2023-06-07 22:54:52

- reply

📅 Original date posted:2021-06-18
📝 Original message:A few questions/comments:
Why is there a 10 sat fee on each tx? Where does that fee go?
I don’t think this design sufficiently protects against double spends by
the “issuer” (the person who actually has the UTXO). Your guarantee tx
mechanism only really covers the case where someone tries to double spend
part of a UTXO balance (in other words, if the penalty lost is less than
the value gained by doing a double spend, its worth it to double spend, and
in a world where you’re passing around digital IOUs, it’s easy to make it
worth it). Later in the post, you mention that there will be a p2p network
to gossip fund transfers and that will prevent an issuer from double
spending. The problem there is that network latency is non-zero, large
network partitions are both real and common, and nodes can come and go
anytime (hardware failure, power failure, network partition healing, just
because they feel like it, etc). Different nodes on the network might hear
about different, conflicting transactions. Nodes will need a way to all
come to consensus on what the right set of “sent notes” is. I think you
will end up reinventing a lot of the problems solved by bitcoin.
Why did you pick email as the RPC mechanism to transfer these notes? Email
is going to add variable amounts of latency and things like spam filters
will cause issues.
Alex
On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> for very small transactions, this seems to make a hell of a lot of sense.
>
> it's like lightning, but with no limits, no routing protocols...
> everything is guaranteed by relative fees and the cost-of-theft.
>
> pretty cool.
>
> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi,
> > I have a proposal for improve Bitcoin TPS and privacy, here is the post.
> >
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> > https://bitcointalk.org/index.php?topic=5344020.0
> > Can you please read it and share your idea about it.
> >
> > Cheers
> > Raymo
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210618/00874202/attachment.html>