Nostr notes by

📅 Original date posted:2023-08-21 🗒️ Summary of this ...

2023-08-22T16:20:57+02:00

In reply to nevent1q…dtj6
_________________________

📅 Original date posted:2023-08-21
🗒️ Summary of this message: Ryan envisions a system where there is no cryptographic proof involved in validating transactions, which contradicts the idea of fraud proof. This reliance on trusted entities and the ability to choose different sets of validators could lead to consensus failures. Ruben raises concerns about data availability and the potential issues it may cause.
📝 Original message:
Hi Ryan,

>As I envision it, there is no cryptographic proof involved at all.

That seems to directly contradict your previous message where you stated
"[t]hey transmit invalid transactions or blocks". This transmission you
alluded to is basically a (non-optimized) fraud proof, and it assumes that
this data is actually available (unsafe assumption).

If you envision that this step is not actually needed, then users are
essentially never validating and merely relying on a set of trusted
entities. Furthermore, the idea that everyone can just pick their own set
of validators is antithetical to consensus. What if my set of validators
disagrees with your set of validators? Now one of us will reject the
Bitcoin block with the peg-out while the other will not, causing sidechain
consensus failure to directly affect the mainchain.

Cheers,
Ruben

On Sat, Aug 19, 2023 at 8:58 PM <ryan at breen.xyz> wrote:

> Thank you for the feedback, Ruben. I have a question.
>
> Could you please clarify what qualifies as a fraud proof in this concept?
> As I envision it, there is no cryptographic proof involved at all.
>
> In the context of a Sentinel chain, the sidechain's full nodes monitor
> Bitcoin mempools and blocks for withdrawals that violate the rules of the
> sidechain's consensus (such as thefts or incorrect balances). When the
> sidechain's full nodes detect an invalid withdrawal on Bitcoin, they
> publish a signed attestation to a public broadcast network (Nostr in this
> case). Participating Bitcoin full nodes and miners monitor the network for
> these attestations and subsequently reject the offending transactions. The
> process doesn't involve the presentation of proof because it's a
> distributed trust relationship.
>
> While Bitcoin full nodes could decide to operate their own sidechain
> nodes, we aim not to make this a requirement (addressing the long-standing
> sidechain dilemma). Bitcoin full nodes and miners wishing to participate
> can instead choose a distributed trust network comprising operators of
> sidechain full nodes that they trust. For instance, if they decide to
> follow 100 well-respected sidechain node operators, they might collectively
> agree that if 75 of them issue an attestation indicating that a transaction
> violates sidechain withdrawal rules, then that transaction should be deemed
> invalid by their node. Withdrawals are assumed valid if no public
> attestations are present.
>
> Furthermore, I'm uncertain about what potential data availability issue
> that might arise from this. Since there are no alterations to Bitcoin
> Core's validation logic, when a full node operator starts a new node from
> the genesis block, they will validate the proof of work of the longest
> chain and remain blissfully unaware that the transactions within the blocks
> are even associated with a sidechain.
>
> On Aug 19, 2023, at 10:35 AM, Ruben Somsen <rsomsen at gmail.com> wrote:
>
> Hi Ryan,
>
> Thanks for taking the time to write a proposal. As is often the case,
> these ideas aren't actually as novel as you might think. What you describe
> here is known as "fraud proofs". The crucial problem it doesn't address is
> "data availability".
>
> The general idea behind fraud proofs is that if you commit to every
> computational step (note Bitcoin currently doesn't, but could), anyone can
> succinctly reveal erroneous steps (e.g. 1+1=3), thus convincing everyone
> the state transition (i.e. block) is invalid. This works if a bunch of
> people have all the data and are willing to construct and spread the fraud
> proofs, but what if nobody has the data?
>
> When someone claims data is unavailable, the only way to verify this claim
> is by downloading the data. You can't just ban this peer for false claims
> either, since the data might have actually been unavailable when the claim
> was made but then became available. In essence this means malicious peers
> can cause you to download all data, meaning you effectively haven't saved
> any bandwidth.
>
> It should be noted that fraud proofs could still reduce the need for
> computation (i.e. you download all data, but only verify the parts for
> which you receive fraud notifications), so it can still provide some form
> of scaling.
>
> As a bit of history, fraud proofs were actually briefly considered for
> inclusion into segwit, but were abandoned due to the data availability
> issue:
> https://bitcoincore.org/en/2016/01/26/segwit-benefits/#update-2016-10-19
>
> And finally, there is a way to address the data availability issue, which
> I describe here (PoW fraud proofs/softchains, though note I am currently of
> the opinion it's better used for low-bandwidth mainchain nodes instead of
> for sidechains):
> https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1
>
> In theory you can also do data availability sampling through the use of
> erasure codes, but that gets very complex and brittle.
>
> Hope this helps.
>
> Cheers,
> Ruben
>
> On Sat, Aug 19, 2023 at 4:29 PM Ryan Breen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Recent discussions on social media regarding drivechains have prompted me
>> to consider the implementation of a two-way sidechain peg within the
>> Bitcoin protocol. I would like to propose what I believe may be a novel
>> solution to this issue.
>>
>> I have previously written about here on my blog:
>> https://ursus.camp/bitcoin/2023/08/10/sidechains.html
>> And here is the Stacker News discussion:
>> https://stacker.news/items/222480
>>
>> Nevertheless, I will hit the high points of the concept here:
>>
>> The most challenging problem that BIP-300 aims to address is how to
>> establish a two-way peg without involving a multisig federation and without
>> requiring miners and full nodes to possess knowledge about the sidechain or
>> run a sidechain node. This is, in fact, a very difficult nut to crack.
>>
>> The method adopted by BIP-300 involves conducting sidechain withdrawals
>> directly through the miners. To prevent miners from engaging in theft, the
>> proposal mandates a three-month period for peg-outs, during which all
>> miners vote on the peg-out. The intention here is to allow the community to
>> respond in the event of an incorrect peg-out or theft. The miners are
>> expected to be responsive to community pressure and make the correct
>> decisions. To streamline this process of social consensus, withdrawals are
>> grouped into one large bundle per three month period.
>>
>> Despite criticisms of this proposal, I find it to be a viable and likely
>> effective solution. After all, Bitcoin's underlying mechanism is
>> fundamentally rooted in social consensus, with the only question being the
>> extent of automation. Nonetheless, I believe we now possess tools that can
>> improve this process, leading to the concept of Sentinel chains.
>>
>> The core idea is that sidechain nodes function as Sentinels, notifying
>> full nodes of thefts via a secondary network. These sidechain nodes monitor
>> the current state of Bitcoin blocks and mempool transactions, actively
>> searching for peg-outs that contravene sidechain consensus in order to
>> steal funds. They transmit invalid transactions or blocks to public Nostr
>> servers. Bitcoin full nodes wishing to partake in sidechain consensus can
>> run a small daemon alongside Bitcoin Core. This daemon can monitor public
>> Nostr nodes for messages about invalid transactions and then instruct
>> Bitcoin Core, via RPC calls, to ignore and not forward those invalid
>> transactions.
>>
>> Full nodes can choose any group of individuals or organizations to
>> receive updates from Nostr. For instance, a full node might choose to trust
>> a collective of 100 sidechain nodes consisting of a mix of prominent
>> companies and individuals in the sidechain's sphere. Rather than relying on
>> a single trusted group, full nodes form their own decentralized web of
>> trust.
>>
>> This reverses the conventional model of two-way pegged sidechains.
>> Instead of requiring nodes to monitor sidechains, sidechains now monitor
>> nodes. In this sense, it is akin to drivechains, with the difference being
>> that peg-outs could be instantaneous and individual, without the need for
>> the three-month gradual social consensus. Furthermore, a single daemon can
>> be configured to monitor notifications from any number of Sentinel chains,
>> rendering this solution highly scalable for numerous sidechains.
>>
>> In summary, drivechains:
>>
>> - Require an initial consensus soft fork
>> - Treat each new sidechain as a miner-activated soft fork (easier to
>> deploy but more centralized)
>> - Feature withdrawals occurring in three-month periods
>> - Involve withdrawals in bundles
>> - Exclude Bitcoin full nodes from participation in sidechain consensus
>> - Are currently production-ready
>>
>> Sentinel chains:
>>
>> - Require no initial soft fork of any kind
>> - Permit each new sidechain to be miner-activated OR user-activated (more
>> challenging to deploy but more decentralized)
>> - Allow instantaneous withdrawals
>> - Facilitate individual withdrawals
>> - Enable Bitcoin full nodes to engage in consensus
>> - Are only at the concept stage
>>
>> Sentinel chains could potentially offer substantial advantages over other
>> forms of two-way pegs, primarily in terms of speed and efficiency of
>> consensus. Moreover, they align more closely with Bitcoin's principles by
>> ensuring that power remains within the realm of full nodes. Lastly, they
>> shield Core-only users from potential bug consequences stemming from
>> consensus changes directly implemented in Bitcoin Core, possibly fulfilling
>> the long-awaited promise of a fully opt-in soft fork.
>>
>>
>> Ryan Breen
>> Twitter: ursuscamp
>> Email: ryan @ breen.xyz
>> Web: https://ursus.camp
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230822/c7aa16d5/attachment-0001.html>;

📅 Original date posted:2022-04-07 📝 Original message: Hi ...

2023-06-09T15:05:44+02:00

In reply to nevent1q…mhzl
_________________________

📅 Original date posted:2022-04-07
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220407/88044966/attachment.html>;

📅 Original date posted:2022-10-18 📝 Original message:Hi ...

2023-06-08T01:14:05+02:00

In reply to nevent1q…ycrr
_________________________

📅 Original date posted:2022-10-18
📝 Original message:Hi Rijndael,

I think your thoughts are pretty much compatible with this proposal, as
what I'm describing (the recipient signing their keys) is also essentially
a form of authentication.

It's a good observation that in general this makes the communication of
addresses more secure. I do wish to re-emphasize Bryan's remark that you
still need to ensure the pubkey itself is securely communicated.

>depending on the setup, this could be that the address server also has the
Address Authentication privkey for bob, or it could be that bob gets some
callback or notification, or that bob has pre-signed a batch of addresses

In my opinion the only meaningful distinction is whether Bob runs the
Trustless Address Server himself (full privacy) or not. In either case I
see no reason to diverge from the model where Bob deposits a batch of
signed keys to the server, ensuring that no malicious addresses can be
handed out.

Note I discussed the Trustless Address Server design in the first 20
minutes of this podcast:
https://twitter.com/bitcoinoptech/status/1580573594656333825

And I also brought it up in my presentation at Tabconf last Saturday, but
that video isn't online yet.

Cheers,
Ruben

On Tue, Oct 18, 2022 at 2:07 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unbeknownst to them, the clipboard contents have been replaced with an
>> address controlled by some bad actor.
>>
> [snip]
>
>> Now imagine instead that the wallet has some address book with a pubkey
>> for each recipient the user wants to send bitcoin to.
>>
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/090a0721/attachment.html>;

📅 Original date posted:2022-09-29 📝 Original message:Hi ...

2023-06-08T01:13:49+02:00

In reply to nevent1q…xw4y
_________________________

📅 Original date posted:2022-09-29
📝 Original message:Hi Bastien,

>The other change mentioned (making OP_TRUE standard and allowing outputs
that are below dust) can be added later, as those won't be standard until
we start allowing them, so there shouldn't be any backwards-compatibility
issue with postponing this change. But maybe it's still worth having from
the get-go, even though it may take a bit more time? Again, I'm curious to
have other people's opinion here

I'm sensitive to not wanting to overload the current discussion but this
also interests me, provided it can be done in a way that is acceptable
(i.e. minimizing the potential UTXO set impact). It would solve a big cost
issue in my spacechains design if transactions could be 0 fees and have a 0
sat output that could be used in order to pay all the fees with CPFP.

My current view is that a tx containing a single 0 sat OP_TRUE output
should only get relayed if it is a package where the OP_TRUE output is
currently being spent in a way that increases the overall fee rate. But
even then, one theoretical edge case remains:
- Another CPFP tx can feebump the package on a different (non-OP_TRUE)
output with an even higher fee rate
- Subsequently, the tx that is spending the OP_TRUE might fall out of the
mempool if the mempool fee rate rises
- This could cause the 0 sat output to enter the UTXO set (specifically,
rational miners wouldn't refuse to mine such a tx)

It doesn't seem like this would happen much in practice (nor is there an
incentive to do it on purpose), but the chance isn't 0.

Cheers,
Ruben

On Thu, Sep 29, 2022 at 4:50 PM Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > Right, good catch, this does require new logic to handle this case.
> As Gloria points out, this should be doable, and is definitely worth
> adding (those CSV 1 on every other output are really hacky, glad to
> find a way to get rid of them).
>
> For the record, it turns out ephemeral anchors + v3 solves this already,
> as the anchor must be spent, and the parent tx may only have one child.
> Somehow I missed this implication for a few months. It's great news if we
> can directly source fees from any output claimable, including HTLCs!
>
> On Thu, Sep 29, 2022 at 5:15 AM Bastien TEINTURIER <bastien at acinq.fr>
> wrote:
>
>> Hi Gloria, Greg,
>>
>> > I interpret most of the discussion around limitations as ideas for
>> > future improvements rather than criticisms of the proposal
>>
>> As far as I'm concerned, definitely!
>>
>> My current understanding is that the main change/improvement that would
>> make sense here is restricting the whole v3 package's size (instead of
>> just the child) via committing to a specific value in the taproot annex
>> (also note that it's probably not just the v3 package's size, it should
>> be the whole unconfirmed package including potential v2 unconfirmed
>> ancestors).
>>
>> While I think this would be very valuable and would like to see this
>> happen, I believe that can be done in a second, separate step since this
>> would make relay policy stricter (some v3 transactions that previously
>> propagated wouldn't propagate under this new rule). As long as you are
>> able to find a path to miners through upgraded peers that use this annex
>> approach, you should be able to resolve ACP pinning issues?
>>
>> I'm curious to know how other people feel about that: is it ok to do
>> later or should we try to implement this for the first release of v3
>> transactions?
>>
>> The other change mentioned (making OP_TRUE standard and allowing outputs
>> that are below dust) can be added later, as those won't be standard until
>> we start allowing them, so there shouldn't be any backwards-compatibility
>> issue with postponing this change. But maybe it's still worth having from
>> the get-go, even though it may take a bit more time? Again, I'm curious to
>> have other people's opinion here, I'd be happy to get all of those
>> directly
>> in the first release of v3 transactions, but I don't know how much
>> implementation will have to go into that.
>>
>> > For clarification, package RBF is ParentTx*s*(plural), and
>> ChildTx(singular),
>> > so it might be a bit more complicated than we're thinking
>>
>> Right, good catch, this does require new logic to handle this case.
>> As Gloria points out, this should be doable, and is definitely worth
>> adding (those CSV 1 on every other output are really hacky, glad to
>> find a way to get rid of them).
>>
>> Thanks,
>> Bastien
>>
>> Le lun. 26 sept. 2022 à 18:48, Gloria Zhao <gloriajzhao at gmail.com> a
>> écrit :
>>
>>> Hi Greg, Antoine, Bastien,
>>>
>>> Thanks very much for the feedback! I interpret most of the discussion
>>> around limitations as ideas for future improvements rather than criticisms
>>> of the proposal (please correct me if I'm wrong). I'll try to respond to as
>>> much as possible.
>>>
>>> Also I realize that I didn't contextualize this proposal clearly enough;
>>> it is very tailored for LN Penalty and definitely doesn't close all pinning
>>> attacks possible (sorry for confusing anyone). I also agree that some bits
>>> can be a little ugly or tack-on; I would definitely prefer a comprehensive
>>> RBF revamp to fix all our problems and enable other fee-bumping strategies
>>> such as
>>> sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broadcast. I
>>> was hoping to get some ideas with the "RBF Improvements" post in January,
>>> but it doesn't seem like we're much closer to a workable proposal. I think
>>> this is a minimally-invasive step that works for Lightning today, a small
>>> fix similar to CPFP carve out.
>>>
>>> > As you likely know from previous discussions the biggest scenario this
>>> does not fix in my estimation is ANYONECANPAY situations. If the parent
>>> transaction can be "inflated" by tacking on additional inputs, this means
>>> the total weight of the parent tx lowers the effective feerate of the
>>> package.
>>>
>>> (For more context to other readers I wrote an explanation for this in
>>> "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this
>>> unfortunately doesn't fix any of the existing pinning attacks for single
>>> transaction RBF but also doesn't make them worse. This boils down to adding
>>> an incentive compatibility rule that ensures you can't replace a
>>> transaction with something that will confirm slower. Package RBF has an
>>> ancestor feerate-based rule for this (note it is quite conservative and not
>>> perfect).
>>>
>>> So in the scenario above with the "inflated" parent that was signed ACP,
>>> the replacement would be rejected because the package ancestor feerate is
>>> lower than the feerate of what is being replaced. But it is imperfect
>>> (explained below) and thus I wouldn't recommend it for single transaction
>>> replacement. So that attack still exists for single transactions, yes.
>>>
>>> The strategy of using ACP to bring-your-own-fees has its own challenges
>>> but hopefully has no current use cases as you say. AFAIK LN Penalty is not
>>> affected by this since it doesn't use ACP, though obviously I agree we
>>> should fix it for the future.
>>>
>>> So when I said "this is intended for fee-bumping presigned txns in
>>> contracting protocols," I should have said "this is intended for
>>> fee-bumping presigned txns specifically using CPFP and anchor outputs."
>>> Apologies for forgetting to contextualize, I've been sitting on this for
>>> too long.
>>>
>>> > The other scenario it doesn't really fix is where HTLC/commitment-like
>>> transactions are being resolved in a batch, but due to relative time
>>> constraints, you may want to accelerate some and not others. Now you must
>>> pay higher rates to replace all of the transaction bumps. This is a
>>> "self-pin" and "get good at utxos noob" type problem, but it's something
>>> that axing rule#3 in favor of a Replace-by-ancestor-feerate system would
>>> get us.
>>>
>>> I understand you to mean "if you don't have enough UTXOs and you're
>>> forced to batch-bump, you over-pay because you need to bring them all to
>>> the highest target feerate." Isn't this kind of separate, wallet-related
>>> problem? Contracting or not, surely every wallet needs to have enough UTXOs
>>> to not batch transactions that shouldn't be batched... I don't see how a
>>> replace-by-ancestor-feerate policy would make any difference for this?
>>>
>>> Also in general I'd like to reiterate that ancestor feerate is not a
>>> panacea to all our RBF incentive compatibility concerns. Like individual
>>> feerate, unless we run the mining algorithm, it cannot tell us exactly how
>>> quickly this transaction would be mined.
>>>
>>> We're estimating the incentive compatibility of the original
>>> transaction(s) and replacement transaction(s), with the goal of not letting
>>> a transaction replace something that would have been more incentive
>>> compatible to mine. As such, we don't want to overestimate how good the
>>> replacement is, and we don't want to underestimate how good the original
>>> transactions are. This rule "The minimum between package feerate and
>>> ancestor feerate of the child is not lower than the individual feerates of
>>> all directly conflicting transactions and the ancestor feerates of all
>>> original transactions" is a conservative estimate.
>>>
>>> > Would kind of be nice if package RBF would detect a "sibling output
>>> spend" conflict, and knock it out of the mempool via the other replacement
>>> rules? Getting rid of the requirement to 1 block csv lock every output
>>> would be quite nice from a smart contracting composability point of view.
>>>
>>> Interesting, so when a transaction hits a mempool tx's descendant limit,
>>> we consider evicting one of its descendants in favor of this transaction,
>>> based on the RBF rules.
>>> Cool idea! After chewing on this for a bit, I think this *also* just
>>> boils down to the fact that RBF should require replacements to be better
>>> mining candidates. As in, if we added this policy and it can make us evict
>>> the sibling and accept a transaction with a bunch of low-feerate ancestor
>>> junk, it would be a new pinning vector.
>>>
>>> > If you're a miner and you receive a non-V3, second descendant of an
>>> unconfirmed V3 transaction, if the offered fee is in the top mempool
>>> backlog, I think you would have an interest to accept such a transaction.
>>>
>>> > So I'm not sure if those two rules are compatible with miners
>>> incentives...
>>>
>>> The same argument can be made for the 26th descendant of a mempool
>>> transaction; it's also not entirely incentive-compatible to reject it, but
>>> that is not the *only* design goal in mempool policy. Of course, the
>>> difference here is that the 25-descendant limit rule is a sensible DoS
>>> protection, while this 1-descendant limit rule is more of a "help the
>>> Bitcoin ecosystem" policy, just like CPFP carve-out, dust limit, etc. I can
>>> of course understand why not everyone would be in favor of this, but I do
>>> think it's worth it.
>>>
>>> > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>> > > larger than 1000 virtual bytes.
>>>
>>> > If I understand correctly the 1000 vb upper bound rational, it would
>>> be to constraint the pinning counterparty to attach a high fee to a child
>>> due to the limited size, if they would like this transaction to be stuck in
>>> the network mempools. By doing so this child has high odds to confirm.
>>>
>>> Yeah exactly, the "Rule 3 pin" is done by adding a child that's high-fee
>>> (so you have to pay that much to evict it). Because they *don't* want this
>>> tx to confirm, normally, this child would be really large. If they only
>>> have 1000vB for the child, they can't increase the replacement cost without
>>> also fee-bumping the transaction to make it confirm faster.
>>>
>>> > As of today, I think yes you can already fingerprint LN transactions
>>> on the spec-defined amount value of the anchor outputs, 330 sats. There is
>>> always one of them on post-anchor commitment transactions. And sadly I
>>> would say we'll always have tricky fingerprints leaking from unilateral LN
>>> closures such as HTLC/PTLC timelocks...
>>>
>>> > I agree with you, this isn't worse than today, unilateral closes will
>>> probably always be identifiable on-chain.
>>>
>>> Great to hear that there is no privacy worsening!
>>>
>>> Best,
>>> Gloria
>>>
>>> On Mon, Sep 26, 2022 at 5:02 PM Greg Sanders <gsanders87 at gmail.com>
>>> wrote:
>>>
>>>> Bastien,
>>>>
>>>> > This may be already covered by the current package RBF logic, in that
>>>> scenario we are simply replacing [ParentTx, ChildTx1] with
>>>> [ParentTx, ChildTx2] that pays more fees, right?
>>>>
>>>> For clarification, package RBF is ParentTx*s*(plural), and
>>>> ChildTx(singular), so it might be a bit more complicated than we're
>>>> thinking, and currently the V3 proposal would first de-duplicate the
>>>> ParentTx based on what is in the mempool, then look at the "rest" of the
>>>> transactions as a package, then individually. Not the same, not sure how
>>>> different. I'll defer to experts.
>>>>
>>>> Best,
>>>> Greg
>>>>
>>>> On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Thanks Gloria for this great post.
>>>>>
>>>>> This is very valuable work for L2 contracts, and will greatly improve
>>>>> their security model.
>>>>>
>>>>> > "Only 1 anchor output? What if I need to bump counterparty's
>>>>> commitment tx in mempool?"
>>>>> > You won't need to fee-bump a counterparty's commitment tx using CPFP.
>>>>> > You would just package RBF it by attaching a high-feerate child to
>>>>> > your commitment tx.
>>>>>
>>>>> Note that we can also very easily make that single anchor spendable by
>>>>> both participants (or even anyone), so if you see your counterparty's
>>>>> commitment in your mempool, you can bump it without publishing your
>>>>> own commitment, which is quite desirable (your own commitment tx has
>>>>> CSV delays on your outputs, whereas your counterparty's commitment tx
>>>>> doesn't).
>>>>>
>>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>> transactions based on nVersion?"
>>>>>
>>>>> I agree with you, this isn't worse than today, unilateral closes will
>>>>> probably always be identifiable on-chain.
>>>>>
>>>>> > Would kind of be nice if package RBF would detect a "sibling output
>>>>> spend"
>>>>> > conflict, and knock it out of the mempool via the other replacement
>>>>> rules?
>>>>> > Getting rid of the requirement to 1 block csv lock every output
>>>>> would be
>>>>> > quite nice from a smart contracting composability point of view.
>>>>>
>>>>> +1, that would be very neat!
>>>>>
>>>>> This may be already covered by the current package RBF logic, in that
>>>>> scenario we are simply replacing [ParentTx, ChildTx1] with
>>>>> [ParentTx, ChildTx2] that pays more fees, right?
>>>>>
>>>>> > 1) I do think that we should seriously consider allowing OP_TRUE to
>>>>> become
>>>>> > a standard script type as part of this policy update. If pinning is
>>>>> solved,
>>>>> > then there's no reason to require all those extra bytes for
>>>>> "binding" an
>>>>> > anchor to a specific wallet/user. We can save quite a few bytes by
>>>>> having
>>>>> > the input be empty of witness data.
>>>>> > 2) If we allow for a single dust-value(0 on up) output which is
>>>>> immediately
>>>>> > spent by the package, anchors become even easier to to design. No
>>>>> value has
>>>>> > to be "sapped" from contract participants to make an anchor output.
>>>>> There's
>>>>> > more complications for this, such as making sure the parent
>>>>> transaction is
>>>>> > dropped if the child spend is dropped, but maybe it's worth the
>>>>> squeeze.
>>>>>
>>>>> I also think both of these could be quite useful. This would probably
>>>>> always
>>>>> be used in combination with a parent transaction that pays 0 fees, so
>>>>> the
>>>>> 0-value output would always be spent in the same block.
>>>>>
>>>>> But this means we could end up with 0-value outputs in the utxo set,
>>>>> if for
>>>>> some reason the parent tx is CPFP-ed via another output than the
>>>>> 0-value one,
>>>>> which would be a utxo set bloat issue. But I'd argue that we're
>>>>> probably
>>>>> already creating utxo set bloat with the 330 sat anchor outputs
>>>>> (especially
>>>>> since we use two of them, but only one is usually spent), so it would
>>>>> probably be *better* than what we're doing today.
>>>>>
>>>>> Thanks,
>>>>> Bastien
>>>>>
>>>>> Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev <
>>>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>>>
>>>>>> Hi Gloria,
>>>>>>
>>>>>> Thanks for the progress on package RBF, few early questions.
>>>>>>
>>>>>> > 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>>>>>>
>>>>>> > 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>>>>>>
>>>>>> If you're a miner and you receive a non-V3, second descendant of an
>>>>>> unconfirmed V3 transaction, if the offered fee is in the top mempool
>>>>>> backlog, I think you would have an interest to accept such a transaction.
>>>>>>
>>>>>> So I'm not sure if those two rules are compatible with miners
>>>>>> incentives...
>>>>>>
>>>>>> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>>>> > larger than 1000 virtual bytes.
>>>>>>
>>>>>> If I understand correctly the 1000 vb upper bound rational, it would
>>>>>> be to constraint the pinning counterparty to attach a high fee to a child
>>>>>> due to the limited size, if they would like this transaction to be stuck in
>>>>>> the network mempools. By doing so this child has high odds to confirm.
>>>>>>
>>>>>> I still wonder if this compatible with miner incentives in period of
>>>>>> empty mempools, in the sense that if you've already a V3 transaction of
>>>>>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement
>>>>>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the former
>>>>>> should be conserved.
>>>>>>
>>>>>> (That said, the hard thing with any replacement strategy we might
>>>>>> evict a parent transaction *now* to which is attached a high-feerate child
>>>>>> *latter* making for a utxo considered the best ancestor set. Maybe in the
>>>>>> long-term miners should keep every transaction ever accepted...)
>>>>>>
>>>>>> > (Lower bound) the smaller this limit, the fewer UTXOs a child may
>>>>>> use
>>>>>> > to fund this fee-bump. For example, only allowing the V3 child to
>>>>>> have
>>>>>> > 2 inputs would require L2 protocols to manage a wallet with
>>>>>> high-value
>>>>>> > UTXOs and make batched fee-bumping impossible. However, as the
>>>>>> > fee-bumping child only needs to fund fees (as opposed to payments),
>>>>>> > just a few UTXOs should suffice.
>>>>>>
>>>>>> Reminder for L2 devs, batched fee-bumping of time-sensitive
>>>>>> confirmations of commitment transactions is unsafe, as the counterparty
>>>>>> could enter in a "cat-and-mouse" game to replace one of the batch element
>>>>>> at each block to delay confirmation of the remaining elements in the batch,
>>>>>> I think.
>>>>>>
>>>>>> On the other hand, I wonder if we wouldn't want a higher bound. LN
>>>>>> wallets are likely to have one big UTXO in their fee-bumping reserve pool,
>>>>>> as the cost of acquiring UTXO is non-null and in the optimistic case, you
>>>>>> don't need to do unilateral closure. Let's say you close dozens of channels
>>>>>> at the same time, a UTXO pool management strategy might be to fan-out the
>>>>>> first spends UTXOs in N fan-out outputs ready to feed the remaining
>>>>>> in-flight channels.
>>>>>>
>>>>>> > 1. The rule around unconfirmed inputs was
>>>>>> > originally "A package may include new unconfirmed inputs, but the
>>>>>> > ancestor feerate of the child must be at least as high as the
>>>>>> ancestor
>>>>>> > feerates of every transaction being replaced."
>>>>>>
>>>>>> Note, I think we would like this new RBF rule to also apply to single
>>>>>> transaction package, e.g second-stage HTLC transactions, where a
>>>>>> counterparty pins a HTLC-preimage by abusing rule 3. In that case, the
>>>>>> honest LN node should be able to broadcast a "at least as high ancestor
>>>>>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is no
>>>>>> unconfirmed ancestor to replace, as the commitment transaction, whatever
>>>>>> the party it is originating from, should already be confirmed.
>>>>>>
>>>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>>> transactions based on nVersion?"
>>>>>>
>>>>>> As of today, I think yes you can already fingerprint LN transactions
>>>>>> on the spec-defined amount value of the anchor outputs, 330 sats. There is
>>>>>> always one of them on post-anchor commitment transactions. And sadly I
>>>>>> would say we'll always have tricky fingerprints leaking from unilateral LN
>>>>>> closures such as HTLC/PTLC timelocks...
>>>>>>
>>>>>> > "Can a V2 transaction replace a V3 transaction and vice versa?"
>>>>>>
>>>>>> IIUC, a V3 package could replace a V2 package, with the benefit of
>>>>>> the new package RBF rules applied. I think this would be a significant
>>>>>> advantage for LN, as for the current ~85k of opened channels, the old V2
>>>>>> states shouldn't be pinning vectors. Currently, commitment transactions
>>>>>> signal replaceability.
>>>>>>
>>>>>> Le ven. 23 sept. 2022 à 11:26, Gloria Zhao via bitcoin-dev <
>>>>>> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'm writing to propose a very simple set of mempool/transaction relay
>>>>>>> policies intended to aid L2/contract protocols. I realized that
>>>>>>> the previously proposed Package Mempool Accept package RBF [1]
>>>>>>> had a few remaining problems after digging into the RBF logic more
>>>>>>> [2].
>>>>>>> This additional set of policies solves them without requiring a huge
>>>>>>> RBF overhaul.
>>>>>>>
>>>>>>> I've written an implementation (and docs) for Bitcoin Core:
>>>>>>> https://github.com/bitcoin/bitcoin/pull/25038
>>>>>>>
>>>>>>> (You may notice that this proposal incorporates feedback on the PR -
>>>>>>> thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony Towns,
>>>>>>> and others.)
>>>>>>>
>>>>>>> If you are interested in using package RBF/relay to bump presigned
>>>>>>> transactions, I think you may be interested in reviewing this
>>>>>>> proposal.
>>>>>>> This should solve Rule 3 pinning and perhaps allow us
>>>>>>> to get rid of CPFP carve-out (yay!). I'm keen to hear if people find
>>>>>>> the 1-anchor-output, 1000vB child limit too restrictive. Also, if
>>>>>>> you find a
>>>>>>> pinning attack or something that makes it unusable for you, I would
>>>>>>> really really like to know.
>>>>>>>
>>>>>>> Note that transactions with nVersion=3 ("V3 transactions") are
>>>>>>> currently non-standard in Bitcoin Core. That means **anything that
>>>>>>> was
>>>>>>> standard before this policy change would still be standard
>>>>>>> afterwards.** If you don't want your transactions to be subject to
>>>>>>> these rules, just continue whatever you're doing and don't use
>>>>>>> nVersion=3. AFAICT this shouldn't break anything, but let me know if
>>>>>>> this would be disruptive for you?
>>>>>>>
>>>>>>> **New Policies:**
>>>>>>>
>>>>>>> This includes:
>>>>>>> - a set of additional policy rules applying to V3 transactions
>>>>>>> - modifications to package RBF rules
>>>>>>>
>>>>>>> **V3 transactions:**
>>>>>>>
>>>>>>> Existing standardness rules apply to V3 (e.g. min/max tx weight,
>>>>>>> standard output types, cleanstack, etc.). The following additional
>>>>>>> rules apply to V3:
>>>>>>>
>>>>>>> 1. A V3 transaction can be replaced, even if it does not signal
>>>>>>> BIP125
>>>>>>> replaceability. (It must also meet the other RBF rules around
>>>>>>> fees,
>>>>>>> etc. for replacement to happen).
>>>>>>>
>>>>>>> 2. Any descendant of an unconfirmed V3 transaction must also be V3.
>>>>>>>
>>>>>>> *Rationale*: Combined with Rule 1, this gives us the property of
>>>>>>> "inherited" replaceability signaling when descendants of unconfirmed
>>>>>>> transactions are created. Additionally, checking whether a
>>>>>>> transaction
>>>>>>> signals replaceability this way does not require mempool traversal,
>>>>>>> and does not change based on what transactions are mined. It also
>>>>>>> makes subsequent rules about descendant limits much easier to check.
>>>>>>>
>>>>>>> *Note*: The descendant of a *confirmed* V3 transaction does not need
>>>>>>> to be V3.
>>>>>>>
>>>>>>> 3. An unconfirmed V3 transaction cannot have more than 1 descendant.
>>>>>>>
>>>>>>> *Rationale*: (Upper bound) the larger the descendant limit, the more
>>>>>>> transactions may need to be replaced. This is a problematic pinning
>>>>>>> attack, i.e., a malicious counterparty prevents the transaction from
>>>>>>> being replaced by adding many descendant transactions that aren't
>>>>>>> fee-bumping.
>>>>>>>
>>>>>>> (Lower bound) at least 1 descendant is required to allow CPFP of the
>>>>>>> presigned transaction. The contract protocol can create presigned
>>>>>>> transactions paying 0 fees and 1 output for attaching a CPFP at
>>>>>>> broadcast time ("anchor output"). Without package RBF, multiple
>>>>>>> anchor
>>>>>>> outputs would be required to allow each counterparty to fee-bump any
>>>>>>> presigned transaction. With package RBF, since the presigned
>>>>>>> transactions can replace each other, 1 anchor output is sufficient.
>>>>>>>
>>>>>>> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
>>>>>>> larger than 1000 virtual bytes.
>>>>>>>
>>>>>>> *Rationale*: (Upper bound) the larger the descendant size limit, the
>>>>>>> more vbytes may need to be replaced. With default limits, if the
>>>>>>> child
>>>>>>> is e.g. 100,000vB, that might be an additional 100,000sats (at
>>>>>>> 1sat/vbyte) or more, depending on the feerate.
>>>>>>>
>>>>>>> (Lower bound) the smaller this limit, the fewer UTXOs a child may use
>>>>>>> to fund this fee-bump. For example, only allowing the V3 child to
>>>>>>> have
>>>>>>> 2 inputs would require L2 protocols to manage a wallet with
>>>>>>> high-value
>>>>>>> UTXOs and make batched fee-bumping impossible. However, as the
>>>>>>> fee-bumping child only needs to fund fees (as opposed to payments),
>>>>>>> just a few UTXOs should suffice.
>>>>>>>
>>>>>>> With a limit of 1000 virtual bytes, depending on the output types,
>>>>>>> the
>>>>>>> child can have 6-15 UTXOs, which should be enough to fund a fee-bump
>>>>>>> without requiring a carefully-managed UTXO pool. With 1000 virtual
>>>>>>> bytes as the descendant limit, the cost to replace a V3 transaction
>>>>>>> has much lower variance.
>>>>>>>
>>>>>>> *Rationale*: This makes the rule very easily "tacked on" to existing
>>>>>>> logic for policy and wallets. A transaction may be up to 100KvB on
>>>>>>> its
>>>>>>> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
>>>>>>> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction
>>>>>>> in the mempool is 100KvB, its descendant can only be 1000vB, even if
>>>>>>> the policy is 10KvB.
>>>>>>>
>>>>>>> **Package RBF modifications:**
>>>>>>>
>>>>>>> 1. The rule around unconfirmed inputs was
>>>>>>> originally "A package may include new unconfirmed inputs, but the
>>>>>>> ancestor feerate of the child must be at least as high as the
>>>>>>> ancestor
>>>>>>> feerates of every transaction being replaced."
>>>>>>>
>>>>>>> The package may still include new unconfirmed inputs. However,
>>>>>>> the new rule is modified to be "The minimum between package feerate
>>>>>>> and ancestor feerate of the child is not lower than the individual
>>>>>>> feerates of all directly conflicting transactions and the ancestor
>>>>>>> feerates of all original transactions."
>>>>>>>
>>>>>>> *Rationale*: We are attempting to ensure that the replacement
>>>>>>> transactions are not less incentive-compatible to mine. However, a
>>>>>>> package/transaction's ancestor feerate is not perfectly
>>>>>>> representative
>>>>>>> of its incentive compatibility; it may overestimate (some subset of
>>>>>>> the ancestors could be included by itself if it has other
>>>>>>> high-feerate
>>>>>>> descendants or are themselves higher feerate than this
>>>>>>> package/transaction). Instead, we use the minimum between the package
>>>>>>> feerate and ancestor feerate of the child as a more conservative
>>>>>>> value
>>>>>>> than what was proposed originally.
>>>>>>>
>>>>>>> 2. A new rule is added, requiring that all package transactions with
>>>>>>> mempool conflicts to be V3. This also means the "sponsoring"
>>>>>>> child transaction must be V3.
>>>>>>>
>>>>>>> *Note*: Combined with the V3 rules, this means the package must be
>>>>>>> a child-with-parents package. Since package validation is only
>>>>>>> attempted if the transactions do not pay sufficient fees to be
>>>>>>> accepted on their own, this effectively means that only V3
>>>>>>> transactions can pay to replace their ancestors' conflicts, and only
>>>>>>> V3 transactions' replacements may be paid for by a descendant.
>>>>>>>
>>>>>>> *Rationale*: The fee-related rules are economically rational for
>>>>>>> ancestor packages, but not necessarily other types of packages.
>>>>>>> A child-with-parents package is a type of ancestor package. It
>>>>>>> may be fine to allow any ancestor package, but it's more difficult
>>>>>>> to account for all of the possibilities. For example, it gets much
>>>>>>> harder to see that we're applying the descendant limits correctly if
>>>>>>> the package has a gnarly, many-generation, non-tree shape. I'm also
>>>>>>> not sure if this policy is 100% incentive-compatible if the sponsor
>>>>>>> is not a direct descendant of the sponsee.
>>>>>>>
>>>>>>> Please see doc/policy/version3_transactions.md and
>>>>>>> doc/policy/packages.md in the PR for the full set of rules.
>>>>>>>
>>>>>>> **Intended usage for LN:**
>>>>>>>
>>>>>>> Commitment transactions should be V3 and have 1 anchor output. They
>>>>>>> can be signed with 0 fees (or 1sat/vbyte) once package relay is
>>>>>>> deployed
>>>>>>> on a significant portion of the network. If the commitment tx must
>>>>>>> be broadcast, determine the desired feerate at broadcast time and
>>>>>>> spend the anchor output in a high feerate transaction. I'm going to
>>>>>>> call the broadcasted commitment tx "the parent" and the attached
>>>>>>> fee-bumping tx "the child."
>>>>>>>
>>>>>>> - This child must be V3.
>>>>>>> - This child must be at most 1000vB. Note this restricts the
>>>>>>> number of inputs you can use to fund the fee bump. Depending
>>>>>>> on the output types, this is around 6-15.
>>>>>>> - One child may fund fees for multiple commitment tx ("batched
>>>>>>> fee-bumping").
>>>>>>> - To do a second fee-bump to add more fees, replace the
>>>>>>> *child* with a higher-feerate tx. Do not try to attach a
>>>>>>> grandchild.
>>>>>>>
>>>>>>> Otherwise, never try to spend from an unconfirmed V3 transaction. The
>>>>>>> descendant limits for V3 transactions are very restrictive.
>>>>>>>
>>>>>>> **Expected Questions:**
>>>>>>>
>>>>>>> "Does this fix Rule 3 Pinning?"
>>>>>>> Yes. The V3 descendant limit restricts both you and your
>>>>>>> counterparty.
>>>>>>> Assuming nodes adopted this policy, you may reasonably assume that
>>>>>>> you
>>>>>>> only need to replace the commitment transaction + up to 1000vB.
>>>>>>>
>>>>>>> "Only 1 anchor output? What if I need to bump counterparty's
>>>>>>> commitment tx in mempool?"
>>>>>>> You won't need to fee-bump a counterparty's commitment tx using CPFP.
>>>>>>> You would just package RBF it by attaching a high-feerate child to
>>>>>>> your commitment tx.
>>>>>>>
>>>>>>> "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN
>>>>>>> transactions based on nVersion?"
>>>>>>> Indeed it may be unrealistic to assume V3 transactions will be in
>>>>>>> widespread use outside of L2. IIUC, unilateral closes are already
>>>>>>> obvious LN transactions because of the HTLC inputs. For e.g.
>>>>>>> cooperative closes and opens, I think it makes sense to continue
>>>>>>> using
>>>>>>> V2. So, unless I'm missing something, this shouldn't make it worse.
>>>>>>>
>>>>>>> "So a V3 transaction that doesn't signal BIP125 replaceability is
>>>>>>> replaceable? Is that a backward compatibility issue?"
>>>>>>> Yes it's replaceable. It's not an issue AFAICT because,
>>>>>>> under previous policy, the V3 transaction wouldn't have been
>>>>>>> in the mempool in the first place.
>>>>>>>
>>>>>>> "Can a V2 transaction replace a V3 transaction and vice versa?"
>>>>>>> Yes, otherwise someone can use V3 transactions to censor V2
>>>>>>> transactions spending shared inputs. Note if the
>>>>>>> original V3 transaction has an unconfirmed V3 parent, this would
>>>>>>> violate the "inherited V3" rule and would be rejected.
>>>>>>>
>>>>>>> Thanks for reading! Feedback and review would be much appreciated.
>>>>>>>
>>>>>>> [1]:
>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
>>>>>>> [2]:
>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
>>>>>>>
>>>>>>> Best,
>>>>>>> Gloria
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220930/a5096f54/attachment-0001.html>;

📅 Original date posted:2022-07-18 📝 Original message:Good ...

2023-06-08T01:11:55+02:00

In reply to nevent1q…tqta
_________________________

📅 Original date posted:2022-07-18
📝 Original message:Good evening ZmnSCPxj,

Interesting attempt.

>a * G + b * G + k * G

Unfortunately I don't think this qualifies as a commitment, since one could
trivially open the "commitment" to some uncommitted value x (e.g. a is set
to x and b is set to a+b-x). Perhaps you were thinking of Pedersen
commitments (a * G + b * H + k * J)?

Even if we fixed the above with some clever cryptography, the crucial
merkle sum tree property is missing, so "double spending" a burn becomes
possible. You also still run into the same atomicity issue, except the risk
is moved to the seller side, as the buyer could refuse to finalize the
purchase after the on-chain commitment was made by the seller. Arguably
this is worse, since generally only the seller has a reputation to lose,
not the buyer.

Cheers,
Ruben

On Mon, Jul 18, 2022 at 12:34 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Ruben and Veleslav,
>
> > Hi Veleslav,
> >
> > This is something I've been interested in.
> >
> >
> > What you need is a basic merkle sum tree (not sparse), so if e.g. you
> want to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx
> you can burn 100 sats and commit to a tree with four leaves, and the merkle
> proof contains the values. E.g. the rightmost leaf is 40 and has 30 as its
> neighbor, and moves up to a node of 70 which has 30 (=10+20) as its
> neighbor, totalling 100.
> >
> >
> > The leaf hash needs to commit to the intent/recipient of the burn, so
> that way you can't "double spend" the burn by reusing it for more than one
> purpose.
> >
> >
> > You could outsource the burn to an aggregating third party by paying
> them e.g. over LN but it won't be atomic, so they could walk away with your
> payment without actually following through with the burn (but presumably
> take a reputational hit).
>
> If LN switches to PTLCs (payment points/scalars), it may be possible to
> ensure that you only pay if they release an opening of the commitment.
>
> WARNING: THIS IS ROLL-YOUR-OWN-CRYPTO.
>
> Rather than commit using a Merkle tree, you can do a trick similar to what
> I came up with in `OP_EVICT`.
>
> Suppose there are two customers who want to commit scalars `a` and `b`,
> and the aggregating third party has a private key `k`.
> The sum commitment is then:
>
> a * G + b * G + k * G
>
> The opening to show that this commits to `a` is then:
>
> a, b * G + k * G, sign(b + k, a)
>
> ...where `sign(k, m)` means sign message `m` with the private key `k`.
> Similarly the opening for `b` is:
>
> b, a * G + k *G, sign(a + k, b)
>
> The ritual to purchase a proof goes this way:
>
> * Customer provides the scalar they want committed.
> * Aggregator service aggregates the scalars to get `a + b + ....` and adds
> their private key `k`.
> * Aggregator service reveals `(a + b + ... + k) * G` to customer.
> * Aggregator creates an onchain proof-of-burn to `(a + b + ... + k) * G`.
> * Everyone waits until the onchain proof-of-burn is confirmed deeply
> enough.
> * Aggregator creates the signatures for each opening for `a`, `b`,.... of
> the commitment.
> * Aggregator provides the corresponding `R` of each signature to each
> customer.
> * Customer computes `S = s * G` for their own signature that opens the
> commitment.
> * Customer offers a PTLC (i.e. pay for signature scheme) that pays in
> exchange for `s`.
> * Aggregator claims the PTLC, revealing the `s` for the signature.
> * Customer now has an opening of the commitment that is for their specific
> scalar.
>
> WARNING: I am not a cryptographer, I only portray one on bitcoin-dev.
> There may be cryptographic failures in the above scheme.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220719/5f0f8099/attachment.html>;

📅 Original date posted:2022-07-17 📝 Original message:Hi ...

2023-06-08T01:11:54+02:00

In reply to nevent1q…c4t0
_________________________

📅 Original date posted:2022-07-17
📝 Original message:Hi Veleslav,

This is something I've been interested in.

What you need is a basic merkle sum tree (not sparse), so if e.g. you want
to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you
can burn 100 sats and commit to a tree with four leaves, and the merkle
proof contains the values. E.g. the rightmost leaf is 40 and has 30 as its
neighbor, and moves up to a node of 70 which has 30 (=10+20) as its
neighbor, totalling 100.

The leaf hash needs to commit to the intent/recipient of the burn, so that
way you can't "double spend" the burn by reusing it for more than one
purpose.

You could outsource the burn to an aggregating third party by paying them
e.g. over LN but it won't be atomic, so they could walk away with your
payment without actually following through with the burn (but presumably
take a reputational hit).

As I believe you already realized, while an op_return is needed (or rather,
preferred) to burn, you don't necessarily have to put the hash there and
can thus save some bytes. One possible place to commit the root hash is in
a double taproot commitment in the change output. So while taproot is Q =
P + hash(Q||mast)*G, you'd commit the root in P such that P = N +
hash(N||burn_tree_root)*G. What's important is that the location is fully
deterministic, in order to ensure there isn't more than one tree (which
would be yet another way to "double spend").

Finally, you can perform the burn on a spacechain[0] (basically a
"sidechain" that has burned BTC as its native token) in order to pretty
much avoid using mainchain block space altogether, so it should scale much
better. It's worth noting that this fully supports SPV proofs, so the third
party you're proving the burn to doesn't have to run a full node (though
SPV may not be safe enough for big amounts).

To me this seems like a possible way to revitalize the original hashcash
use case, e.g. by only accepting emails which have an SPV proof of some
burned sats attached, or any other place where spam is an issue.

Cheers,
Ruben

[0] Spacechains:
https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains

On Sun, Jul 17, 2022 at 9:41 PM Велеслав via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello List,
>
> I have been pondering this problem for some time and have not yet come up
> with an elegant solution, so I am asking here to get more perspective.
>
> There are many usecases for proof of burn. The current working solution is
> to use OP_RETURN with some application specific data.
>
> However, this is limited because block space is finite, and although the
> use of block space itself is an implicit form of burn and can be used in
> the economic calculation of the burn, it is still a fundamental scalability
> constraint.
>
> It would be great to have some sort of second layer protocol where
> micro-burns could be instantly exchanged and public proofs generated.
> Something like the Lightning Network, but with public evidence of burns.
>
> I was thinking of pre-committing a larger OP_RETURN burn in the
> blockchain, with an additional output that would include a merkel tree with
> sparse summation (see Taro), but I haven't found a solution to the
> double-spend problem. I see that the space in this tree can be oversold
> before it is committed to the blockchain.
>
> This makes me wonder if there really is no solution other than to use a
> blockchain. For example, a liquid type sidechain, where the pre-commitments
> being burned are a kind of pledge, and the resulting merkel tree is built
> and fixed via a bail-out sidechain mechanism.
>
> Burns can be performed on the side chain at a very high frequency, and the
> side chain can end up fixing these burns back into the main chain within
> some effective merkel tree proof structure.
>
> All in all, I would like some kind of solution that would be similar to
> buying a micro-burn using the Lightning network milisatoshis, and then
> quickly and reliably obtaining a unique and valid burn proof that is cheap
> to verify. Is something like this possible?
>
> Kind Regards,
> Veleslav
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220717/bc75c3de/attachment-0001.html>;

📅 Original date posted:2022-02-24 📝 Original message:Note ...

2023-06-08T01:04:51+02:00

In reply to nevent1q…37tl
_________________________

📅 Original date posted:2022-02-24
📝 Original message:Note this has always been possible, and is not specifically related to
tapscript. As long as you're committing to an ECC point, you can tweak it
to commit data inside it (i.e. pay-to-contract). This includes P2PK and
P2PKH.

Committing to 1.5GB of data has equally been possible with OP_RETURN
<hash>, or even an entire merkle tree of hashes, as is the case with Todd's
opentimestamps.

Also, tweaking an ECC point (this includes tapscript) in non-deterministic
ways also makes it harder to recover from backup, because you can't recover
the key without knowing the full commitment.

Furthermore, the scheme is not actually equivalent to op_return, because
it requires the user to communicate out-of-band to reveal the commitment,
whereas with op_return the data is immediately visible (while not popular,
BIP47 and various colored coin protocols rely on this).

Cheers,
Ruben

On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Since Taproot was activated, we no longer need separate OP_RETURN outputs
> to be pushed on-chain. If we want to attach any data to a transaction, we
> can create "OP_RETURN <anything>" as a branch in the TapScript. In this
> way, we can store that data off-chain and we can always prove that they are
> connected with some taproot address, that was pushed on-chain. Also, we can
> store more than 80 bytes for "free", because no such taproot branch will be
> ever pushed on-chain and used as an input. That means we can use "OP_RETURN
> <1.5 GB of data>", create some address having that taproot branch, and
> later prove to anyone that such "1.5 GB of data" is connected with our
> taproot address.
>
> Currently in Bitcoin Core we have "data" field in "createrawtransaction".
> Should the implementation be changed to place that data in a TapScript
> instead of creating separate OP_RETURN output? What do you think?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/e1bb7a97/attachment-0001.html>;

📅 Original date posted:2020-05-15 📝 Original message:Hi ...

2023-06-07T20:24:44+02:00

In reply to nevent1q…chnt
_________________________

📅 Original date posted:2020-05-15
📝 Original message:Hi ZmnSCPxj,

>The proper response here is that Bob should broadcast success tx before
the refund tx #1 becomes valid.

That's right. And even if Bob neglects to do that, it still won't cause
chaos for Alice as long as she chooses the path for refund tx #2.

>at least part of the fund must be lost in fees and Bob can still suffer a
small loss

Yes, after protocol completion Alice can broadcast one more transaction
that is paid for by Bob, and Bob would have to respond with another
transaction of his own. As you said, bring-your-own-fees would be better
here (also see FAQ question "Can't Alice just publish the revoke_tx after
protocol completion?").

>the server should take Alice position and the client should take Bob
position [...] a client will want to make multiple CoinSwaps in sequence

I think this can be summarized as: whoever is planning to spend their UTXO
first should be Bob.

In your protocol it might make sense for the server and client to swap
roles depending on what the client plans to do. If they plan to swap again
soon, they can be Bob, if they don't, they're Alice.

But there's also another consideration: whoever is less likely to abort the
protocol should be Bob.

Clients can be unreliable. If clients are Bob, they can waste Alice's
resources by initiating the protocol and aborting (which imo is more severe
than the risk of the revoke tx getting published). Whereas if the client is
Alice, she'd be first to commit resources before the server commits
anything.

>ensure the txo is spent before refund tx #1 becoms valid

Yes, this is important. Luckily, pretty much all the options we discussed
could be applied here, including sighash_single + anyonecanpay. In your
specific example this seems preferable to adding a change output and making
multiple transactions with different RBF amounts, especially since this
only concerns a situation where the protocol stalls at a specific step
(after the success tx).

And I agree with your general assessment that three transactions are
required in order to pay a third party. This could be done from either side
of the swap, but of course it makes more sense to pay from the timelock
side and get rid of the online requirement.

Cheers,
Ruben

On Fri, May 15, 2020 at 6:39 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Ruben,
>
> > Hi ZmnSCPxj,
> >
> > >on completion of the protocol, if Bob lets the refund tx#1 become valid
> (i.e. does not spend the BTC txo) then Alice can broadcast it, putting both
> their funds into chaos
> >
> > You forget, refund tx #1 has a script (which btw won't be visible with
> taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice
> broadcasts it after protocol completion, she is just giving Bob the key to
> her LTC (note: if she's wise she'd move the LTC beforehand), but Bob
> doesn't lose the BTC because he has both keys and can just react before the
> relative timelock expires. No chaos.
>
> Ah, that explains the existence of the Alice && Bob clause in that output
> then.
>
> The attack is now as follows:
>
> * Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.
> * Bob returns the `secretBob`.
> * Alice stalls the protocol and never sends the `Alice` privkey, and waits
> for 1 day, then sneaks the refund tx #1 and spends the LTC via direct miner
> collusion.
>
> The proper response here is that Bob should broadcast success tx before
> the refund tx #1 becomes valid.
> (Which I think is the point: chaos can only occur if you let backouts
> become valid, and it is the best policy for Bob to just spend the BTC txo
> well before the timeout.
> Even if the protocol is completed, without a bring-your-own-fees that lets
> you malleate the tx (i.e. CPFP hooks still require the transction itself to
> reduce the fund by at least the minimum feerate), at least part of the fund
> must be lost in fees and Bob can still suffer a small loss of funds.)
>
> --
>
> Tangentially, I now think in the case of client-server CoinSwap, the
> server should take Alice position and the client should take Bob position.
>
> Suppose a client wants to do some mixing of its own received coins.
> It should not depend on only one server, as the server might secretly be a
> surveillor (or hacked by a surveillor) and recording swaps.
> Thus, a client will want to make multiple CoinSwaps in sequence, to
> obscure its history.
>
> (Do note the objections under "Directionality" in
> https://zmnscpxj.github.io/bitcoin/multiswap.html though; a counter to
> this objections is that the analysis there is only applicable if the
> surveillor already identified the CoinSwap sequence, but hopefully the
> increased steganography of CoinSwaps means they are not identifiable
> anyway.)
>
> Since Bob really should spend its received coin before a timeout, it is
> best for Bob to be the client; it is likely that the client will need to
> swap "soon" again, meaning it has to redirect the funds to a new 2-of-2
> anyway.
>
> For the final swap, the client can then spend the final coins to an HD
> wallet it controls, reducing the key backup load on the client to be the
> same as normal HD wallets.
> Presumably the server in this situation has greater ability to dynamically
> update its backups to include key backups for `secretAlice` keys.
>
> Further, if the client program has the policy that all spends out of the
> wallet must be done via a swap (similar to a rule imposed by JoinMarket
> where sendpayment.py always does 1 CoinJoin), then this still matches well
> with the requirement on Bob to spend the fund before the first timeout of
> refund tx #1.
>
> If the client needs to spend to a classic, address-using service, then
> nothing in the SAS protocol allows Alice to receive its funds directly into
> a specific third-party address.
> However, Bob can hand over a specific third-party address to use in the
> success tx.
> Indeed, the SAS protocol can be modified so that Bob can specify a set of
> address/value pairs to be put in the success tx instead of just Bob pubkey;
> for example, Bob might swap more than the amoutn that needs to be paid to
> the third-party service, in order to give some additional leeway later for
> RBF once Alice hands over the Alice privkey and Bob can remake the success
> tx (and more importantly, ensure the txo is spent before refund tx #1
> becoms valid).
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200515/dcb4a03f/attachment.html>;

📅 Original date posted:2020-05-13 📝 Original message:Hi ...

2023-06-07T20:24:44+02:00

In reply to nevent1q…e55g
_________________________

📅 Original date posted:2020-05-13
📝 Original message:Hi Dmitry,

Thanks for creating a specification for testing, I appreciate the interest!

>The checking of the model encoded in the specification can successfully
detect the violation of 'no mutual secret knowledge' invariant when one of
the participant can bypass mempool and give the transaction directly to the
miner (this problem was pointed out by ZmnSCPxj in the original SAS thread
[2])

I'm not sure if I follow. The issue ZmnSCPxj described about bypassing the
mempool was not a violation. It was merely a "nuisance" strategy that
causes Alice to have to abort in three transactions. Also note that I
subsequently pointed out in the thread that this strategy does not work,
because Alice is supposed to abort sooner than that if Bob still has not
locked up any funds.

Or perhaps you're referring to the issue ZmnSCPxj pointed out after that,
where refund transaction #1 and the success transaction could both become
valid at the same time. It would make sense for the test to pick up on
that, but I believe that is ultimately also not an issue (see my last reply
in the thread).

>I did not understand what the destination of Alice&Bob cooperative spend
of refund_tx#1 will be

This transaction can be spent by Alice & Bob right away or by Alice a day
later (in relative time, so the tx has to confirm first). The Alice & Bob
condition is there purely to ensure that Bob can spend the money before
Alice once he receives her key at the end of the protocol.

If it helps, you could model this transaction as two separate transactions
instead:
txA: 1 day absolute timelock to Alice & Bob (reveals secretAlice), which
can then be spent by
txB: +1 day relative timelock to Alice

This should be functionally equivalent. Also note that the protocol should
fully function if refund tx #1 did not exist at all. It merely serves to
save block space in certain refund scenarios.

>it would be great to have an established framework for modelling of the
behavior in Bitcoin-like blockchain networks. In particular, having a model
of mempool-related behavior would help to reason about difficult RBF/CPFP
issues

A laudable goal. Good luck with your efforts.

Cheers,
Ruben

On Wed, May 13, 2020 at 7:07 PM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The Succint Atomic Swap contract presented by Ruben Somsen recently has
> drawn much interest.
>
> I personally am interested in the smart contracts realizeable in the
> UTXO model, and also interested in applying formal methods to the
> design and implementation of such contracts.
>
> I think that having formal specifications for the contracts and to be
> able to machine-check the properties of these specifications is very
> valuable, as it can uncover the corner cases that might be difficult to
> uncover otherwise.
>
> The SAS contract is complex enough that it may benefit from formal
> specification and machine checking.
>
> I created a specification in TLA+ [1] specification language based on
> the explanation and the diagram given by Ruben.
>
> The checking of the model encoded in the specification can successfully
> detect the violation of 'no mutual secret knowledge' invariant when one
> of the participant can bypass mempool and give the transaction directly
> to the miner (this problem was pointed out by ZmnSCPxj in the original
> SAS thread [2])
>
> There's one transition that was unclear how to model, though: I did not
> understand what the destination of Alice&Bob cooperative spend of
> refund_tx#1 will be, so this transition is not modelled.
>
> I believe there can be more invariants and temporal properties of the
> model that can be checked. At the moment the temporal properties
> checking does not work, as I didn't master TLA+ enough yet. The safety
> invariants checking should work fine, though, but more work needed to
> devise and add the invariants.
>
> In the future, it would be great to have an established framework for
> modelling of the behavior in Bitcoin-like blockchain networks.
> In particular, having a model of mempool-related behavior would help to
> reason about difficult RBF/CPFP issues. The specification I present
> models the mempool, but in a simple way, without regards to the fees.
>
> The specification can be found in this github repository:
> https://github.com/dgpv/SASwap_TLAplus_spec
>
> There could be mistakes or omissions in the specified model, I hope
> that public review can help find these.
>
> It would be great to receive comments, suggestions and corrections,
> especially from people experienced in formal methods and TLA+, as this
> is only my second finished TLA+ spec and only my third project using
> formal methods (I created bitcoin transaction deserialization code in
> Ada/SPARK before that [3]). Please use the github issues or off-list
> mail to discuss if the matter is not interesting to the general
> bitcoin-dev list audience.
>
> [1] https://lamport.azurewebsites.net/tla/tla.html
>
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html
>
> [3] https://github.com/dgpv/spark-bitcoin-transaction-example
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200513/d2dc3c1c/attachment-0001.html>;

📅 Original date posted:2020-05-13 📝 Original message:Hi ...

2023-06-07T20:24:43+02:00

In reply to nevent1q…as5n
_________________________

📅 Original date posted:2020-05-13
📝 Original message:Hi ZmnSCPxj,

>on completion of the protocol, if Bob lets the refund tx#1 become valid
(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both
their funds into chaos

You forget, refund tx #1 has a script (which btw won't be visible with
taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice
broadcasts it after protocol completion, she is just giving Bob the key to
her LTC (note: if she's wise she'd move the LTC beforehand), but Bob
doesn't lose the BTC because he has both keys and can just react before the
relative timelock expires. No chaos.

>This is why we eventually decided in Lightning to use two CPFP outpoints
rather than one

I appreciate the explanation. I see the problem now, and yes, that does
seem like a headache.

Cheers,
Ruben

On Wed, May 13, 2020 at 1:39 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Ruben,
>
> > Hi ZmnSCPxj,
> >
> > >potentially both Alice and Bob know all the secrets on the LTC side and
> end up competing over it
> >
> > That's exactly right.
> >
> > >Bob can thus give a copy of the revoke tx with signature directly to
> its favorite miner, forcing Alice to take 3 transactions
> >
> > Note that the timelock on the revoke tx is longer than the timelock on
> refund tx #1. The idea is that Alice aborts the protocol by publishing
> refund tx #1 if the protocol hasn't reached step 4 in the svg by the time
> it becomes valid. This should entirely mitigate the issue you're describing.
>
> But if refund tx #1 at all exists, then you drop to the same issue you
> objected to with my proposal, which is that, on completion of the protocol,
> if Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo)
> then Alice can broadcast it, putting both their funds into chaos.
>
> So you might as well just use my counterproposal instead, which is
> simpler, gets bring-your-own-fees for free, etc.
>
> I suppose there is some *slight* improvement in that with your proposal,
> Alice *can* use revoke tx -> refund tx #2, but still, if Alice is insane
> then it could very well mess with the protocol by instead using refund tx
> #1.
> Thus, if Bob wants to survive in an environment where Alices are possibly
> insane (e.g. the real world), it should do everything in its power to
> ensure that the BTC txo is spent before the timeout of refund tx #1, if
> refund tx #1 exists at all.
> And if Bob is already going to do that, then Alice and Bob might as well
> just use my counterproposal etc etc.
>
> > >adding two CPFP outputs (one for each participant)
> >
> > There seems to be a situation where RBF can be disabled by the other
> party, but I'm not sure I see it... Why would a single output spendable by
> either key be insufficient?
>
> If one party quickly broadcasts a long chain of low-feerate transactions
> on top of the single output, then the output is "pinned".
>
> Low feerate means it is undesirable for miners to mine it, because it pays
> low for the amount of blockspace it has.
> But because there is a long chain of transactions, the absolute fee of
> that chain can be sizable, and we have a rule in RBF which, paraphrased,
> goes something like "the replacing transaction should also have a higher
> absolute fee than *all* the transactions it replaces", meaning the fee jump
> that the other side has to offer *has to be* pretty big.
>
> If the other outputs of the tx are then multisig, then the pinning
> participant can simply refuse to sign for those, and if the existing txes
> spending the other outputs are relative-time-locked, they cannot be used to
> CPFP the revoke tx onchain.
>
> This is why we eventually decided in Lightning to use two CPFP outpoints
> rather than one, and are also realizing just how much of a headache the RBF
> rules are, sigh.
>
> Still, in your proposed protocol the dependent transactions are all
> relative-timelocked, so timely confirmation of the revoke tx is not
> necessary, unlike in the case of Lightning where all HTLCs have to use an
> absolute timelock because we have to coordinate multiple HTLCs in
> forwarding and violation of the timelocks can lead to headaches and fund
> loss and so on.
> So maybe a single hook output, or even none at all, is workable.
>
> >
> > >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well
> >
> > Allowing others to add inputs/outputs would introduce malleability.
> Refund tx #2 and the timeout tx would become invalid.
>
> Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.
>
> > >Bob cannot safely perform step 2 before getting both signatures for the
> revoke tx
> >
> > That's right, as you guessed, he does receive a copy of the signed
> revoke tx at protocol start.
> >
> > >>alternatively Bob can just spend before the timelock expires.
> > >This seems to be the safest alternative
> >
> > I agree not giving Alice time to publish the revoke tx is safest, but
> one does not preclude the other. The revoke tx is on an absolute timelock,
> so spending it before that time means you don't have anything to
> worry about, and spending it later means you'll have to be online and keep
> an eye out. If staying online is not a problem, then fee wise that seems
> preferable. As long as less than half of all valid (i.e. the timelock was
> reached) revoke transactions get broadcast, you'll be saving on fees.
>
> In a world where Alice may be insane and mess with the protocol just to
> grief Bob even if Alice loses its money (e.g. the real world), Bob should
> not depend on Alice behaving correctly or politely, so it should still have
> backup watchers set up in case it accidentally goes to sleep and so on.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200513/257878bf/attachment.html>;

📅 Original date posted:2020-05-13 📝 Original message:Hi ...

2023-06-07T20:24:42+02:00

In reply to nevent1q…guk4
_________________________

📅 Original date posted:2020-05-13
📝 Original message:Hi ZmnSCPxj,

>potentially both Alice and Bob know all the secrets on the LTC side and
end up competing over it

That's exactly right.

>Bob can thus give a copy of the revoke tx with signature directly to its
favorite miner, forcing Alice to take 3 transactions

Note that the timelock on the revoke tx is longer than the timelock on
refund tx #1. The idea is that Alice aborts the protocol by publishing
refund tx #1 if the protocol hasn't reached step 4 in the svg by the time
it becomes valid. This should entirely mitigate the issue you're describing.

>adding two CPFP outputs (one for each participant)

There seems to be a situation where RBF can be disabled by the other party,
but I'm not sure I see it... Why would a single output spendable by either
key be insufficient?

>We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well

Allowing others to add inputs/outputs would introduce malleability. Refund
tx #2 and the timeout tx would become invalid.

>Bob cannot safely perform step 2 before getting both signatures for the
revoke tx

That's right, as you guessed, he does receive a copy of the signed revoke
tx at protocol start.

>>alternatively Bob can just spend before the timelock expires.
>This seems to be the safest alternative

I agree not giving Alice time to publish the revoke tx is safest, but one
does not preclude the other. The revoke tx is on an absolute timelock, so
spending it before that time means you don't have anything to worry about,
and spending it later means you'll have to be online and keep an eye out.
If staying online is not a problem, then fee wise that seems preferable. As
long as less than half of all valid (i.e. the timelock was reached) revoke
transactions get broadcast, you'll be saving on fees.

Cheers,
Ruben

On Wed, May 13, 2020 at 11:57 AM Ruben Somsen <rsomsen at gmail.com> wrote:

> Hi Chris,
>
> Thanks for taking a look :)
>
> >it also improves privacy because the coins could stay unspend for a long
> time, potentially indefinitely
>
> Excellent point. The pre-swap setup transactions would still be subject to
> timing/amount analysis, but it's clearly a lot less problematic than the
> traditional 4 tx swap. And Payswap may be able to mitigate the amount
> analysis.
>
> >Using relative timelocks and private key handover for old-style coinswaps
> would give us the same two-transaction effect
>
> I agree, Lloyd pointed out the same thing. One thing to add is that such a
> setup would result in four on-chain transactions if the protocol is
> aborted, due to the need to invalidate the refund transaction.
>
> >the idea of private key handover was mentioned as early as 2016 in the
> original Lightning Network paper
>
> Interesting! Thanks for pointing that out.
>
> Cheers,
> Ruben
>
> On Wed, May 13, 2020 at 10:39 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Ruben,
>>
>> > >If the shortened refund transaction exists (labeled "refund
>> transaction #1" in the SVG) then the same issue still occurs
>> >
>> > Yes, but there is one crucial difference: at that point in the protocol
>> (Bob has the success transaction and then stops cooperating) Alice and Bob
>> both had the opportunity not to take that path. Bob could have sent the
>> success transaction, and Alice could have waited and sent the revoke
>> transaction. They would essentially be "colluding" to fail.
>>
>> Okay, so the concern is basically, that Bob misses the deadline, then
>> Alice feels obligated to reclaim the funds.
>> In your proposal, the tx competition is between the secret-revealing
>> success TX and the non-secret-revealing revoke tx.
>> Whereas in my counterproposal, under the same conditions, the tx
>> competition is between the secret-revealing success tx and the
>> secret-revealing backout tx, and both transactions becoming visible on P2P
>> network means potentially both Alice and Bob know all the secrets on the
>> LTC side and end up competing over it, RBFing each other until the entire
>> fund goes to miners.
>>
>>
>> > >Without the refund#1 in your proposal, Bob refusing cooperation after
>> Alice puts the BTC into lock for 3 days and 2 further onchain transactions
>> >
>> > I'm not sure if I correctly understood what you're saying, but it's as
>> follows:
>> >
>> > Refund #1 can only safely be used before the signed success tx is given
>> to Bob. The cost to Alice at this point if Bob aborts is two on-chain
>> transactions while Bob hasn't put anything on-chain yet.
>> >
>> > Refund #2 needs to be used after Bob receives the signed success tx.
>> The cost to Alice is now three transactions, but Bob also went-on-chain by
>> this point, so causing this wasn't costless to Bob and is thus a similar
>> failure mode.
>>
>> I think it is not accurate that Bob is already on-chain before Alice can
>> be forced to use 3 transactions to fail.
>>
>> The revoke tx signatures are shared at step 0 of your protocol
>> description.
>> Thus Bob has a copy of the revoke tx that is valid once Alice signs and
>> confirms the funding transaction.
>> Bob can thus give a copy of the revoke tx with signature directly to its
>> favorite miner, forcing Alice to take 3 transactions to back out of the
>> swap.
>>
>> Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There
>> ain't no such thing as a global mempool"), Alice will only know about this
>> event when the revoke tx is confirmed once, at which point it is very
>> difficult to reverse, even if Alice has a refund#1 tx prepared.
>>
>> Bob can do this before step 2 in your protocol description, meaning
>> before Bob locks up any funds, so Bob can do this for free, and will even
>> use funds going back to Alice to pay for confirmation of the revoke tx.
>> Because Bob can do this for free, there is no disincentive for trolling
>> Bobs to exist whose sole life goal is to just grief possible Alices.
>>
>> This can be slightly mitigated by adding two CPFP outputs (one for each
>> participant) and using the minimum relayable feerate for the revoke tx so
>> that Bob is forced to bring its own fees in order to incentivize miners.
>> This is similar to the "bring your own fees" currently proposed for
>> Lightning, but note the recent hand-wringing about the various problems
>> this adds to mempools and CPFP and RBF rules and etc etc:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html
>>
>> We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a
>> bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the
>> transaction graph as special.
>> And forcing bring-your-own-fees means neither Alice nor Bob can swap all
>> their funds in a single operation, they have to keep a reserve.
>>
>>
>> Bob cannot safely perform step 2 before getting both signatures for the
>> revoke tx, as without Bob having access to the rveoke tx, if Bob locks up
>> LTC, Alice can stop responding and lock both their funds indefinitely with
>> Bob not having any way to recover its funds, which a rich Alice can use to
>> completely lock out an impoverished Bob.
>> But if Bob is given both signatures for the revoke tx before step 2, then
>> Bob can send the revoke tx to its favorite miner, forcing Alice to take 3
>> transactions to back out, before Bob locks any funds in LTC side.
>>
>> >
>> > I also agree with your observation that alternatively Bob can just
>> spend before the timelock expires.
>>
>> This seems to be the safest alternative; in my context, where Bob is a
>> CoinSwap server/maker, Bob can wait a short while for new clients/takers,
>> and if no new clients arrive, spend.
>> Bob can run multiple servers, each of which are given the completed
>> success transaction, and the servers can check that if the timeout is near,
>> to spam the Bitcoin P2P network with the completed success transactions.
>> (these servers need not even run fullnodes, they could just periodically
>> poll a number of blockchain explorers and electrum servers, and when the
>> blockheight approaches, attempt broadcast; if the "main" server that
>> accepts clients/takers has already spent the TXO the broadcast of the
>> completed success tx is simply rejected by the Bitcoin P2P network; if the
>> timeout is based on sidereal time then the backup servers only need to be
>> running NTP)
>>
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200513/d7e238fb/attachment.html>;

📅 Original date posted:2020-05-13 📝 Original message:Hi ...

2023-06-07T20:24:41+02:00

In reply to nevent1q…52l3
_________________________

📅 Original date posted:2020-05-13
📝 Original message:Hi Chris,

Thanks for taking a look :)

>it also improves privacy because the coins could stay unspend for a long
time, potentially indefinitely

Excellent point. The pre-swap setup transactions would still be subject to
timing/amount analysis, but it's clearly a lot less problematic than the
traditional 4 tx swap. And Payswap may be able to mitigate the amount
analysis.

>Using relative timelocks and private key handover for old-style coinswaps
would give us the same two-transaction effect

I agree, Lloyd pointed out the same thing. One thing to add is that such a
setup would result in four on-chain transactions if the protocol is
aborted, due to the need to invalidate the refund transaction.

>the idea of private key handover was mentioned as early as 2016 in the
original Lightning Network paper

Interesting! Thanks for pointing that out.

Cheers,
Ruben

On Wed, May 13, 2020 at 10:39 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Ruben,
>
> > >If the shortened refund transaction exists (labeled "refund transaction
> #1" in the SVG) then the same issue still occurs
> >
> > Yes, but there is one crucial difference: at that point in the protocol
> (Bob has the success transaction and then stops cooperating) Alice and Bob
> both had the opportunity not to take that path. Bob could have sent the
> success transaction, and Alice could have waited and sent the revoke
> transaction. They would essentially be "colluding" to fail.
>
> Okay, so the concern is basically, that Bob misses the deadline, then
> Alice feels obligated to reclaim the funds.
> In your proposal, the tx competition is between the secret-revealing
> success TX and the non-secret-revealing revoke tx.
> Whereas in my counterproposal, under the same conditions, the tx
> competition is between the secret-revealing success tx and the
> secret-revealing backout tx, and both transactions becoming visible on P2P
> network means potentially both Alice and Bob know all the secrets on the
> LTC side and end up competing over it, RBFing each other until the entire
> fund goes to miners.
>
>
> > >Without the refund#1 in your proposal, Bob refusing cooperation after
> Alice puts the BTC into lock for 3 days and 2 further onchain transactions
> >
> > I'm not sure if I correctly understood what you're saying, but it's as
> follows:
> >
> > Refund #1 can only safely be used before the signed success tx is given
> to Bob. The cost to Alice at this point if Bob aborts is two on-chain
> transactions while Bob hasn't put anything on-chain yet.
> >
> > Refund #2 needs to be used after Bob receives the signed success tx. The
> cost to Alice is now three transactions, but Bob also went-on-chain by this
> point, so causing this wasn't costless to Bob and is thus a similar failure
> mode.
>
> I think it is not accurate that Bob is already on-chain before Alice can
> be forced to use 3 transactions to fail.
>
> The revoke tx signatures are shared at step 0 of your protocol description.
> Thus Bob has a copy of the revoke tx that is valid once Alice signs and
> confirms the funding transaction.
> Bob can thus give a copy of the revoke tx with signature directly to its
> favorite miner, forcing Alice to take 3 transactions to back out of the
> swap.
>
> Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There
> ain't no such thing as a global mempool"), Alice will only know about this
> event when the revoke tx is confirmed once, at which point it is very
> difficult to reverse, even if Alice has a refund#1 tx prepared.
>
> Bob can do this before step 2 in your protocol description, meaning before
> Bob locks up any funds, so Bob can do this for free, and will even use
> funds going back to Alice to pay for confirmation of the revoke tx.
> Because Bob can do this for free, there is no disincentive for trolling
> Bobs to exist whose sole life goal is to just grief possible Alices.
>
> This can be slightly mitigated by adding two CPFP outputs (one for each
> participant) and using the minimum relayable feerate for the revoke tx so
> that Bob is forced to bring its own fees in order to incentivize miners.
> This is similar to the "bring your own fees" currently proposed for
> Lightning, but note the recent hand-wringing about the various problems
> this adds to mempools and CPFP and RBF rules and etc etc:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html
>
> We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a
> bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the
> transaction graph as special.
> And forcing bring-your-own-fees means neither Alice nor Bob can swap all
> their funds in a single operation, they have to keep a reserve.
>
>
> Bob cannot safely perform step 2 before getting both signatures for the
> revoke tx, as without Bob having access to the rveoke tx, if Bob locks up
> LTC, Alice can stop responding and lock both their funds indefinitely with
> Bob not having any way to recover its funds, which a rich Alice can use to
> completely lock out an impoverished Bob.
> But if Bob is given both signatures for the revoke tx before step 2, then
> Bob can send the revoke tx to its favorite miner, forcing Alice to take 3
> transactions to back out, before Bob locks any funds in LTC side.
>
> >
> > I also agree with your observation that alternatively Bob can just spend
> before the timelock expires.
>
> This seems to be the safest alternative; in my context, where Bob is a
> CoinSwap server/maker, Bob can wait a short while for new clients/takers,
> and if no new clients arrive, spend.
> Bob can run multiple servers, each of which are given the completed
> success transaction, and the servers can check that if the timeout is near,
> to spam the Bitcoin P2P network with the completed success transactions.
> (these servers need not even run fullnodes, they could just periodically
> poll a number of blockchain explorers and electrum servers, and when the
> blockheight approaches, attempt broadcast; if the "main" server that
> accepts clients/takers has already spent the TXO the broadcast of the
> completed success tx is simply rejected by the Bitcoin P2P network; if the
> timeout is based on sidereal time then the backup servers only need to be
> running NTP)
>
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200513/537d6559/attachment-0001.html>;

📅 Original date posted:2020-05-12 📝 Original message:Hi ...

2023-06-07T20:24:40+02:00

In reply to nevent1q…awdx
_________________________

📅 Original date posted:2020-05-12
📝 Original message:Hi ZmnSCPxj,

>If the shortened refund transaction exists (labeled "refund transaction
#1" in the SVG) then the same issue still occurs

Yes, but there is one crucial difference: at that point in the protocol
(Bob has the success transaction and then stops cooperating) Alice and Bob
both had the opportunity not to take that path. Bob could have sent the
success transaction, and Alice could have waited and sent the revoke
transaction. They would essentially be "colluding" to fail.

>Without the refund#1 in your proposal, Bob refusing cooperation after
Alice puts the BTC into lock for 3 days and 2 further onchain transactions

I'm not sure if I correctly understood what you're saying, but it's as
follows:

Refund #1 can only safely be used before the signed success tx is given to
Bob. The cost to Alice at this point if Bob aborts is two on-chain
transactions while Bob hasn't put anything on-chain yet.

Refund #2 needs to be used after Bob receives the signed success tx. The
cost to Alice is now three transactions, but Bob also went-on-chain by this
point, so causing this wasn't costless to Bob and is thus a similar failure
mode.

>my formulation allows any of the result transactions to be CPFP directly
by their beneficiaries

Yes, that is indeed very nice. The way I set it up, insufficient fees can
unfortunately cause delays, but they should not be able to cause losses.

>there is still an onlineness requirement in case Bob does not complete the
protocol

Yes, that is very much the design. Alice needs to be on time with claiming
her refund (and revealing her secret), otherwise Bob takes it.

>I have not seen the 2-tx variant video yet, as I prefer to read than listen

The video is not required, it just restates what is in the write-up. I
personally find it easier to understand concepts from video, but I seem to
be in the minority when I ask other devs about this. But let me reiterate
one part you might be confused about (though you probably mostly get it
already):

The online requirement I was alluding to doesn't expire, and is
specifically how the 2 tx SAS protocol is performed. Bob never broadcasts
the success transaction (unless he prefers not to have to be online, i.e.
the 3 tx SAS protocol) and instead Alice and Bob swap their keys: first Bob
hands over secretAlice, then Alice hands over her key. Now the swap is
complete, but Bob has to remain online to make sure Alice never attempts to
broadcast her refund tx. It doesn't expire either because of the relative
timelocks.

Just take a look at the slide 6m8s into the video:
https://youtu.be/TlCxpdNScCA?t=6m8s

I also agree with your observation that alternatively Bob can just spend
before the timelock expires.

>Regardless, the overall protocol of using 3 clauses in the swap, and
reusing the privkey as the payment secret demanded by the pointlocks, is
still a significant innovation.

I'm glad you like it :)

>In the context of CoinSwap, a proposal is that a CoinSwap server would
provide swapping service to incoming clients.

That is an excellent use case that takes good advantage of the asymmetry of
SAS. I completely agree with your observation that the "Bob" side is
perfect for servers (online and/or spending again soon) and the "Alice"
side is perfect for clients (settled in 1 tx). I similarly hope that this
may pave the way for a practical implementation of Payswap between
merchants and customers!

Cheers,
Ruben

On Tue, May 12, 2020 at 5:06 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Ruben,
>
> > >Would this not work?
> >
> > I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable
> by both parties. This chaotic scenario is a failure mode that did not seem
> acceptable to me. The revoke transaction was specifically added to mitigate
> that issue (invalidating any attempt of Bob to claim the coins and reveal
> his secret). That said, it doesn't particularly seem in either party's
> interest wait until a moment where two timelocks become valid, so maybe it
> is not quite as bad as I thought. However, it still means that the
> incompetence/malevolence of one party can lead to losses for both parties.
> I have my doubts a gain in privacy in the uncooperative case is worth that
> risk.
> >
> > Of course it also reverts the protocol to 3 transactions, instead of 2,
> but regardless, not having to watch the chain is probably more practical in
> many cases. As an aside, if both chains support timelocks then we can
> ensure that the more expensive chain only receives one transaction.
>
> If the shortened refund transaction exists (labeled "refund transaction
> #1" in the SVG) then the same issue still occurs: after 1 day it is
> possible for either success or refund#1 to be broadcasted, leading to
> revelation of both secrets, leading to the same failure mode you described.
>
> Without the refund#1 in your proposal, Bob refusing cooperation after
> Alice puts the BTC into lock for 3 days and 2 further onchain transactions
> (with the refund#2 transaction being relative-locked, meaning it cannot be
> used to CPFP the revoke transaction; my formulation allows any of the
> result transactions to be CPFP directly by their beneficiaries).
>
> It seems to me that there is still an onlineness requirement in case Bob
> does not complete the protocol: once the revoke tx becomes valid an online
> Bob can cheat an offline Alice by broadcasting the revoke tx (which, if my
> understanding of the protocol is correct, the signatures are shared to both
> Alice and Bob).
> So Alice needs to be online starting at 2 days to 3 days in order to
> ensure it reclaims it funds.
>
> I have not seen the 2-tx variant video yet, as I prefer to read than
> listen, but I will also check it if I can find an opportunity.
>
> Regardless, the overall protocol of using 3 clauses in the swap, and
> reusing the privkey as the payment secret demanded by the pointlocks, is
> still a significant innovation.
>
>
>
> In the context of CoinSwap, a proposal is that a CoinSwap server would
> provide swapping service to incoming clients.
> Using my counterproposal, the Bob position can be taken by the server and
> the Alice position taken by the client.
> In this context, the L1 can be made reasonably close in the future and L2
> far in the future, in which case Alice the client can be "weakly offline"
> most of the time until L2, and even in a protocol abort would be able to
> recover its funds.
> If the protocol completes, the server Bob can claim its funds before L1,
> and (with knowledge of Alice[0]) can immediately put it in a new funding tx
> for a new incoming client before L1, which is a fine tradeoff for server
> Bob since presumably Bob is always online.
>
> Regards,
> ZmnSCPxj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200512/1f2d4869/attachment-0001.html>;

📅 Original date posted:2020-05-12 📝 Original message:Hi ...

2023-06-07T20:24:39+02:00

In reply to nevent1q…cpt9
_________________________

📅 Original date posted:2020-05-12
📝 Original message:Hi ZmnSCPxj,

>Would this not work?

I considered and rejected that model for the following reason: there are
moments where both Alice and Bob can claim the BTC. If they both attempt to
do so, it also reveals both secrets, causing the LTC to also be claimable
by both parties. This chaotic scenario is a failure mode that did not seem
acceptable to me. The revoke transaction was specifically added to mitigate
that issue (invalidating any attempt of Bob to claim the coins and reveal
his secret). That said, it doesn't particularly seem in either party's
interest wait until a moment where two timelocks become valid, so maybe it
is not quite as bad as I thought. However, it still means that the
incompetence/malevolence of one party can lead to losses for both parties.
I have my doubts a gain in privacy in the uncooperative case is worth that
risk.

Of course it also reverts the protocol to 3 transactions, instead of 2, but
regardless, not having to watch the chain is probably more practical in
many cases. As an aside, if both chains support timelocks then we can
ensure that the more expensive chain only receives one transaction.

>if relative locktimes are used as often as absolute locktimes for
block-sniping-prevention and a decent Scriptless Script system, then all
protocol aborts should be doable with no information leaks

I see your point, interesting observation.

>A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on
the LTC side would not be in that HD, and if Alice wants to cold-store the
LTC, it should move the money as well into an HD pubkey.

Agreed, I had that listed as one of the disadvantages: "Access to money is
contingent on remembering secrets (backup complexity)"

Cheers,
Ruben

On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn at gmail.com>
wrote:

> A quick correction to my post:
>
>>
>> Here's where the truly novel part comes in. Ruben solves this by
>> extending the standard *TLC contract:
>> 1. Bob redeem with secret
>> 2. Alice refund after T1
>> 3. Bob redeem without secret after T2
>>
>> This is actually:
>
> 1. Bob redeem with redeem secret
> 2. Alice refund after T1 with refund secret
> 3. Bob redeem without secret after T2
>
> The fact that Alice reveals a secret when she refunds is crucial.
>
> LL
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200512/235cbe50/attachment.html>;

📅 Original date posted:2020-05-12 📝 Original message:Hi ...

2023-06-07T20:24:39+02:00

In reply to nevent1q…2rat
_________________________

📅 Original date posted:2020-05-12
📝 Original message:Hi Lloyd,

>In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done!

Thanks for the kind praise, and for providing a summary of what you think
makes the protocol useful. Your different perspective is undoubtedly useful
for others who are trying to understand it.

>We might call this a "Forced Refund *TLC"

Good description, I like it.

>The advantages that Ruben's two tx protocol has over this is that
timelocks and monitoring is only needed on one of the chains.

Well put, and I agree with your point that the traditional 4 tx protocol
can also be turned into 2 tx with an online requirement. One minor thing to
add is that this would make the 4 tx protocol more clunky in the
non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no
cost.

Cheers,
Ruben

On Tue, May 12, 2020 at 1:30 PM Ruben Somsen <rsomsen at gmail.com> wrote:

> Hi ZmnSCPxj,
>
> >Would this not work?
>
> I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable
> by both parties. This chaotic scenario is a failure mode that did not seem
> acceptable to me. The revoke transaction was specifically added to mitigate
> that issue (invalidating any attempt of Bob to claim the coins and reveal
> his secret). That said, it doesn't particularly seem in either party's
> interest wait until a moment where two timelocks become valid, so maybe it
> is not quite as bad as I thought. However, it still means that the
> incompetence/malevolence of one party can lead to losses for both parties.
> I have my doubts a gain in privacy in the uncooperative case is worth that
> risk.
>
> Of course it also reverts the protocol to 3 transactions, instead of 2,
> but regardless, not having to watch the chain is probably more practical in
> many cases. As an aside, if both chains support timelocks then we can
> ensure that the more expensive chain only receives one transaction.
>
> >if relative locktimes are used as often as absolute locktimes for
> block-sniping-prevention and a decent Scriptless Script system, then all
> protocol aborts should be doable with no information leaks
>
> I see your point, interesting observation.
>
> >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO
> on the LTC side would not be in that HD, and if Alice wants to cold-store
> the LTC, it should move the money as well into an HD pubkey.
>
> Agreed, I had that listed as one of the disadvantages: "Access to money is
> contingent on remembering secrets (backup complexity)"
>
> Cheers,
> Ruben
>
>
> On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn at gmail.com>
> wrote:
>
>> A quick correction to my post:
>>
>>>
>>> Here's where the truly novel part comes in. Ruben solves this by
>>> extending the standard *TLC contract:
>>> 1. Bob redeem with secret
>>> 2. Alice refund after T1
>>> 3. Bob redeem without secret after T2
>>>
>>> This is actually:
>>
>> 1. Bob redeem with redeem secret
>> 2. Alice refund after T1 with refund secret
>> 3. Bob redeem without secret after T2
>>
>> The fact that Alice reveals a secret when she refunds is crucial.
>>
>> LL
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200512/7f7a23d1/attachment.html>;

📅 Original date posted:2020-03-27 📝 Original message:Hi ...

2023-06-07T20:23:38+02:00

In reply to nevent1q…dv7a
_________________________

📅 Original date posted:2020-03-27
📝 Original message:Hi ZmnSCPxj,

I appreciate the input.

>Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you
can use an `OP_TRUE` `redeemScript`, for instance.

Good point. I guess the conversation I recall reading must have been about
avoiding p2sh in order to lower the tx size.

>broadcast a non-RBF child transaction with tiny fee, so that it and its
parent transaction will be accepted into mempools but would not be
replaceable

I believe this is solved by inherited signalling. As long as the kickoff tx
is RBF enabled (and unconfirmed), any transaction spending it automatically
inherits its RBF status. See:
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#Summary

>The broadcasting of the kickoff simply means that the first stage cannot
be easily changed

I see what you're saying. Yeah, it does ruin the stages. If the kickoff tx
hits the chain, you'd probably just want to "refresh" the UTXO by agreeing
with the statechain entity to spend it to a new statechain 2-of-2 UTXO
on-chain, thus removing all prior owners. Ideally you'd want it to be more
costly to CPFP the kickoff tx than it is to refresh the UTXO, so the
defender is at an advantage. The statechain entity should probably pay for
every refresh ("insurance"), since the actual owner isn't at fault.

Cheers,
Ruben

On Fri, Mar 27, 2020 at 2:46 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Ruben,
>
> > Hey Christian,
> >
> > Thanks for chiming in :)
> >
> > >It might be worth adopting the late fee binding we have in eltoo
> >
> > That is where my thinking originally went as well, but then I remembered
> that this alters the txid, causing the settlement tx to become invalid.
> What I am suggesting should be functionally the same (albeit less
> space-efficient): a secondary output that can be spent by anyone, which can
> be used to fee bump the kickoff tx with CPFP. I believe this same idea was
> considered for Lightning as well at some point. Do you happen to recall if
> there was some kind of non-standardness issue with it?
>
> Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you
> can use an `OP_TRUE` `redeemScript`, for instance.
>
> Using an `OP_TRUE` `redeemScript` would allow any third party to make you
> cry by opportunistically spending such an output.
> For example your Bitcoin-network peer could notice you broadcasting such a
> transaction with an `OP_TRUE` output, see you spend that output with a
> CPFP-RBF-ed child transaction, then instead of further broadcasting the
> child transaction, instead broadcast a non-RBF child transaction with tiny
> fee, so that it and its parent transaction will be accepted into mempools
> but would not be replaceable with a higher-feerate child transaction
> (because not RBF-flagged).
> Thus, some portion of mempools will contain this poisoned low-fee child
> transaction and prevent the parent from being confirmed (because the
> parent+child fees are not enough to justify being put in a block).
> Which I suppose is an argument for Full RBF aka
> ignore-the-RBF-flag-and-always-RBF.
>
> The solution that I remember being proposed for this in Lightning was to
> give each participant its own attach-your-fees output that only that
> participant can spend, which works for Lightning because the set of
> participants in a channel is permanently fixed, but probably not for
> statechains.
>
> --
>
> The broadcasting of the kickoff simply means that the first stage cannot
> be easily changed, and you might still be able to make further updates by
> updating only the later stages, until the last stage is confirmable, so the
> kickoff being broadcast simply creates a "dead man walking" statechain.
> However, the implementation complexity would probably increase
> tremendously.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200327/c11adfcc/attachment.html>;

📅 Original date posted:2020-03-26 📝 Original message:Hey ...

2023-06-07T20:23:37+02:00

In reply to nevent1q…cajm
_________________________

📅 Original date posted:2020-03-26
📝 Original message:Hey Christian,

Thanks for chiming in :)

>It might be worth adopting the late fee binding we have in eltoo

That is where my thinking originally went as well, but then I remembered
that this alters the txid, causing the settlement tx to become invalid.
What I am suggesting should be functionally the same (albeit less
space-efficient): a secondary output that can be spent by anyone, which can
be used to fee bump the kickoff tx with CPFP. I believe this same idea was
considered for Lightning as well at some point. Do you happen to recall if
there was some kind of non-standardness issue with it?

>Wouldn't that result in a changing pubkey at each update, and thus require
an onchain move to be committed?

I have yet to take a closer look at the math, but my understanding is that
the same key (x) gets redistributed. First x = s1 + o1 and after the
transfer x = s2 + o2 (not the actual math, but it demonstrates how the
transitory key can change from o1 to o2). Assuming s1 is then thrown away
(trust assumption), o1 becomes harmless information.

Cheers,
Ruben

On Thu, Mar 26, 2020 at 6:17 PM Greg Sanders <gsanders87 at gmail.com> wrote:

> > Wouldn't that result in a changing pubkey at each update, and thus
> require an onchain move to be committed?
>
> Suggestion was in line with original proposal where no keys are changing
> ever, just not presupposing existence of MuSig.
>
> On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>> writes:
>> > Regarding modification 1, I agree with ZmnSCPxj that
>> > Decker-Wattenhofer is your next best option, given that eltoo is not
>> > yet available. But if you are going to use a kickoff transaction, keep
>> > in mind that every previous owner will have a copy of it. Because of
>> > this, you can't include a fee, and will instead need to have a second
>> > output for CPFP. This way a previous owner will at least have to pay
>> > the fee if they want to publish it. Note that it's still an
>> > improvement, because even if the kickoff transaction gets posted, it
>> > basically becomes no different than what it would have been, had you
>> > not used a kickoff transaction at all.
>>
>> It might be worth adopting the late fee binding we have in eltoo by
>> having the kickoff transaction input spending the funding tx signed with
>> sighash_single. This works because we only have 1 input and 1 output
>> that we really care about, and can allow others to attach fees at
>> will. That'd at least remove the need to guess the feerate days or
>> months in advance and thus having to overestimate.
>>
>> > Regarding modification 2, I like it a lot conceptually. It hadn't
>> > occurred to me before, and it's a clear security improvement. The only
>> > question is something Greg Sanders mentioned: whether it's enough to
>> > justify the added complexity of using 2P ECDSA. The alternative would
>> > be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
>> > possibly).
>>
>> Wouldn't that result in a changing pubkey at each update, and thus
>> require an onchain move to be committed?
>>
>> > I'm looking forward to seeing statechains become a reality.
>>
>> That'd indeed be great :-)
>>
>> Cheers,
>> Christian
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200326/c5056e1f/attachment.html>;

📅 Original date posted:2020-03-26 📝 Original message:Hi ...

2023-06-07T20:23:36+02:00

In reply to nevent1q…f0j3
_________________________

📅 Original date posted:2020-03-26
📝 Original message:Hi Tom,

Nice to see you working on this.

Regarding modification 1, I agree with ZmnSCPxj that Decker-Wattenhofer is
your next best option, given that eltoo is not yet available. But if you
are going to use a kickoff transaction, keep in mind that every previous
owner will have a copy of it. Because of this, you can't include a fee, and
will instead need to have a second output for CPFP. This way a previous
owner will at least have to pay the fee if they want to publish it. Note
that it's still an improvement, because even if the kickoff transaction
gets posted, it basically becomes no different than what it would have
been, had you not used a kickoff transaction at all.

Regarding modification 2, I like it a lot conceptually. It hadn't occurred
to me before, and it's a clear security improvement. The only question is
something Greg Sanders mentioned: whether it's enough to justify the added
complexity of using 2P ECDSA. The alternative would be to simply use a
regular 2-of-2 multisig (until Schnorr arrives, possibly).

I'm looking forward to seeing statechains become a reality.

Cheers,
Ruben

On Thu, Mar 26, 2020 at 5:20 AM Albert via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> Great to see some work in this direction, here's some thoughts on your
> keygen scheme:
>
> In the scenario where Owner1=Owner2, that is, one of the owners sends some
> coins to itself, that owner would get to know both x1*s1 and
> x2*s2=x2*s1*o2_inv*o1, and, because he already knows o1 and o2, that
> implies knowledge of both x1*s1 and x2*s1 where x1 and x2 are random
> numbers sampled from an uniform distribution. Once the owner has these two
> numbers, he can just sum these together to obtain s1*(x1+x2).
> Now, because of the central limit theorem, the distribution of x1+x2
> should approximate a normal one, concretely an Irwin–Hall distribution,
> with that approximation getting better when more numbers are collected
> through iterations of the protocol. Once you've collected enough numbers to
> approximate a normal well enough (looking at Irwin Hall distribution
> graphs^[1] you can observe that with less than 10 samples the distribution
> is already pretty similar to a normal one), it should be possible to
> drastically reduce the search space and apply brute force to guess the
> value of \sum x and, consequently, s1.
>
> Practically, it's possible that the search space is still too large for
> brute-force to be fruitful, so this attack might not work, but it shows
> that there is information leakage in every protocol iteration.
>
> On another note, if you are not already aware of, something which might be
> worth looking into is the possibility of further trust-minimising the SE
> role by forcing it's code to be run inside an AWS oracle or a hardware
> isolated processor such as SGX.
>
> Albert
>
> [1] https://en.wikipedia.org/wiki/Irwin%E2%80%93Hall_distribution
>
> On Wed, Mar 25, 2020, at 9:52 PM, Tom Trevethan via bitcoin-dev wrote:
>
> Hi all,
>
> We are starting to work on an implementation of the statechains concept (
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
> with particular interest in using the protocol enable the change of
> ownership (novation) of an individual position in an active discreet log
> contract (DLC) without an on-chain transaction, and without needing the
> cooperation of the counterparty. The protocol as outlined by Ruben requires
> features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it
> is uncertain when (or even if) this will be added. So we are looking at
> variants that would work with current Bitcoin functionality, and it would
> be good to get some feedback on them.
>
> There are two main modifications we are looking at:
> 1. Instead of an eltoo-based backup/refund transaction (enabling the
> current owner to claim the UTXO in case the statechain entity disappears)
> we propose using a decrementing nLocktime for backup transactions as the
> output changes hands. Here, the first owner gets a backup transaction with
> an nLocktime at some future height (h0), then the next owner gets a backup
> transaction with nLocktime (h0-c) where c is a confirmation window. This
> approach has the downside of limiting the lifetime of the UTXO, but it also
> doesn't require the current owner to be always online.
>
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE
> key and transitory key) with a single P2(W)PKH output where the public key
> shared between the SE and the current owner. The SE and the current owner
> can then sign with a 2-of-2 ECDSA MPC. This enables each owner to generate
> their own private key share, and the SE changes their key share at each
> change of ownership (with the shared public key remaining the same). This
> works as follows (.G is EC point multiplication, * is scalar
> multiplication):
>
> KeyGen:
>
> a. Owner 1 generates private key share o1 then calculates the
> corresponding public key of the share O1 and sends it to the SE: O1 = o1.G
> b. The SE then generates a private key: s1 (the SE private key share),
> calculates the corresponding public key and sends it to Owner 1: S1 = s1.G
> c. Both SE and Owner 1 then multiply the public keys they receive by their
> own private key shares to obtain the same shared public key P (which
> corresponds to a shared private key of p = o1*s1): P = o1.(s1.G) = s1.(o1.G)
> d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the
> address corresponding to P (but doesn't sign it).
> e. Once Owner 1 and SE cooperatively sign the first backup transaction,
> Owner 1 then signs and broadcasts the deposit transaction Tx0.
>
> Transfer from Owner 1 to Owner 2:
>
> a. Owner 2 generates two private keys: o2 (the new owner UTXO private key
> share) and b2 (the new owner refund private key).
> b. The SE generates a temporary blinding nonce x and calculates the value
> x*s1 and sends this securely to Owner 2.
> c. Owner 2 then multiplies this received value by the modular inverse of
> o2 (o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1.
> d. Owner 1 then multiplies this received value by the key share o1 and
> sends the resulting value (x*s1*o2_inv*o1) to the SE.
> e. The SE then multiplies this received value by the modular inverse of
> the temporary nonce (x_inv) to obtain x*s1*o2_inv*o1*x_inv. This cancels
> the blinding nonce x to give s1*o2_inv*o1. This value, when multiplied by
> the new owner key share o2 equals the original shared private key s1*o1.
> f. The SE then sets this value equal to s2 = s1*o2_inv*o1 and deletes s1.
> s2 and o2 are now the key shares of `P` and can be used to colaboritively
> sign (with 2P ECDSA). So long as the SE delets s1, the old owner key share
> (o1) is of no use in deriving or co-signing with the full shared private
> key, and is invalidated.
> g. The shared public key P remains unchanged, but the corresponding
> private key (which no individual party ever has knowledge of or can derive)
> can only be determined from the key shares of the SE and Owner 2 (i.e. P =
> s2*o2.G).
> h. Owner 2 then calculates their backup public key (B2 = b2.G) and sends
> it to the SE.
> i. The SE creates a backup transaction (Tx2) that pays the output of Tx0
> to the address corresponding to B2 , with `nLockTime` set to a block height
> h0 - c0, where c0, is a confirmation time sufficient to guarantee that Tx2
> can be confirmed in the blockchain before Tx1 (therefore making Tx1
> invalid).
> j. Owner 2 and the SE then cooperate to sign Tx2 with shared key (P) using
> the 2P ECDSA protocol, which Owner 2 then saves.
>
> The principle of the logic of the key transfer is that the two separate
> key shares are updated, but the full shared private key (which no-one
> knows) remains the same. The new owner chooses a new secret value for their
> private key share, and this (along with the private key share of the
> previous owner) is utilized by the SE to update their share. The use of the
> nonce (x) prevents any of the participants from determining any information
> about each others secret keys. In this way Owner 2 cannot determine s1 from
> x*s1, Owner 1 cannot determine s1 or o2 from x*s1*o2_inv and the SE cannot
> determine o1 or o2 from x*s1*o2_inv*o1.
>
> This transfer protocol can be repeated to transfer the ownership to new
> owners. Each time the SE key share sX is updated, the previous key shares
> become invalid and are of no use even if the current key share is
> subsequently revealed. The SE still needs to be trusted to delete the old
> key share, but this protocol removes the risk the the SE can be hacked by a
> previous owner to steal the funds.
>
> Any comments on the above would be greatly appreciated.
>
> Tom
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200326/0a5f4fef/attachment.html>;

📅 Original date posted:2019-09-09 📝 Original message:Hi ...

2023-06-07T20:20:26+02:00

In reply to nevent1q…0xtj
_________________________

📅 Original date posted:2019-09-09
📝 Original message:Hi ZmnSCPxj,

Thank you for your comments. You raise an important point that I should clarify.

>1. In event of a sybil attack, a fullnode will stall and think the blockchain has no more miners.

You can still attack the full node by feeding it a minority PoW chain,
then it won't stall.

>2. In event of a sybil attack, an SPV, even using this style, will follow the false blockchain.

Correct, but this false blockchain does need to have valid PoW.

So in both cases valid PoW is required to fool nodes. The one
difference is that for a full node, the blocks themselves also need to
be valid (except for the fact that they are in a minority chain), but
the end result is still that a victim can be successfully double spent
and lose money.

I hope this clarifies why I consider the security for these two
situations to be roughly equivalent. In either situation, victims can
be fooled into accepting invalid payments.

Cheers,
Ruben

On Mon, Sep 9, 2019 at 6:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Ruben,
>
>
> > One might intuitively feel that the lack of a commitment is unsafe,
> > but there seems to be no impact on security (only bandwidth). The only
> > way you can be fooled is if all peers lie to you (Sybil), causing you
> > to follow a malicious minority chain. But even full nodes (or the
> > committed version of PoW fraud proofs) can be fooled in this way if
> > they are denied access to the valid most PoW chain. If there are
> > additional security concerns I overlooked, I’d love to hear them.
>
>
> I think it would be better to more precisely say that:
>
> 1. In event of a sybil attack, a fullnode will stall and think the blockchain has no more miners.
> 2. In event of a sybil attack, an SPV, even using this style, will follow the false blockchain.
>
> This has some differences when considering automated systems.
>
> Onchain automated payment processing systems, which use a fullnode, will refuse to acknowledge any incoming payments.
> This will lead to noisy complaints from clients of the automated payment processor, but this is a good thing since it warns the automated payment processor of the possibility of this attack occurring on them.
> The use of a timeout wherein if the fullnode is unable to see a new block for, say, 6 hours, could be done, to warn higher-layer management systems to pay attention.
> While it is sometimes the case that the real network will be unable to find a new block for hours at a time, this warning can be used to confirm if such an event is occurring, rather than a sybil attack targeting that fullnode.
>
> On the other hand, such a payment processing system, which uses an SPV with PoW fraud proofs, will be able to at least see incoming payments, and continue to release product in exchange for payment.
> Yet this is precisely a point of attack, where the automated payment processing system is sybilled and then false payments are given to the payment processor on the attack chain, which are double-spent on the global consensus chain.
> And the automated system may very well not be able to notice this.
>
> Regards,
> ZmnSCPxj

📅 Original date posted:2019-09-08 📝 Original message:After ...

2023-06-07T20:20:26+02:00

In reply to nevent1q…wn47
_________________________

📅 Original date posted:2019-09-08
📝 Original message:After looking more deeply into Tadge Dryja’s utreexo work [0], it has
become clear to me that this opens up a way to implement PoW fraud
proofs [1] without a soft fork. With utreexo, we can efficiently
verify state transitions between blocks. Verifying a block from a
valid utreexo hash requires only about a megabyte worth of merkle
proofs.

PoW fraud proofs assume that block N is valid if no miner has tried to
fork it (read my original post for details [1]). We can extend that
assumption to the utreexo hash of block N, and use that to verify fork
block N+1, and reject it if the block is invalid, with just 2-3MB of
data.

For simplicity, I’ll first start by explaining a version with
commitments (which would require a soft fork).

When a fork (i.e. a PoW fraud proof) occurs at height N+1, indicating
that the block might be invalid, you’d need to download:

1. block N+1 from the most PoW chain (~1-2MB)
2. the utreexo hash commitment inside of block N (e.g. a merkle path
to the coinbase)
3. the utreexo merkle proofs which prove that all inputs of N+1 are
part of the UTXO set (~1MB)

Of course step 2 requires a soft fork, but we can also do a
non-committed version by relying on the assumption that at least one
of your peers is honest and then evaluate disagreements.

We simply replace step 2 above with the following:
2. [Download] the utreexo hash of block N from all your peers

If it turns out that one of your peers disagrees on what the correct
hash is, you find the last utreexo hash where that peer still agreed,
let’s say block M, and you simply execute the same three steps to find
out which peer is wrong: download block M+1, then get the merkle
proofs to verify whether the peer correctly transitioned their utreexo
hash from M to M+1.

One might intuitively feel that the lack of a commitment is unsafe,
but there seems to be no impact on security (only bandwidth). The only
way you can be fooled is if all peers lie to you (Sybil), causing you
to follow a malicious minority chain. But even full nodes (or the
committed version of PoW fraud proofs) can be fooled in this way if
they are denied access to the valid most PoW chain. If there are
additional security concerns I overlooked, I’d love to hear them.

In short, utreexo can enable PoW fraud proofs without a soft fork. At
the cost of downloading a couple of MB per stale block (and per
malicious peer), an SPV client gains the ability to (eventually)
reject the most PoW chain as long as one honest block gets mined,
thereby increasing its security beyond 51% honest miners.

Finally, while I think this goes without saying, I’d like to reiterate
that this is by no means a replacement for running a full node. You’re
depending on other full nodes to do full verification and assuming at
least some of the miners are honest. If everyone did this, Bitcoin
would not be secure.

-- Ruben Somsen

[0] Utreexo paper: https://eprint.iacr.org/2019/611.pdf

[1] Improving SPV security with PoW fraud proofs:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html

📅 Original date posted:2019-06-12 📝 Original message:Hi ...

2023-06-07T20:18:36+02:00

In reply to nevent1q…mz6m
_________________________

📅 Original date posted:2019-06-12
📝 Original message:Hi ZmnSCPxj,

Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking
Bitcoin have been keeping me busy.

Transcript from Coredev (thanks Bryan):
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/

Blind Statechains at Breaking Bitcoin:
https://www.youtube.com/watch?v=DqhxPWsJFZE&t=4h59m4s

>an early draft

I meant an early draft of Statechains, sorry if that was confusing.
But yes, it's essentially no different from channel factories without
eltoo.

>If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.

That is a good point. One thing I have not yet fully analysed are the
privacy considerations. Perhaps we don't want to reveal X on-chain.

>This would be nearer to my own Smart Contracts Unchained

Adding scripting is not my preferred approach. The beauty of the
system is that the server doesn't evaluate any scripts whatsoever.

That being said, Smart Contracts Unchained (SCU) can be inserted quite
elegantly as a separate smart contracting layer.

The observation is that anything that can be done with a UTXO
on-chain, can also be done off-chain via Statechains, including SCU.

If SCU is a single (N-of-N or (1-of-N + escrow)) key, you can simply
use this as the userKey (as well as inside the off-chain eltoo tx).

It's pretty interesting how smart contracting can be added like this.
Cool stuff, ZmnSCPxj. I'll definitely be thinking about this more.

Cheers,
Ruben

On Thu, Jun 6, 2019 at 8:32 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Ruben,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, June 6, 2019 1:20 PM, Ruben Somsen <rsomsen at gmail.com> wrote:
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your comments.
> >
> > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not strictly required. We can still make use of the Decker-Wattenhofer construction instead.
> >
> > Yes, an early draft (from before the eltoo paper) was using that
> > construction, but it seemed quite unwieldy. Timelocks have to be long,
> > nesting adds more transactions, channels expire faster with more use,
> > and tx fee handling is more complex. But you make a good point that if
> > SIGHASH_ANYPREVOUT turns out to be too controversial (or for
> > supporting older altcoins), this would be a potential fallback.
>
> The lack of `SIGHASH_ANYPREVOUT` does make it difficult to operate a channel factory.
> Factory operations would still require the signatures of all participants, but once a participant has released its signature, it cannot be sure whether its channels should be rooted on the previous factory state or the next (i.e. the [Stale Factory problem](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001974.html) ).
> This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transactions.
> Alternately without that flag we can run channels rooted on both the previous and next factory states, which actually is similar to what we need to do for splice-in (so we could reuse that code, possibly).
>
> >
> > > This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
> >
> > That is correct. The worst case for security still comes down to
> > having to trust the federation, but the transitory key, as well as the
> > blind signature scheme, does add an interesting layer of separation
> > that makes it essentially "non-custodial". The article I linked has
> > more on this.
>
> Of note is that this is roughly the same as the common key in my own Smart Contracts Unchained.
>
> If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.
>
> Going further on Smart Contracts Unchained, I observe that the below:
>
> > // Start new signature chain
> > (1) requestNewKey(userPubkey) => returns a new serverPubkey and registers it to userPubkey
> > // Extend existing chain
> > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) => returns blindSignature, registers the serverPubkey to nextUserPubkey
>
> Can be generalized, such that instead of pubKeys and their signatures, we have validation programs and their witnesses.
>
> For example, instead of userPubkey and nextUserPubkey we have a userScript and nextUserScript, with userSignature replaced by a userWitness.
>
> This would be nearer to my own Smart Contracts Unchained, though without committing to the smart contract onchain, only offchain in the server.
>
>
>
> >
> > Cheers,
> > Ruben
> >
> > On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> >
> > > Good morning Ruben,
> > >
> > > > At
> > > > Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> > > > [2] to make the entity unaware of what it's signing. I now think this
> > > > is the more interesting approach. The functionality can be described
> > > > fairly elegantly as follows.
> > >
> > > I agree.
> > > I had no interest in Statechains at all before, but now that you have blind signing servers, this is significantly more interesting.
> > >
> > > > Blind signing server with two functions users can call:
> > > > // Start new signature chain
> > > > (1) requestNewKey(userPubkey) => returns a new serverPubkey and
> > > > registers it to userPubkey
> > > > // Extend existing chain
> > > > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> > > > returns blindSignature, registers the serverPubkey to nextUserPubkey
> > > > The resulting output is a public ECC chain (one blindSignature per
> > > > user, one chain per serverPubkey) of blindly signed messages,
> > > > requested by users (1, 2, 3, etc.):
> > > > userSignature1(blindedMessage1, userPubkey2) => blindSignature1
> > > > userSignature2(blindedMessage2, userPubkey3) => blindSignature2
> > > > etc.
> > > > Assuming the server is honest (more on this below), we can use it to
> > > > transfer over the signing rights of a private key without actually
> > > > changing the key itself.
> > > > The functionality is general and therefore suitable for more than just
> > > > Bitcoin, but let's walk through the primary envisioned use case where
> > > > we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
> > > > server is kept completely unaware that it's handling a BTC
> > > > transaction, since it's signing blindly:
> > > >
> > > > - B uses function (1) with userPubkey = B to request serverPubkey A
> > > >
> > > > - B then generates transitory key X, and creates a single MuSig key AX
> > > > (key X is called “transitory” because its private key will later be passed on)
> > > >
> > > > - B prepares tx1: 1BTC to AX (he doesn't send it yet)
> > > >
> > > > - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
> > > >
> > >
> > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not strictly required.
> > > We can still make use of the Decker-Wattenhofer construction instead.
> > > The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` update systems.
> > > Number of maximum updates is limited by the starting `nSequence`, however if we put an update system inside an update system, we can "reset" the `nSequence` of the inner update system by updating the outer update system.
> > > We can chain this concept further and add more update systems nested inside update systems to gain more leverage from the maximum relative wait time.
> > > As we expect fewer updates are needed for statechains than e.g. actual Lightning channels (your given CoinSwap protocol is "only" two updates, for instance) this is usually a good tradeoff,
> > > It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too controversial to get into Bitcoin, provided Schnorr (definitely uncontroversial) does get into Bitcoin.
> > >
> > > > A and B can collude to take the money from C, but since all instances
> > > > of userSignature and blindSignature are published openly, cheating is
> > > > publicly detectable (e.g. the server signed two messages from B
> > > > instead of one).
> > > >
> > >
> > > This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
> > >
> > > > Trust can be distributed by turning the server into a multisig
> > > > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
> > > > means security can be on par with federated sidechains [5], and is
> > > > similar to how ZmnSCPxj replaced the escrow key with a federation in
> > > > “Smart Contracts Unchained” [6].
> > > >
> > >
> > > This makes me happy.
> > > Regards,
> > > ZmnSCPxj
>
>

📅 Original date posted:2019-06-06 📝 Original message:Hi ...

2023-06-07T20:18:35+02:00

In reply to nevent1q…7luk
_________________________

📅 Original date posted:2019-06-06
📝 Original message:Hi ZmnSCPxj,

Thank you for your comments.

>Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *strictly* required. We can still make use of the Decker-Wattenhofer construction instead.

Yes, an early draft (from before the eltoo paper) was using that
construction, but it seemed quite unwieldy. Timelocks have to be long,
nesting adds more transactions, channels expire faster with more use,
and tx fee handling is more complex. But you make a good point that if
SIGHASH_ANYPREVOUT turns out to be too controversial (or for
supporting older altcoins), this would be a potential fallback.

>This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.

That is correct. The worst case for security still comes down to
having to trust the federation, but the transitory key, as well as the
blind signature scheme, does add an interesting layer of separation
that makes it essentially "non-custodial". The article I linked has
more on this.

Cheers,
Ruben

On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Ruben,
>
> > At
> > Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> > [2] to make the entity unaware of what it's signing. I now think this
> > is the more interesting approach. The functionality can be described
> > fairly elegantly as follows.
>
> I agree.
> I had no interest in Statechains at all before, but now that you have blind signing servers, this is significantly more interesting.
>
>
> >
> > Blind signing server with two functions users can call:
> >
> > // Start new signature chain
> > (1) requestNewKey(userPubkey) => returns a new serverPubkey and
> > registers it to userPubkey
> >
> > // Extend existing chain
> > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> > returns blindSignature, registers the serverPubkey to nextUserPubkey
> >
> > The resulting output is a public ECC chain (one blindSignature per
> > user, one chain per serverPubkey) of blindly signed messages,
> > requested by users (1, 2, 3, etc.):
> >
> > userSignature1(blindedMessage1, userPubkey2) => blindSignature1
> > userSignature2(blindedMessage2, userPubkey3) => blindSignature2
> > etc.
> >
> > Assuming the server is honest (more on this below), we can use it to
> > transfer over the signing rights of a private key without actually
> > changing the key itself.
> >
> > The functionality is general and therefore suitable for more than just
> > Bitcoin, but let's walk through the primary envisioned use case where
> > we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
> > server is kept completely unaware that it's handling a BTC
> > transaction, since it's signing blindly:
> >
> > - B uses function (1) with userPubkey = B to request serverPubkey A
> > - B then generates transitory key X, and creates a single MuSig key AX
> > (key X is called “transitory” because its private key will later be passed on)
> >
> > - B prepares tx1: 1BTC to AX (he doesn't send it yet)
> > - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
>
> Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *strictly* required.
> We can still make use of the Decker-Wattenhofer construction instead.
>
> The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` update systems.
> Number of maximum updates is limited by the starting `nSequence`, however if we put an update system inside an update system, we can "reset" the `nSequence` of the inner update system by updating the outer update system.
> We can chain this concept further and add more update systems nested inside update systems to gain more leverage from the maximum relative wait time.
>
> As we expect fewer updates are needed for statechains than e.g. actual Lightning channels (your given CoinSwap protocol is "only" two updates, for instance) this is usually a good tradeoff,
>
> It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too controversial to get into Bitcoin, provided Schnorr (definitely uncontroversial) does get into Bitcoin.
>
> > A and B can collude to take the money from C, but since all instances
> > of userSignature and blindSignature are published openly, cheating is
> > publicly detectable (e.g. the server signed two messages from B
> > instead of one).
>
> This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
>
> >
> > Trust can be distributed by turning the server into a multisig
> > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
> > means security can be on par with federated sidechains [5], and is
> > similar to how ZmnSCPxj replaced the escrow key with a federation in
> > “Smart Contracts Unchained” [6].
>
> This makes me happy.
>
> Regards,
> ZmnSCPxj

📅 Original date posted:2019-06-04 📝 Original message:Hi ...

2023-06-07T20:18:34+02:00

In reply to nevent1q…qaxm
_________________________

📅 Original date posted:2019-06-04
📝 Original message:Hi everyone,

For those who are unfamiliar, Statechains enable the transfer UTXOs
off-chain with the help of a Statechain entity (trusted server(s))
without giving them full custodial control over your coins [0]. At
Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
[2] to make the entity unaware of what it's signing. I now think this
is the more interesting approach. The functionality can be described
fairly elegantly as follows.

Blind signing server with two functions users can call:

// Start new signature chain
(1) requestNewKey(userPubkey) => returns a new serverPubkey and
registers it to userPubkey

// Extend existing chain
(2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
returns blindSignature, registers the serverPubkey to nextUserPubkey

The resulting output is a public ECC chain (one blindSignature per
user, one chain per serverPubkey) of blindly signed messages,
requested by users (1, 2, 3, etc.):

userSignature1(blindedMessage1, userPubkey2) => blindSignature1
userSignature2(blindedMessage2, userPubkey3) => blindSignature2
etc.

Assuming the server is honest (more on this below), we can use it to
transfer over the signing rights of a private key without actually
changing the key itself.

The functionality is general and therefore suitable for more than just
Bitcoin, but let's walk through the primary envisioned use case where
we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
server is kept completely unaware that it's handling a BTC
transaction, since it's signing blindly:

- B uses function (1) with userPubkey = B to request serverPubkey A
- B then generates transitory key X, and creates a single MuSig key AX
(key X is called “transitory” because its private key will later be passed on)
- B prepares tx1: 1BTC to AX (he doesn't send it yet)
- B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
- B uses (2) with nextUserPubkey = B and blindedMessage = tx2
- B sends tx1 to the blockchain and waits for it to confirm
- B receives a key from C in order to prepare a payment
- B creates tx3: an eltoo tx (with higher priority) with 1BTC to C (off-chain)
- B uses (2) with nextUserPubkey = C and blindedMessage = tx3
- B passes the private key of X (the transitory key) on to C
- C takes blinded tx2 and tx3 from the public server output and
unblinds them with X
- C only accepts the payment if everything is in order [4]

Even if the server goes offline, C can still get the money by sending
tx3 to the blockchain.

A and B can collude to take the money from C, but since all instances
of userSignature and blindSignature are published openly, cheating is
publicly detectable (e.g. the server signed two messages from B
instead of one).

Trust can be distributed by turning the server into a multisig
threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
means security can be on par with federated sidechains [5], and is
similar to how ZmnSCPxj replaced the escrow key with a federation in
“Smart Contracts Unchained” [6].

Lastly, by utilizing adaptor signatures [7], the userSignature can be
tied to the blindSignature. In fact, this can be done for any number
of signatures, allowing multiple signing sessions to take place
atomically [8]. This denies the server the ability to selectively
publish one signature and not the other, allowing safe atomic swaps
via the server.

Essentially, anything that requires UTXO ownership can be achieved
off-chain via Blind Statechains. Coinjoin, Lightning channel
opening/adjusting/closing, Discreet Log Contract style bets [9],
cross-chain atomic swaps, etc. Since the blind signing server
functionality is non-specific to Bitcoin, it'll be useful for
non-cryptocurrency related use cases as well, but I have not given
this a lot of thought.

I also recently published a more high-level overview of Statechains
here, which may be of interest:
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39

-- Ruben Somsen

[0] Statechains paper:
https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statechains.pdf

[1] Statechains Scaling Bitcoin ‘18: http://youtu.be/FI9cwksTrQs?t=47m36s
Transcript:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/statechains/

[2] Blind signatures, Jonas Nick:
http://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/blind-signatures-and-scriptless-scripts/

[3] eltoo: https://blockstream.com/eltoo.pdf

[4] Similar to client-side validation, Peter Todd:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/client-side-validation/

[5] Sidechains Appendix A, federated peg: https://blockstream.com/sidechains.pdf

[6] Smart Contracts Unchained ,ZmnSCPxj:
https://zmnscpxj.github.io/bitcoin/unchained.html

[7] Adaptor signatures, Andrew Poelstra:
http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/

[8] Adam Gibson (Waxwing) separately made a similar observation on his
blog: https://joinmarket.me/blog/blog/multiparty-s6/

[9] Discreet Log Contracts, Thaddeus Dryja: https://adiabat.github.io/dlc.pdf

📅 Original date posted:2019-04-15 📝 Original ...

2023-06-07T20:17:39+02:00

In reply to nevent1q…yk68
_________________________

📅 Original date posted:2019-04-15
📝 Original message:Simplified-Payment-Verification (SPV) is secure under the assumption
that the chain with the most Proof-of-Work (PoW) is valid. As many
have pointed out before, and attacks like Segwit2x have shown, this is
not a safe assumption. What I propose below improves this assumption
-- invalid blocks will be rejected as long as there are enough honest
miners to create a block within a reasonable time frame. This still
doesn’t fully inoculate SPV clients against dishonest miners, but is a
clear improvement over regular SPV (and compatible with the privacy
improvements of BIP157[0]).

The idea is that a fork is an indication of potential misbehavior --
its block header can serve as a PoW fraud proof. Conversely, the lack
of a fork is an indication that a block is valid. If a fork is created
from a block at height N, this means a subset of miners may disagree
on the validity of block N+1. If SPV clients download and verify this
block, they can judge for themselves whether or not the chain should
be rejected. Of course it could simply be a natural fork, in which
case we continue following the chain with the most PoW.

The way Bitcoin currently works, it is impossible to verify the
validity of block N+1 without knowing the UTXO set at block N, even if
you are willing to assume that block N (and everything before it) is
valid. This would change with the introduction of UTXO set
commitments, allowing block N+1 to be validated by verifying whether
its inputs are present in the UTXO set that was committed to in block
N. An open question is whether a similar result can be achieved
without a soft fork that commits to the UTXO set[0][1].

If an invalid block is created and only 10% of the miners are honest,
on average it would take 100 minutes for a valid block to appear.
During this time, the SPV client will be following the invalid chain
and see roughly 9 confirmations before the chain gets rejected. It may
therefore be prudent to wait for a number of confirmations that
corresponds to the time it may take for the conservative percentage of
miners that you think may behave honestly to create a block (including
variance).

If users do not wait and happen to accept payments from an invalid
chain during this time, these payments could get reverted. This is a
weakness, but still seems preferably to continually following an
invalid chain. As long as a reasonable number of miners remains
honest, a dishonest majority can only temporarily control the network,
and their blocks (and all coins gained from it) will eventually be
rejected.

-- Ruben Somsen

[0] Olaoluwa Osuntokun, BIP 157: Client Side Block Filtering,
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki

[1] Peter Todd, TXO commitments do not need a soft-fork to be useful,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html

📅 Original date posted:2018-12-17 📝 Original message:Hi ...

2023-06-07T20:15:43+02:00

In reply to nevent1q…jdtm
_________________________

📅 Original date posted:2018-12-17
📝 Original message:Hi Johnson,

The design considerations here seem similar to the ML discussion of
whether Graftroot should be optional [1].

>While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?

As far as I can tell it should be compatible with Statechains [2],
since it pretty much mirrors Eltoo in setup.

My understanding is somewhat lacking, so perhaps I am missing the
mark, but it is not completely clear to me how this affects
fungibility if taproot gets added and the setup and trigger tx for
Eltoo get combined into a single transaction. Would the NOINPUT
spending condition be hidden inside the taproot commitment?

Cheers,
Ruben Somsen

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006.html
[2] https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_statechains_offchain_transfer_of/

On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the first tx made in block 170 reused the previous public key). I don’t see any hope to change this norm any time soon, if possible at all.
>
> As the people who are designing the layer-1 protocol, we could always blame the payer and/or payee for their stupidity, just like those people laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The existing bitcoin script language is so restrictive. It disallows many useful smart contracts, but at the same time prevented many dumb contracts. After all, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.
>
> So NOINPUT brings us more smart contract capacity, and at the same time we are one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts we want, while minimising the risks of misuse.
>
> The risk I am trying to mitigate is a payer mistakenly pay to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is not uncommon. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers (mostly exchanges) may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT)
>
> The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:
>
> 1. A certain bit in the tx version must be set
> 2. A certain bit in the scriptPubKey must be set
>
> I will analyse the pros and cons later.
>
> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and should not be tagged. This makes it indistinguishable from normal 1-of-1 utxo. The trigger tx, which spends the setup utxo, should be tagged, so the update txs could spend the trigger utxo with NOINPUT. Similarly, all update txs should be tagged, so they could be spent by other update txs and settlement tx with NOINPUT. As the final destination, there is no need to tag in the settlement tx.
>
> In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.
>
> I mentioned 2 ways of tagging, and they have pros and cons. First of all, tagging in either way should not complicate the eltoo protocol in anyway, nor bring extra block space overhead.
>
> A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Otherwise, *all* P2SH addresses would become “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.
>
> Another problem with scriptPubKey tagging is all the existing bech32 implementations will not understand the special tag, and will pay to a tagged address as usual. An upgrade would be needed for them to refuse sending to tagged addresses by default.
>
> On the other hand, tagging with tx version will also protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx. Also, as Bitcoin Core has just removed the tx version from the UTXO database, adding it back could be a little bit annoying, but doable.
>
> There is an extension to the version tagging, which could make NOINPUT even safer. In addition to tagging requirement, NOINPUT will also sign the version of the previous tx. If the wallet always uses a randomised tx version, it makes accidental replay very unlikely. However, that will burn a few more bits in the tx version field.
>
> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev