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:
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
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
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
On Sat, May 15, 2021 at 10:32 PM Tim Ruffing via bitcoin-dev <
> On Sat,
Thanks for bringing this up.
It seems spacechains are impacted by this. Simply explained, the idea is
to allow for fee-bidding Blind Merged Mining by creating one transaction
for each block, to which anyone can attach a block hash. The preferred
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
>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
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.
> On Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev <
> firstname.lastname@example.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
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
That's a tricky issue you're trying to tackle.
>and/or use the blockchain for that function, but that is too slow and
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
Blind signatures are certainly a nice feature, great to see that you're
>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
>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
>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.
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). Perhaps it's useful.
>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
>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.
On Thu, May 14,
>While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly
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
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
>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
>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
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
>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
>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
>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
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, or with
Schnorr + MuSig.
- Requires merely two on-chain transactions for successful completion,
as opposed to
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
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,
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.
>> Ruben Somsen via bitcoin-dev
>> > 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
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.
> On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bitcoin-dev <
> email@example.com> 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
>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 , it has
become clear to me that this opens up a way to implement PoW fraud
proofs  without a soft fork. With utreexo, we can efficiently
verify state transitions between blocks. Verifying a block from a
valid utreexo hash requires
>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
Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking
Bitcoin have been keeping me busy.
Transcript from Coredev (thanks Bryan):
Blind Statechains at Breaking Bitcoin:
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
Yes, an early draft (from before the eltoo paper) was using that
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 . At
Scaling Bitcoin ‘18  I briefly mentioned utilizing blind signatures
 to make
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
>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
The design considerations here seem similar to the ML discussion of
whether Graftroot should be optional .
>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
Mail list logo