Hi Ryan,
>As I envision it, there is no cryptographic proof involved at all.
That seems to directly contradict your previous message where you stated
"[t]hey transmit invalid transactions or blocks". This transmission you
alluded to is basically a (non-optimized) fraud proof, and it assumes that
Hi Ryan,
Thanks for taking the time to write a proposal. As is often the case, these
ideas aren't actually as novel as you might think. What you describe here
is known as "fraud proofs". The crucial problem it doesn't address is "data
availability".
The general idea behind fraud proofs is that
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
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
Hi,
Apologies, the link I sent in my previous post was incorrect and should
have been:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1218641521
Let me also use this opportunity to share another clarifying comment:
"There seems to be some confusion about the function of the
A. Harding wrote:
> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
> > An alternative mitigation (more user friendly, but more implementation
> > complexity) would be to require the sender to reveal their intended
> > transaction to the server prior to rec
Hi Bastien,
>Greg already has a draft design that addresses your concerns
Thanks, that is very nice. In that case I currently have no outstanding
objections.
>I'm curious why you would need more than one such output
My reasoning was actually to allow only one OP_TRUE output per transaction,
so
Hi Peter,
Thanks for your comments.
>handing out xpubs makes the gap limit problem quadratic
Yes, my thinking on this is that if you're handing out xpubs you can lower
the gap limit for addresses generated by those xpubs, provided you assume
those addresses will be used by the same person, so
Hi Bastien,
>The other change mentioned (making OP_TRUE standard and allowing outputs
that are below dust) can be added later, as those won't be standard until
we start allowing them, so there shouldn't be any backwards-compatibility
issue with postponing this change. But maybe it's still worth
Hi woltx,
Excellent work.
>Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead
To expand on this, the scheme basically allows the resulting address to be
recognizably marked (only recognizable by the recipient of course),
Hi Eloy,
Nice idea.
Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
I agree with your general assessment that this is a scheme that seems like
Hi all,
In short, this is yet another way to hand out addresses without interaction
between sender and recipient (Silent Payments, BIP47). The idea here is
that in non-ideal cases where you're already exposing your xpub to a server
(most light clients today, unfortunately), you might as well rely
Hi Alfred,
Thanks for all the effort.
Note that in the previous thread I mentioned[0] that this proposal
introduces a scanning requirement in order to detect incoming notifications
(complicating light client implementation). I recommend that you put this
information in the BIP, as this is an
Good evening ZmnSCPxj,
>I suppose that means that the knower of `k` is a trusted party; it is
trusted to only issue commitments and not generate fake ones
Then you can reduce the scheme to just committing to K and having that key
sign whatever the burn was intended for. I doubt this is useful in
Good evening ZmnSCPxj,
Interesting attempt.
>a * G + b * G + k * G
Unfortunately I don't think this qualifies as a commitment, since one could
trivially open the "commitment" to some uncommitted value x (e.g. a is set
to x and b is set to a+b-x). Perhaps you were thinking of Pedersen
Hi Veleslav,
This is something I've been interested in.
What you need is a basic merkle sum tree (not sparse), so if e.g. you want
to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you
can burn 100 sats and commit to a tree with four leaves, and the merkle
proof contains the
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
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
This discussion took place at Pizza Day Prague 2022[0] after a brief
discussion on Silent Payments[1]. The main points have been summarized
below.
The discussion was mainly between Alekos Filini, Martin Habovštiak, and
myself, as well as Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore
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
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
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
on)?
>>>>
>>>> It seems the primary benefit of this is privacy for the recipient. To
>>>> that end, it seems like a pretty useful protocol. It's definitely a level
>>>> of privacy one would only care about if they might receive a lot money
>&g
tweaked address, such
> that only those addresses can be downloaded and checked by light clients.
> It reduces the anonymity set a bit, but it would probably still be
> sufficient.
>
>
>
> On Mon, Mar 28, 2022, 10:29 Ruben Somsen via bitcoin-dev <
> bitcoin-dev@l
Hi all,
I'm publishing a new scheme for private non-interactive address generation
without on-chain overhead. It has upsides as well as downsides, so I
suspect the main discussion will revolve around whether this is worth
pursuing or not. There is a list of open questions at the end.
I added the
In Q = P + hash(P||commitment)G you cannot spend from Q without knowing
both the private key of P as well as the commitment (i.e. 32 bytes,
assuming the commitment itself is another hash). This is generally not a
problem for tapscript, as the scripts are deterministically generated (i.e.
backing
Note this has always been possible, and is not specifically related to
tapscript. As long as you're committing to an ECC point, you can tweak it
to commit data inside it (i.e. pay-to-contract). This includes P2PK and
P2PKH.
Committing to 1.5GB of data has equally been possible with OP_RETURN
, or
Hi Jeremy,
Thanks for sharing your thoughts.
To summarize your arguments: the intentionally malicious path to getting
the 0 sat output confirmed without being spent is uneconomical compared to
simply creating dust outputs. And even if it does happen, the tx spending
from the 0 sat output may
Hi Jeremy,
I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat
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
Hi Prayank,
While I can see how this can come from a place of good intentions, I’d
strongly advise you to tread carefully because what you are suggesting is
quite controversial. A related event occurred in the Linux community and it
did not go over well. See https://lkml.org/lkml/2021/5/5/1244
Hi all,
Thanks for the lively discussion. On behalf of the bitcoin-dev moderators
and with the readers of this mailing list in mind, we'd like to suggest
finishing up this discussion. Of course there should be some room for
exploring fringe ideas, but it should not dominate the mailing list
Hi,
That's an excellent question, but note that answering such questions is not
the primary function of this mailing list. Places like Bitcoin Stack
Exchange or even IRC are probably better for that!
Specific to your question: in Taproot Q = P + hash(P||m)*G. The fact that P
is hashed together
What Tim said is right. To add to that, you may also wish to read about
MuSig:
https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/
Cheers,
Ruben
On Sat, May 15, 2021 at 10:32 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sat,
Hi Antoine,
Thanks for bringing this up.
It seems spacechains[0] are impacted by this. Simply explained, the idea is
to allow for fee-bidding Blind Merged Mining[1] by creating one transaction
for each block, to which anyone can attach a block hash. The preferred
mechanism utilizes
Good evening ZmnSCPxj,
Thanks for thinking it through. I appreciate the time and effort.
>sidechain functionaries will not earn anything once there are at least 2
functionaries [...] they are doing all this work of validating the
sidechain blocks, but gain nothing [...] the entire sidechain
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
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
> the whole sidechain validity, as in Coda (now renamed Mina), drivechains
> are the low-hanging-fruit.
>
> regards
>
> On Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>>
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
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
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
Hi Tom,
Blind signatures are certainly a nice feature, great to see that you're
considering it.
>So each new owner of a UTXO must receive, store and verify the full
sequence of previous owner backup transactions to make sure that no
previous owner has asked the SE to sign a transaction that
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
Hi ZmnSCPxj,
>Just to be clear, you mean we can use the MuSig key-combination protocol
for the non-timelocked SAS output, but (of course) not the signing protocol
which is inherently Schnorr. Then knowledge of both of the original private
keys is enough to derive the single combined private key.
Hey Chris,
Excellent write-up. I learned a few new things while reading this
(particularly how to overcome the heuristics for address reuse and address
types), so thank you for that.
I have a few thoughts about how what you wrote relates to Succinct Atomic
Swaps (SAS)[0]. Perhaps it's useful.
Hi ZmnSCPxj,
>The proper response here is that Bob should broadcast success tx before
the refund tx #1 becomes valid.
That's right. And even if Bob neglects to do that, it still won't cause
chaos for Alice as long as she chooses the path for refund tx #2.
>at least part of the fund must be lost
Hi Dmitry,
>But it should be noted that it is not enough that Bob publishes success_tx
before refund_tx_1 became valid. The success_tx needs to be confirmed
before refund_tx_1 became valid.
Agreed, my write-up would benefit from pointing this out more explicitly.
Cheers,
Ruben
On Thu, May 14,
Hi Dmitry,
>While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly
miner
I see, so you're talking about prior to protocol completion, right after
Alice sends Bob the success_tx. The reason this is not an issue is because
Alice and Bob both had to misbehave in order for this to
Hi Dmitry,
Thanks for creating a specification for testing, I appreciate the interest!
>The checking of the model encoded in the specification can successfully
detect the violation of 'no mutual secret knowledge' invariant when one of
the participant can bypass mempool and give the transaction
Hi ZmnSCPxj,
>on completion of the protocol, if Bob lets the refund tx#1 become valid
(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both
their funds into chaos
You forget, refund tx #1 has a script (which btw won't be visible with
taproot): "Alice & Bob OR Alice in +1
Hi ZmnSCPxj,
>potentially both Alice and Bob know all the secrets on the LTC side and
end up competing over it
That's exactly right.
>Bob can thus give a copy of the revoke tx with signature directly to its
favorite miner, forcing Alice to take 3 transactions
Note that the timelock on the
Hi Chris,
Thanks for taking a look :)
>it also improves privacy because the coins could stay unspend for a long
time, potentially indefinitely
Excellent point. The pre-swap setup transactions would still be subject to
timing/amount analysis, but it's clearly a lot less problematic than the
Hi ZmnSCPxj,
>If the shortened refund transaction exists (labeled "refund transaction
#1" in the SVG) then the same issue still occurs
Yes, but there is one crucial difference: at that point in the protocol
(Bob has the success transaction and then stops cooperating) Alice and Bob
both had the
Hi Lloyd,
>In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done!
Thanks for the kind praise, and for providing a summary of what you think
makes the protocol useful. Your different perspective is undoubtedly useful
for others who are trying to
Hi ZmnSCPxj,
>Would this not work?
I considered and rejected that model for the following reason: there are
moments where both Alice and Bob can claim the BTC. If they both attempt to
do so, it also reveals both secrets, causing the LTC to also be claimable
by both parties. This chaotic scenario
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
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
Hi ZmnSCPxj,
the current owner can ask the statechain entity to sign an alternative to
> the first stage, with 0 relative locktime
Unless I am misunderstanding something, this seems to run into the problem
that the original first stage transaction is already out there (and its
relative timelock
Hi Bob,
Looks like we're largely thinking along the same lines.
It's unlikely that a party sending a UTXO to another party will have a UTXO
> of exactly the right size that's needed
My original proposal uses adaptor signatures to ensure swapping UTXOs is
atomic. All parties choose a secret,
Hi ZmnSCPxj,
I appreciate the input.
>Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you
can use an `OP_TRUE` `redeemScript`, for instance.
Good point. I guess the conversation I recall reading must have been about
avoiding p2sh in order to lower the tx size.
>broadcast
nuxfoundation.org> wrote:
>
>> Ruben Somsen via bitcoin-dev
>> writes:
>> > Regarding modification 1, I agree with ZmnSCPxj that
>> > Decker-Wattenhofer is your next best option, given that eltoo is not
>> > yet available. But if you are going to use a
Hi Tom,
Nice to see you working on this.
Regarding modification 1, I agree with ZmnSCPxj that Decker-Wattenhofer is
your next best option, given that eltoo is not yet available. But if you
are going to use a kickoff transaction, keep in mind that every previous
owner will have a copy of it.
tay?
>
> https://commerceblock.readthedocs.io/en/latest/mainstay/index.html
>
> https://mainstay.xyz
>
>
> On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Blind Merged Mining (BMM) is
Blind Merged Mining (BMM) is the idea of committing the hash of another
blockchain into a unique location on the Bitcoin blockchain, and paying a
Bitcoin fee to miners for the privilege of deciding this hash and capturing
the fees inside the other blockchain. Since miners don’t have to know what
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
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
Hi ZmnSCPxj,
>Basically, the "Stale Factory" and "Broken Factory" problems.
I see, I'll have to read up on those.
>Combining it via MuSig is probably best, as the server is now unable to
>recognize even the pubkey (assuming it never is informed `X`).
Yes, that's the current thinking. See
Hi ZmnSCPxj,
Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking
Bitcoin have been keeping me busy.
Transcript from Coredev (thanks Bryan):
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/
Blind Statechains at Breaking Bitcoin:
Hi ZmnSCPxj,
Thank you for your comments.
>Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not
>*strictly* required. We can still make use of the Decker-Wattenhofer
>construction instead.
Yes, an early draft (from before the eltoo paper) was using that
construction, but
Hi everyone,
For those who are unfamiliar, Statechains enable the transfer UTXOs
off-chain with the help of a Statechain entity (trusted server(s))
without giving them full custodial control over your coins [0]. At
Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
[2] to make
Hi ZmnSCPxj,
Allow me to reply to your post in mixed order (fraud proofs first):
>But peers can be set up to allow you to hear of all chains while denying you
>proof of the invalidity of some UTXO.
I don't believe this is fundamentally different. In either scenario
you end up on the wrong
Hi ZmnSCPxj,
>There is no safe way to use UTXO sets without identifying who is telling you
>those sets are valid, or making it expensive to lie
>The first option requires trust and is weaker than SPV, the second requires
>committing to a proof-of-work
Olaoluwa Osuntokun's BIP157 manages to
Hi ZmnSCPxj and Ethan,
I apologize if my initial explanation was confusing, but it looks like
you figured it out. For every fork, SPV clients only have to download
one block. If there is a fork after block N, this means there are two
blocks at N+1. You only download and verify N+1 from the longer
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
Hi Johnson,
The design considerations here seem similar to the ML discussion of
whether Graftroot should be optional [1].
>While this seems fully compatible with eltoo, is there any other proposals
>require NOINPUT, and is adversely affected by either way of tagging?
As far as I can tell it
which are only valid if they are mined on
> top of a specific block." - in practice, does that usually means at any
> height above a specific block?
>
>
> From: bitcoin-dev-boun...@lists.linuxfoundation.org
> on behalf of Ruben Somsen v
77 matches
Mail list logo
