Ruben Somsen [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-09-01 to 2022-10-20
💬 Posted a total of 82 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, BIP proposal, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0

Profile Code

nprofile1qqsvf3e7frra0ucnjw9fp4cl7hjtuhgpm4q407vwmxdd79rn00ah3cqz0vyqs

Author Public Key

npub1cnrnujx86le38yu2jrt3la0yhewsrh2p2lucakv6mu28x7lm0rsq9qyeq0

Show more details

Last Notes

2023-06-09 13:05:47

- reply

📅 Original date posted:2022-04-15
📝 Original message:
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 <laolu32 at gmail.com>
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 parties to verify the level
> of collateralization on-chain, with the join parties maintaining the
> pool of collateralized assets accordingly?
>
> * continuing with the above, is it feasible to use a DLC script within
> one
> of these fixed tapscript leaves to allow more collateral to be
> added/removed from the pool backing those assets?
>
> I think it's too early to conclude that the scripting layer isn't useful.
> Over time I plan to add more concrete ideas like the above to the section
> tracking the types of applications that can be built on Taro.
>
> > 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.
>
> Exactly! Exactly how practical it ends up being would depend on the types
> of
> covenants deployed in the future. With something like a TLUV and OP_CAT (as
> they're sufficiently generalized vs adding op codes to very the proofs) a
> Script would be able to re-create the set of commitments to restrict the
> set
> of outputs that can be created after spending. One would use OP_CAT to
> handle re-creating the taro asset root, and TLUV (or something similar) to
> handle the Bitcoin tapscript part (swap out leaf index 0 where the taro
> commitment is, etc).
>
> > 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
>
> Yep, the location needs to be fully specified which includes factoring the
> output index as well. A simple way to restrict this would just to say it's
> always the first output. Otherwise, you could lift the output index into
> the
> asset ID calculation.
>
> -- Laolu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/17d2aa29/attachment.html>

2023-06-09 13:05:46

- reply

📅 Original date posted:2022-04-10
📝 Original message:
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 <laolu32 at gmail.com> 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 questions about how things like transfers worked[1][2],
> but it
> seemed either people didn't know, or they hadn't finished the core design
> (large TBD sections) as they were working on adding other components to
> create
> a "new new Internet".
>
> > 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.
>
> This is correct, as a result in most contexts, an incentive exists for the
> holder of an asset to observe the Taro validation rules as otherwise, their
> assets are burnt in the process from the PoV of asset verifiers. In the
> single
> party case things are pretty straight forward, but more care needs to be
> taken
> in cases where one attempts to express partial application and permits
> anyone
> to spend a UTXO in question.
>
> By strongly binding all assets to Bitcoin UTXOs, we resolve issues related
> to
> double spending or duplicate assets, but needs to mind the fact that
> assets can
> be burnt if a user doesn't supply a valid witness. There're likely ways to
> get
> around this by lessening the binding to Bitcoin UTXO's, but then the system
> would need to be able to collect, retain and order all the set of possible
> spends, essentially requiring a parallel network. The core of the system
> as it
> stands today is pretty simple (which was an explicit design goal to avoid
> getting forever distracted by the large design space), with a minimal
> implementation being relatively compact given all the Bitcoin
> context/design
> re-use.
>
> Also one cool trait of the way commitments are designed is that the Taro
> commitment impact the final derived taproot output key. As a result,
> potential
> Script extensions like TAPLEAF_UPDATE_VERIFY can actually be used to
> further
> _bind_ Taro transitions at the Bitcoin level, without Bitcoin explicitly
> needing to be aware of the Taro rules. In short, covenants can allow
> Bitcoin
> Script to bind Taro state transitions, without any of the logic bleeding
> over,
> as the covenant just checks for a certain output key, which is a function
> of
> the Taro commitment being present.
>
> > 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).
>
> Mechanically, with respect to the way the change/UTXOs work in the system,
> both
> are expressible: Dave can chose to merge them into a single UTXO (with the
> appropriate witnesses included for each of them), or Dave can keep them
> distinct in the asset tree. You're correct in that asset issuers may opt to
> issue assets in denominations vs allowing them to be fully divisible.
> Ultimately, the compatibility with the LN layer will be the primary way to
> keep
> asset histories compressed, without relying on another trust model, or
> relying
> on the incentive of an asset issuer to do a "re-genesis" which would
> effectively re-create assets in a supply-preserving manner (burn N units,
> then
> produce a new genesis outpoint for N units). Alternatively,
> implementations can
> also chose to utilize a checkpointing system similar to what some Bitcoin
> full
> node clients do today.
>
> > is that you end up with a linked transaction graph, just like in Bitcoin
>
> This is correct, the protocol doesn't claim to achieve better privacy
> guarantees than the base chain. However inheriting this transaction graph
> model
> imo makes it easier for existing Bitcoin developers to interact with the
> system, and all the data structures are very familiar tooling wise.
> However any
> privacy enhancing protocol used for on-chain top-level Bitcoin UTXOs can
> also
> be applied to Taro, so people can use things like coinswap and coinjoin,
> along
> with LN to shed prior coin lineages.
>
> > This implies the location of the Taro tree inside the taproot tree is not
> > fixed. What needs to be prevented here is that a taproot tree contains
> more
> > than one Taro tree, as that would enable the owner of the commitment to
> show
> > different histories to different people.
>
> Great observation, I patched a similar issue much earlier in the design
> process
> by strongly binding all signatures to a prevOut super-set (so the outpoint
> along with the unique key apth down into the tree), which prevents
> duplicating
> the asset across outputs, as signature verification would fail.
>
> In terms of achieving this level of binding within the Taro tree itself, I
> can
> think of three options:
>
> 1. Require the Taro commitment to be in the first/last position within
> the
> (fully sorted?) Tapscript tree, and also require its sibling to be the
> hash
> of some set string (all zeroes or w/e). We'd require the sibling to the
> empty
> as the tapscript hashes are sorted before hashing so you sort of lose
> that
> final ordering information.
>
> 2. Include the position of the Taro commitment within the tapscript tree
> within the sighash digest (basically the way the single input in the
> virtual
> transaction is created from the TLV structure).
>
> 3. Include the position of the Taro commitment within the tapscript tree
> as
> part of the message that's hashed to derive asset IDs.
>
> AFAICT, #1 resolves the issue entirely, #2 renders transfers outside of the
> canonical history invalid, and #2 minds hte asset ID to the initial
> position
> meaning you can track a canonical lineage from the very start.
>
> > Finally, let me conclude with two questions. Could you clarify the
> purpose of
> > the sparse merkle tree in your design?
>
> Sure, it does a few things:
>
> * Non-inclusion proofs so I can do things like prove to your I'm no
> longer
> committing to my 1-of-1 holographic beefzard card when we swap.
>
> * The key/tree structure means that the tree is history independent,
> meaning
> that if you and I insert the same things into the tree in a different
> order, we'll get the same root hash. This is useful for things like
> tracking all the issuance events for a given asset, or allowing two
> entities to sync their knowledge/history of a single asset, or a set of
> assets.
>
> * Each asset/script mapping to a unique location within the tree means
> it's
> easy to ensure uniqueness of certain items/commitments (not possible to
> commit to the same asset ID twice in the tree as an example).
>
> * The merkle-sum trait means I that validation is made simpler, as you
> just
> check that the input+output commitment sum to the same value, and I can
> also verify that if we're swapping, then you aren't committing to more
> units that exist (so I make sure I don't get an invalid split).
>
> > And the second question – when transferring Taro token ownership from one
> > Bitcoin UTXO to another, do you generate a new UTXO for the recipient or
> do
> > you support the ability to "teleport" the tokens to an existing UTXO
> like how
> > RGB does it? If the latter, have you given consideration to timing issues
> > that might occur when someone sends tokens to an existing UTXO that
> > simultaneously happens to get spent by the owner?
>
> So for interactive transfers, the UTXOs generated as just the ones part of
> the
> MIMO transaction. When sending via the address format, a new non-dust
> output is
> created which holds the new commitment, and uses an internal key provided
> by
> the receiver, so only they can move the UTXO. Admittedly, I'm not familiar
> with
> how the RGB "teleport" technique works, I checked out some slide decks a
> while
> back, but they were mostly about all the new components they were creating
> and
> their milestone of 1 million lines of code. Can you point me to a coherent
> explanation of the technique? I'd love to compare/contrast so we can
> analyze
> the diff tradeoffs being made here.
>
> Thanks for an initial round of feedback/analysis, I'll be updating the
> draft
> over the next few days to better spell things out and particularly that
> commitment/sighash uniqueness trait.
>
> -- Laolu
>
> [1]:
> https://twitter.com/roasbeef/status/1330654936074371073?s=20&t=feV0kWAjJ6MTQlFm06tSxA
> [2]:
> https://twitter.com/roasbeef/status/1330692571736117249?s=20&t=feV0kWAjJ6MTQlFm06tSxA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220410/99b8e403/attachment-0001.html>

2023-06-09 13:05:44

- reply

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

2023-06-07 23:14:48

- reply

📅 Original date posted:2022-10-20
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj at erisian.com.au> 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
> with very low fee, or high purchase amount, or many dependent unconfirmed
> transactions, stuff like that. In some cases we do a human assessment of
> the support ticket and often just pass them through.
>
>
>> > This is very much not nothing, and all of us here want Lightning to
>> grow,
>> > but I think it warrants a serious discussion on whether we want
>> Lightning
>> > adoption to go to 100% by means of disabling on-chain commerce.
>>
>> If the numbers above were accurate, this would just mean you'd go from 60%
>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>>
>
> Point is that RBF transactions are unsafe even when waiting for a
> confirmation, which Peter Todd trivially proved in the reply next to this.
> The reliable solution is to reject all RBF payments and direct those users
> to custodial accounts. There are other variants to solve this with varying
> degree of convolutedness. RBF is a strictly worse UX as proven by anyone
> accepting bitcoin payments at scale.
>
>
>> > For me
>> > personally it would be an easier discussion to have when Lightning is at
>> > 80%+ of all bitcoin transactions.
>>
>> Can you extrapolate from the numbers you've seen to estimate when that
>> might be, given current trends?
>>
>
> Not sure, it might be exponential growth, and the next 60% of Lightning
> growth happen faster than the first 15%. Hard to tell. But we're likely
> talking years here..
>
>
>>
>> > The benefits of Lightning are many and obvious,
>> > we don't need to limit onchain to make Lightning more appealing.
>>
>> To be fair, I think making lightning (and coinjoins) work better is
>> exactly what inspired this -- not as a "make on-chain worse so we look
>> better in comparison", but as a "making lightning work well is a bunch
>> of hard problems, here's the next thing we need in order to beat the
>> next problem".
>>
>
> In deed. The fact that the largest non-custodial Lightning wallet started
> this thread should be an indicator that despite these intentions the
> solution harms more than it fixes.
> Transactions being evicted from mempool is solved by requiring a minimum
> fee rate, which we do and now seems to have become a standard practice.
> Theoretically we can imagine them being evicted anyway but now we're
> several theoreticals deep again when discussing something that will cause
> massive problems right away. In emergency situations CPFP and similar can
> of course be done manually in special circumstances.
>
> Cheers
> Sergej
>
>
> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj at erisian.com.au> 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)
>>
>> > 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?
>>
>> 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
>>
>> > 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
>>
>> > This is very much not nothing, and all of us here want Lightning to
>> grow,
>> > but I think it warrants a serious discussion on whether we want
>> Lightning
>> > adoption to go to 100% by means of disabling on-chain commerce.
>>
>> If the numbers above were accurate, this would just mean you'd go from 60%
>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>>
>> > For me
>> > personally it would be an easier discussion to have when Lightning is at
>> > 80%+ of all bitcoin transactions.
>>
>> Can you extrapolate from the numbers you've seen to estimate when that
>> might be, given current trends? Or perhaps when fine-for-zeroconf txs
>> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
>> work the same in a fullrbf world.
>>
>> > The benefits of Lightning are many and obvious,
>> > we don't need to limit onchain to make Lightning more appealing.
>>
>> To be fair, I think making lightning (and coinjoins) work better is
>> exactly what inspired this -- not as a "make on-chain worse so we look
>> better in comparison", but as a "making lightning work well is a bunch
>> of hard problems, here's the next thing we need in order to beat the
>> next problem".
>>
>> > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> > After interacting with users during high-fee periods I've come to not
>> > appreciate RBF as a solution to that issue. Most users (80% or so)
>> simply
>> > don't have access to that functionality, because their wallet doesn't
>> > support it, or they use a custodial (exchange) wallet etc. Of those that
>> > have the feature - only the power users understand how RBF works, and
>> > explaining how to do RBF to a non-power-user is just too complex, for
>> the
>> > same reason why it's complex for wallets to make sensible
>> non-power-user UI
>> > around it. Current equilibrium is that mostly only power users have
>> access
>> > to RBF and they know how to handle it, so things are somewhat working.
>> But
>> > rolling this out to the broad market is something else and would likely
>> > cause more confusion.
>> > CPFP is somewhat more viable but also not perfect as it would require
>> lots
>> > of edge case code to handle abuse vectors: What if users abuse a
>> generous
>> > CPFP policy to unstuck past transactions or consolidate large wallets.
>> Best
>> > is for CPFP to be done on the wallet side, not the merchant side, but
>> there
>> > too are the same UX issues as with RBF.
>>
>> I think if you're ruling out both merchants and users being able to add
>> fees to a tx to get it to confirm, then you're going to lose either way.
>> Txs will either expire because they've been stuck for more than a week,
>> and be vulnerable to replacement at that point anyway, or they'll be
>> dropped from mempools because they've filled up and they were the lowest
>> fee tx, and be vulnerable to replacement for that reason. In the expiry
>> case, the merchant can rebroadcast the original transaction to keep it
>> alive, perhaps with a good chance of beating an attacker to the punch,
>> but in the full mempool case, you could only do that if you were also
>> CPFPing it, which you already ruled out.
>>
>> Cheers,
>> aj
>>
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/29536c80/attachment-0001.html>

2023-06-07 23:14:05

- reply

📅 Original date posted:2022-10-18
📝 Original message:Hi Rijndael,
I think your thoughts are pretty much compatible with this proposal, as
what I'm describing (the recipient signing their keys) is also essentially
a form of authentication.
It's a good observation that in general this makes the communication of
addresses more secure. I do wish to re-emphasize Bryan's remark that you
still need to ensure the pubkey itself is securely communicated.
>depending on the setup, this could be that the address server also has the
Address Authentication privkey for bob, or it could be that bob gets some
callback or notification, or that bob has pre-signed a batch of addresses
In my opinion the only meaningful distinction is whether Bob runs the
Trustless Address Server himself (full privacy) or not. In either case I
see no reason to diverge from the model where Bob deposits a batch of
signed keys to the server, ensuring that no malicious addresses can be
handed out.
Note I discussed the Trustless Address Server design in the first 20
minutes of this podcast:
https://twitter.com/bitcoinoptech/status/1580573594656333825
And I also brought it up in my presentation at Tabconf last Saturday, but
that video isn't online yet.
Cheers,
Ruben
On Tue, Oct 18, 2022 at 2:07 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unbeknownst to them, the clipboard contents have been replaced with an
>> address controlled by some bad actor.
>>
> [snip]
>
>> Now imagine instead that the wallet has some address book with a pubkey
>> for each recipient the user wants to send bitcoin to.
>>
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/090a0721/attachment.html>

2023-06-07 23:14:04

- reply

📅 Original date posted:2022-10-03
📝 Original message: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 <dave at dtrt.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221004/e94a81c6/attachment-0001.html>

2023-06-07 23:10:48

- reply

📅 Original date posted:2022-06-27
📝 Original message: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 at 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 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.
>
> 3. Payment code versioning is no longer done because it creates the
> potential for fragmentation and disparate standard updates by different
> parties that don't follow the BIP process (BIP47 is a good example of that).
>
> 4. Relying on static compressed pubkeys as opposed to extended keys means
> shorter payment codes.
>
> ==Proposed Payment Code Structure==
>
> bytes 0-1: - enabled (watched) address types (16 possible address types)
> bytes 2-35: - compressed public key P
>
> ==Encoding==
>
> A payment code is encoded in base58check and the version byte produces "S"
> for the first character. A code might look like
> "SwLUHs3UfMUXq956aXLTUPPfow7a8gDfSUUAtafwqHcobf6mKcMbJk".
>
> ==Pubkey Derivation==
>
> Recipient's payment code pubkey `P` is derived from a master key using the
> following path: `m/purpose'/coin_type'/account'`. `purpose` will be defined
> once a BIP number is assigned. Its corresponding private key is `p`.
>
> Notifier/sender's pubkey `N` is derived using the following derivation
> path: `m/purpose'/coin_type'/account'/*`, where each recipient gets a new
> index. This way send-side privacy is always preserved. Its corresponding
> private key is `n`.
>
> ==Notifications==
>
> Alice wants to notify Bob that he will receive future payments from her.
> Alice selects any UTXO in her wallet (preferably not associated with her)
> and `n_Alice`. Alice selects the public key contained in Bob's payment code
> `P_Bob`. Alice performs the following process (`*` and `+` are EC
> operations):
>
> notification = SHA256(n_Alice * P_Bob)
>
> Alice then constructs a 72-byte OP_RETURN output whose value is set to
> `BIPXXXX + notification + N_Alice` (`+` is concat) and sends it in a
> transaction containing no other outputs (XXXX to be replaced once a BIP
> number is assigned). Alice MUST now keep track of `n_Alice` or its
> derivation path as it will be used in future transactions exclusively with
> Bob (not for spending but to calculate secret addresses).
>
> Bob's wallet receives whole blocks but doesn't need to waste resources on
> decoding them if the environment is resource constrained. Bob simply needs
> find the string BIPXXXX in the binary blob that represents an undecoded
> block. Once found, Bob extracts the subsequent 32 bytes (`notification`)
> and the subsequent 33 bytes (`N_Alice`). The benefit of this approach is
> that Bob doesn't have to decode blocks and extract pubkeys from scriptsigs.
>
> Since ECDH dictates that SHA256(n_Alice * P_Bob) == SHA256(N_Alice *
> p_Bob), Bob calculates the expected notification value and checks if it
> matches the first value in the payload. If so, Bob found a notification
> transaction addressed to himself and stores `N_Alice` in order to be able
> to detect and spend future payments from Alice. The added benefit of this
> approach over BIP47 is that Bob doesn't learn Alice's payment code, so
> Alice can pay Bob without revealing her identity. To take advantage of
> these privacy benefits, Alice simply has to engage in coin control on her
> end. A real world scenario where this might be useful is anonymous
> donations to a party whose wallet may be seized in the future. Seizing such
> a wallet won't reveal who Alice is (as long as she engages in coin
> control), whereas BIP47 would by default leak her identity even if her
> coins as anonymized.
>
> If this process fails for any reason, Bob assumes a spurious notification
> or one not addressed to himself and gives up.
>
> ==Transacting==
>
> Now that they are connected, Alice can send transactions to Bob. Alice
> needs to keep track of her transaction count toward Bob; let's name that
> counter `X`. This process is similar to what BIP47 does.
>
> Alice calculates a secret point:
>
> S = n_Alice * P_Bob
>
> Alice calculates a shared secret:
>
> s = SHA256(S, X)
>
> Alice calculates Bob's ephemeral public key and its associated address
> where the funds will be sent:
>
> P_Bob' = P_Bob + s*G
>
> When Bob detects a payment to `P_Bob'`, he can spend such coins by
> calculating the shared secret `s` in the same manner using `N_Alice` and
> `p_Bob` and performing:
>
> p_bob' = p_bob + s
>
> The fact that Alice and Bob are using a shared counter means we can do
> away with chain codes and make payment codes much smaller. Bob simply needs
> to derive a number of addresses to watch with respect to some gap limit
> (which can be as low as 1 in practice).
>
> ==Anti-spam==
>
> While DoS hasn't been a problem with BIP47, it is possible to build
> anti-spam measures into payment codes. The owner of a code could simply
> demand that a notification transaction meets some minimum miner fee or a
> multiple of some trailing average. This would help prevent spam
> notifications that might otherwise overwhelm a payment code with addresses
> to watch. But that is purely optional.
>
> Looking forward to hearing thoughts and ideas.
>
> Alfred
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220627/eda92cd3/attachment-0001.html>

2023-06-07 23:10:47

- reply

📅 Original date posted:2022-06-27
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> Hi,
>
> On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev <
> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220627/10c581f6/attachment-0001.html>

2023-06-07 23:04:51

- reply

📅 Original date posted:2022-02-24
📝 Original message:Note this has always been possible, and is not specifically related to
tapscript. As long as you're committing to an ECC point, you can tweak it
to commit data inside it (i.e. pay-to-contract). This includes P2PK and
P2PKH.
Committing to 1.5GB of data has equally been possible with OP_RETURN
<hash>, or even an entire merkle tree of hashes, as is the case with Todd's
opentimestamps.
Also, tweaking an ECC point (this includes tapscript) in non-deterministic
ways also makes it harder to recover from backup, because you can't recover
the key without knowing the full commitment.
Furthermore, the scheme is not actually equivalent to op_return, because
it requires the user to communicate out-of-band to reveal the commitment,
whereas with op_return the data is immediately visible (while not popular,
BIP47 and various colored coin protocols rely on this).
Cheers,
Ruben
On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Since Taproot was activated, we no longer need separate OP_RETURN outputs
> to be pushed on-chain. If we want to attach any data to a transaction, we
> can create "OP_RETURN <anything>" as a branch in the TapScript. In this
> way, we can store that data off-chain and we can always prove that they are
> connected with some taproot address, that was pushed on-chain. Also, we can
> store more than 80 bytes for "free", because no such taproot branch will be
> ever pushed on-chain and used as an input. That means we can use "OP_RETURN
> <1.5 GB of data>", create some address having that taproot branch, and
> later prove to anyone that such "1.5 GB of data" is connected with our
> taproot address.
>
> Currently in Bitcoin Core we have "data" field in "createrawtransaction".
> Should the implementation be changed to place that data in a TapScript
> instead of creating separate OP_RETURN output? What do you think?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/e1bb7a97/attachment-0001.html>

2023-06-07 22:59:56

- reply

📅 Original date posted:2021-10-05
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211005/82c3f918/attachment.html>

2023-06-07 22:51:49

- reply

📅 Original date posted:2021-04-20
📝 Original message: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
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018803.html>
if you wish to learn more, particularly the video
<https://youtu.be/N2ow4Q34Jeg>.
Cheers,
Ruben
On Tue, Apr 20, 2021 at 3:23 AM <yanmaani at cock.li> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210420/1b718ee7/attachment.html>

2023-06-07 22:51:47

- reply

📅 Original date posted:2021-04-16
📝 Original message: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 at 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 at lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/1f3a90a5/attachment-0001.html>

2023-06-07 18:27:59

- reply

📅 Original date posted:2020-12-31
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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 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 to have a minimum accepted difficulty for softchain
> blocks (slowing down the chain when fees are not sufficient). Merged Mining
> could also help here, since that would allow the softchains to potentially
> receive the same hashrate as Bitcoin (assuming all miners participate), but
> of course this would also put an additional validation burden on miners.
> >
> > In closing
> >
> > It may turn out that the consensus risks outlined above make this
> prohibitively risky, but at the very least it seems worth exploring the
> possibilities. At a minimum it would provide more opt-in block space, and
> it could potentially open the door to chains with entirely different
> consensus rules.
> >
> > Thank you for taking the time to read and comprehend my work. I will
> happily answer any questions and I look forward to any feedback on issues
> that I might have overlooked, and ideas on mitigating problems to ensure
> maximum safety.
> >
> > Hopefully this will bring decentralized two-way peg sidechains one step
> closer to becoming a reality.
> >
> > Happy new year, everyone.
> >
> > -- Ruben Somsen
> >
> > This post is mirrored and kept up-to-date here:
> > https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1
> >
> > [0] Drivechains
> > https://www.drivechain.info/
> >
> > [1] PoW FP
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html
> >
> > [2] PoW FP without a soft fork
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017287.html
> >
> > [3]: utreexo
> > https://eprint.iacr.org/2019/611.pdf
> >
> > [4]: Forkmonitor
> > https://forkmonitor.info/notifications
> >
> > [5]: Harding on worst-case utreexo
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017298.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210101/6aa5944d/attachment-0001.html>

2023-06-07 18:27:35

- reply

📅 Original date posted:2020-11-23
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev <
> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201123/32a9a5c5/attachment.html>

2023-06-07 18:25:00

- reply

📅 Original date posted:2020-06-01
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200601/aee5c117/attachment.html>

2023-06-07 18:24:37

- reply

📅 Original date posted:2020-05-11
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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?) then it would select the version of the transaction with the best feerate, which it effectively pays out to what it recovers.
>
>
> Regards,
> ZmnSCPxj
>
>
> > 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 feedback and review.
> >
> > If you find any further errors, I will endeavor to fix them here:
> > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
> >
> > Related work:
> >
> > Tier Nolan Atomic Swap:
> > https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
> > Monero Atomic Swap:
> > https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
> >
> > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
> >
> > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017595.html
> >
> > [2] https://blockstream.com/eltoo.pdf
> >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

2023-06-07 18:24:36

- reply

📅 Original date posted:2020-05-11
📝 Original message: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 feedback and review.
If you find any further errors, I will endeavor to fix them here:
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
Related work:
Tier Nolan Atomic Swap:
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
Monero Atomic Swap:
https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017595.html
[2] https://blockstream.com/eltoo.pdf

2023-06-07 18:20:27

- reply

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

2023-06-07 18:20:26

- reply

📅 Original date posted:2019-09-08
📝 Original message:After looking more deeply into Tadge Dryja’s utreexo work [0], it has
become clear to me that this opens up a way to implement PoW fraud
proofs [1] without a soft fork. With utreexo, we can efficiently
verify state transitions between blocks. Verifying a block from a
valid utreexo hash requires only about a megabyte worth of merkle
proofs.
PoW fraud proofs assume that block N is valid if no miner has tried to
fork it (read my original post for details [1]). We can extend that
assumption to the utreexo hash of block N, and use that to verify fork
block N+1, and reject it if the block is invalid, with just 2-3MB of
data.
For simplicity, I’ll first start by explaining a version with
commitments (which would require a soft fork).
When a fork (i.e. a PoW fraud proof) occurs at height N+1, indicating
that the block might be invalid, you’d need to download:
1. block N+1 from the most PoW chain (~1-2MB)
2. the utreexo hash commitment inside of block N (e.g. a merkle path
to the coinbase)
3. the utreexo merkle proofs which prove that all inputs of N+1 are
part of the UTXO set (~1MB)
Of course step 2 requires a soft fork, but we can also do a
non-committed version by relying on the assumption that at least one
of your peers is honest and then evaluate disagreements.
We simply replace step 2 above with the following:
2. [Download] the utreexo hash of block N from all your peers
If it turns out that one of your peers disagrees on what the correct
hash is, you find the last utreexo hash where that peer still agreed,
let’s say block M, and you simply execute the same three steps to find
out which peer is wrong: download block M+1, then get the merkle
proofs to verify whether the peer correctly transitioned their utreexo
hash from M to M+1.
One might intuitively feel that the lack of a commitment is unsafe,
but there seems to be no impact on security (only bandwidth). The only
way you can be fooled is if all peers lie to you (Sybil), causing you
to follow a malicious minority chain. But even full nodes (or the
committed version of PoW fraud proofs) can be fooled in this way if
they are denied access to the valid most PoW chain. If there are
additional security concerns I overlooked, I’d love to hear them.
In short, utreexo can enable PoW fraud proofs without a soft fork. At
the cost of downloading a couple of MB per stale block (and per
malicious peer), an SPV client gains the ability to (eventually)
reject the most PoW chain as long as one honest block gets mined,
thereby increasing its security beyond 51% honest miners.
Finally, while I think this goes without saying, I’d like to reiterate
that this is by no means a replacement for running a full node. You’re
depending on other full nodes to do full verification and assuming at
least some of the miners are honest. If everyone did this, Bitcoin
would not be secure.
-- Ruben Somsen
[0] Utreexo paper: https://eprint.iacr.org/2019/611.pdf
[1] Improving SPV security with PoW fraud proofs:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html

2023-06-07 18:20:26

- reply

📅 Original date posted:2019-09-09
📝 Original message:Hi ZmnSCPxj,
Thank you for your comments. You raise an important point that I should clarify.
>1. In event of a sybil attack, a fullnode will stall and think the blockchain has no more miners.
You can still attack the full node by feeding it a minority PoW chain,
then it won't stall.
>2. In event of a sybil attack, an SPV, even using this style, will follow the false blockchain.
Correct, but this false blockchain does need to have valid PoW.
So in both cases valid PoW is required to fool nodes. The one
difference is that for a full node, the blocks themselves also need to
be valid (except for the fact that they are in a minority chain), but
the end result is still that a victim can be successfully double spent
and lose money.
I hope this clarifies why I consider the security for these two
situations to be roughly equivalent. In either situation, victims can
be fooled into accepting invalid payments.
Cheers,
Ruben
On Mon, Sep 9, 2019 at 6:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Ruben,
>
>
> > One might intuitively feel that the lack of a commitment is unsafe,
> > but there seems to be no impact on security (only bandwidth). The only
> > way you can be fooled is if all peers lie to you (Sybil), causing you
> > to follow a malicious minority chain. But even full nodes (or the
> > committed version of PoW fraud proofs) can be fooled in this way if
> > they are denied access to the valid most PoW chain. If there are
> > additional security concerns I overlooked, I’d love to hear them.
>
>
> I think it would be better to more precisely say that:
>
> 1. In event of a sybil attack, a fullnode will stall and think the blockchain has no more miners.
> 2. In event of a sybil attack, an SPV, even using this style, will follow the false blockchain.
>
> This has some differences when considering automated systems.
>
> Onchain automated payment processing systems, which use a fullnode, will refuse to acknowledge any incoming payments.
> This will lead to noisy complaints from clients of the automated payment processor, but this is a good thing since it warns the automated payment processor of the possibility of this attack occurring on them.
> The use of a timeout wherein if the fullnode is unable to see a new block for, say, 6 hours, could be done, to warn higher-layer management systems to pay attention.
> While it is sometimes the case that the real network will be unable to find a new block for hours at a time, this warning can be used to confirm if such an event is occurring, rather than a sybil attack targeting that fullnode.
>
> On the other hand, such a payment processing system, which uses an SPV with PoW fraud proofs, will be able to at least see incoming payments, and continue to release product in exchange for payment.
> Yet this is precisely a point of attack, where the automated payment processing system is sybilled and then false payments are given to the payment processor on the attack chain, which are double-spent on the global consensus chain.
> And the automated system may very well not be able to notice this.
>
> Regards,
> ZmnSCPxj

2023-06-07 18:17:39

- reply

📅 Original date posted:2019-04-15
📝 Original message:Simplified-Payment-Verification (SPV) is secure under the assumption
that the chain with the most Proof-of-Work (PoW) is valid. As many
have pointed out before, and attacks like Segwit2x have shown, this is
not a safe assumption. What I propose below improves this assumption
-- invalid blocks will be rejected as long as there are enough honest
miners to create a block within a reasonable time frame. This still
doesn’t fully inoculate SPV clients against dishonest miners, but is a
clear improvement over regular SPV (and compatible with the privacy
improvements of BIP157[0]).
The idea is that a fork is an indication of potential misbehavior --
its block header can serve as a PoW fraud proof. Conversely, the lack
of a fork is an indication that a block is valid. If a fork is created
from a block at height N, this means a subset of miners may disagree
on the validity of block N+1. If SPV clients download and verify this
block, they can judge for themselves whether or not the chain should
be rejected. Of course it could simply be a natural fork, in which
case we continue following the chain with the most PoW.
The way Bitcoin currently works, it is impossible to verify the
validity of block N+1 without knowing the UTXO set at block N, even if
you are willing to assume that block N (and everything before it) is
valid. This would change with the introduction of UTXO set
commitments, allowing block N+1 to be validated by verifying whether
its inputs are present in the UTXO set that was committed to in block
N. An open question is whether a similar result can be achieved
without a soft fork that commits to the UTXO set[0][1].
If an invalid block is created and only 10% of the miners are honest,
on average it would take 100 minutes for a valid block to appear.
During this time, the SPV client will be following the invalid chain
and see roughly 9 confirmations before the chain gets rejected. It may
therefore be prudent to wait for a number of confirmations that
corresponds to the time it may take for the conservative percentage of
miners that you think may behave honestly to create a block (including
variance).
If users do not wait and happen to accept payments from an invalid
chain during this time, these payments could get reverted. This is a
weakness, but still seems preferably to continually following an
invalid chain. As long as a reasonable number of miners remains
honest, a dishonest majority can only temporarily control the network,
and their blocks (and all coins gained from it) will eventually be
rejected.
-- Ruben Somsen
[0] Olaoluwa Osuntokun, BIP 157: Client Side Block Filtering,
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
[1] Peter Todd, TXO commitments do not need a soft-fork to be useful,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html