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

[Alex Schoof via bitcoin-dev]

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@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@lists.linuxfoundation.org
> 

Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Alex Schoof via bitcoin-dev]

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

Re: [bitcoin-dev] CTV dramatically improves DLCs

[Alex Schoof via bitcoin-dev]

> 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@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  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
> ` CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with ` 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 
> 
>
>
> On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
> bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 


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

Re: [bitcoin-dev] CTV BIP review

[Alex Schoof via bitcoin-dev]

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@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 
> 
>
>
> On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@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.
>>
>> 

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

[Alex Schoof via bitcoin-dev]

> 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@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@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@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
>


-- 


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

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

[Alex Schoof via bitcoin-dev]

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  wrote:

> On Thu, Dec 09, 2021 at 09:49:11AM +, Christian Moss wrote:
> > p...@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-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-- 


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

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Alex Schoof via bitcoin-dev]

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@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,
> > 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Alex Schoof via bitcoin-dev]

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@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
>  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@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
>
-- 


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