Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Ruben Somsen via bitcoin-dev]

Hi,

There is a reasonable tradeoff one can make to get eventual settlement
assurance prior to confirmation: lock up the funds with a counterparty in a
2-of-2 multisig with a timelock back to the owner. As long as the timelock
has not expired and the recipients trust the counterparty not to sign
double spends, transactions that are spent from this multisig can be
considered instant. In cases where the counterparty and the recipient are
the same person, this solution is trustless. Since merchant purchases tend
to be low-value, the counterparty risk (facilitating double spends) seems
acceptable. GreenAddress provided such a service in 2015 or so, but the
idea got abandoned.

Personally, I find this solution much more tenable than relying on spurious
network assumptions about what will be propagated and mined.

Best regards,
Ruben



On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, 20 Oct 2022 at 09:22, Anthony Towns  wrote:
>
>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > The
>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> > (it's actually quite easily managed),
>>
>> You mean "it's quite easily managed, provided the transaction doesn't
>> opt-in to rbf", right? At least, that's what I understood you saying last
>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>> matter what other trustworthy signals you might see:
>>
>>   https://twitter.com/ziggamon/status/1435863691816275970
>>
>> (rbf txs seem to have increased from 22% then to 29% now)
>>
>
> Yeah. Our share of RBF is a bit lower than that as many RBF transactions
> are something other than consumer purchases, and most consumer purchases
> can't do RBF
>
>
>> > it's FX risk as the merchant must
>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> > some transactions lose money to FX and others earn money - that evens
>> out
>> > in the end.
>>
>> > But if there is an _easily accessible in the wallet_ feature to
>> > "cancel transaction" that means it will eventually get systematically
>> > abused. A risk of X% loss on many payments that's easy to systematically
>> > abuse is more scary than a rare risk of losing 100% of one occasional
>> > payment. It's already possible to execute this form of abuse with opt-in
>> > RBF,
>>
>> If someone's going to systematically exploit your store via this
>> mechanism, it seems like they'd just find a single wallet with a good
>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>> where opt-in rbf vs fullrbf policies make any difference at all?
>>
>
> Sort of. But yes once this starts being abused systemically we will have
> to do something else w RBF payments, such as crediting the amount in BTC to
> a custodial account. But this option isn't available to your normal payment
> processor type business.
>
> Also worth keeping in mind that sometimes "opportunity makes the thief".
> Currently only power-user wallet have that feature and their market share
> is relatively small, mainly electrum stands out. But if this is available
> to all users everywhere then it will start being abused and we'll have to
> then direct all payments to custodial account, or some other convoluted
> solution.
>
>
>> It's not like existing wallets that don't let you set RBF will suddenly
>> get a good UX for replacing transactions just because they'd be relayed
>> if they did, is it?
>>
>> > To successfully fool (non-RBF)
>> > zeroconf one needs to have access to mining infrastructure and
>> probability
>> > of success is the % of hash rate controlled.
>>
>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>> two conflicting txs in advance, one paying the merchant, one paying
>> yourself, connect to many peers, relay the one paying the merchant to
>> the merchant, and the other to everyone else.
>>
>> I'm just basing this off Peter Todd's stuff from years ago:
>>
>>
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>
>>
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>
>>
>
> Yeah, I know the list still rehashes a single incident from 10 years ago
> to declare the entire practice as unsafe, and ignores real-world data that
> of the last million transactions we had zero cases of this successfully
> abusing us.
>
>
>> > Currently Lightning is somewhere around 15% of our total bitcoin
>> payments.
>>
>> So, based on last year's numbers, presumably that makes your bitcoin
>> payments break down as something like:
>>
>>5% txs are on-chain and seem shady and are excluded from zeroconf
>>   15% txs are lightning
>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>   60% txs are on-chain and seem fine for zeroconf
>>
>
> Numbers are right. Shady is too strong a word, it's mostly transactions
> wi

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Ruben Somsen via bitcoin-dev]

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

> On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
> bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Third version of Silent Payment implementation

[Ruben Somsen via bitcoin-dev]

Hi,

Apologies, the link I sent in my previous post was incorrect and should
have been:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1218641521

Let me also use this opportunity to share another clarifying comment:

"There seems to be some confusion about the function of the identifier. Its
function is not to create more than one identity, but to be able to
distinguish why someone paid you. For example, when the same entity is
raising money on behalf of two different charities and wants to know for
which of the two charities the sender intended their donation.

To be absolutely clear, the payments that appear on-chain are still
absolutely unlinkable by a third party observer, nor are they able to tell
which identifier was used.

In cases where you don't want people to know that you're the same entity,
the identifier is insufficient – you'll need a completely separate Silent
Payment address which (roughly) doubles your scanning efforts, so it's much
more costly in terms of performance."

This comment can be found here:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1266193417

Cheers,
Ruben

On Fri, Sep 30, 2022 at 1:03 AM Ruben Somsen  wrote:

> Hi woltx,
>
> Excellent work.
>
> >Implements the new scheme suggested by Ruben Somsen that allows multiple
> silent addresses per wallet with minimal overhead
>
> To expand on this, the scheme basically allows the resulting address to be
> recognizably marked (only recognizable by the recipient of course), which
> enables you to distinguish between different payment purposes (e.g. some
> people donate to you for purpose A, others for purpose B). Here's my
> original comment describing it:
>
> "Naively, the issue is that two keys means twice the scanning, but an
> interesting alternative would be to simply use the same key (assuming
> you're OK with using the same identity) but add a public identifier f to it
> when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*G
> . This means every additional "address" only costs one additional ECC
> addition when scanning (relatively cheap compared to doing ECC
> multiplications).
>
> The main downside with this is that f becomes crucial for recovering from
> backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
> remember how many "addresses" you issued (and perhaps overshoot when
> unsure) to ensure recovery of funds, though of course you'd rather also
> remember which index is associated with what payment reason.
>
> Absolute worst case scenario you could even do something similar to the
> gap limit where you scan the full history (not just the UTXO set so you
> don't miss spent outputs) with a default max index of e.g. 100, and then if
> you find out most of them are in use, you scan the next 100, etc. Costly,
> but thorough, and only needed as a last resort."
>
> Original comment here:
>
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
>
> Also good to note that f needs to be communicated to the sender somehow,
> perhaps as part of the address format.
>
> Cheers,
> Ruben
>
> On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> This new version addresses most (or all) requests made in PR:
>>
>> . Implements the new scheme suggested by Ruben Somsen that allows
>> multiple silent addresses per wallet with minimal overhead.
>> . Implements a new RPC to retrieve silent addresses, which allows users
>> to assign different labels to different addresses. That way, the user knows
>> which silent address the UTXO came from.
>>
>> Example:
>>
>> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
>> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>>
>> # This will return the same address as above (both have no label)
>> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
>> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>>
>> # New label, new address
>> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress 'donation'
>> tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt
>>
>> In this new scheme, the address has a new field called identifier, which
>> tells the receiver and sender how to set the address correctly.
>>
>> If the receiver, for whatever reason, doesn't know which identifiers have
>> been used, there is no problem. The wallet can scan all identifiers from 0
>> to 99. Currently, only 100 different identifiers per wallet are allowed.
>> This limit, however, can be increased at any time in the future.
>>
>> Unlike address formats so far, sp addresses are not script-related and
>> may eventually include any additional information needed, such as an
>> expiration timestamp (or block height). That way, users don't have to track
>> the address indefinitely.
>>
>> As usual I wrote a step by step tutorial:
>> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
>>
>> __

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Ruben Somsen via bitcoin-dev]

Hi David,

Thanks for the excellent suggestion, that makes the protocol much more
elegant and actually increases my optimism about its practicality. Also,
interesting observation that there is overlap with BIP78. From the
perspective of the recipient it does mean there's a potential privacy
reduction when a placeholder transaction goes through (these should perhaps
be marked in the wallet?), but I suppose this is still better than no
payment at all. I also like your point that it doubles as a way to
potentially bridge gaps.

Cheers,
Ruben







On Mon, Oct 3, 2022 at 12:48 AM David A. Harding  wrote:

> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
> > An alternative mitigation (more user friendly, but more implementation
> > complexity) would be to require the sender to reveal their intended
> > transaction to the server prior to receiving the address[^9]. This is
> > not a privacy degradation, since the server could already learn this
> > information regardless. If the transaction doesn't end up getting
> > sent, any subsequent attempt to reuse one of the inputs should either
> > be (temporarily) blacklisted or responded to with the same address
> > that was given out earlier
> > [...]
> > [^9]: *This would essentially look like an incomplete but signed
> > transaction where the output address is still missing.*
>
> Hi Ruben,
>
> Instead of maintaining a database of inputs that should be blocked or
> mapped to addresses, have the spender submit to you (but not the
> network) a valid transaction paying a placeholder address and in return
> give them a guaranteed unique address.  They can then broadcast a
> transaction using the same inputs to pay the guaranteed unique address.
> If you don't see that transaction within a reasonable amount of time,
> broadcast the transaction paying the placeholder address.  This makes it
> cost the same to them whether they use the unique address or not.  By
> placeholder address, I mean an address of yours that's never received a
> payment but which may have been provided in a previous invoice (e.g. to
> prevent exceeding the gap limit).
>
> In short, what I think I've described is the BIP78 payjoin protocol
> without any payjoining going on (which is allowed by BIP78).  BTCPay
> already implements BIP78, as do several wallets, and I think it
> satisfies all the design constraints you've described.
>
> -Dave
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

[Ruben Somsen via bitcoin-dev]

Hi Bastien,

>Greg already has a draft design that addresses your concerns

Thanks, that is very nice. In that case I currently have no outstanding
objections.

>I'm curious why you would need more than one such output

My reasoning was actually to allow only one OP_TRUE output per transaction,
so I think we agree. Apologies if that wasn't clear.

To summarize:

1. OP_TRUE output must be spent
2. Only one child allowed per transaction

This ensures there is no scenario where a child is propagated that does not
spend the OP_TRUE output.

Cheers,
Ruben

On Fri, Sep 30, 2022 at 2:17 PM Greg Sanders  wrote:

> It's likely better if the ephemeral output can be any value, including
> dust. This lets contract designers put "trimmed output" value indirectly
> towards CPFP fees without making the parent tx have fees itself.
>
> On Fri, Sep 30, 2022, 8:08 AM Bastien TEINTURIER  wrote:
>
>> Hey Ruben,
>>
>> I discussed this further over IRC, and I now agree that this particular
>> change would be very desirable and can likely fit in the initial release
>> (even though I'm not the one writing that code, but I'd be happy to
>> review it and test it).
>>
>> Greg already has a draft design that addresses your concerns: if there is
>> an "ephemeral output" (0-value, OP_TRUE) in an unconfirmed v3 transaction,
>> it MUST be spent by any child v3 transaction. This way, you ensure that
>> any child transaction spending the unconfirmed parent spends the ephemeral
>> output(s). @Greg, correct me if I misunderstood something here. Note that
>> we will need to precisely define the criteria for those "ephemeral
>> outputs"
>> (it can probably simply be "outputs that are 0 sats").
>>
>> Coupled with transactions that pay no fees (and thus require a child to
>> CPFP in order to be included in a block), this ensures those outputs can
>> never leak into the utxo set. How does that sound?
>>
>> I'm curious why you would need more than one such output, can you detail?
>> I believe we only ever need one, spendable by anyone.
>>
>> Cheers,
>> Bastien
>>
>> Le ven. 30 sept. 2022 à 02:14, Ruben Somsen  a écrit :
>>
>>> 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@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 
 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 th

Re: [bitcoin-dev] Trustless Address Server ? Outsourcing handing out addresses

[Ruben Somsen via bitcoin-dev]

Hi Peter,

Thanks for your comments.

>handing out xpubs makes the gap limit problem quadratic

Yes, my thinking on this is that if you're handing out xpubs you can lower
the gap limit for addresses generated by those xpubs, provided you assume
those addresses will be used by the same person, so there is less of a
reason to expect a gap. This thread is related:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020954.html

>How can we make a layer 1 address that expires

This was brought up by Sjors Provoost in relation to Silent Payments. He
suggested embedding a sunset date in the address format.

>Could there be some more exotic deterministic path that doesn't split
receive and change addresses

I don't follow this one. I see no reason not to split the two, and I do see
potential pitfalls when you don't. Conceptually, I think receiving money
twice on the same address is never good. Even if you're doing it to
actively mislead people, that attempt is still leaking information that
simply didn't need to be leaked.

Cheers,
Ruben

On Sat, Oct 1, 2022 at 10:57 AM Peter via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Ruben,
>
>
> I think this is an important conversation you have raised. I want to add
> some points for discussion.
>
>
> 1) handing out xpubs makes the gap limit problem quadratic.
>
>
> Each customer, of a given business, on an invoice must be given a unique
> address or xpub but they may pay in cash or credit card or bank wire. How
> do we present more than 20 customers with an "invoice address" (regular
> address or xpub)?
>
> (In Lightning world you give a Lightning address that uses plus addresses.
> Like castiron+customer1.invoi...@lsp.com
>
>
> If you hand out xpubs it can be the case that you hand out a consecutive
> streak of 20 xpubs that are never used. Your wallet has to scan 20 xpubs
> and their 20 first receive addresses.
>
>
>
> 2) Whether you give the sender an address for reuse or an xpub for reuse
> there needs to be an expiry such that the receiver can confirm they still
> have the corresponding keys. How can we make a layer 1 address that expires
> like a PGP key where it can still be used but raises a warning to the
> sender?
>
> (In Lightning we have that)
>
>
> 3) Could there be some more exotic deterministic path that doesn't split
> receive and change addresses? What is the first principle of splitting
> change and receive? What's wrong with an address reused exactly twice? The
> sender and receiver both with know what was a payment and what was change.
> Will it create plausible deniability about change addresses?
>
>
> Satoshi original wallet concept was an ever growing key pool with a 100
> address "gap". Maybe the solution to the gap limit is to add invoice
> functionality to wallets that manage issuing fresh addresses even without
> them being used and have a configurable gap limit. Is that what
> Btcpayserver does?
>
>
> Regards
>
> Peter Kroll
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] Third version of Silent Payment implementation

[Ruben Somsen via bitcoin-dev]

Hi woltx,

Excellent work.

>Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead

To expand on this, the scheme basically allows the resulting address to be
recognizably marked (only recognizable by the recipient of course), which
enables you to distinguish between different payment purposes (e.g. some
people donate to you for purpose A, others for purpose B). Here's my
original comment describing it:

"Naively, the issue is that two keys means twice the scanning, but an
interesting alternative would be to simply use the same key (assuming
you're OK with using the same identity) but add a public identifier f to it
when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*G
. This means every additional "address" only costs one additional ECC
addition when scanning (relatively cheap compared to doing ECC
multiplications).

The main downside with this is that f becomes crucial for recovering from
backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
remember how many "addresses" you issued (and perhaps overshoot when
unsure) to ensure recovery of funds, though of course you'd rather also
remember which index is associated with what payment reason.

Absolute worst case scenario you could even do something similar to the gap
limit where you scan the full history (not just the UTXO set so you don't
miss spent outputs) with a default max index of e.g. 100, and then if you
find out most of them are in use, you scan the next 100, etc. Costly, but
thorough, and only needed as a last resort."

Original comment here:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing

Also good to note that f needs to be communicated to the sender somehow,
perhaps as part of the address format.

Cheers,
Ruben

On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> This new version addresses most (or all) requests made in PR:
>
> . Implements the new scheme suggested by Ruben Somsen that allows multiple
> silent addresses per wallet with minimal overhead.
> . Implements a new RPC to retrieve silent addresses, which allows users to
> assign different labels to different addresses. That way, the user knows
> which silent address the UTXO came from.
>
> Example:
>
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>
> # This will return the same address as above (both have no label)
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>
> # New label, new address
> ./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress 'donation'
> tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt
>
> In this new scheme, the address has a new field called identifier, which
> tells the receiver and sender how to set the address correctly.
>
> If the receiver, for whatever reason, doesn't know which identifiers have
> been used, there is no problem. The wallet can scan all identifiers from 0
> to 99. Currently, only 100 different identifiers per wallet are allowed.
> This limit, however, can be increased at any time in the future.
>
> Unlike address formats so far, sp addresses are not script-related and may
> eventually include any additional information needed, such as an expiration
> timestamp (or block height). That way, users don't have to track the
> address indefinitely.
>
> As usual I wrote a step by step tutorial:
> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC for a BIP32 recurrent address derivation scheme

[Ruben Somsen via bitcoin-dev]

Hi Eloy,

Nice idea.

Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing

I agree with your general assessment that this is a scheme that seems like
an improvement over the status quo. Note that both BIP47 and Silent
Payments don't require any interaction with the sender, while this scheme
requires one-time interaction (e.g. this wouldn't be suitable for one-time
donations). I think this would mostly be a convenience feature that
improves the regular interactive payment flow (interact once, instead of
repeatedly asking for addresses with each payment).

>master / purpose' / coin_type' / contact' / index

Despite your explanation, it's still not fully clear to me how "contact" is
defined, but I assume it's just a counter? Just in case, note that you
can't let Bob define it for Carol, as then you can't deterministically
recover your payments without also backing up how it's defined (the seed
alone won't be enough).

The gap limit also needs to be kept in mind. If we allow each xpub to have
its own gap limit, you potentially get an exponential blowup (gaps in the
xpub * gaps in the addresses generated from the xpubs). It may be OK to
define a low default gap limit for these xpubs, since there should be no
reason to expect the same sender to leave any gaps, though this may depend
on how the xpubs are used (e.g. it may also be used to derive addresses for
others) so it's probably important to be explicit about this.

Cheers,
Ruben



On Thu, Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is a known issue on bitcoin, that is that every transaction requires
> a new address to prevent address reuse, making it uncomfortable to make
> recurring payments, as every payment requires a new off-chain interaction.
> A scheme is already mentioned on the [on the BIP32 itself][1], but it
> cannot be implemented as is.
>
> Here I propose a scheme that follows the structure described on [BIP44]
> that should make it possible to send recurring payments using a single
> offline interaction.
>
> The proposed scheme is:
>
> master / purpose' / coin_type' / contact' / index
>
> Where the definitions of all the levels follow BIP44, except for `contact`
> that is described below.
>
> Example usage: Bob wants to make recurring payments to Carol, so he asks
> her for a _contact address_, that is, an extended public key.
>
> Bob can use that public key to generate multiple derived addresses to make
> multiple recurring payments to Carol, the contact address is stored
> off-chain, anyone inspecting the chain will just see normal transactions
> on-chain.
>
> ## Considerations
>
> [BIP47] tries to solve the same issue, but the solution is more complex
> and involves more on-chain transactions that involve data, this
> implementation simpler and requires less work to implement.
>
> Also, the derivation path might need some adjustments for different
> address types on bitcoin.
>
> Finally, this only works in a single direction and does not make it
> possible for Carol to send anything to Bob, as it would require Bob sending
> her a contact address.
>
> ## Advantages
>
> A positive side effect of using this, is that Bob can choose to send
> payments to Carol using multiple outputs, giving him more privacy.
>
> Also, those payments can be easily labeled by the receiving wallet, as
> they are received.
>
> Regards.
>
> ### References
>
> [1]:
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0
> [BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
> "Reusable Payment Codes for Hierarchical Deterministic Wallets"
> [BIP43]:
> https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose
>
> --- Eloy
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Ruben Somsen via bitcoin-dev]

Hi all,

In short, this is yet another way to hand out addresses without interaction
between sender and recipient (Silent Payments, BIP47). The idea here is
that in non-ideal cases where you're already exposing your xpub to a server
(most light clients today, unfortunately), you might as well rely on them
to hand out addresses on your behalf.

Other than BTCPay Server, I am not aware of any serious attempts of
exploring this direction. Perhaps this is justified, due to the difficulty
of dealing with the gap limit, but it seems worth discussing nonetheless.

The write-up is available (and kept up-to-date) here as a gist:
https://gist.github.com/RubenSomsen/960ae7eb52b79cc826d5b6eaa61291f6

And here's a copy for the list:


### Introduction

Address reuse prevention generally requires interacting with the recipient
in order to receive a fresh address for each payment. There are various
protocols that ensure no interaction is required such as BIP47[^1] and
Silent Payments[^2], though neither is without downsides.

One area that is seemingly underexplored is that of outsourced interaction.
BTCPay Server[^3] is an example of this. The sender interacts with a
server, which acts on behalf of the recipient and hands out an address from
an xpub. The recipient controls and therefore trusts the server, so
malicious addresses won't be given out.

### Outsourcing and Malicious Keys

The vast majority of light clients today (even ones that support BIP47,
curiously) already control the user's xpub, so it seems logical to think
the interaction can be outsourced to them. However, unlike when running
your own server, a third party server *could* potentially hand out
malicious addresses (i.e. addresses that belong to someone other than you).

The solution to this is identity. As long as the sender knows a public key
by which the recipient can be identified, the recipient can sign the
addresses that are derived from their xpub[^4]. This way the sender can be
sure that the address it receives from the server belongs to the recipient.

### Gap Limit

One big remaining problem is the gap limit[^5]. When an adversary
repeatedly requests addresses from the server but then never uses them,
this could result in a large gap of unused addresses. This is a problem
because when recovering from backup the wallet stops looking for payments
when a large enough gap is encountered. Unfortunately there is no perfect
solution, but mitigations are still possible.

Whenever a sender wants to make their first payment, they could be expected
to obtain an address at a cost (solving captchas, paying over LN,
proof-of-burn[^6]). If the sender doesn't mind (or maybe even desires)
having their payments correlated by the recipient, a fresh xpub[^7] can be
handed out instead of an address in order to enable repeated payments. If
non-correlated payments are preferable, after each successful payment the
server could hand out a blind ecash[^8] token that entitles the sender to
another address.

An alternative mitigation (more user friendly, but more implementation
complexity) would be to require the sender to reveal their intended
transaction to the server prior to receiving the address[^9]. This is not a
privacy degradation, since the server could already learn this information
regardless. If the transaction doesn't end up getting sent, any subsequent
attempt to reuse one of the inputs should either be (temporarily)
blacklisted or responded to with the same address that was given out
earlier[^10].

If despite best efforts the gap limit is inadvertently reached anyway, the
recipient may have to be instructed to ensure they properly receive a
payment to bridge the gap before new addresses can be handed out. The
alternative is to forego privacy when this happens, but this seems unwise.

### Use Case

This protocol seems useful for users that a.) want to use light clients,
b.) accept the privacy degradation of handing out their xpub to a third
party, and c.) want to receive payments non-interactively. If any one of
these is not true, other protocols are likely to be a better choice[^11].
Finally, it should be acknowledged that this protocol introduces more
friction on the sender side due to the need for a gap limit mitigation
strategy.

-- Ruben Somsen


[^1]: BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

[^2]: Silent Payments:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8

[^3]: BTCPay Server https://btcpayserver.org/

[^4]: *Specifically, this could be a single signature on a merkle root, so
the amount of data that the recipient needs to send to the server can be
minimized and the server can just generate the same tree from the xpub and
hand out merkle proofs to senders. The order of the leaves should be
randomized so senders cannot learn how many payments were made.*

[^5]: Gap limit:
https://bitcoin.stackexchange.com/questions/111534/bitcoin-address-gap-limit

[^6]: Efficient Proof-of-Burn:
https://lists.linu

Re: [bitcoin-dev] New BIP: Private Payments

[Ruben Somsen via bitcoin-dev]

Hi Alfred,

Thanks for all the effort.

Note that in the previous thread I mentioned[0] that this proposal
introduces a scanning requirement in order to detect incoming notifications
(complicating light client implementation). I recommend that you put this
information in the BIP, as this is an important downside that readers
should be aware of.

I'm also now realizing that your proposal is actually *very* similar to the
BIP47 protocol improvement suggestions that were made in Prague:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae

As far as I can tell, the one difference is that you added an extra ECDH
calculation to hide the recipient payment code. Uncoincidentally, this is
also exactly what causes the downside of having a scanning requirement, and
it seems the only benefit you get in return is that you don't have to
outsource the notification (as is the case in the Prague protocol) and can
broadcast it yourself instead. I'm personally unsure whether this is a net
improvement, but that is certainly open to debate. I'd say it's worth
having this discussion prior to finalizing the BIP, as otherwise it could
potentially result in yet another incompatible standard further down the
line.

Considering the similarity, perhaps you could consider crediting the
participants of the Prague discussion (namely Alekos Filini, Martin
Habovštiak, and myself). And I imagine Silent Payments[1] may have served
as an inspiration as well. I also recommend taking another look at the
"Allowing collisions" paragraph from the Prague discussion, as it can
potentially shave off up to 28 bytes.

I hope you find this feedback reasonable and it doesn't discourage you.
There's way too much work to be done on Bitcoin, so I'm happy to see you
are actively putting in the effort to move things forward. Working out the
details such as how to handle address formats is also very much
appreciated. Keep it up.

Cheers,
Ruben


[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020607.html

[1] https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8



On Sat, Jul 30, 2022 at 1:59 PM Alfred Hodler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> We propose a new BIP that facilitates more private two-party transactions.
> This is a strict improvement upon BIP47, with increased privacy and better
> future-proofing.
>
> The contents may be found here:
>
> https://github.com/alfred-hodler/bips/blob/bip-alfredhodler-private-payments/bip-alfredhodler-privatepayments.mediawiki
>
> We hope to collect feedback and be assigned with a BIP number. A reference
> implementation will be published once the BIP is deemed viable.
>
> Alfred
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How to do Proof of Micro-Burn?

[Ruben Somsen via bitcoin-dev]

Good evening ZmnSCPxj,

>I suppose that means that the knower of `k` is a trusted party; it is
trusted to only issue commitments and not generate fake ones

Then you can reduce the scheme to just committing to K and having that key
sign whatever the burn was intended for. I doubt this is useful in practice.

>can you please explain

The goal is to burn multiple amounts (10, 20, 30, 40) in a single OP_RETURN
(100) and specifically indicating how much of the total is intended for
what use case. A merkle sum tree achieves this.

(1a)  100  (1b)  ABCD   (2a)  100 (2b)  ABCD
/\  /\  /\ /\
  30  70  AB  CD  30  70 AB  CD
 /  \/  \/  \/  \/  \   /  \
10  20  30  40   A  BC  D   10  20  A  B

(view as monospace font, e.g. via bitcoin-dev archive)

So while in a normal merkle tree (1a) you hash e.g. A and B to get AB, with
a sum tree (1b) you also hash 10 and 20 to get 30.

When you verify the full merkle sum proof (2a + 2b, combined in a single
tree), you verify that 10 (A) + 20 (B) add up to 30 (AB), and 30 (AB) + 70
(CD) add up to 100 (ABCD), else the root hash won't match.

This ensures that you can't create a valid tree with commitments that
add up to more than the burned amount (essentially a "double spend").

>the buyer has every incentive to actually pay

Not if you never had any intention of buying it and are just trying to run
them out of business.

Hope this helps!

Cheers,
Ruben



On Tue, Jul 19, 2022 at 4:48 PM ZmnSCPxj  wrote:

>
> Good morning Ruben,
>
> > 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)?
>
> I believe this is only possible for somebody who knows `k`?
> As mentioned, an opening here includes a signature using `b + k` as the
> private key, so the signature can only be generated with knowledge of both
> `b` and `k`.
>
> I suppose that means that the knower of `k` is a trusted party; it is
> trusted to only issue commitments and not generate fake ones.
>
> > 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.
>
> I do not understand what this property is and how it is relevant, can you
> please explain this to a non-mathematician?
>
> > 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.
>
> A buyer can indeed impose this cost on the seller, though the buyer then
> is unable to get a valid opening of its commitment, as it does not know `k`.
> Assuming the opening of the commitment is actually what has value (since
> the lack of such an opening means the buyer cannot prove the commitment)
> then the buyer has every incentive to actually pay for the opening.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How to do Proof of Micro-Burn?

[Ruben Somsen via bitcoin-dev]

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  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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How to do Proof of Micro-Burn?

[Ruben Somsen via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP proposal] Private Payments

[Ruben Somsen via bitcoin-dev]

Hi Bryan,

>just publishing on a tor hidden service that other wallets check

The problem is that this data is critical to access the funds. By putting
it on-chain you're guaranteeing that it's always available when you restore
your funds from backup.

Cheers,
Ruben

On Mon, Jun 27, 2022 at 10:21 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 2. Notification transactions still exist but no longer leave a privacy
>> footprint on the blockchain. Instead, a notification transaction is simply
>> a single OP_RETURN containing a value that only Alice and Bob can
>> calculate. If Alice's notification transaction uses UTXOs not associated
>> with her identity, there is never a footprint showing that either her or
>> Bob are using private payments. If Alice uses tainted coins, only she is
>> exposed as a user of Private Payments but Bob still isn't.
>>
>
> That's a neat trick. What about not using OP_RETURN at all, and just
> publishing on a tor hidden service that other wallets check?  Alice
> wouldn't have to expose on-chain that she is a sender of a private payment.
>
> - Bryan
> https://twitter.com/kanzure
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP proposal] Private Payments

[Ruben Somsen via bitcoin-dev]

Hi Alfred,

Thanks for taking the time to write a proposal.

>The inability of payment codes to explicitly state which address types
they derive places a burden on more resource constrained wallets

I agree it's not as efficient as it could be, but how big is this problem
in practice? Expecting payments on more addresses doesn't seem like a huge
overhead. Or are you talking about the hassle of having to support spending
from all these address types?

>a notification transaction is simply a single OP_RETURN containing a value
that only Alice and Bob can calculate

This seems to be the meat of the proposal. You're hiding the intended
recipient, but in doing so you introduce a scanning requirement. Of course
you only need to scan notification transactions, so it'll be much less
heavy than Silent Payments*, but it does make it rather difficult to
support light clients.

If some degree of scanning is acceptable, then Robin Linus' scheme may be
an interesting alternative:
https://gist.github.com/RobinLinus/4e7467abaf0a0f8a521d5b512dca4833

The basic idea is that everyone publishes a single pubkey on-chain, and
everyone derives a shared secret with everyone else's pubkey. It also
requires "scanning", but the number of transactions will be lower as it's
one tx per new pubkey as opposed to one tx per sender/recipient pair. This
also means it uses far less block space. The main downside is that you have
to watch as many incoming addresses as there are registered pubkeys, but
this could be indexed relatively efficiently. Also not light client
friendly, though.

And then of course there's the recent BIP47 discussion:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020549.html

This proposes to outsource the publishing of the notification transaction
in order to break the link (as well as reduce block space usage). There's
no scanning, so this preserves light client support, but the downside here
is that you now need to anonymously pay a third party (e.g. over LN).

>demand that a notification transaction meets some minimum miner fee

Note that this mechanism is not safe against miners, as they can pay
themselves arbitrarily high fees with no downside.

Hope this helps.

Cheers,
Ruben


*Silent Payments:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8

On Mon, Jun 27, 2022 at 9:14 PM Alfred Hodler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> There have been attempts to create static payment codes that function as a
> way for transacting parties to create "private" addresses, where private
> stands for "known only to transacting parties". BIP47 was one such standard.
>
> The standard suffered from a number of problems:
>
> 1. The standard promised extensibility through versioning but it never
> used that capability to follow innovations in the Bitcoin protocol. It was
> designed around the idea that legacy p2pkh addresses would always be the
> primary and only way to transact. As new standard script types started to
> emerge (Segwit v0, Taproot), the creators dealt with the problem by stating
> that implementing wallets should scan for all existing standard scripts.
> The inability of payment codes to explicitly state which address types they
> derive places a burden on more resource constrained wallets.
>
> 2. The standard relied on a notification mechanism in order to connect a
> sender with a recipient, which included either offchain technology
> (Bitmessage), or so called "notification addresses" which a) left a
> footprint b) created toxic change. That type of footprint is particularly
> harmful because it makes it obvious that a particular recipient is going to
> receive private transactions. If the notifying party performs this process
> with coins linked to its identity (i.e. tainted or non-anonymized inputs),
> it forever becomes visible that Alice connected with Bob despite the fact
> that her payment code was blinded. While future transactions and their
> amounts aren't visible, this metadata makes it possible to build a social
> graph.
>
> 3. The standard was implemented only by an entity that disavowed the BIP
> process and didn't wish to use it to keep the standard up to date. Further
> updates did take place but only outside the BIP process, creating a lack of
> clarity as to what the real specification is. Ultimately the standard was
> abandoned.
>
> I propose to build on the idea of payment codes under a new BIP with the
> following principal differences:
>
> 1. The new standard will allocate a 2-byte bitflag array that will signal
> address/script types that the receiver is deriving. Since the vast majority
> of scripts are p2pkh (47.3%) and p2wpkh (26.2%), bits 0 and 1 will be used
> for those respectively. Bit 2 will be p2tr. The remaining 13 bits are
> reserved for future standard script types.
>
> 2. Notification transactions still exist but no longer leave a privacy
> footprint on the blockchain. Instead, a notification transacti

[bitcoin-dev] BIP47 Prague Discussion

[Ruben Somsen via bitcoin-dev]

This discussion took place at Pizza Day Prague 2022[0] after a brief
discussion on Silent Payments[1]. The main points have been summarized
below.

The discussion was mainly between Alekos Filini, Martin Habovštiak, and
myself, as well as Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore
Ingala, and others.

Also available as a gist:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae

And my personal opinion can be found in the comments:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=4197284#gistcomment-4197284


Improving BIP47

BIP47 requires a notification transaction prior to making payments. This
transaction takes up on-chain space and can easily leak privacy if not
handled with extreme caution. In practice this is quite hard.

The discussion revolved around whether we can a.) minimize the on-chain
space required and b.) outsource the notification transaction so the link
between the sender and recipient is no longer apparent on-chain.


BIP47 space requirements

As currently implemented, BIP47 (V1/V2)[2] requires an input key for
blinding, the blinded sender payment code in an op_return, and the
recipient key in an output.

The first question that came up was whether it is necessary for the
recipient to learn the payment code of the sender. The benefit is that this
enables the recipient to send a notification transaction and subsequent
payment to the sender, but in practice this never happens. It therefore
seems acceptable to forego this requirement, as this potentially saves
space. The minimum notification payload that seems required is a fresh
sender key and a static recipient key.

The sender key should ideally be deterministically derived from the sender
xpub based on the recipient key. If the user checks all the keys that were
registered with the recipient prior to notification, it can statelessly
find out whether the sender key was already previously registered. This
step can be skipped, which is easier for light clients, but means the
notification transaction will have to be resent if the user ever forgets
they already sent a notification (such as when restoring from backup).


Outsourcing the notification

The next part of the discussion revolved around the idea of putting
multiple notifications in a single transaction that can be outsourced to a
third party in order to break the sender/recipient link. This third party
could be paid over the Lightning Network for their services.

One idea was to use the taproot annex to insert the notification payload as
(discounted) witness data. One downside with this approach is that it
requires custom software for the recipient to notice the notification,
since it's not tied to an easily noticeable output. The middle ground
solution would be to put the sender keys there but still create an output
for each recipient key.


Allowing collisions

One interesting point that came up was that you could represent the
recipient key using e.g. only 4 bytes (provided you put it in the annex).
This leaves a window of 1 in ~4.3 billion for a collision, but the extra
work that needs to be performed when it does happen is negligible
(essentially expecting a payment while there is none). This would reduce
the payload from 64 bytes to 36 bytes of witness data.

While this did not come up in the discussion, it should be noted that using
the annex makes the transaction non-standard[3]. It could either be
standardized as the first use case for the annex, or perhaps an alternative
method[4] should be considered.


[0] Pizza Day Prague 2022: https://www.pizzaday.cz

[1] Silent Payments:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8

[2] BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

[3] Annex non-standard:
https://github.com/bitcoin/bitcoin/pull/17977/files#diff-ea6d307faa4ec9dfa5abcf6858bc19603079f2b8e110e1d62da4df98f4bdb9c0R250

[4] Using p2wsh:
https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=4189419#gistcomment-4189419
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ruben Somsen via bitcoin-dev]

Hi Laolu,

> ignoring the rules leads to assets being burnt, but in most cases imo
that's a sufficient enough incentive to maintain and validate the relevant
set of witnesses

I agree it is sufficient, but only because using Bitcoin script without an
additional scripting language inside of Taro is already sufficient. Perhaps
you could show me a concrete example where you think replicating Bitcoin's
scripting capabilities inside Taro can be useful, so I can show you where I
think it fails.

> came up with a "issuance covenant" design sketch that may or may not be
useful

To summarize my view from my first post, I basically think there are two
broad exceptions to the "can't do scripting" rule:

1. Self-encumbrance: you have to use the token according to the rules, else
the token becomes burned/invalid. The example you're giving here can be
said to fall under this category. The usefulness of this is
extremely narrow, and merely replicating Bitcoin's script inside of Taro is
certainly not sufficient to achieve it.

2. On-chain validation: instead of keeping the satisfaction of the script
off-chain, you publish it on-chain in the Bitcoin blockchain. This works,
but breaks a fundamental design goal of Taro/RGB (remaining off-chain), and
adds significant complexity.

These two points lead me to my conclusion that off-chain validation
protocols (to rule out the exception in point 2) can't do any meaningful
(to rule out the exception in point 1) scripting.

This doesn't mean you can't still add some scripting to facilitate certain
use cases that fall under the two exceptions, but a regular scripting
language for on-chain payments such as Bitcoin's is not going to cut it (at
least not without significant changes).

Personally I'd be inclined to leave out the scripting language altogether
(as the encumbrance of Bitcoin UTXOs is sufficient in most cases), unless
you have a very specific and compelling use case in mind that justify the
complexity.

Cheers,
Ruben


On Mon, Apr 11, 2022 at 9:52 PM Olaoluwa Osuntokun 
wrote:

> Hi Ruben,
>
> > Also, the people that are responsible for the current shape of RGB aren't
> > the people who originated the idea, so it would not be fair to the
> > originators either (Peter Todd, Alekos Filini, Giacomo Zucco).
>
> Sure I have no problems acknowledging them in the current BIP draft. Both
> the protocols build off of ideas re client-side-validation, but then end up
> exploring different parts of the large design space.  Peter Todd is already
> there, but I can add the others you've listed. I might even just expand
> that
> section into a longer "Related Work" section along the way.
>
> > What I tried to say was that it does not make sense to build scripting
> > support into Taro, because you can't actually do anything interesting
> with
> > it due to this limitation.  can do with their own Taro tokens, or else he
> > will burn them – not very useful
>
> I agree that the usage will be somewhat context specific, and dependent on
> the security properties one is after. In the current purposefully
> simplified
> version, it's correct that ignoring the rules leads to assets being burnt,
> but in most cases imo that's a sufficient enough incentive to maintain and
> validate the relevant set of witnesses.
>
> I was thinking about the scripting layer a bit over the weekend, and came
> up
> with a "issuance covenant" design sketch that may or may not be useful. At
> a
> high level, lets say we extend the system to allow a specified (so a new
> asset type) or generalized script to be validated when an asset issuance
> transaction is being validated. If we add some new domain specific covenant
> op codes at the Taro level, then we'd be able to validate issuance events
> like:
>
>   * "Issuing N units of this assets can only be done if 1.5*N units of BTC
> are present in the nth output of the minting transaction. In addition,
> the output created must commit to a NUMs point for the internal key,
> meaning that only a script path is possible. The script paths must be
> revealed, with the only acceptable unlocking leaf being a time lock of
> 9
> months".
>
> I don't fully have a concrete protocol that would use something like that,
> but that was an attempt to express certain collateralization requirements
> for issuing certain assets. Verifiers would only recognize that asset if
> the
> issuance covenant script passes, and (perhaps) the absolute timelock on
> those coins hasn't expired yet. This seems like a useful primitive for
> creating assets that are somehow backed by on-chain BTC collateralization.
> However this is just a design sketch that needs to answer questions like:
>
>   * are the assets still valid after that timeout period, or are they
> considered to be burnt?
>
>   * assuming that the "asset key family" (used to authorize issuance of
> related assets) are jointly owned, and maintained in a canonical
> Universe, then would it be possible for 3rd p

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

[Ruben Somsen via bitcoin-dev]

Hi Laolu,

>happy to hear that someone was actually able to extract enough details
from the RGB devs/docs to be able to analyze it properly

Actually, even though I eventually puzzled everything together, this did
not go well for me either. There is a ton of documentation, but it's a maze
of unhelpful details, and none of it clearly maps out the fundamental
design. I was also disappointed by the poor response I received when asking
questions, and I ended up getting chastised for helping others understand
it and pointing out potential flaws[1][2][3].Given my experience, I think
the project is not in great shape, so the decision to rebuild from scratch
seems right to me.

That said, in my opinion the above should not factor into the decision of
whether RGB should be credited in the Taro documentation. The design
clearly precedes (and seems to have inspired) Taro, so in my opinion this
should be acknowledged. Also, the people that are responsible for the
current shape of RGB aren't the people who originated the idea, so it would
not be fair to the originators either (Peter Todd, Alekos Filini, Giacomo
Zucco).

>assets can be burnt if a user doesn't supply a valid witness

I am in agreement with what you said, but it is not clear to me whether we
are on the same page. What I tried to say was that it does not make sense
to build scripting support into Taro, because you can't actually do
anything interesting with it due to this limitation. The only type of smart
contract you can build is one where you limit what the owner (as defined by
Bitcoin's script) can do with their own Taro tokens, or else he will burn
them – not very useful. Anything involving a conditional transfer of
ownership to either A or B (i.e. any meaningful type of script) won't work.
Do you see what I mean, or should I elaborate further?

>TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transitions
at the Bitcoin level, without Bitcoin explicitly needing to be aware

That is conceptually quite interesting. So theoretically you could get
Bitcoin covenants to enforce certain spending conditions on Taro assets.
Not sure how practical that ends up being, but intriguing to consider.

>asset issuer to do a "re-genesis"

Yes, RGB suggested the same thing, and this can work under some
circumstances, but note that this won't help for tokens that aim to have a
publicly audited supply, as the proof that a token was legitimately
re-issued is the history of the previous token (so you'd actually be making
things worse, as now everyone has to verify it). And of course the idea
also requires the issuer to be active, which may not always be the case.

>I'm not familiar with how the RGB "teleport" technique works [...] Can you
point me to a coherent explanation of the technique

To my knowledge no good explanation exists. "Teleporting" is just what I
thought was a good way of describing it. Basically, in your design when
Alice wants to send a Taro token to Bob, Alice has to spend her own output,
make a new output for Bob, and make a change output for herself. Inside the
Taro tree you'll then point to the index of Bob's output in order to assign
the tokens to his new output. Instead of pointing to the index, you could
point to the outpoint (txid, index) of an existing UTXO owned by Bob, thus
"teleporting" the Taro tokens to this UTXO. This saves on-chain space, as
now you don't have to create a new output for Bob (but now you have to
ensure Bob doesn't spend from this output while you're simultaneously
sending tokens to it, as I mentioned in my previous post, as this would
destroy the tokens).

The above also reminds me of another potential issue which you need to be
aware of, if you're not already. Similar to my comment about how the
location of the Taro tree inside the taproot tree needs to be deterministic
for the verifier, the output in which you place the Taro tree also needs to
be. If it's not, then you can commit to a different Taro tree in each
output of the transaction, allowing you to secretly fork the history.

Hope this helps.

Cheers,
Ruben

[1] https://twitter.com/SomsenRuben/status/1397267261619064836
[2] https://twitter.com/SomsenRuben/status/1397559406565462017
[3] https://twitter.com/afilini/status/1397484341236797441

On Fri, Apr 8, 2022 at 7:48 PM Olaoluwa Osuntokun  wrote:

> (this might be a double post as it ran into the size limit)
>
> Hi Ruben,
>
> Thanks! I don't really consider things final until we have a good set of
> test
> vectors in the final set, after which we'd start to transition the set of
> documents beyond the draft state.
>
> > 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.
>
> I'm happy to hear that someone was actually able to extract enough details
> from
> the RGB devs/docs to be able to analyze it properly! In the past I tried
> to ask
> their developers ques

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

[Ruben Somsen via bitcoin-dev]

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 bette

Re: [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

[Ruben Somsen via bitcoin-dev]

d keys evenly divide it. Perhaps
>> that's what hashing was being used to solve. What if we added the shared
>> diffie hellman secret modulo N to remove this correlation:
>>
>> X' = i*X*G + X + (i*X)%N =  x*I*G + X + (x*I)%N
>>
>> Then for each `item = {recipient: X' % N, sender: I%N}`, we detect via
>> `item.recipient - X%N == x*item.sender*(1+G)`. Is my math right here?
>> I'm thinking this should work because (a+b%N)%N == (a%N + b%N)%N.
>>
>>
>>
>> On Tue, Mar 29, 2022 at 10:36 AM Ruben Somsen  wrote:
>>
>>> Hi Billy,
>>>
>>> Thanks for taking a look.
>>>
>>> >Maybe it would have been more accurate to say no *extra* on chain
>>> overhead
>>>
>>> I can see how it can be misinterpreted. I updated the gist to be more
>>> specific.
>>>
>>> >primary benefit of this is privacy for the recipient
>>>
>>> Fair, but just wanted to note the sender can get in trouble too if they
>>> send money to e.g. blacklisted addresses.
>>>
>>> >there could be a standard that [...] reduces the anonymity set a bit
>>>
>>> This has occurred to me but I am reluctant to make that trade-off. It
>>> seems best to first see how well this can be optimized without resorting to
>>> reducing anonymity, and it's hard to analyze exactly how impactful the
>>> anonymity degradation is (I suspect it's worse than you think because it
>>> can help strengthen existing heuristics about output ownership).
>>>
>>> Cheers,
>>> Ruben
>>>
>>>
>>>
>>> On Tue, Mar 29, 2022 at 4:57 PM Billy  wrote:
>>>
>>>> Hi Ruben,
>>>>
>>>> Very interesting protocol. This reminds me of how monero stealth
>>>> addresses work, which gives monero the same downsides regarding light
>>>> clients (among other things). I was a bit confused by the following:
>>>>
>>>> > without requiring any interaction or on-chain overhead
>>>>
>>>> After reading through, I have to assume it was rather misleading to say
>>>> "no on-chain overhead". This still requires an on-chain transaction to be
>>>> sent to the tweaked address, I believe. Maybe it would have been more
>>>> accurate to say no *extra* on chain overhead (over a normal transaction)?
>>>>
>>>> It seems the primary benefit of this is privacy for the recipient. To
>>>> that end, it seems like a pretty useful protocol. It's definitely a level
>>>> of privacy one would only care about if they might receive a lot money
>>>> related to that address. However of course someone might not know they'll
>>>> receive an amount of money they want to be private until they receive it.
>>>> So the inability to easily do this without a full node is slightly less
>>>> than ideal. But it's another good reason to run a full node.
>>>>
>>>> Perhaps there could be a standard that can identify tweaked address,
>>>> such that only those addresses can be downloaded and checked by light
>>>> clients. It reduces the anonymity set a bit, but it would probably still be
>>>> sufficient.
>>>>
>>>>
>>>>
>>>> On Mon, Mar 28, 2022, 10:29 Ruben Somsen via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm publishing a new scheme for private non-interactive address
>>>>> generation without on-chain overhead. It has upsides as well as downsides,
>>>>> so I suspect the main discussion will revolve around whether this is worth
>>>>> pursuing or not. There is a list of open questions at the end.
>>>>>
>>>>> I added the full write-up in plain text below, though I recommend
>>>>> reading the gist for improved formatting and in order to benefit from
>>>>> potential future edits:
>>>>> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8
>>>>>
>>>>> Cheers,
>>>>> Ruben
>>>>>
>>>>>
>>>>>
>>>>> Silent Payments
>>>>>
>>>>> Receive private payments from anyone on a single static address
>>>>> without requiring any interaction or on-chain overhead
>>>>>
>>>>>
>>>>>
>>>>

Re: [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

[Ruben Somsen via bitcoin-dev]

Hi Billy,

Thanks for taking a look.

>Maybe it would have been more accurate to say no *extra* on chain overhead

I can see how it can be misinterpreted. I updated the gist to be more
specific.

>primary benefit of this is privacy for the recipient

Fair, but just wanted to note the sender can get in trouble too if they
send money to e.g. blacklisted addresses.

>there could be a standard that [...] reduces the anonymity set a bit

This has occurred to me but I am reluctant to make that trade-off. It seems
best to first see how well this can be optimized without resorting to
reducing anonymity, and it's hard to analyze exactly how impactful the
anonymity degradation is (I suspect it's worse than you think because it
can help strengthen existing heuristics about output ownership).

Cheers,
Ruben



On Tue, Mar 29, 2022 at 4:57 PM Billy  wrote:

> Hi Ruben,
>
> Very interesting protocol. This reminds me of how monero stealth addresses
> work, which gives monero the same downsides regarding light clients (among
> other things). I was a bit confused by the following:
>
> > without requiring any interaction or on-chain overhead
>
> After reading through, I have to assume it was rather misleading to say
> "no on-chain overhead". This still requires an on-chain transaction to be
> sent to the tweaked address, I believe. Maybe it would have been more
> accurate to say no *extra* on chain overhead (over a normal transaction)?
>
> It seems the primary benefit of this is privacy for the recipient. To that
> end, it seems like a pretty useful protocol. It's definitely a level of
> privacy one would only care about if they might receive a lot money related
> to that address. However of course someone might not know they'll receive
> an amount of money they want to be private until they receive it. So the
> inability to easily do this without a full node is slightly less than
> ideal. But it's another good reason to run a full node.
>
> Perhaps there could be a standard that can identify tweaked address, such
> that only those addresses can be downloaded and checked by light clients.
> It reduces the anonymity set a bit, but it would probably still be
> sufficient.
>
>
>
> On Mon, Mar 28, 2022, 10:29 Ruben Somsen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> I'm publishing a new scheme for private non-interactive address
>> generation without on-chain overhead. It has upsides as well as downsides,
>> so I suspect the main discussion will revolve around whether this is worth
>> pursuing or not. There is a list of open questions at the end.
>>
>> I added the full write-up in plain text below, though I recommend reading
>> the gist for improved formatting and in order to benefit from potential
>> future edits:
>> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8
>>
>> Cheers,
>> Ruben
>>
>>
>>
>> Silent Payments
>>
>> Receive private payments from anyone on a single static address without
>> requiring any interaction or on-chain overhead
>>
>>
>>
>> OVERVIEW
>>
>>
>> The recipient generates a so-called silent payment address and makes it
>> publicly known. The sender then takes a public key from one of their chosen
>> inputs for the payment, and uses it to derive a shared secret that is then
>> used to tweak the silent payment address. The recipient detects the payment
>> by scanning every transaction in the blockchain.
>>
>> Compared to previous schemes[1], this scheme avoids using the Bitcoin
>> blockchain as a messaging layer[2] and requires no interaction between
>> sender and recipient[3] (other than needing to know the silent payment
>> address). The main downsides are the scanning requirement, the lack of
>> light client support, and the requirement to control your own input(s). An
>> example use case would be private one-time donations.
>>
>> While most of the individual parts of this idea aren’t novel, the
>> resulting protocol has never been seriously considered and may be
>> reasonably viable, particularly if we limit ourselves to detecting only
>> unspent payments by scanning the UTXO set. We’ll start by describing a
>> basic scheme, and then introduce a few improvements.
>>
>>
>>
>> BASIC SCHEME
>>
>>
>> The recipient publishes their silent payment address, a single 32 byte
>> public key:
>> X = x*G
>>
>> The sender picks an input containing a public key:
>> I = i*G
>>
>> The sender tweaks the silent payment address with the public key of their
>>

[bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

[Ruben Somsen via bitcoin-dev]

Hi all,

I'm publishing a new scheme for private non-interactive address generation
without on-chain overhead. It has upsides as well as downsides, so I
suspect the main discussion will revolve around whether this is worth
pursuing or not. There is a list of open questions at the end.

I added the full write-up in plain text below, though I recommend reading
the gist for improved formatting and in order to benefit from potential
future edits:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8

Cheers,
Ruben



Silent Payments

Receive private payments from anyone on a single static address without
requiring any interaction or on-chain overhead



OVERVIEW


The recipient generates a so-called silent payment address and makes it
publicly known. The sender then takes a public key from one of their chosen
inputs for the payment, and uses it to derive a shared secret that is then
used to tweak the silent payment address. The recipient detects the payment
by scanning every transaction in the blockchain.

Compared to previous schemes[1], this scheme avoids using the Bitcoin
blockchain as a messaging layer[2] and requires no interaction between
sender and recipient[3] (other than needing to know the silent payment
address). The main downsides are the scanning requirement, the lack of
light client support, and the requirement to control your own input(s). An
example use case would be private one-time donations.

While most of the individual parts of this idea aren’t novel, the resulting
protocol has never been seriously considered and may be reasonably viable,
particularly if we limit ourselves to detecting only unspent payments by
scanning the UTXO set. We’ll start by describing a basic scheme, and then
introduce a few improvements.



BASIC SCHEME


The recipient publishes their silent payment address, a single 32 byte
public key:
X = x*G

The sender picks an input containing a public key:
I = i*G

The sender tweaks the silent payment address with the public key of their
input:
X' = hash(i*X)*G + X

Since i*X == x*I (Diffie-Hellman Key Exchange), the recipient can detect
the payment by calculating hash(x*I)*G + X for each input key I in the
blockchain and seeing if it matches an output in the corresponding
transaction.



IMPROVEMENTS


UTXO set scanning

If we forgo detection of historic transactions and only focus on the
current balance, we can limit the protocol to only scanning the
transactions that are part of the UTXO set when restoring from backup,
which may be faster.

Jonas Nick was kind enough to go through the numbers and run a benchmark of
hash(x*I)*G + X on his 3.9GHz Intel® Core™ i7-7820HQ CPU, which took
roughly 72 microseconds per calculation on a single core. The UTXO set
currently has 80 million entries, the average transaction has 2.3 inputs,
which puts us at 2.3*8000*72/1000/1000/60 = 221 minutes for a single
core (under 2 hours for two cores).

What these numbers do not take into account is database lookups. We need to
fetch the transaction of every UTXO, as well as every transaction for every
subsequent input in order to extract the relevant public key, resulting in
(1+2.3)*8000 = 264 million lookups. How slow this is and what can be
done to improve it is an open question.

Once we’re at the tip, every new unspent output will have to be scanned.
It’s theoretically possible to scan e.g. once a day and skip transactions
with fully spent outputs, but that would probably not be worth the added
complexity. If we only scan transactions with taproot outputs, we can
further limit our efforts, but this advantage is expected to dissipate once
taproot use becomes more common.


Variant using all inputs

Instead of tweaking the silent payment address with one input, we could
instead tweak it with the combination of all input keys of a transaction.
The benefit is that this further lowers the scanning cost, since now we
only need to calculate one tweak per transaction, instead of one tweak per
input, which is roughly half the work, though database lookups remain
unaffected.

The downside is that if you want to combine your inputs with those of
others (i.e. coinjoin), every participant has to be willing to assist you
in following the Silent Payment protocol in order to let you make your
payment. There are also privacy considerations which are discussed in the
“Preventing input linkage” section.

Concretely, if there are three inputs (I1, I2, I3), the scheme becomes:
hash(i1*X + i2*X + i3*X)*G + X == hash(x*(I1+I2+I3))*G + X.


Scanning key

We can extend the silent payment address with a scanning key, which allows
for separation of detecting and spending payments. We redefine the silent
payment address as the concatenation of X_scan, X_spend, and derivation
becomes X' = hash(i*X_scan)*G + X_spend. This allows your
internet-connected node to hold the private key of X_scan to detect
incoming payments, while your hardware wallet controls X_spend to make
payments. If X_scan is compro

Re: [bitcoin-dev] OP_RETURN inside TapScript

[Ruben Somsen via bitcoin-dev]

In Q = P + hash(P||commitment)G you cannot spend from Q without knowing
both the private key of P as well as the commitment (i.e. 32 bytes,
assuming the commitment itself is another hash). This is generally not a
problem for tapscript, as the scripts are deterministically generated (i.e.
backing up the policy once is sufficient), but what you are suggesting is
not deterministic. Hope that clarifies things.

On Thu, Feb 24, 2022 at 2:27 PM  wrote:

> > 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.
>
> I don't think so. You can spend coins from taproot by key or by script. If
> you spend by key, making backup is simple, we have WIF for that. If you
> spend by script, you only need a part of the tree. So, you can "recover the
> key without knowing the full commitment", because you can spend coins
> "without knowing the full commitment". On-chain, you never reveal your
> "OP_RETURN " or "OP_RETURN " or " 
>  OP_RETURN ". Those additional branches are
> stored only by those who wants their data to be connected with some key,
> knowing the full script is not needed, because it is not needed for
> on-chain validation.
>
> > 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).
>
> Yes, but storing that additional data on-chain is not needed. It is
> expensive. By paying one satoshi per byte, you would pay 0.01 BTC for
> pushing 1 MB of data. That means 1 BTC for 100 MB of data, so 15 BTC for
> that 1.5 GB file. And in practice it is the absolute minimum, because you
> have to wrap your data somehow, you cannot just push 1.5 GB file. By
> placing that in TapScript, you can use your taproot public key as usual and
> attach any data into your key for "free", because it takes zero additional
> bytes on-chain.
>
> On 2022-02-24 11:08:39 user Ruben Somsen  wrote:
>
> 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
> , 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@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 " 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@lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_RETURN inside TapScript

[Ruben Somsen via bitcoin-dev]

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
, 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@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 " 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit

[Ruben Somsen via bitcoin-dev]

Hi Jeremy,

Thanks for sharing your thoughts.

To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may still be valid (as long as none of its inputs get
spent elsewhere) and could eventually get confirmed.

I think those are good points. I do still see a possibility where a user
non-maliciously happens to behave in a way that causes all of the above to
happen, but it does seem somewhat unlikely.

It could happen if all of the following occurs:
1. Another output happens to get spent at a higher feerate (e.g. because an
absolute timelock expires and the output gets used)
2. The tx spending the 0 sat output then happens to not make it into the
block due to the lower fees
3. The user then happens to invalidate the tx that was spending from the 0
sat output (seems rational at that point)

Assuming this is the only scenario (I am at least not currently aware of
others), the question then becomes whether the above is acceptable in order
to avoid a soft fork.

Cheers,
Ruben


On Wed, Dec 8, 2021 at 6:41 PM Jeremy  wrote:

> IMO this is not a big problem. The problem is not if a 0 value ever enters
> the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
> can be spent. In fact, it increases it's feerate with P1's confirmation so
> it's somewhat likely it would go in. C2 further has to be pretty expensive
> compared to C1 in order to be mined when C2 would not be, so the user
> trying to do this has to pay for it.
>
> If we're worried it might never be spent again since no incentive, it's
> rational for miners *and users who care about bloat* to save to disk the
> transaction spending it to resurrect it. The way this can be broken is if
> the txn has two inputs and that input gets spent separately.
>
> That said, I think if we can say that taking advantage of keeping the 0
> value output will cost you more than if you just made it above dust
> threshold, it shouldn't be economically rational to not just do a dust
> threshold value output instead.
>
> So I'm not sure the extent to which we should bend backwards to make 0
> value outputs impossible v.s. making them inconvenient enough to not be
> popular.
>
>
>
> -
> Consensus changes below:
> -
>
> Another possibility is to have a utxo with drop semantics; if UTXO X with
> some flag on it is not spent in the block it is created, it expires and can
> never be spent. This is essentially an inverse timelock, but severely
> limited to one block and mempool evictions can be handled as if a conflict
> were mined.
>
> These types of 0 value outputs could be present just for attaching fee in
> the mempool but be treated like an op_return otherwise. We could add two
> cases for this: one bare segwit version (just the number, no data) and one
> that's equivalent to taproot. This covers OP_TRUE anchors very efficiently
> and ones that require a signature as well.
>
> This is relatively similar to how Transaction Sponsors works, but without
> full tx graph de-linkage... obviously I think if we'll entertain a
> consensus change, sponsors makes more sense, but expiring utxos doesn't
> change as many properties of the tx-graph validation so might be simpler.
>
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit

[Ruben Somsen via bitcoin-dev]

Hi Jeremy,

I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:

- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat per byte
and they enter the mempool as a package
- Child C2 spends the other output of P1 with a really high feerate and
enters the mempool
- Fees rise and child C1 falls out of the mempool, leaving the 0 sat output
unspent

For this to not be a problem, the 0 sat output needs to provably be the
only spendable output. As you pointed out to me a few days ago, having a
relative timelock on the other outputs would do the trick (and this happens
to be true for spacechains), but that will only be provable if all script
conditions are visible prior to spending time (ruling out p2sh and taproot,
and conflicting with standardness rules for transactions).

It's worth noting out that you can't really make a policy rule that says
the 0 sat output can't be left unspent (i.e. C1 can't be evicted without
also evicting P1), as this would not mirror economically rational behavior
for miners (they would get more fees if they evicted C1, so we must assume
they will, if the transaction ever reaches them).

This last example really points out the tricky situation we're dealing
with. In my opinion, we'd only want to relay 0 sat outputs if we can
guarantee that it's never economically profitable to mine them without them
getting spent in the same block.

Finally, here's a timestamped link to a diagram that shows where 0 sat
outputs would be helpful for spacechains (otherwise someone would have to
pay the dust up front for countless outputs):
https://youtu.be/N2ow4Q34Jeg?t=2556

Cheers,
Ruben




On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER  wrote:

> Hi Jeremy,
>
> Right now, lightning anchor outputs use a 330 sats amount. Each commitment
> transaction has two such outputs, and only one of them is spent to help the
> transaction get confirmed, so the other stays there and bloats the utxo
> set.
> We allow anyone to spend them after a csv of 16 blocks, in the hope that
> someone will claim a batch of them when the fees are low and remove them
> from the utxo set. However, that trick wouldn't work with 0-value outputs,
> as
> no-one would ever claim them (doesn't make economical sense).
>
> We actually need to have two of them to avoid pinning: each participant is
> able to spend only one of these outputs while the parent tx is unconfirmed.
> I believe N-party protocols would likely need N such outputs (not sure).
>
> You mention a change to the carve-out rule, can you explain it further?
> I believe it would be a necessary step, otherwise 0-value outputs for
> CPFP actually seem worse than low-value ones...
>
> Thanks,
> Bastien
>
> Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Bitcoin Devs (+cc lightning-dev),
>>
>> Earlier this year I proposed allowing 0 value outputs and that was shot
>> down for various reasons, see
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>>
>> I think that there can be a simple carve out now that package relay is
>> being launched based on my research into covenants from 2017
>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>>
>> Essentially, if we allow 0 value outputs BUT require as a matter of
>> policy (or consensus, but policy has major advantages) that the output be
>> used as an Intermediate Output (that is, in order for the transaction to be
>> creating it to be in the mempool it must be spent by another tx)  with the
>> additional rule that the parent must have a higher feerate after CPFP'ing
>> the parent than the parent alone we can both:
>>
>> 1) Allow 0 value outputs for things like Anchor Outputs (very good for
>> not getting your eltoo/Decker channels pinned by junk witness data using
>> Anchor Inputs, very good for not getting your channels drained by at-dust
>> outputs)
>> 2) Not allow 0 value utxos to proliferate long
>> 3) It still being valid for a 0 value that somehow gets created to be
>> spent by the fee paying txn later
>>
>> Just doing this as a mempool policy also has the benefits of not
>> introducing any new validation rules. Although in general the IUTXO concept
>> is very attractive, it complicates mempool :(
>>
>> I understand this may also be really helpful for CTV based contracts
>> (like vault continuation hooks) as well as things like spacechains.
>>
>> Such a rule -- if it's not clear -- presupposes a fully working package
>> relay system.
>>
>> I believe that this addresses all the issues with allowing 0 value
>> outputs to be created for the narrow case of immediately spendable outputs.
>>
>> Cheers,
>>
>> Jeremy
>>
>> p.s. why another post today? Thank Greg
>> https://twitter.com/JeremyRubin/status/1468390561417547780
>>
>>
>> --
>> @JeremyRubin 

Re: [bitcoin-dev] Question- must every mining rig attempt every block?

[Ruben Somsen via bitcoin-dev]

Hi Nathan,

That's a fair question, but note that we've already had a bunch of "green
mining" related posts a few months ago, so I suspect you'll be able to find
many criticisms to this idea in the following thread:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018937.html

It also looks like you'll be able to find some related answers on Bitcoin
Stack Exchange:
https://bitcoin.stackexchange.com/questions/106308/decreasing-energy-consumption-of-bitcoins-pow-with-paired-mining-rounds

And generally speaking these types of discussions don't end up being very
fruitful for bitcoin-dev, because these are the types of changes that are
unlikely to ever be seriously considered for Bitcoin.

Cheers,
Ruben

On Tue, Oct 5, 2021 at 4:09 PM Nathan T Alexander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For purposes of conserving energy, couldn't each mining rig have some
> non-gameable attribute which would be used to calculate if a block would
> be accepted by that rig?
>
> Don't the mining rigs have to be able to identify themselves to the
> network somehow, in order to claim their block reward? Could their
> bitcoin network ID be used as a non-gameable attribute?
>
> Essentially a green light / red light system. In order for a block to be
> accepted by the network, it must have all attributes of a successful
> block today, and it must also have come from a rig that had a green light.
>
> Perhaps hash some data from the last successful block, along with the
> miners non-gameable attribute, and if it's below a certain number set by
> algorithm, the miner gets a green light to race to produce a valid block.
>
> Nathan Alexander
>
> Arlington, TX
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Ruben Somsen via bitcoin-dev]

Hi Prayank,

While I can see how this can come from a place of good intentions, I’d
strongly advise you to tread carefully because what you are suggesting is
quite controversial. A related event occurred in the Linux community and it
did not go over well. See https://lkml.org/lkml/2021/5/5/1244 and
https://lore.kernel.org/linux-nfs/yh%2ffm%2ftsbmczz...@kroah.com/ .

The main point of contention is that your research comes at the expense of
the existing open source contributors – you’d be one-sidedly deceiving
them, encouraging an environment of increased mistrust, and causing them a
lot of work in order to gather the data you’re interested in. For this
reason, it would be appropriate to check first whether your plan is
actually appreciated.

Speaking on behalf of the bitcoin-dev moderators, please ensure your plan
is welcomed by the contributors, prior to proceeding.

Best regards,
Ruben Somsen

On Tue, Sep 28, 2021 at 10:05 AM Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi ZmnSCPxj,
>
> Thanks for suggestion about sha256sum. I will share 10 in next few weeks.
> This exercise will be done for below projects:
>
> 1.Two Bitcoin full node implementations (one will be Core)
> 2.One Lightning implementation
> 3.Bisq
> 4.Two Bitcoin libraries
> 5.Two Bitcoin wallets
> 6.One open source block explorer
> 7.One coinjoin implementation
>
> Feel free to suggest more projects. There are no fixed dates for it
> however it will be done in next 6 months. All PRs will be created within a
> span of few days. I will ensure nothing is merged that affects the security
> of any Bitcoin project. Other details and results will be shared once
> everything is completed.
>
> x00 will help me in this exercise, he does penetration testing since few
> years and working for a cryptocurrencies derivatives exchange to manage
> their security. His twitter account: https://twitter.com/1337in
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Sep 27, 2021, 15:43 by zmnsc...@protonmail.com:
>
> Good morning Prayank,
>
> Good morning Bitcoin devs,
>
> In one of the answers on Bitcoin Stackexchange it was mentioned that some
> companies may hire you to introduce backdoors in Bitcoin Core:
> https://bitcoin.stackexchange.com/a/108016/
>
> While this looked crazy when I first read it, I think preparing for such
> things should not be a bad idea. In the comments one link was shared in
> which vulnerabilities were almost introduced in Linux:
> https://news.ycombinator.com/item?id=26887670
>
> I was thinking about lot of things in last few days after reading the
> comments in that thread. Also tried researching about secure practices in
> C++ etc. I was planning something which I can do alone but don't want to
> end up being called "bad actor" later so wanted to get some feedback on
> this idea:
>
> 1.Create new GitHub accounts for this exercise
> 2.Study issues in different important Bitcoin projects including Bitcoin
> Core, LND, Libraries, Bisq, Wallets etc.
> 3.Prepare pull requests to introduce some vulnerability by fixing one of
> these issues
> 4.See how maintainers and reviewers respond to this and document it
> 5.Share results here after few days
>
> Let me know if this looks okay or there are better ways to do this.
>
>
>
> This seems like a good exercise.
>
> You may want to hash the name of the new Github account, plus some
> randomized salt, and post it here as well, then reveal it later (i.e.
> standard precommitment).
> e.g.
>
> printf 'MyBitcoinHackingName
> 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' |
> sha256sum
> f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef
>
> Obviously do not share the actual name, just the sha256sum output, and
> store how you got the sha256sum elsewhere in triplicate.
>
> (to easily get a random 256-bit hex salt like the `2c3e...` above: `head
> -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum`
> produces a single hex string you can easily double-click and copy-paste
> elsewhere, assuming you are human just like I am (note: I am definitely
> 100% human and not some kind of AI with plans to take over the world).)
>
> Though you may need to be careful of timing (i.e. the creation date of the
> Github account would be fairly close to, and probably before, when you post
> the commitment here).
>
> You could argue that the commitment is a "show of good faith" that you
> will reveal later.
>
> Regards,
> ZmnSCPxj
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Ruben Somsen via bitcoin-dev]

Hi all,

Thanks for the lively discussion. On behalf of the bitcoin-dev moderators
and with the readers of this mailing list in mind, we'd like to suggest
finishing up this discussion. Of course there should be some room for
exploring fringe ideas, but it should not dominate the mailing list either.
Fun as it may be, perhaps it's time to get back to focusing on the topics
that are more directly relevant to Bitcoin.

Cheers,
Ruben

On Fri, Jun 25, 2021 at 9:29 AM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> No, that's not how it works.
>
> PoS is constitutionally incapable of producing any further consensus
> from its starting point. If you start out by hardcoding the bitcoin
> ledger state at June 1, 2021, then your PoS system will be unable to
> reach a global consensus as to what the state was on June 2, 2021.
>
> To get global consensus in PoS, you have to know which block came first.
> To reach a consensus on which block was first, you need to solve the
> timestamp problem. And to solve the timestamp problem, you need a
> consensus system. You'll notice that at no point does PoS provide such a
> consensus system.
>
> Implementations of PoS sacrifice global consensus for 'weak
> subjectivity', meaning that each node has its own notion of when a
> certain block arrived. Astute observers will note that 'each node has
> its own notion of what happened' differs somewhat from 'all nodes agree
> on what happened', and that only one of these is a good description of
> what is commonly known as 'consensus'.
>
> Maybe a simpler way of looking at it is from the coder's perspective:
> how do you implement IBD? In PoW, the "longest chain" rule is used -
> "Nodes can leave and rejoin the network at will, accepting the
> proof-of-work chain as proof of what happened while they were gone.".
> Does PoS have this property?
>
> On 2021-06-24 21:50, Erik Aronesty wrote:
> >> PoS is not suitable for use as a consensus system, because
> > it is constitutionally incapable of producing a consensus.
> >
> > true - but only for a system that is starting from nothing.
> >
> > since bitcoin already exists, and we have a consensus, you can use
> > bitcoin's existing consensus to maintain that consensus using
> > references to prior state.  and yes, you simply have to limit reorgs
> > to not go back before PoW was abandoned in favor of PoS/PoB (assuming
> > all incentive problems are solved).
> >
> > ie: once you have uses PoW to bootstrap the system, you can "recycle"
> > that work.
> >
> > On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
> >  wrote:
> >>
> >> No, 51% of the *coin holders* can't do diddly squat. 51% of miners
> >> can,
> >> but in PoW, that's a different set to the coin holders.
> >>
> >> The basic problem with PoS, anyway, is that it's not actually a
> >> consensus system ("weak subjectivity"). Either you allow long reorgs,
> >> and then you open the door to long-range attacks, or you don't, and
> >> then
> >> you're not guaranteed that all nodes agree on the state of the chain,
> >> which was the purpose of the system to begin with.
> >>
> >> To put it more plainly: for PoS to work, you need a consensus on which
> >> block was seen first. But if you had that, you could presumably apply
> >> that method to determine which *transaction* was seen first, in which
> >> case you could do away with the blockchain entirely. (Real-world
> >> implementations of PoS, such that they are, do away with this
> >> requirement, scrapping the global consensus on ordering in favor of
> >> having each node decide for itself which block came first.)
> >>
> >> In other words, even if you solved all the incentive problems, the
> >> fact
> >> remains that PoS is not suitable for use as a consensus system,
> >> because
> >> it is constitutionally incapable of producing a consensus.
> >>
> >> On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
> >> >>  This is not true in a Proof of Work system and this difference
> >> > absolutely should not be trivialized.
> >> >
> >> > That is in fact true of Proof of Work as well. If a colluding
> >> > coalition of miners with more than 50% of the hashrate want to censor
> >> > transactions, they absolutely can do that by orphaning blocks that
> >> > contain transactions they want to censor. This is not different in
> >> > proof of stake.
> >> >
> >> > On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
> >> >  wrote:
> >> >
> >> >>> Premise: There is a healthy exchange market for PoS Coin X with
> >> >> tens of thousands of participants bidding to buy and sell the coin
> >> >> for other currencies on the market.
> >> >>
> >> >> The difference here though is that Proof of Stake allows the quorum
> >> >> of coin holders to block the exchange of said coins if they are
> >> >> going to a particular destination. Nothing requires these staking
> >> >> nodes to include particular transactions into a block. With that in
> >> >> mind, it isn't just that you re

Re: [bitcoin-dev] Tweaking tapscript instead of public key

[Ruben Somsen via bitcoin-dev]

Hi,

That's an excellent question, but note that answering such questions is not
the primary function of this mailing list. Places like Bitcoin Stack
Exchange or even IRC are probably better for that!

Specific to your question: in Taproot Q = P + hash(P||m)*G. The fact that P
is hashed together with the message, makes it a commitment. If you try to
change m to e.g. m2, then Q - hash(P||m2) will never result in P (unless
the hash function is broken).

The original Taproot thread can be found here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html

Cheers,
Ruben

On Sun, May 23, 2021 at 7:10 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As far as I know, P2TR address contains 32-byte public key. It can be used
> directly by creating Schnorr signature or indirectly, by revealing
> tapscript. Does it mean that any taproot output could be modified
> on-the-fly after being confirmed without changing an address? I mean, if we
> have base point as the private key with P2TR address
> tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz, then the
> owner of that key can modify spending conditions without moving on-chain
> coins?
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sum of the keys attack on taproot

[Ruben Somsen via bitcoin-dev]

What Tim said is right. To add to that, you may also wish to read about
MuSig:
https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/

Cheers,
Ruben

On Sat, May 15, 2021 at 10:32 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, 2021-05-15 at 12:21 +0200, vjudeu via bitcoin-dev wrote:
>
>
> >  All that is needed is producing a signature matching the sum of the
> > public keys used in taproot, which is "(a+b-a)*G",
>
> This is simply not true.
>
> Taproot does not enable this, or any other form of "cross-input
> aggregation", i.e., spending multiple UTXOs with a single signature.
>
>
> Tim
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

[Ruben Somsen via bitcoin-dev]

Hi Antoine,

Thanks for bringing this up.

It seems spacechains[0] are impacted by this. Simply explained, the idea is
to allow for fee-bidding Blind Merged Mining[1] by creating one transaction
for each block, to which anyone can attach a block hash. The preferred
mechanism utilizes sighash_anyprevout and is not affected, but there is
also a practical variant that could be used without requiring the
anyprevout soft fork, which unfortunately does seem to be impacted. Here's
a brief description:

TX0:

input 0

output 1a*
output 1b

TX1:

input 1a*

output 2a**
output 2b

TX2:

input 2a**

output 3a***
output 3b

Etc.

Every TX has two outputs, one of which ("a") is used as the input for the
next TX (these are pre-signed and act as a covenant), resulting in a
continuous chain of transactions. The other output ("b") can be spent by
anyone, and is meant to CPFP the parent TX and, importantly, be RBF
replaceable by anyone. This allows whoever pays the highest CPFP fee to
"win the RBF auction" and attach their TX to the output, containing the
winning spacechain block hash.

With inherited signalling, this works because each pre-signed TX is RBF
enabled, so each CPFP transaction inherits RBF as well. But if inherited
signalling does not function, the first person who makes a CPFP transaction
can simply disable RBF and win the auction, thus breaking the intended
fee-bidding mechanism.

You can also find a diagram in this spacechains presentation (timestamped
link): https://youtu.be/N2ow4Q34Jeg?t=2555

As it stands, this bug gets in the way of being able to deploy spacechains.

-- Ruben Somsen



[0]
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302

[1] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5




On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Antoine,
>
>
> Thank you for the disclosure.
>
>
>
> > * Onchain DLC/Coinswap/Vault : Those contract protocols have also
> multiple stages of execution with time-sensitive transactions opening the
> way to pinning attacks. Those protocols being non-deployed or in early
> phase, I would recommend that any in-protocol competing transactions
> explicitly signal RBF.
>
>
> For what it's worth, Revault isn't vulnerable as all transactions signal
> RBF and there is no way to sneak a non-signaling competing transaction (as
> long as the CSV isn't matured yet).
>
>
>
> Thanks,
>
> Antoine (the other one)___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

[Ruben Somsen via bitcoin-dev]

Good evening ZmnSCPxj,

Thanks for thinking it through. I appreciate the time and effort.

>sidechain functionaries will not earn anything once there are at least 2
functionaries [...] they are doing all this work of validating the
sidechain blocks, but gain nothing [...] the entire sidechain depends on
this one sidechain functionary

I think your description is accurate, and while it may intuitively sound
problematic, it turns out it does not actually cause any issues.

Even in a scenario where one entity is consistently creating all the
spacechain blocks, they can only do so as long as they consistently leave 0
profit on the table for others. This is actually perfectly acceptable,
because that means this entity is not censoring anyone. As soon as they try
to abuse their position with censorship, it's trivial for anyone to step in
and outbid them.

How trivial, you may wonder? Well, there is very little difference between
being a spacechain miner and a spacechain user. Both are expected to run
full nodes, the only difference is that the miner has some BTC available
and is willing to use it to "mine" the block reward in the spacechain. This
means that the barrier for users to act as miners is low to the point where
it may happen altruistically, and, interestingly, it also doubles as an
appealing way for users to purchase spacecoins in a decentralized fashion.

Btw, I personally prefer not to call a "BMM chain" a sidechain, because in
my eyes it's not a sidechain if the chain has its own altcoin. The
spacechain design (which avoids the use of an altcoin) comes closer to
being a sidechain in that regard, but even there the use of the term
"sidechain" is debatable.

I hope this clarifies things.

Cheers,
Ruben





On Mon, May 3, 2021 at 7:17 AM ZmnSCPxj  wrote:

> Good morning Ruben,
>
> > Hi Yanmaani,
> >
> > >Merged mining at present only needs one hash for a merkle root, and
> that's stored in the coinbase.
> >
> > Yes, but that method is not "blind", meaning BTC miners have to
> validate the merged-mined chain, which is a significant downside.
> >
> > >It would be even simpler to add the following rules
> >
> > That would require a specific soft fork, whereas the method described in
> my post avoids doing that.
> >
> > >do I need to put in a transaction that burns bitcoins for the tx fee
> >
> > The blind merged-mined chain (which I call a "spacechain") needs its own
> native token in order to pay for fees. The mechanism I proposed for that is
> the perpetual one-way peg, which allows fair "spacecoin" creation by
> burning BTC, and circumvents creating bad speculative altcoin incentives.
> Anyone can create a spacechain block and take the fees, and then try to get
> BTC miners to include it by paying a higher fee than others (via RBF).
>
> What bothers me about BMM is the B.
>
> Mainchain miners assume that sidechain functionaries check the sidechain
> rules.
> Their rule is that if the sidechain functionary is willing to pay an
> amount, then obviously the sidechain functionary must benefit by at *least*
> that amount (if not, the sidechain functionary is losing funds over time
> and will go out of business at some point).
> Thus the BMM is an economic incentive for sidechain functionaries to be
> honest, because dishonesty means that sidechain nodes will reject their
> blocks and they will have earned nothing in the sidechain that is of equal
> or greater value than what they spend on the mainchain.
>
> But the BMM on mainchain is done by bidding.
> Suppose a sidechain functionary creates a block where it gets S fees, and
> it pays (times any exchange rates that arise due to differing security
> profiles of mainchain vs sidechain) M in fess to mainchain miners to get
> its commitment on the mainchain.
> Then any other competing sidechain functionary can create the same block
> except the S fees go to itself, and paying M+1 in fees to mainchain miners
> to get *that* commitment mainchain.
> This triggers a bidding war.
> Logically, further sidechain functionaries will now bid M+2 etc. until M=S
> (times exchange rates) and the highest bidder earns nothing.
>
> That means that sidechain functionaries will not earn anything once there
> are at least 2 functionaries, because if there are two sidechain
> functionaries then they will start the above bidding war and all earnings
> go to mainchain miners, who are not actually validating anything in the
> sidechain.
> So they are doing all this work of validating the sidechain blocks, but
> gain nothing thereby, and are thus not much better than fullnodes.
>
> Even if you argue that the sidechain functionaries might gain economic
> benefit from the existence of the sidechain, that economic benefit can be
> quantified as some economic value, that can be exchanged at some exchange
> rate with some number of mainchain tokens, so M just rises above S by that
> economic benefit and sidechain functionaries will still end up earning 0
> money.
>
> If there is only one

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

[Ruben Somsen via bitcoin-dev]

Hi Yanmaani,

>Merged mining at present only needs one hash for a merkle root, and that's
stored in the coinbase.

Yes, but that method is not "blind", meaning BTC miners have to
validate the merged-mined chain, which is a significant downside.

>It would be even simpler to add the following rules

That would require a specific soft fork, whereas the method described in my
post avoids doing that.

>do I need to put in a transaction that burns bitcoins for the tx fee

The blind merged-mined chain (which I call a "spacechain") needs its own
native token in order to pay for fees. The mechanism I proposed for that is
the perpetual one-way peg, which allows fair "spacecoin" creation by
burning BTC, and circumvents creating bad speculative altcoin incentives.
Anyone can create a spacechain block and take the fees, and then try to get
BTC miners to include it by paying a higher fee than others (via RBF).

>That isn't free in terms of storage

It's not necessary for everyone to burn individually. My preferred design
is to only let BMM block creators burn BTC, then others will have to buy
spacecoins from them. This limits the potential burn outputs to one per
block (likely much less, because BTC will logically only get burned when
spacecoin demand increases). It's also possible to create more spacechains
inside the initial spacechain, at no additional storage cost to Bitcoin.

I highly recommend checking out the links in my prior post

if you wish to learn more, particularly the video
.

Cheers,
Ruben

On Tue, Apr 20, 2021 at 3:23 AM  wrote:

> > If only one hash is allowed per block, then those who wish to utilize
> > the hash will have to out-bid each other ("fee-bidding"). This hash can
> > then be used to create another chain ("merged-mining")
>
> Merged mining at present only needs one hash for a merkle root, and
> that's stored in the coinbase. It would be even simpler to add the
> following rules:
>
> 1) No OP_RETURN transactions allowed at all
> 2) If you want to commit data, do so in that one transaction in the
> coinbase
>
> Also curious about how you'd handle the payment - do I need to put in a
> transaction that burns bitcoins for the tx fee? That isn't free in terms
> of storage either.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

[Ruben Somsen via bitcoin-dev]

Hi Chris,

I agree with all the points that were made by others. You should also be
aware that layer two ideas like yours have already been explored, both by
myself and others. Allowing one hash per block allows for what I call
"fee-bidding Blind Merged-Mining" (BMM), which as far as I know was first
proposed by Paul Storc for Drivechains.[0]

If only one hash is allowed per block, then those who wish to utilize the
hash will have to out-bid each other ("fee-bidding"). This hash can then be
used to create another chain ("merged-mining"), while the Bitcoin miners do
not have to be aware of this other chain ("blind"). There are also non
fee-bidding variants that function e.g. by burning or locking up bitcoins
in order to create consensus.

As it turns out, fee-bidding BMM can be achieved using only a covenant
structure for transactions.[1] You'd have to create a sequence of
transactions (one per block), to which a hash can be attached. These can
simply be pre-signed transactions (requires forgetting a key, but the worst
that can happen is that the chain halts), or an actual covenant using
either sighash_anyprevout or op_ctv (we don't have these yet) – no
specialized soft fork (or hard fork) is required.

You might think any decentralized alternative chain requires an altcoin,
but this can also be avoided with a perpetual one-way peg.[2] For more
details, I recommend watching this video of the full concept, which I call
"spacechains": https://youtu.be/N2ow4Q34Jeg

-- Ruben Somsen



[0] Blind Merged-Mining for Drivechains:
https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki

[1] Fee-bidding Blind Merged-Mining with covenants:
https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5

[2] Perpetual one-way peg:
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302

On Fri, Apr 16, 2021 at 9:33 PM Kostas Karasavvas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Christopher,
>
> Some feedback:
>
> "OP_RETURN is limited to 40 bytes of data."
> It is 80 bytes.
>
> "A future BIP proposing such a layer two protocol will be forthcoming."
> So what is this BIP about? Just saying that it would be a nice idea? This
> BIP should be the one that would go through this L2 suggestion. If one root
> OP_RETURN substitutes all the rest it should say how that would be done...
> where would the merkle proofs be stored, what are the trust
> assumptions that we need to make, etc.
>
> "Objections to this proposal" section
> I agree with others re hard-fork, which would be a good thing of course.
> My main objection with this proposal is that I don't see a proposal. It
> seems like wishful thinking... if only we could substitute all the
> OP_RETURNs with one :-)
>
> We have to make sure that a proposal like this (L2, etc.) would make sure
> that there are incentives that justify the added complexity for the users.
> Multisig is not the only way data could be stored the wrong way; P2PK,
> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not good
> enough people would start using these UTXO-bloat-heavy alternatives.
>
> There are a multitude of L2's (kind-of) that do this 'aggregation' of data
> hashes using merkle trees. Factom is adding a single merkle root per
> bitcoin block for the millions upon millions of records (of thousand of
> users) that they keep in their network. Opentimestamps, tierion,
> blockstacks and others do a similar thing. I have investigated several of
> those in the past, for one of my projects, but I ended up using plain old
> OP_RETURN because the overhead of their (L2-like) solution and trust
> assumptions where not to my liking; at least for my use case. They were
> pretty solid/useful for other use cases.
>
> Unless the proposed L2 is flexible/generic enough it would really prohibit
> this L2 innovation that OP_RETURN allowed (see above).
>
>
>
> On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Konstantinos A. Karasavvas
> Software Architect, Blockchain Engineer, Researcher, Educator
> https://twitter.com/kkarasavvas
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.o

Re: [bitcoin-dev] Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

[Ruben Somsen via bitcoin-dev]

Hi Sergio,

Thanks for taking an interest.

>I don't understand how your proposal prevents miners proposing a peg-out
for an invalid sidechain fork which is not made available to the nodes
(there are missing blocks)

Good question. Data availability is a common problem for sidechain designs,
but PoW FP are actually a unique solution to this problem. In order for a
block with missing data to be accepted for a peg-out, it has to a.) remain
in the chain with the most PoW for a whole year, and b.) no fork that
questions the validity/availability of that block must exist. If a fork
does exist, this triggers all nodes to attempt to download the block with
the missing data. Since they will fail, the chain will be considered
invalid. I recommend reading the original posts about PoW FP ([1] and [2]
in my original post) for more elaboration.

>it is very limited in the types of sidechains it can verify

I agree that something like drivechains is much more flexible, but it comes
with a security tradeoff that many find uncomfortable.

>based on both a large multisig AND a drivechain, where both groups need to
agree for the peg-out to occur.  It's a censorship/security trade-off that
most users would be willing to accept

I think federations are an absolutely fine tradeoff, but of course the
softchain design is one that deliberately tries to avoid them for reasons
that I assume are obvious.

>until a trusted-setup-free SNARK-like based solution is finally available

>From my research into SNARKs I concluded that they still won't get you away
from having the sidechain function like an extension block, so the fruit
doesn't seem to be hanging that low from my perspective. This is because
SNARKs actually do suffer from the data availability problem you were
asking about. You can definitely save a lot by aggregating witness data
with SNARKs, but non-witness data cannot be aggregated and must be
downloaded by everyone, so you're still going to be restricted by
bandwidth. I described the issue here in detail:
https://medium.com/@RubenSomsen/snarks-and-the-future-of-blockchains-55b82012452b

Cheers,
Ruben




On Fri, Jan 1, 2021 at 12:38 AM Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:

> Hi Roben,
>  It's an interesting proposal, but I have two issues with it, one
> technical and one philosophical.
>
> On the technical side, I don't understand how your proposal prevents
> miners proposing a peg-out for an invalid sidechain fork which is not made
> available to the nodes (there are missing blocks). It seems that the system
> would need to allow users to challenge miners to make available full
> sidechain blocks that are missing, which really complicates the protocol.
>
> On the philosophical side, as you mentioned, it is very limited in the
> types of sidechains it can verify. I won't be able to verify RSK
> (merge-mined with Bitcoin, but with different block format and different
> functionality). It cannot verify a zCash-like sidechain for the same
> reasons. Therefore it is strictly a payment scalability solution.
> Drivechains, on the other hand, enable many new use cases apart from
> scaling, which have a much lower level of complexity (if implemented
> correctly).
>
> Since the inception of RSK sidechain, I suggested in its white-paper that
> sidechains should be designed to support an hybrid peg-out system, based on
> both a large multisig AND a drivechain, where both groups need to agree for
> the peg-out to occur.  It's a censorship/security trade-off that most users
> would be willing to accept until a trusted-setup-free SNARK-like based
> solution is finally available.
> Until we have a sidechain-selectable SNARK-like succinct verification of
> any block state transition function, having a single succint proof to cover
> the whole sidechain validity, as in Coda (now renamed Mina), drivechains
> are the low-hanging-fruit.
>
> regards
>
> On Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> This post describes a fully decentralized two-way peg sidechain design.
>> Activating new sidechains requires a soft fork, hence the name softchains.
>> The key aspect is that all softchains are validated by everyone via
>> Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus
>> mechanism that only requires the validation of disputed blocks. This does
>> increase the validation burden of mainchain full nodes, but only by a
>> minimal amount (~100MB per chain per year). It's similar to drivechains[0],
>> but without the major downside of having to rely on miners, since all
>> Bitcoin full node users can efficiently validate each sidechain.
>>
>>
>> Proof-of

Re: [bitcoin-dev] Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

[Ruben Somsen via bitcoin-dev]

Happy new morning ZmnSCPxj,

Thanks for taking a look :)

>If sidechains are for experimental new features, then softforking in a new
sidechain with novel untested new features would be additionally risky

There is definitely a risk, but it's one that can be minimized. For
instance, a softchain with Confidential Transactions could be introduced,
which allows for appealing privacy features without introducing a
completely new code base.

>If sidechains are for scaling, then I would like to remind anyone reading
this that ***blockchains do not scale***

I agree, you will still run into limitations, but you do get some scaling
gains from not having to verify each chain, but only the subset that
interests you.

>you would be splitting the global energy budget for blockchain security
among multiple blockchains

Not necessarily if you incorporate Merged Mining, but of course that comes
with the tradeoff of requiring miners to do more validation.

Cheers,
Ruben

On Fri, Jan 1, 2021 at 12:26 AM ZmnSCPxj  wrote:

> Good morning Ruben, and list,
>
> First and foremost --- what is the point of sidechains, in the first place?
>
> If sidechains are for experimental new features, then softforking in a new
> sidechain with novel untested new features would be additionally risky ---
> as you note, a bug in the sidechain consensus may cause non-deterministic
> consensus in the sidechain which would propagate into mainchain.
> Federated sidechains, which already are enabled on current Bitcoin, are
> safer here, as mainchain will only care about the k-of-n signature that the
> federation agrees on, and if the federation is unable to come to consensus
> due to a sidechain consensus bug, "fails safe" in that it effectively
> disables the peg-out back to mainchain and restricts the consensus problem
> to the sidechain.
>
> If sidechains are for scaling, then I would like to remind anyone reading
> this that ***blockchains do not scale***, and adding more blockchains for
> the purpose of scaling is *questionable*.
> "I have a scaling problem.
> I know, I will add a sidechain!
> Now I have two scaling problems."
>
> Ultimately, proof-of-work is about energy expenditure, and you would be
> splitting the global energy budget for blockchain security among multiple
> blockchains, thus making each blockchain easier to 51%.
>
> Regards,
> ZmnSCPxj
>
> > Hi everyone,
> >
> > This post describes a fully decentralized two-way peg sidechain design.
> Activating new sidechains requires a soft fork, hence the name softchains.
> The key aspect is that all softchains are validated by everyone via
> Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus
> mechanism that only requires the validation of disputed blocks. This does
> increase the validation burden of mainchain full nodes, but only by a
> minimal amount (~100MB per chain per year). It's similar to drivechains[0],
> but without the major downside of having to rely on miners, since all
> Bitcoin full node users can efficiently validate each sidechain.
> >
> > Proof-of-Work Fraud Proofs
> >
> > Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2].
> The idea is that we can use the existence of a fork in Bitcoin's PoW as
> evidence that a block might be invalid (i.e. a proof of potential fraud).
> Whenever this occurs, we download the block in question to verify whether
> it was valid (and available), and reject it if it was not. We forego the
> need for maintaining a UTXO set with UTXO set commitments (such as
> utreexo[3]), by assuming that the commitment inside the last block to exist
> in both forks is valid. As a result, we only need to download as many
> blocks (and their corresponding UTXO set proofs) as there are orphans,
> which lowers the validation costs considerably compared to running a full
> node.
> >
> > In the past 4 months, Forkmonitor has registered 11 stale and invalid
> blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin
> consensus would have to download and verify a little over 100MB per year in
> order to have consensus guarantees that come close to that of a full node:
> > - All PoW headers (~4MB per year)
> > - 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)
> > - UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)
> >
> > The reason consensus is considered slow, is because we need to allow
> time for a honest PoW minority to fork away from an invalid chain. If we
> assume only 1% of all miners are honest, this means consensus slows down by
> 100x. If you are normally satisfied waiting for 6 confirmations, you now
> need to wait 600 confirmations. The longer you wait, the less honest miners
> you need.
> >
> > Softchains
> >
> > In order to have two-way pegged sidechains, you need a succinct method
> for proving to the mainchain that a peg-out is valid. PoW FP provides
> exactly that -- a low-bandwidth way of determining if a chain, and thus a
> peg-out, is valid. The slowness of PoW FP consensus is not an i

[bitcoin-dev] Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

[Ruben Somsen via bitcoin-dev]

Hi everyone,

This post describes a fully decentralized two-way peg sidechain design.
Activating new sidechains requires a soft fork, hence the name softchains.
The key aspect is that all softchains are validated by everyone via
Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus
mechanism that only requires the validation of disputed blocks. This does
increase the validation burden of mainchain full nodes, but only by a
minimal amount (~100MB per chain per year). It's similar to drivechains[0],
but without the major downside of having to rely on miners, since all
Bitcoin full node users can efficiently validate each sidechain.


Proof-of-Work Fraud Proofs

Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2].
The idea is that we can use the existence of a fork in Bitcoin's PoW as
evidence that a block might be invalid (i.e. a proof of potential fraud).
Whenever this occurs, we download the block in question to verify whether
it was valid (and available), and reject it if it was not. We forego the
need for maintaining a UTXO set with UTXO set commitments (such as
utreexo[3]), by assuming that the commitment inside the last block to exist
in both forks is valid. As a result, we only need to download as many
blocks (and their corresponding UTXO set proofs) as there are orphans,
which lowers the validation costs considerably compared to running a full
node.

In the past 4 months, Forkmonitor has registered 11 stale and invalid
blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin
consensus would have to download and verify a little over 100MB per year in
order to have consensus guarantees that come close to that of a full node:
- All PoW headers (~4MB per year)
- 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)
- UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)

The reason consensus is considered slow, is because we need to allow time
for a honest PoW minority to fork away from an invalid chain. If we assume
only 1% of all miners are honest, this means consensus slows down by 100x.
If you are normally satisfied waiting for 6 confirmations, you now need to
wait 600 confirmations. The longer you wait, the less honest miners you
need.


Softchains

In order to have two-way pegged sidechains, you need a succinct method for
proving to the mainchain that a peg-out is valid. PoW FP provides exactly
that -- a low-bandwidth way of determining if a chain, and thus a peg-out,
is valid. The slowness of PoW FP consensus is not an issue, as peg-outs can
be made arbitrarily slow (e.g. one year).

The safest design would be a set of softchains that shares its consensus
code with Bitcoin Core, with the addition of UTXO set commitments, and
disabling non-taproot address types to minimize certain resource usage
issues[5]. All users validate the mainchain as usual with their full node,
and all softchains are validated with PoW FP consensus. If a user is
interested in directly using a specific softchain, they should run it as a
full node in order to get fast consensus.

Peg-ins occur by freezing coins on the mainchain and assigning them to a
softchain. Peg-outs occur by creating a mainchain transaction that points
to a peg-out transaction on a softchain and waiting for a sufficient number
of mainchain confirmations. If the peg-out transaction remains part of the
softchain according to PoW FP consensus, the coins become spendable.

The peg-in/peg-out mechanism itself would require a soft fork (the exact
design is an open question), and subsequently every softchain that gets
activated will also require a soft fork.


Potential dangers

Softchain consensus still requires a form of validation from mainchain
users, which means that consensus bugs can have an adverse effect. In
particular, if a softchain suffers from a non-deterministic consensus bug,
it may be the case that a majority accepts a peg-in, while a minority
rejects it. This specific scenario could cause a chain split in mainchain
consensus. This is why it would be safest to base softchain designs on
Bitcoin Core.

Similarly, it can theoretically be possible that a softchain gets a major
reorg, invalidating a peg-out right as it would have become accepted on the
mainchain, thus splitting consensus. The slow peg-out process makes this
increasingly unlikely, but not impossible. One thing that might help (or
perhaps only make it worse) is introducing a consensus rule that disallows
reorgs that are bigger than half the peg-out time (e.g. half a year, if the
peg-out is one year). This kind of rule does not actually solve this
consensus problem, but instead pushes the problem forward so it plays out
first on the softchain, giving time to take action before the problem
affects the mainchain.

It is also important that each softchain produces a non-trivial amount of
PoW, because if the difficulty is too low, the cost of creating forks and
increasing the resource usage of PoW FP consensus goes down. It may
therefore make sense

Re: [bitcoin-dev] Bulletin boards without selective censorability for bitcoin fungibility markets

[Ruben Somsen via bitcoin-dev]

Hi Adam,

That's a tricky issue you're trying to tackle.

>and/or use the blockchain for that function, but that is too slow and
expensive, usually

While perhaps not the most easy/practical path to take, it IS possible to
create a custom blockchain for this specific purpose to use as a
censorship-resistant data layer via Blind Merged Mining:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017534.html

Note that while it's not described in detail in my post, there is a
(slightly suboptimal) way to do it without a soft fork.

And here are more details about the perpetual one-way peg mechanism (needed
to pay for fees without introducing speculation):
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302

Cheers,
Ruben

On Mon, Nov 23, 2020 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> ‐‐‐ Original Message ‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Canvassing opinions/critiques from those working on bitcoin and related
> protocols.
> >
> > See the attached gist for a write-up of an outline of an idea, which is
> conceived for joinmarket but can apply in other scenarios where there is
> market for liquidity and in which privacy is a very high priority (hence
> 'bitcoin fungibility markets' can certainly include coinswap along with
> coinjoin, but possibly other things):
> >
> > https://gist.github.com/AdamISZ/b52704905cdd914ec9dac9fc52b621d6
>
> Greg Maxwell pointed out to me on IRC that this idea doesn't work: there
> is only a receipt on the commitment to the offer (message) from the maker,
> not on the plaintext version, hence there is nothing stopping the maker
> from falsely claiming censorship after not sending the plaintext.
>
> Reflecting on this a bit more, my intuition is that this problem is much
> more difficult than I had hoped; if there is a solution I suspect it
> involves much more sophisticated ideas. Many solutions just end up begging
> the question by presuming the existence of an uncensorable BB in order to
> create a new one; and/or use the blockchain for that function, but that is
> too slow and expensive, usually. I'd be happy to be proved wrong, though :)
>
> waxwing
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Blind Statechains

[Ruben Somsen via bitcoin-dev]

Hi Tom,

Blind signatures are certainly a nice feature, great to see that you're
considering it.

>So each new owner of a UTXO must receive, store and verify the full
sequence of previous owner backup transactions to make sure that no
previous owner has asked the SE to sign a transaction that could be used to
steal the UTXO. This may end up making wallets more bloated and clunky,
given that ownership of a UTXO could change hands thousands of times
off-chain.

Users would have to validate the history of the chain regardless, even if
it wasn't blind, to verify whether the statechain entity hasn't been
cheating, so the main difference would be in unblinding the data.

One of my original ideas was to use the transitory key to derive the
secrets that blind the signatures (basically like an HD wallet). The
statechain entity would then store and serve blind signatures, and any new
owner would download and unblind/verify them using the transitory key (no
extensive peer-to-peer transfer needed). It's possible to make the
off-chain transactions themselves deterministic, so they can just be
generated by the client without any additional data transfer. The only
potentially unique thing in a transaction is the refund address, but this
can be the same key as the ownership key on the statechain, tweaked with
the transitory key via Diffie-Hellman (to ensure it's not linkable if it
goes on-chain).

The general downside of this method is that all transactions are exposed to
anyone who learns the transitory key -- not just for the current
transactions (which can always be leaked no matter what you do), but also
all future transactions in that particular statechain. However, I should
note there doesn't actually seem to be much to learn, because the history
of each statechain is actually quite uninformative. The money just goes
from one pseudonymous owner to the next.

Of course you now have scheme that changes the transitory key with each
step, so I instead suggest you introduce a secondary "blinding key" to
achieve what I described.

I'm not sure whether this can also apply to 2P-ECDSA, but with Schnorr the
statechain entity wouldn't even learn the address for the funding
transaction, so it wouldn't be able to tell which UTXO it controls by
watching the blockchain. Ideally, this functionality would be preserved to
ensure the statechain entity can't be aware of the funds it's holding.

Another thing to note is that you won't know when a statechain has been
pegged out, so pruning will be impossible. You may wish to consider some
kind of liveness rule where one statechain transaction needs to be made per
year. If they miss the deadline, they're just forced on-chain, which is not
terrible, in any case.

Hope this helps!

Cheers,
Ruben



On Fri, Jun 12, 2020 at 9:23 PM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> A statechain implementation and service co-signs 'backup' (off-chain)
> transactions to transfer ownership of a UTXO from one owner to the next. A
> suggested here
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
> , this service (the statechain entity or SE) can be engineered to be
> 'blind' to the transactions it is signing (i.e. it does not and cannot know
> the details of the transactions it is signing) which can give significant
> privacy benefits. It would enable more private off-chain coin-swaps, and
> make collusion more difficult.
>
> The only downside of a blind SE is that it can no longer enforce the rules
> governing the sequence of backup transactions it co-signs as owners can ask
> the SE to cosign any transaction. So each new owner of a UTXO must receive,
> store and verify the full sequence of previous owner backup transactions to
> make sure that no previous owner has asked the SE to sign a transaction
> that could be used to steal the UTXO. This may end up making wallets more
> bloated and clunky, given that ownership of a UTXO could change hands
> thousands of times off-chain.
>
> In the case of a multisig, and Schnorr signatures, existing blind Schnorr
> protocols could be used to implement a blind SE, however we are opting to
> use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA
> will give a much bigger anonymity set). There is no current 2P ECDSA
> protocol that enables one of the two signers to be completely blinded, but
> it seems that this would require only minor modifications to an existing 2P
> ECDSA scheme (outlined here
> https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md
> based on Lindell 2017 https://eprint.iacr.org/2017/552 ).
>
> Any comments on any of this gratefully received.
>
> Tom
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bit

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,

>If Alice is paying to a non-SAS aware payee

Yeah, I agree that this use case is not possible without a third
transaction (preferably from the timelocked side, in the case of SAS). My
point was merely that you can swap and simultaneously merge some of your
outputs into the post-swap non-timelocked output, though perhaps that is
not very useful.

Cheers,
Ruben



On Mon, Jun 1, 2020 at 4:34 AM ZmnSCPxj  wrote:

> Good morning Ruben,
>
>
> >
> > That assumes there will be a second transaction. With SAS I believe we
> can avoid that, and make it look like this:
> >
> >  +---+
> > Alice ---|   |--- Bob
> > Alice ---|   |
> >   Bob ---|   |
> >  +---+
>
> If Alice is paying to a non-SAS aware payee that just provides an onchain
> address (i.e. all current payees today), then the 2-of-2 output it gets
> from the swap (both of whose keys it learns at the end of the swap) is
> **not** the payee onchain address.
> And it cannot just hand over both private keys, because the payee will
> still want unambiguous ownership of the entire UTXO.
> So it needs a second transaction anyway.
> (with Schnorr then Alice and payee Carol can act as a single entity/taker
> to Bob, a la Lightning Nodelets using Composable MuSig, but that is a
> pretty big increase in protocol complexity)
>
> If Alice does not want to store the remote-generated privkey as well, and
> use only an HD key, then it also has to make the second transaction.
> Alice might want to provide the same assurances as current wallets that
> memorizing a 12-word or so mnemonic is sufficient backup for all the funds
> (other than funds currently being swapped), and so would not want to leave
> any funds in a 2-of-2.
>
> If Bob is operating as a maker, then it also cannot directly use the
> 2-of-2 output it gets from the swap, and has to make a new 2-of-2 output,
> for the *next* taker that arrives to request its services.
>
> So there is always going to be a second transaction in a SwapMarket
> system, I think.
>
>
> What SAS / private key turnover gets us is that there is not a *third*
> transaction to move from a 1-of-1 to the next address that makers and
> takers will be moving anyway, and that the protocol does not have to add
> communication provisions for special things like adding maker inputs or
> specifying all destination addresses for the second stage and so on,
> because those can be done unilaterally once the private key is turned over.
>
>
> > >A thing I have been trying to work out is whether SAS can be done with
> more than one participant, like in S6
> >
> > S6 requires timelocks for each output in order to function, so I doubt
> it can be made to work with SAS.
>
> Hmmm right right.
>
> Naively it seems both chaining SAS/private key turnover to multiple
> makers, and a multi-maker S6 augmented with private key turnover, would
> result in the same number of transactions onchain, but I probably have to
> go draw some diagrams or something first.
>
> But S6 has the mild advantage that all the funding transactions paying to
> 2-of-2s *can* appear on the same block, whereas chaining swaps will have a
> particular order of when the transactions appear onchain, which might be
> used to derive the order of swaps.
> On the other hand, funds claiming in S6 is also ordered in time, so
> someone paying attention to the mempool could guess as well the order of
> swaps.
>
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,

>Just to be clear, you mean we can use the MuSig key-combination protocol
for the non-timelocked SAS output, but (of course) not the signing protocol
which is inherently Schnorr. Then knowledge of both of the original private
keys is enough to derive the single combined private key.

That's correct.

>basically private key handover gets us PayJoin for free

That assumes there will be a second transaction. With SAS I believe we can
avoid that, and make it look like this:

 +---+
Alice ---|   |--- Bob
Alice ---|   |
  Bob ---|   |
 +---+

This is basically what I was trying to explain in my previous email: "I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement)"

I don't have a strong opinion on whether it is actually useful to combine
CoinSwap with PayJoin.

>A thing I have been trying to work out is whether SAS can be done with
more than one participant, like in S6

S6 requires timelocks for each output in order to function, so I doubt it
can be made to work with SAS.

I've also tried applying SAS to partially blind swaps and ran into
likability issues, though it's less clear to me whether there is some
fundamental reason why it couldn't work there.

Cheers,
Ruben

On Sun, May 31, 2020 at 4:31 AM ZmnSCPxj  wrote:

> Good morning Ruben and Chris,
>
> > >For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses
> >
> > This may perhaps be counter-intuitive, but SAS doesn't actually require
> multisig for one of the two outputs, so a single key will suffice. ECDSA is
> a signing algorithm that doesn't support single key multisig (at least not
> without 2p-ECDSA), but notice how for the non-timelocked SAS output we
> never actually have to sign anything together with the other party. We swap
> one of the two keys, and the final owner will create a signature completely
> on their own. No multisig required, which means we can simply use MuSig,
> even today without Schnorr.
>
> Just to be clear, you mean we can use the MuSig key-combination protocol
> for the non-timelocked SAS output, but (of course) not the signing protocol
> which is inherently Schnorr.
>
> Then knowledge of both of the original private keys is enough to derive
> the single combined private key.
>
> > Of course the other output will still have to be a 2-of-2, for which you
> rightly note 2p-ECDSA could be considered. It may also be interesting to
> combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
> want to open a channel with 1 BTC each, but Alice funds it in her entirety
> with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
> to tell Bob entered the Lightning Network, especially if the channel is
> opened in a state that isn't perfectly balanced. And Alice will gain an
> uncorrelated single key output.
>
> Dual-funding could be done by a single-funding Lightning open followed by
> an onchain-to-offchain swap.
> Though the onchain swap would have to be done, at least currently, with
> hashes.
>
> > >=== PayJoin with CoinSwap ===
> >
> > While it's probably clear how to do it on the timelocked side of SAS, I
> believe PayJoin can also be applied to the non-timelocked side. This does
> require adding a transaction that undoes the PayJoin in case the swap gets
> aborted, which means MuSig can't be used. Everything else stays the same:
> only one tx if successful, and no timelock (= instant settlement). I can
> explain it in detail, if it happens to catch your interest.
>
> I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much
> privacy.
>
> These transactions:
>
>  +---+  +---+
> Alice ---|   |--|   |--- Bob
> Alice ---|   |  |   |
>   Bob ---|   |  +---+
>  +---+
>
> Are not really much different in coin ownership analysis from these:
>
>  +---++---+
> Alice ---|   ||   |--- Bob
> Alice ---|   | +--|   |
>  +---+ |  +---+
>   Bob -+
>
> The latter is possible due to private key handover, the intermediate
> output becomes owned solely by Bob and Bob can add many more inputs to that
> second transaction unilaterally for even greater confusion to chain
> analysis, basically private key handover gets us PayJoin for free.
> It also removes the need for Bob to reveal additional UTXOs to Alice
> during the swap protocol; yes PoDLE mitigates the privacy probing attack
> that Alice can mount on Bob, but it is helpful to remember this is "only" a
> mitigation.
>
> Now of course things are different if Alice is paying some exact amount to
> Carol, and Alice wants to dissociate her funds from the payment.
> The difference i

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

[Ruben Somsen via bitcoin-dev]

Hey Chris,

Excellent write-up. I learned a few new things while reading this
(particularly how to overcome the heuristics for address reuse and address
types), so thank you for that.

I have a few thoughts about how what you wrote relates to Succinct Atomic
Swaps (SAS)[0]. Perhaps it's useful.

>For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2
multisignature addresses that look the same as regular single-signature
addresses

This may perhaps be counter-intuitive, but SAS doesn't actually require
multisig for one of the two outputs, so a single key will suffice. ECDSA is
a signing algorithm that doesn't support single key multisig (at least not
without 2p-ECDSA), but notice how for the non-timelocked SAS output we
never actually have to sign anything together with the other party. We swap
one of the two keys, and the final owner will create a signature completely
on their own. No multisig required, which means we can simply use MuSig,
even today without Schnorr.

Of course the other output will still have to be a 2-of-2, for which you
rightly note 2p-ECDSA could be considered. It may also be interesting to
combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
want to open a channel with 1 BTC each, but Alice funds it in her entirety
with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
to tell Bob entered the Lightning Network, especially if the channel is
opened in a state that isn't perfectly balanced. And Alice will gain an
uncorrelated single key output.

As a side note, we could use the same MuSig observation on 2-of-2 outputs
that need multisig by turning the script into (A & B) OR MuSig(A,B), which
would shave off quite a few bytes by allowing single sig spending once the
private key is handed over, but this would also make the output stick out
like a sore thumb... Only useful if privacy is not a concern.

>=== Multi-transaction CoinSwaps to avoid amount correlation ===

This can apply cleanly to SAS, and can even be done without passing on any
extra secrets by generating a sharedSecret (Diffie-Hellman key exchange).

Non-timelocked:
CoinSwap AddressB = aliceSecret + bobSecret
CoinSwap AddressC = aliceSecret + bobSecret + hash(sharedSecret,0)*G
CoinSwap AddressD  = aliceSecret + bobSecret + hash(sharedSecret,1)*G

The above is MuSig compatible (single key outputs), there are no timelocks
to worry about, and the addresses cannot be linked on-chain.

>they would still need to watch the chain and respond in case a
hash-time-locked contract transaction is broadcasted

Small detail, but it should be noted that this would require the atomic
swap to be set up in a specific way with relative timelocks.

>=== PayJoin with CoinSwap ===

While it's probably clear how to do it on the timelocked side of SAS, I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement). I can
explain it in detail, if it happens to catch your interest.

Cheers,
Ruben


[0]  Succinct Atomic Swaps (SAS)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html

On Mon, May 25, 2020 at 3:21 PM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> === Abstract ===
>
> Imagine a future where a user Alice has bitcoins and wants to send them
> with maximal privacy, so she creates a special kind of transaction. For
> anyone looking at the blockchain her transaction appears completely
> normal with her coins seemingly going from address A to address B. But
> in reality her coins end up in address Z which is entirely unconnected
> to either A or B.
>
> Now imagine another user, Carol, who isn't too bothered by privacy and
> sends her bitcoin using a regular wallet which exists today. But because
> Carol's transaction looks exactly the same as Alice's, anybody analyzing
> the blockchain must now deal with the possibility that Carol's
> transaction actually sent her coins to a totally unconnected address. So
> Carol's privacy is improved even though she didn't change her behaviour,
> and perhaps had never even heard of this software.
>
> In a world where advertisers, social media and other companies want to
> collect all of Alice's and Carol's data, such privacy improvement would
> be incredibly valuable. And also the doubt added to every transaction
> would greatly boost the fungibility of bitcoin and so make it a better
> form of money.
>
> This undetectable privacy can be developed today by implementing
> CoinSwap, although by itself that isn't enough. There must be many
> building blocks which together make a good system. The software could be
> standalone as a kind of bitcoin mixing app, but it could also be a
> library that existing wallets can implement allowing their users to send
> Bitcoin trans

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

[Ruben Somsen via bitcoin-dev]

Hi Dmitry,

>But it should be noted that it is not enough that Bob publishes success_tx
before refund_tx_1 became valid. The success_tx needs to be confirmed
before refund_tx_1 became valid.

Agreed, my write-up would benefit from pointing this out more explicitly.

Cheers,
Ruben

On Thu, May 14, 2020 at 9:05 AM Dmitry Petukhov  wrote:

> В Thu, 14 May 2020 07:31:13 +0200
> Ruben Somsen  wrote:
>
> > Hi Dmitry,
> >
> > >While refund_tx_1 is in the mempool, Bob gives success_tx to the
> > >friendly miner
> >
> > I see, so you're talking about prior to protocol completion, right
> > after Alice sends Bob the success_tx. The reason this is not an issue
> > is because Alice and Bob both had to misbehave in order for this to
> > happen. Bob is misbehaving here because he should have published the
> > success_tx before refund_tx_1 became valid, and Alice is misbehaving
> > here because she should have sent the revoke_tx (which invalidates
> > the success_tx) followed by refund_tx_2 (revealing her secret only
> > AFTER Bob can no longer claim the BTC). In other words: yes, the
> > protocol can fail if Alice and Bob together work towards that goal. A
> > feature, not a bug. This won't happen if either of them doesn't want
> > it to. I imagine this is difficult to model.
>
> Right. But it should be noted that it is not enough that Bob publishes
> success_tx before refund_tx_1 became valid. The success_tx needs to be
> confirmed before refund_tx_1 became valid.
>
> Only Bob can spend success_tx so this is unlikely to be the practical
> problem, unless the original fee of success_tx is too small and Bob
> epically screws up CPFP-ing it.
>
> > >Bob will receive BTC, and the LTC can be locked forever, but Bob
> > >doesn't
> > care, he got his BTC.
> >
> > No, because diagram step 5 comes before step 6 -- Alice won't give
> > her key until she learns secretBob.
>
> I somehow missed it, and steps 5 and 6 in the diagram was not modelled
> at all (on the other hand, it made the model simpler and I had
> something working relatively quick). I now made the `signers_map` into
> variable that can be changed to give Bob the ability to sign for Alice.
>
> With that change, step 6 can be modelled, but this will add a bunch of
> new txs to the model (each Alice&Bob spend will have 'Bob unilateral
> override' case)
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

[Ruben Somsen via bitcoin-dev]

Hi Dmitry,

>While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly
miner

I see, so you're talking about prior to protocol completion, right after
Alice sends Bob the success_tx. The reason this is not an issue is because
Alice and Bob both had to misbehave in order for this to happen. Bob is
misbehaving here because he should have published the success_tx before
refund_tx_1 became valid, and Alice is misbehaving here because she should
have sent the revoke_tx (which invalidates the success_tx) followed by
refund_tx_2 (revealing her secret only AFTER Bob can no longer claim the
BTC). In other words: yes, the protocol can fail if Alice and Bob together
work towards that goal. A feature, not a bug. This won't happen if either
of them doesn't want it to. I imagine this is difficult to model.

>As I understand, this is a way to deny Alice to use refund_tx_1.

That is correct, and it also denies refund_tx_2 by making the revoke_tx
directly spendable by Bob.

>could Bob just spend the Alice&Bob output of the very first, "commitment"
transaction that locks BTC

Yes, he can. This is what makes it possible to complete the protocol in
merely two transactions.

>Bob will receive BTC, and the LTC can be locked forever, but Bob doesn't
care, he got his BTC.

No, because diagram step 5 comes before step 6 -- Alice won't give her key
until she learns secretBob.

I hope this clarifies it!

Cheers,
Ruben

On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov  wrote:

> В Wed, 13 May 2020 21:03:17 +0200
> Ruben Somsen  wrote:
>
> > 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).
>
> This one.
>
> The issue as I see it: Bob can not broadcast success_tx and wait until
> Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,
> Bob gives success_tx to the friendly miner to have a chance to
> invalidate success_tx. Bob already learned secretAlice, so he grabs
> his LTC back. If the Bob-friendly miner has luck, success_tx is
> confirmed while refund_tx_1 is invalidated, and Bob now have both LTC
> and BTC, while Alice is out of her BTC.
>
> > >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.
>
> Ah, so this is possible because of the step 5 in the diagram: ``Alice
> gives Bob her key ("Alice")'' -- As I understand, this is a way to deny
> Alice to use refund_tx_1.
>
> Then if Alice gives her _key_ to Bob before Bob has to share secretBob
> via success_tx, could Bob just spend the Alice&Bob output of the
> very first, "commitment" transaction that locks BTC ? Bob will receive
> BTC, and the LTC can be locked forever, but Bob doesn't care, he got
> his BTC.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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  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 
> 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
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

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 
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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,

Thanks for your feedback :)

>CoinSwap for privacy is practically a "cross" chain atomic swap with the same 
>chain and token for both sides of the swap

I agree, I didn't mean to imply that was new, only that this protocol
makes it more efficient.

>"Instead, Bob simply hands secretBob to Alice" is basically the same as 
>private key turnover

Thanks for the link. I will add it to the links at the bottom of the
write-up, as I agree it's related. Do note there are a few key
differences:

- The swap is set up in an "asymmetric" way with only timelocks on one
side, so on the other side the swap *never* expires
- The timelocks are set up in such a way that the swap does not expire
unless Alice starts the relative timelock countdown (the revoke
transaction)
- This relative timelock setup comes practically for free, because the
asymmetry naturally requires that kind of setup

>The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin and 
>similar blockchains, by signing a specific `nSequence`

"OR Alice in +1 day" is "refund transaction #1" from the diagram. If
I'm not mistaken, the change you are suggesting is exactly how "refund
transaction #2" is constructed. Note that #1 and #2 serve the same
purpose. Strictly speaking, #1 is not needed at all, but it's there to
give Alice the option to back out of the swap in two transactions as
opposed to three.

>It strikes me that the relative locktime is unnecessary on the output of this 
>refund tx

I believe I addressed this in the FAQ section (the question about
absolute timelocks). An absolute timelock is possible, but you then
need to make absolutely sure that the revoke transaction confirms in
time, otherwise the protocol can fail (namely after Bob has received a
copy of the success transaction and just waits and does nothing). You
also lose the ability to keep the channel open indefinitely.

>having a variety of different versions of the transactions with different 
>feerates could be used

That's a good point.

>As long as the one resolving a particular side of the swap is the one that 
>ocmpletes the signature (which I believe holds true for all branches?)

Unfortunately this does not hold for the revoke transaction. It would
be a bit awkward if Alice had a high fee copy after the protocol
completes. She could send it to the blockchain and essentially Bob
would be paying for it. I'm not as concerned about the other
transactions, because those could all be bumped with CPFP if needed,
but having different feerates would be nice.

And a general comment about privacy: it seems inevitable that some
information will be leaked if the protocol does not complete
cooperatively. As long as the cooperative case is not traceable, that
seems about as good as it can get. That's my view, at least. I'd be
curious to hear if you see that differently.

Cheers,
Ruben



On Mon, May 11, 2020 at 6:45 PM ZmnSCPxj  wrote:
>
> Good morning Ruben,
>
> CoinSwap for privacy is practically a "cross" chain atomic swap with the same 
> chain and token for both sides of the swap, see also this set of ideas: 
> https://github.com/AdamISZ/CoinSwapCS/issues/53
>
> "Instead, Bob simply hands secretBob to Alice" is basically the same as 
> private key turnover, as best as I can understand it, and gives significant 
> advantages, also described in passing here: 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017816.html
>
> Overall, this looks very much like a working CoinSwap as well.
>
> The Refund tx does not need anything more than a 2-of-2 script.
> The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin and 
> similar blockchains, by signing a specific `nSequence`, or if the chain 
> forking predates BIP68, by using absolute locktimes and signing a specific 
> `nLockTime`, with the destination being just "Alice".
> This should help privacy, as now all `scriptPubKey`s will be 2-of-2 (or P2PKH 
> with 2p-ECDSA).
>
> (It strikes me that the relative locktime is unnecessary on the output of 
> this refund tx --- as long as both participants agree on either Alice or Bob 
> having a longer locktime, you can just use the locktime on the refund tx 
> directly as backout; see the topic "`nLockTime`-protected Backouts" on the 
> CoinSwapCS issue link)
>
> If you are willing to accept protocol complexity, having a variety of 
> different versions of the transactions with different feerates could be used 
> rather than the Decker-Russell-Osuntokun "eltoo" bring-your-own-fees method.
> In terms of privacy this is better as you would not be using anything other 
> than the most boring `SIGHASH_ALL` signing flag, whereas the 
> Decker-Russell-Osuntokun will be identifiable onchain (and thus possibly flag 
> the transaction as "of interest" to surveillors) due to use of 
> `SIGHASH_ANYPREVOUT`.
> As long as the one resolving a particular side of the swap is the one that 
> ocmpletes the signature (which I believe holds true for all branches?) 

[bitcoin-dev] SAS: Succinct Atomic Swap

[Ruben Somsen via bitcoin-dev]

Works today with single signer ECDSA adaptor signatures[0], or with
Schnorr + MuSig.

Diagram here:
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg


Advantages:

- Requires merely two on-chain transactions for successful completion,
as opposed to four
- Scriptless, and one of the chains doesn't need to support timelocks
- Can be used for efficient privacy swaps, e.g. Payswap[1]


Disadvantages:

- Access to money is contingent on remembering secrets (backup complexity)
- Online/watchtower requirement for the timelock supporting chain (not
needed with 3 tx protocol)


Protocol steps:


0.) Alice & Bob pre-sign the following transactions, with exception of
the signatures in [brackets]:

- success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob]
- revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must then
be spent by:
  -- refund_tx (relative timelock, refund to Alice): [sigRefundAlice]
+ {sigRefundBob}
  -- timeout_tx (longer relative timelock, money to Bob):
sigTimeoutAlice + [sigTimeoutBob]

{sigRefundBob} is an adaptor signature, which requires secretAlice to complete


1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyBob as pubkeys

If protocol is aborted after step 1:

- Alice publishes the revoke_tx, followed by the refund_tx &
sigRefundBob, to get her BTC back
- If Alice neglects to publish the refund_tx in time, Bob will claim
the BTC with the timeout_tx


2.) Bob locks up altcoins with Alice, using secretAlice & secretBob as pubkeys

If protocol is aborted after step 2:

- Once Alice publishes sigRefundBob, Bob learns secretAlice and
regains control over the altcoins


3.) Protocol completion:

- Alice hands adaptor signature {sigSuccessAlice} to Bob, which
requires secretBob to complete
- Bob could now claim the BTC via the success_tx, reveal secretBob,
and thus give Alice control over the altcoins (= 3 tx protocol)
- Instead, Bob simply hands secretBob to Alice
- Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_tx
- Bob continues to monitor the chain, because he'll have to respond if
Alice ever publishes the revoke_tx


More graceful protocol failure:

If the protocol aborts after step 1, Alice would have been forced to
make three transactions in total, while Bob has made none. We can
reduce that to two by introducing a second refund_tx with timelock
that can be published ahead of the revoke_tx and directly spends from
the funding transaction. Publishing this transaction would also reveal
secretAlice to Bob via an adaptor signature. In the 3 tx protocol,
this output can go directly to Alice. In the 2 tx protocol with
online/watchtower requirement, this output needs a script: spendable
by Alice + Bob right away OR by Alice after a relative timelock. It is
important to note that this transaction must NOT be published during
step 3. Once Bob can complete the success_tx, the revoke_tx is needed
to invalidate the success_tx prior to revealing secretAlice.


FAQ:

- Why not allow Alice to still claim the altcoins if she accidentally
lets Bob publish the timeout_tx?

Alice could send the revoke_tx at the same time, revealing both
secrets and causing likely losses. This can be solved by adding yet
another transaction, but it wouldn't be efficient and wouldn't
motivate Alice to behave.

- Is it possible to implement this protocol on chains which only
support absolute timelocks?

Yes, but then Bob must spend his swapped coins before the timelock
expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST
confirm before the timeout_tx becomes valid, which may become a
problem if fees suddenly rise. The refund_tx can also not be allowed
to CPFP the timeout_tx, as they must confirm independently in order to
invalidate the success_tx first.

- Can't Alice just publish the revoke_tx after protocol completion?

Yes, she'd first have to move the altcoins (to invalidate
secretAlice), and could then try to claim the BTC by publishing the
revoke_tx, forcing Bob to react on-chain before the refund_tx becomes
valid. The eltoo[2] method of paying for fees (requires
sighash_anyprevout) or a second CPFP-able output may be an improvement
here (and also mitigates fee rising issues), but note that this also
increases the required amount of tx data if the protocol doesn't
complete successfully.

- Can this be made to work with hash locks?

Yes, by making the altcoins spendable via sigAlice + preimageBob OR
sigBob + preimageAlice, and ensuring the contracts on the BTC side
reveal either pre-image. Do note that this is not scriptless and will
thus increase the transaction size.


Open question:

Perhaps it's possible to perform an atomic swap in and out of
Lightning with only a single on-chain transaction. This would require
some kind of secondary set of HTLCs, allowing the sender to cancel a
Lightning payment by revealing a secret after a certain period of
time.


-- Ruben Somsen




Thanks to Lloyd Fournier for f

Re: [bitcoin-dev] Statechain implementations

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,

the current owner can ask the statechain entity to sign an alternative to
> the first stage, with 0 relative locktime


Unless I am misunderstanding something, this seems to run into the problem
that the original first stage transaction is already out there (and its
relative timelock started ticking). There is no mechanism ensuring that the
new tx will have precedence. And even if it did work, I doubt it's cleaner
than doing a cooperative peg-out that simultaneously happens to peg back
in, creating a brand new statechain UTXO with no history.

Cheers,
Ruben

On Sat, Mar 28, 2020 at 6:38 PM Ruben Somsen  wrote:

> Hi Bob,
>
> Looks like we're largely thinking along the same lines.
>
> It's unlikely that a party sending a UTXO to another party will have a
>> UTXO of exactly the right size that's needed
>
>
> My original proposal uses adaptor signatures to ensure swapping UTXOs is
> atomic. All parties choose a secret, then they all make adaptor signatures,
> then they reveal their secret to the statechain entity. The SE then
> publishes the signatures, causing everyone to learn the secret. And if the
> SE doesn't publish, it simply means the transfer didn't occur.
>
> But taking a step back and thinking about an MVP, it may be easier to make
> it more like a fully audited transparent blockchain where multiple users
> create a combined transaction of all the UTXOs they want to swap, which is
> published together with all the corresponding Bitcoin transactions. Then
> adaptor signatures aren't needed.
>
> The downside of that method is that you lose the ability to only validate
> the history of the coins you hold (scalability win). For this to be
> possible, you need to keep the history of every individual UTXO completely
> separate. I still think that is where we eventually want to end up (as well
> as having blind signatures), but it adds a lot of complexity (adaptor
> signatures, sparse merkle trees with non-inclusion proofs...).
>
> The natural solution is to decompose your outputs in a binary decomposition
>
>
> I fully agree, but on top of that I think we also need Lightning,
> because
>
> This same mechanism can also be used to pay the SE for its service through
>> a different UTXO than the one being transferred.
>
>
> My conclusion was that opening a Lightning channel on top of a statechain
> makes more sense for this (as ZmnSCPxj explained in his reply to you). If
> we expect BTC fees to go up, we can't expect the statechain to hold UTXOs
> that are small enough to be used to pay for statechain fees.
>
> More on this in my Breaking Bitcoin 2019 talk (timestamped link):
> https://youtu.be/09HcYRjDkMA?t=850
>
> a logical enhancement would be to use some kind of single-use seal
>
>
> Any kind of system where users transfer ownership through signatures will
> resemble single-use seals, so I'd say that's inevitable! :)
>
> Cheers,
> Ruben
>
>
> On Sat, Mar 28, 2020 at 3:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Bob,
>>
>> > Big picture, it seems to me this idea is workable and very interesting.
>> I see
>> > three likely enhancements that will be necessary or desirable:
>> > 1. Atomic swap of multiple UTXOs, and binary decomposition of value in
>> lots
>> > 2. Key exchange ("addresses") to facilitate a secure comms path from
>> > sender -> receiver
>> >
>> > 3. (Optional) single-use seals to close old state
>> >
>> >
>> > (1) It's unlikely that a party sending a UTXO to another party will
>> have a UTXO
>> > of exactly the right size that's needed, already locked into the
>> statechain. If
>> > he has to create the UTXO first and then lock it into the statechain,
>> the
>> > statechain solution is no better than an on-chain send. And once the
>> receiver
>> > has the UTXO, it's unlikely that he will want to send exactly that same
>> amount
>> > to another receiver later. This isn't a problem in Lightning where
>> amounts can
>> > be arbitrarily updated. As a consequence, I think Lightning is more
>> valuable for
>> > small-value payments, and statechains will be more valuable for larger
>> values.
>> >
>> > The natural solution is to decompose your outputs in a binary
>> decomposition,
>> > having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis,
>> and so
>> > on. Then when I want to send, I select the appropriate UTXOs as a binary
>> > decomposition of the value I want to send, with a "lot size" of 1048576
>> > satoshis, or the dust limit. The notion of "lots" like this is common in
>> > traditional markets...many stocks are bought and sold in lots of 100,
>> and forex
>> > is traded in lots of $100,000. Users of a statechain therefore need
>> log(V)
>> > available UTXOs locked into the statechain, where V is their value in
>> BTC.
>> > Having fixed lot sizes like this also makes coinjoin-type uses more
>> viable. The
>> > statechain could also assist in dividing a UTXO into two utxos of the
>> next lot
>> > siz

Re: [bitcoin-dev] Statechain implementations

[Ruben Somsen via bitcoin-dev]

Hi Bob,

Looks like we're largely thinking along the same lines.

It's unlikely that a party sending a UTXO to another party will have a UTXO
> of exactly the right size that's needed


My original proposal uses adaptor signatures to ensure swapping UTXOs is
atomic. All parties choose a secret, then they all make adaptor signatures,
then they reveal their secret to the statechain entity. The SE then
publishes the signatures, causing everyone to learn the secret. And if the
SE doesn't publish, it simply means the transfer didn't occur.

But taking a step back and thinking about an MVP, it may be easier to make
it more like a fully audited transparent blockchain where multiple users
create a combined transaction of all the UTXOs they want to swap, which is
published together with all the corresponding Bitcoin transactions. Then
adaptor signatures aren't needed.

The downside of that method is that you lose the ability to only validate
the history of the coins you hold (scalability win). For this to be
possible, you need to keep the history of every individual UTXO completely
separate. I still think that is where we eventually want to end up (as well
as having blind signatures), but it adds a lot of complexity (adaptor
signatures, sparse merkle trees with non-inclusion proofs...).

The natural solution is to decompose your outputs in a binary decomposition


I fully agree, but on top of that I think we also need Lightning,
because

This same mechanism can also be used to pay the SE for its service through
> a different UTXO than the one being transferred.


My conclusion was that opening a Lightning channel on top of a statechain
makes more sense for this (as ZmnSCPxj explained in his reply to you). If
we expect BTC fees to go up, we can't expect the statechain to hold UTXOs
that are small enough to be used to pay for statechain fees.

More on this in my Breaking Bitcoin 2019 talk (timestamped link):
https://youtu.be/09HcYRjDkMA?t=850

a logical enhancement would be to use some kind of single-use seal


Any kind of system where users transfer ownership through signatures will
resemble single-use seals, so I'd say that's inevitable! :)

Cheers,
Ruben


On Sat, Mar 28, 2020 at 3:42 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Bob,
>
> > Big picture, it seems to me this idea is workable and very interesting.
> I see
> > three likely enhancements that will be necessary or desirable:
> > 1. Atomic swap of multiple UTXOs, and binary decomposition of value in
> lots
> > 2. Key exchange ("addresses") to facilitate a secure comms path from
> > sender -> receiver
> >
> > 3. (Optional) single-use seals to close old state
> >
> >
> > (1) It's unlikely that a party sending a UTXO to another party will have
> a UTXO
> > of exactly the right size that's needed, already locked into the
> statechain. If
> > he has to create the UTXO first and then lock it into the statechain, the
> > statechain solution is no better than an on-chain send. And once the
> receiver
> > has the UTXO, it's unlikely that he will want to send exactly that same
> amount
> > to another receiver later. This isn't a problem in Lightning where
> amounts can
> > be arbitrarily updated. As a consequence, I think Lightning is more
> valuable for
> > small-value payments, and statechains will be more valuable for larger
> values.
> >
> > The natural solution is to decompose your outputs in a binary
> decomposition,
> > having e.g. UTXOs with 1048576 satoshis, another with 2097152 satoshis,
> and so
> > on. Then when I want to send, I select the appropriate UTXOs as a binary
> > decomposition of the value I want to send, with a "lot size" of 1048576
> > satoshis, or the dust limit. The notion of "lots" like this is common in
> > traditional markets...many stocks are bought and sold in lots of 100,
> and forex
> > is traded in lots of $100,000. Users of a statechain therefore need
> log(V)
> > available UTXOs locked into the statechain, where V is their value in
> BTC.
> > Having fixed lot sizes like this also makes coinjoin-type uses more
> viable. The
> > statechain could also assist in dividing a UTXO into two utxos of the
> next lot
> > size down, so that I have the right UTXOs to hit the value I want to
> send.
>
> My understanding of statechains is that nothing prevents the statechain
> from internally having multiple UTXOs divided from a single large onchain
> UTXO.
>
> Indeed, a statechain can act much like a federated blockchain, and the
> interface to the statechain could be for its clients to send a Bitcoin
> transaction to it spending 1 or more of the UTXOs currently instantiated
> inside the statechain.
> Then the statechain validates the client Bitcoin transaction, updates its
> state and republishes it to its clients, removing the
> (internal-to-statechain-only) UTXOs spent, and inserting the new UTXOs of
> the incoming transaction.
>
> For example, suppose I have a 1BTC onchain UTXO that I 

Re: [bitcoin-dev] Statechain implementations

[Ruben Somsen via bitcoin-dev]

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  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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Statechain implementations

[Ruben Somsen via bitcoin-dev]

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  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@lists.linuxfoundation.org> wrote:
>
>> Ruben Somsen via bitcoin-dev 
>> 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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Statechain implementations

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

[Ruben Somsen via bitcoin-dev]

Hello Nick,

Thank you for your interest.

It is quite different. Unlike MainStay, BMM isn't federation controlled.
It's a decentralized consensus mechanism that can function entirely without
a federation. BMM blocks are chosen by the highest bidder, which can be
anyone.

Note that it would be entirely possible for federations to issue two-way
pegged tokens on this decentralized chain, but keep in mind you'll have two
chains to worry about in terms of reorg potential (i.e. slow peg-outs).

Cheers,
Ruben

On Thu, Dec 26, 2019 at 1:32 PM Nick Gregory  wrote:

> This not similar to MainStay?
>
> https://commerceblock.readthedocs.io/en/latest/mainstay/index.html
>
> https://mainstay.xyz
>
>
> On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Blind Merged Mining (BMM) is the idea of committing the hash of another
>> blockchain into a unique location on the Bitcoin blockchain, and paying a
>> Bitcoin fee to miners for the privilege of deciding this hash and capturing
>> the fees inside the other blockchain. Since miners don’t have to know what
>> the hash represents and are simply incentivized to choose the highest
>> bidder, it requires no extra validation on their part (“blind”). This idea
>> was originally conceived of by Paul Sztorc, but required a specific soft
>> fork. [0]
>>
>> In essence, BMM is a mechanism that allows external blockchains
>> (altcoins, tokens) to outsource their mining to the Bitcoin blockchain.
>> Instead of burning electricity with ASICs, they pay bitcoins to miners, who
>> in turn will perform Proof-of-Work (PoW) for the privilege of obtaining
>> this payment. This increases the total PoW on the Bitcoin blockchain, which
>> adds to the security of the Bitcoin network. It's an easy consensus
>> mechanism to implement, and simple to mine, only requiring full node
>> software for both chains and some bitcoins.
>>
>> While it may be hard to justify this as a soft fork, it turns out that
>> the inclusion of sighash_anyprevout (previously sighash_noinput) into
>> Bitcoin is sufficient to make BMM work, because, as noted by Anthony Towns
>> [1], sighash_anyprevout allows for the creation of op_checktemplateverify
>> (op_ctv, previously op_securethebag) style covenants [2]. With that, we can
>> generate the following without any trusted setup:
>>
>> - A long string of sighash_anyprevout transactions, each only spendable
>> by the next (the spending signature is placed in the output script, making
>> it a covenant)
>> - RBF enabled and signed with sighash flags single, anyonecanpay, and
>> anyprevout, allowing the addition of inputs and outputs in order to pay
>> fees (similar to fees in eltoo [3])
>> - A relative locktime of one block, ensuring only one transaction gets
>> mined per block
>>
>> A complete transaction flow diagram can be found here:
>>
>> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
>>
>> (Note that op_ctv instead of sighash_anyprevout would require the use of
>> CPFP, because all outputs need to be pre-defined.)
>>
>> This setup generates a unique location for the hash, which can be freely
>> competed for by anyone with the help of RBF. The hash can be committed into
>> the fee paying output via taproot. If the block corresponding to the hash
>> is not revealed or invalid, then the BMM block simply gets orphaned, just
>> like in Sztorc’s proposal.
>>
>> While the Bitcoin blockchain will be unaware of the BMM chain, the
>> opposite does not have to be true. This enables some interesting
>> possibilities. For instance, you could make a conditional BMM token
>> transfer that only goes through if a specific Bitcoin transaction occurs
>> within a certain period of time, thus enabling atomic swaps (especially
>> useful when combined with asset issuance/colored coins/pegged tokens). It
>> would also be possible to create contracts based on Bitcoin’s hashrate and
>> such.
>>
>> It seems inevitable that this chain will need some kind of native token
>> in order to pay for fees. This makes me uneasy. The fairest and least
>> speculation-inducing method I can think of is a perpetual one-way peg,
>> where at any time 1 BTC can be burned for 1 token, essentially preserving
>> the 21M coin limit. Coins that are burned will never return, benefiting all
>> BTC holders equally. Holding BTC will always be preferable, because the
>> option to move is always open to you. This should disincentivize
>> speculation -- it only makes sense to move coins if they se

[bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

[Ruben Somsen via bitcoin-dev]

Blind Merged Mining (BMM) is the idea of committing the hash of another
blockchain into a unique location on the Bitcoin blockchain, and paying a
Bitcoin fee to miners for the privilege of deciding this hash and capturing
the fees inside the other blockchain. Since miners don’t have to know what
the hash represents and are simply incentivized to choose the highest
bidder, it requires no extra validation on their part (“blind”). This idea
was originally conceived of by Paul Sztorc, but required a specific soft
fork. [0]

In essence, BMM is a mechanism that allows external blockchains (altcoins,
tokens) to outsource their mining to the Bitcoin blockchain. Instead of
burning electricity with ASICs, they pay bitcoins to miners, who in turn
will perform Proof-of-Work (PoW) for the privilege of obtaining this
payment. This increases the total PoW on the Bitcoin blockchain, which adds
to the security of the Bitcoin network. It's an easy consensus mechanism to
implement, and simple to mine, only requiring full node software for both
chains and some bitcoins.

While it may be hard to justify this as a soft fork, it turns out that the
inclusion of sighash_anyprevout (previously sighash_noinput) into Bitcoin
is sufficient to make BMM work, because, as noted by Anthony Towns [1],
sighash_anyprevout allows for the creation of op_checktemplateverify
(op_ctv, previously op_securethebag) style covenants [2]. With that, we can
generate the following without any trusted setup:

- A long string of sighash_anyprevout transactions, each only spendable by
the next (the spending signature is placed in the output script, making it
a covenant)
- RBF enabled and signed with sighash flags single, anyonecanpay, and
anyprevout, allowing the addition of inputs and outputs in order to pay
fees (similar to fees in eltoo [3])
- A relative locktime of one block, ensuring only one transaction gets
mined per block

A complete transaction flow diagram can be found here:
https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(Note that op_ctv instead of sighash_anyprevout would require the use of
CPFP, because all outputs need to be pre-defined.)

This setup generates a unique location for the hash, which can be freely
competed for by anyone with the help of RBF. The hash can be committed into
the fee paying output via taproot. If the block corresponding to the hash
is not revealed or invalid, then the BMM block simply gets orphaned, just
like in Sztorc’s proposal.

While the Bitcoin blockchain will be unaware of the BMM chain, the opposite
does not have to be true. This enables some interesting possibilities. For
instance, you could make a conditional BMM token transfer that only goes
through if a specific Bitcoin transaction occurs within a certain period of
time, thus enabling atomic swaps (especially useful when combined with
asset issuance/colored coins/pegged tokens). It would also be possible to
create contracts based on Bitcoin’s hashrate and such.

It seems inevitable that this chain will need some kind of native token in
order to pay for fees. This makes me uneasy. The fairest and least
speculation-inducing method I can think of is a perpetual one-way peg,
where at any time 1 BTC can be burned for 1 token, essentially preserving
the 21M coin limit. Coins that are burned will never return, benefiting all
BTC holders equally. Holding BTC will always be preferable, because the
option to move is always open to you. This should disincentivize
speculation -- it only makes sense to move coins if they serve an immediate
purpose.

Given the lack of a block subsidy, there may not be enough impetus to move
the chain forward instead of enacting a reorg. However, BMM reorgs are
somewhat unique in that they will have to compete for the same unique
location that the original chain is using. A 10-block reorg would take 100
minutes on average to catch up, during which the original chain won’t move
forward. If fee pressure of new transactions is targeted exclusively
towards the original chain during this time [4], there would be forward
pressure that makes reorgs more expensive. Whether this mitigation is
sufficient is an open question.

Finally, it is worth asking whether BMM interferes too much with the
existing incentive structure of Bitcoin. I don’t have a clear answer, but
it should be noted that a much more inefficient version of BMM is already
possible today. One could simply use up lots of block space instead of
specifying a unique location for the hash, as demonstrated by Veriblock
[5]. I therefore believe that the same argument as adding data via
op_return applies here -- if it’s not supported, more wasteful methods may
be utilized instead.

Some technical details (thanks to Anthony Towns for providing his insights):

- Since the exact signature is committed to ahead of time, private key
security is actually irrelevant. You can simply use G to replace both R and
P instead of the usual s = r + e*p. This means anyon

Re: [bitcoin-dev] PoW fraud proofs without a soft fork

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,

>I suppose the critical difference is that invalid inflation can fool the SPV 
>node, the fullnode will not be so fooled.

That is correct. If you sybil the SPV node, you can break any
consensus rule you like. I believe this is inherent to fraud proofs in
general, because you skip consensus checks unless you're able to
receive a fraud proof.

But note that my goal in the comparison was to assert that there is no
security difference between committing or not committing the utreexo
hash into a block. The attack your describe works in either situation,
so my conclusion remains that committing the hash adds no security.

Other weaknesses compared to full nodes are:
- the SPV nodes rely on the existence of a healthy network of utreexo
supporting full nodes
- at least one honest block needs to be mined
- consensus slows down, because you need to allow time for an honest
minority to produce a block

Cheers,
Ruben

On Mon, Sep 9, 2019 at 8:58 AM ZmnSCPxj  wrote:
>
> Good morning Ruben,
>
> Yes, I suppose that is correct.
>
> I suppose the critical difference is that invalid inflation can fool the SPV 
> node, the fullnode will not be so fooled.
>
> A somewhat larger-scale attack is to force a miner-supported 
> miner-subsidy-increase / blocksize-increase hard fork.
> If enough such SPV nodes can be sybilled, they can be forced to use the hard 
> fork, which might incentivize them to support the hard fork rather than 
> back-compatible consensus chain.
>
> Regards,
> ZmnSCPxj
>
> > 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 zmnsc...@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,
> > >

Re: [bitcoin-dev] PoW fraud proofs without a soft fork

[Ruben Somsen via bitcoin-dev]

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  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] PoW fraud proofs without a soft fork

[Ruben Somsen via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,


>Basically, the "Stale Factory" and "Broken Factory" problems.

I see, I'll have to read up on those.


>Combining it via MuSig is probably best, as the server is now unable to 
>recognize even the pubkey (assuming it never is informed `X`).

Yes, that's the current thinking. See also:
https://twitter.com/SomsenRuben/status/1138199578996555784 (sorry no
time to make a gist)


>As the server is blinded, it cannot determine anything about the message being 
>signed.

Yes, you could build a non-blind variant with scripting, but that
would be quite different.


>a simple scripting that allows "if somebody provides x of H(x) plus signature 
>A, sign a blinded message M1, else if after 2:30PM PST on Jun 24 2019 if 
>somebody provides signature of B, sign a blinded message M2" could still 
>potentially be useful

I believe adaptor signatures are enough to replace hashing. A time
lock could potentially be added with some very basic scripting, but my
feeling is still that this is better avoided. We're essentially
relying on the Bitcoin blockchain for that, because the off-chain
transactions can be encumbered by any script you like.


>anything that can be done with a UTXO onchain, can also be done offchain via 
>any updateable offchain cryptocurrency system

You're right that I didn't properly point to the key difference, which
is transfer of UTXO ownership. Other off-chain systems don't allow you
to go from e.g. 2-of-2 to 3-of-3, but of course we're adding a
federation in order to make this happen, so it's not exactly a fair
comparison.


>(I should probably look up the authors of the Statechains paper to make my 
>naming convention consistent)

That would be "Somsen". I am the sole author.


>By presenting those "further transactions" to the offchain system, we can 
>provide an argument that the offchain system can just "append" those "further 
>transactions" to the existing unilateral-case transactions, then cut-through 
>the further transactions on its next update

That's an interesting way of looking at it. This is currently achieved
in Statechains by making the top-level on the Statechain N-of-N, so
all participants of the "further transactions" have to agree in order
to achieve full cut-through on the Statechain. In practice this would
mean that the final signature requested from the server is a
"cooperative close".


Cheers,
Ruben


On Thu, Jun 13, 2019 at 3:22 AM ZmnSCPxj  wrote:
>
> Good morning Ruben,
> > > 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.
>
> Sorry, I am referring to current issues with channel factories, which were 
> not addressed in the original channel factories paper.
> Basically, the "Stale Factory" and "Broken Factory" problems.
> Broken factory seems unsolvable.
> Stale factory is fixable if the channels within the factory use 
> `SIGHASH_NOINPUT` (assuming it gets into Bitcoin) for all unilateral paths 
> (use `SIGHASH_ALL` for cooperative paths).
>
> >
> > > 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.
>
> On reflection, probably best not to.
> It requires a script that reveals the pubkeys.
> And it now becomes possible for the server to monitor the blockchain for 
> revelation of server pubkey in a spend path.
> This will let the server know, after-the-fact, that it was signing blockchain 
> transactions.
> This might not let it preemptively censor or otherwise disrupt, but it 
> *could* sell the private fact that a statechain was used.
> Combining it via MuSig is probably best, as the server is now unable to 
> recognize even the pubkey (assuming it never is informed `X`).
>
> >
> > > 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.
>
> On reflection, this is probably best.
> As the server is blinded, it cannot determine anything about the message 
> being signed.
>
> On the other cognition sub-agent, however, a simple scripting that allows "if 
> somebody provides x of H(x) plus signature A, sign a blinded message M1, else 
> if after 2:30PM PST on Jun 24 2019 if somebody provides signature of B, sign 
> a blinded message M2" could still potentially be useful, and might allow 
> "programmable escrow" like I imagine Smart Contracts Unchained could allow.
>
> >
> > 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.
>
> The Real (TM) obse

Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

[Ruben Somsen via bitcoin-dev]

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  wrote:
>
> Good morning Ruben,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, June 6, 2019 1:20 PM, Ruben Somsen  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 zmnsc...@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 

Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

[Ruben Somsen via bitcoin-dev]

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

[bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,


Allow me to reply to your post in mixed order (fraud proofs first):


>But peers can be set up to allow you to hear of all chains while denying you 
>proof of the invalidity of some UTXO.

I don't believe this is fundamentally different. In either scenario
you end up on the wrong chain if all your peers are lying to you. One
happens by omission of a fraud proof, while the other happens by
omission of a valid longest chain.


>This is precisely the "data unavailability claim" that shot down the previous 
>fraud proofs

The "data unavailability" issue I was referring to, and which I
believe is the reason why fraud proofs were abandoned, is the
following:

- Alice downloads a block with her full node, but the block is
incomplete (e.g. a transaction is missing).
- Alice reports this to Bob's SPV fraud proof client, who verifies
this by requesting the transaction from the network.
- If Bob can't download it, he rejects the block.
- If Bob can download it, either Alice was malicious, or a miner was
temporarily withholding the data.
- Since Bob can't be certain Alice was being malicious, Bob can't ban
her, which results in a DoS vector where SPV fraud proof clients can
be forced to download all blocks.

We circumvent the data unavailability problem here completely, since
we are only questioning the validity of blocks which are involved in a
fork (expensive and/or rare), and we are simply always downloading
them in full.

If my arguments above hold up, we can use fraud proof commitments as
described in segwit BIP141 [0] instead of UTXO set commitments, which
seems like the more elegant way to achieve the desired outcome.


>Perhaps in combination with BIP157/158 it may be possible, if the filters 
>contain UTXO spends and a BIP158 filter was committed to on-chain. Then a 
>proof of absence could be done by revealing all the BIP158 filters from the 
>UTXO creation to the block being validated, as well as the blocks whose BIP158 
>filters matched the UTXO and revealing that no, they actually do not spend the 
>UTXO.

Yes, I mentioned something similar to Laolu, but it does seem
computationally expensive to run every input in a block through the
filter of every past block. The fact that BIP157/158 can function
without commitments is also why I suspected we may not necessarily
need UTXO set commitments.


>UTXO sets can only be validated by actually running the entire blockchain, 
>i.e. fullnoding.

It seems to me you can validate uncommitted UTXO sets by comparing
them. Download and compare UTXO set hashes from multiple peers. If
they disagree on a certain block, download that block and the relevant
merkle path(s) from the previous block's UTXO set, and then verify who
is right. Ban the peer who lied. Note that unlike fraud proofs, it is
not possible to lie by omission, but it does assume one of your peers
is honest. Of course this does nothing to dispute your earlier point
that this may not be all that efficient (e.g. full nodes keeping
merkle paths of all prior states).


>What BIP157 does is summarize data that is within a block, thus validating 
>them can be done simply by downloading the block in question.
>UTXO sets summarize data in the entire blockchain, hence proper validation 
>requires downloading the entire blockchain.
Thus it cannot be a comparison point.

It's still possible to lie by omission. Let's say a miner spends some
coins in block N, and spends the exact same coins again in block N+1,
making block N+1 invalid. If the filter for block N is maliciously
constructed, you won't notice the spend in block N, causing you to
think block N+1 is valid. In short, you're still relying on one of
your peers to give you a correct filter. If all your peers lie, you
can always be deceived.


>Tangentially, we cannot just magically commit to anything on the blockchain. 
>[...] if you are adding new information to be committed, that may increase the 
>resource usage of fullnodes. [...] This is probably still better than BIP37 
>but we should still be aware the additional load on fullnodes.

I agree with all this.


To summarize, this is my current understanding of our options for
enabling light clients to verify a single block in isolation:
1. UTXO set commitments (complex, more resource usage to full nodes)
2. BIP157/158 commitments (expensive for clients to check all filters
to get exclusion proofs)
3. BIP141 fraud proof commitments (assumes fraud proofs will be passed
on to the SPV client)

The debate is still open on whether the options above can be done
without actually committing them into blocks via a soft fork. My
current hunch is "yes" for 1 and 2, and "no" for 3, which would be
unfortunate, because 3 currently seems to me like the more elegant
solution.


-- Ruben Somsen


[0] 
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Compact_fraud_proof_for_SPV_nodes


>UTXO sets can only be validated by actually running the entire blockchain, 
>i.e. fullnoding.
>What BIP157 does is s

Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj,

>There is no safe way to use UTXO sets without identifying who is telling you 
>those sets are valid, or making it expensive to lie
>The first option requires trust and is weaker than SPV, the second requires 
>committing to a proof-of-work

Olaoluwa Osuntokun's BIP157 manages to function without a commitment:
"If the client receives conflicting filter headers from different
peers for any block and filter type, it SHOULD interrogate them to
determine which is faulty."

I am wondering if the same logic can be applied to UTXO sets or the
fraud proofs I just described.

>This makes no sense
>or you trust that every peer you have is not omitting the proof.

It's the latter, you trust every peer you have is not omitting the
proof. It requires one honest peer. The reason this is acceptable is
because you're already making that assumption. If none of your peers
are honest, you have no guarantee of hearing about the chain with the
most PoW.

Again, this is not a new observation. I am just recalling the fraud
proof debate from when it was being considered for segwit (though of
course it's possible I got some details wrong).

-- Ruben Somsen

On Sat, Apr 20, 2019 at 3:59 AM ZmnSCPxj  wrote:
>
> Good morning,
>
>
> > > As I understand it, this requires that UTXO commitments be mandatory.
> >
> > Perhaps UTXO sets can be made useful without committing them. I have
> > some very loose thoughts on the subject, I consider it an open
> > question.
>
> There is no safe way to use UTXO sets without identifying who is telling you 
> those sets are valid, or making it expensive to lie.
> The first option requires trust and is weaker than SPV, the second requires 
> committing to a proof-of-work (and probably best to fold it into the Bitcoin 
> blockchain if so).
>
> You would get the UTXO commitment from the previous block (if the UTXO 
> commitment is in the coinbase, then all you need is the Merkle proof of the 
> coinbase).
>
>
> >
> > > More difficult is: how can an SPV node acquire the UTXO set at a 
> > > particular block?
> >
> > I think you are asking fair questions about how the UTXO set
> > commitments would work in practice, and how viable that makes it. I'm
> > not sure. The most comprehensive work I have seen on this topic has
> > been the utreexo proposal by Tadge Dryja:
> > https://www.youtube.com/watch?v=edRun-6ubCc
> >
> > Actually, now that I think about it... As an alternative to UTXO set
> > commitments, the old fraud proofs idea for segwit can be applied here.
> >
> > We get miners to commit to the location of the UTXOs that are being
> > spent (e.g. transaction 5 in block 12). This allows full nodes to
> > succinctly prove invalidity to SPV clients in the following ways:
> >
> > -   a committed location does not contain the stated UTXO
> > -   the UTXO has already been spent in a prior block
> >
> > If no fraud proofs are given, then the inputs can be assumed to be 
> > valid.
> >
> > As you may recall, these kinds of fraud proofs were abandoned mainly
> > because the data unavailability claim could only be verified by
> > downloading the data, resulting in a DoS vector where all blocks had
> > to be downloaded. This problem does not seem to apply here, because we
> > are only interested in blocks which have forks, so it's more doable to
> > download them.
>
> This makes no sense.
> In order to validate block N, you need to know that every UTXO spent by a 
> transaction in block N is valid.
> The UTXO you want to validate is located in some other block, not on the 
> single block you are verifying.
>
> Thus the non-existent fraud proof can only be validated by loading the block 
> of the UTXO purported to be spent, and every block between that and the 
> current block you are verifying, i.e. fullnode.
> Either that or you trust that every peer you have is not omitting the proof.
>
> Regards,
> ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

[Ruben Somsen via bitcoin-dev]

Hi ZmnSCPxj and Ethan,

I apologize if my initial explanation was confusing, but it looks like
you figured it out. For every fork, SPV clients only have to download
one block. If there is a fork after block N, this means there are two
blocks at N+1. You only download and verify N+1 from the longer chain.

>Mining a block which will never be accepted is an expensive way to make SPV 
>clients download validate and discard ~2-4 megabytes of data

Absolutely, hence the name "PoW fraud proof". It gets naturally
created by honest miners and is prohibitively expensive to forge.

>SPV clients may not even learn about these splits because it requires that 
>someone relay the split to them. Honest full nodes should not relay such 
>splits.

You could perform a fully valid repeated 1-block reorg from the top of
the chain. So at least theoretically you could get an honest network
to relay every split.

>Having SPV clients slow down or become full nodes when a malicious miner with 
>significant mining power is attempting to disrupt the network is probably a 
>best case outcome.

That is an excellent point.

>As I understand it, this requires that UTXO commitments be mandatory.

Perhaps UTXO sets can be made useful without committing them. I have
some very loose thoughts on the subject, I consider it an open
question.

> More difficult is: how can an SPV node acquire the UTXO set at a particular 
> block?

I think you are asking fair questions about how the UTXO set
commitments would work in practice, and how viable that makes it. I'm
not sure. The most comprehensive work I have seen on this topic has
been the utreexo proposal by Tadge Dryja:
https://www.youtube.com/watch?v=edRun-6ubCc

Actually, now that I think about it... As an alternative to UTXO set
commitments, the old fraud proofs idea for segwit can be applied here.

We get miners to commit to the location of the UTXOs that are being
spent (e.g. transaction 5 in block 12). This allows full nodes to
succinctly prove invalidity to SPV clients in the following ways:

- a committed location does not contain the stated UTXO
- the UTXO has already been spent in a prior block

If no fraud proofs are given, then the inputs can be assumed to be valid.

As you may recall, these kinds of fraud proofs were abandoned mainly
because the data unavailability claim could only be verified by
downloading the data, resulting in a DoS vector where all blocks had
to be downloaded. This problem does not seem to apply here, because we
are only interested in blocks which have forks, so it's more doable to
download them.

-- Ruben Somsen

On Fri, Apr 19, 2019 at 6:48 AM ZmnSCPxj  wrote:
>
> Good morning Ethan,
>
> > My above email contains an error. The SPV client needs to only
> > download S+1, not S+1 and S+2.
> >
> > I agree with you that a weakness of this approach is a miner can make
> > SPV clients do substantially more work. However:
> >
> > 1.  Mining a block which will never be accepted is an expensive way to
> > make SPV clients download, validate and discard ~2-4 megabytes of
> > data. There are far less expensive ways of wasting the resources of
> > SPV clients. Its unclear why someone would want to do this instead of
> > just packeting full nodes or SPV servers like we saw with the recent
> > DDoS attacks against electrum servers.
> >
> > 2.  SPV clients may not even learn about these splits because it
> > requires that someone relay the split to them. Honest full nodes
> > should not relay such splits. To their bitcoin's worth the attacker
> > must also connect to lots of SPV clients.
> >
> > 3.  Having SPV clients slow down or become full nodes when a malicious
> > miner with significant mining power is attempting to disrupt the
> > network is probably a best case outcome. I would prefer this failure
> > mode to the current SPV behavior which is to just go with the
> > "longest" chain.
>
>
> I understand.
> It seems a reasonable point to do so.
>
> As I understand it, this requires that UTXO commitments be mandatory.
> In particular, if UTXO commitments were not mandatory, it would be trivial to 
> force chainsplits at heights where a UTXO commitment was not made, and force 
> an SPV node to download more blocks backwards until a block with a UTXO 
> commitment is found.
>
> More difficult is: how can an SPV node acquire the UTXO set at a particular 
> block?
> Fullnodes automatically update their UTXO set at each block they accept as 
> tip.
> Reversing the blocks to update the UTXO set at a particular past time would 
> require a good amount of CPU and memory.
> Thus any service that can provide the actual UTXO set at each block would 
> potentially be attackable by simply requesting enough past blocks.
>
>
> Regards,
> ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Improving SPV security with PoW fraud proofs

[Ruben Somsen via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Ruben Somsen via bitcoin-dev]

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

Re: [bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome

[Ruben Somsen via bitcoin-dev]

Hi Damian,

>Where you say "create transactions which are only valid if they are mined on 
>top of a specific block." - in practice, does that usually means at any height 
>above a specific block?

Those details aren't important for the point I was trying to make.
BIP115 allows the transaction to be mined at any height, which is
probably as far as you can take this, realistically. What I think
you'll find in practice, is that the more specific you are in how you
want your transaction to be mined, the higher the chance that your
transaction will inadvertently become unmineable.

A perhaps more general point that I realized after posting, is that
fee pressure towards censorship resistance happens naturally if the
system provides anonymity. If the target transaction that miners wish
to censor is indistinguishable from other anonymous transactions, then
miners will have no choice but to censor every anonymous transaction,
so the end result is very similar to what I imagined linking
transactions would do.

-- Ruben Somsen
On Thu, Sep 6, 2018 at 5:48 PM Damian Williamson  wrote:
>
> Humour me please,
>
>
> Where you say "create transactions which are only valid if they are mined on 
> top of a specific block." - in practice, does that usually means at any 
> height above a specific block?
>
> 
> From: bitcoin-dev-boun...@lists.linuxfoundation.org 
>  on behalf of Ruben Somsen via 
> bitcoin-dev 
> Sent: Sunday, 2 September 2018 3:26:54 AM
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Guiding transaction fees towards a more censorship 
> resistant outcome
>
> When a user creates a transaction with a fee attached, they are
> incentivizing miners to add this transaction to the blockchain. The
> task is usually not very specific -- as long as it ends up in a valid
> chain with the most Proof-of-Work, miners get paid. The payment is an
> incentive for miners to act in the way that users desire.
>
> To the user, there’s an individual benefit: their transaction gets
> added. To the network, there’s a shared benefit: all fees add to the
> security of other transactions in the chain. Miners can choose to
> ignore the incentives, but they would be leaving money on the table
> (and eventually get replaced by more competitive miners).
>
> Transactions from Bitcoin Core are slightly more specific about what
> they ask miners to do. Every transaction is only valid at a block
> height that is one higher than the last block. This incentivizes
> miners to build on top of the last block, instead of going back and
> reorganizing the blockchain. This is especially important in a future
> scenario where the fee reward is larger than the block reward.
>
> BIP 115* by Luke-jr is even more specific. It enables users to create
> transactions which are only valid if they are mined on top of a
> specific block. While originally designed as a form of replay
> protection, it actually serves as a deterrent for miners to reorganize
> the blockchain. If they orphan a block, it will invalidate
> transactions that demanded the inclusion of the orphaned block. This
> increases the cost of intentionally reorganizing the blockchain.
>
> Coinjoin**, the act of combining payments of multiple users into a
> single transaction, can be seen as yet another method for users to be
> more specific. The fate of their payments are now intertwined with
> that of others. If miners wish to censor a single payment, they have
> to reject the entire transaction, and the associated fee amount.
> Techniques like mimblewimble simplify this process, by making coinjoin
> non-interactive.
>
> This brings us to a theoretical scenario where:
>
> - every block contains only a single coinjoin transaction
> - the validity of this transaction depends on the inclusion of a
> specific previous block
> - the block reward is negligible compared to transaction fees
>
> In this scenario, if miners wish to undo a specific transaction that
> happened two blocks ago, they would have to create three empty blocks
> (receiving negligible compensation) in order to overtake the longest
> chain. And even then, users can still refuse to let their new
> transactions be mined on top of the empty blocks, disincentivizing
> such behavior completely.
>
> While not easy to achieve in practice (e.g. resolving natural forks
> becomes more complicated), it demonstrates that users can become more
> empowered than they are today, benefitting censorship resistance***.
> It is this line of thinking that I wish to convey. Perhaps it may
> inspire further ideas in this direction.
>
> -- Ruben Somsen
>
>
> * BIP 115: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg

[bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome

[Ruben Somsen via bitcoin-dev]

When a user creates a transaction with a fee attached, they are
incentivizing miners to add this transaction to the blockchain. The
task is usually not very specific -- as long as it ends up in a valid
chain with the most Proof-of-Work, miners get paid. The payment is an
incentive for miners to act in the way that users desire.

To the user, there’s an individual benefit: their transaction gets
added. To the network, there’s a shared benefit: all fees add to the
security of other transactions in the chain. Miners can choose to
ignore the incentives, but they would be leaving money on the table
(and eventually get replaced by more competitive miners).

Transactions from Bitcoin Core are slightly more specific about what
they ask miners to do. Every transaction is only valid at a block
height that is one higher than the last block. This incentivizes
miners to build on top of the last block, instead of going back and
reorganizing the blockchain. This is especially important in a future
scenario where the fee reward is larger than the block reward.

BIP 115* by Luke-jr is even more specific. It enables users to create
transactions which are only valid if they are mined on top of a
specific block. While originally designed as a form of replay
protection, it actually serves as a deterrent for miners to reorganize
the blockchain. If they orphan a block, it will invalidate
transactions that demanded the inclusion of the orphaned block. This
increases the cost of intentionally reorganizing the blockchain.

Coinjoin**, the act of combining payments of multiple users into a
single transaction, can be seen as yet another method for users to be
more specific. The fate of their payments are now intertwined with
that of others. If miners wish to censor a single payment, they have
to reject the entire transaction, and the associated fee amount.
Techniques like mimblewimble simplify this process, by making coinjoin
non-interactive.

This brings us to a theoretical scenario where:

- every block contains only a single coinjoin transaction
- the validity of this transaction depends on the inclusion of a
specific previous block
- the block reward is negligible compared to transaction fees

In this scenario, if miners wish to undo a specific transaction that
happened two blocks ago, they would have to create three empty blocks
(receiving negligible compensation) in order to overtake the longest
chain. And even then, users can still refuse to let their new
transactions be mined on top of the empty blocks, disincentivizing
such behavior completely.

While not easy to achieve in practice (e.g. resolving natural forks
becomes more complicated), it demonstrates that users can become more
empowered than they are today, benefitting censorship resistance***.
It is this line of thinking that I wish to convey. Perhaps it may
inspire further ideas in this direction.

-- Ruben Somsen


* BIP 115: https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki

** Coinjoin: https://bitcointalk.org/index.php?topic=279249.0

*** Risk sharing principle:
https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev