Skip to content

[WIP] BIP300 (Drivechains) consensus-level logic #28311

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 21 commits into from
Closed

[WIP] BIP300 (Drivechains) consensus-level logic #28311

wants to merge 21 commits into from

Conversation

luke-jr
Copy link
Member

@luke-jr luke-jr commented Aug 22, 2023 •
edited
Loading

This is a (rough draft) clean rewrite of BIP300 (Drivechain) consensus-level code.

Instead of a separate sidechain database (which may be prone to hard-to-review/test consistency issues), instead the unusable 8 MSB of the UTXO index are reserved for non-UTXO database entries, and the existing UTXO db and caching layer is shared. This can be refactored in the future, but I think it is the cleanest and most reviewable approach initially - open to other ideas, though. There's also some ugliness in the undo data to handle restoring the new data, but it's abstracted and shouldn't be too hard to reason about.

Using these new primitives, Drivechains can be reimplemented with a UTXO-like model. Note that there is zero activation logic in the current PR: the protocol changes are always active. Therefore, this will not work (at least not safely) on Bitcoin today, and cannot be deployed without significant additional changes to handle an activation.

A new SERIALIZE_TRANSACTION_FOR_WEIGHT serialization flag is also added, that is meant only for weight counting. This allows for adjusting weight (upward) to fit additional resource requirements by new functionality. In this case, several Drivechain "messages" are expected to have a larger burden than their OP_RETURN encoding would otherwise weigh. However, the specific adjustments are not implemented in this draft.

As a consensus change, this can only be implemented with community support. Many people seem to have opinions, but please keep them to other forums. Despite providing and continuing this implementation, I myself do not thereby endorse or otherwise comment on the proposal itself.

Therefore, not looking for concept ACKs/NACKs (ie, about Drivechains), just Approach ACKs / constructive criticism (ie, about how I'm implementing it).

@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 22, 2023 •
edited
Loading

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept NACK aceofbitcoin, RicYashiroLee, amtriorix, petertodd
Concept ACK psztorc, CheemsCommander, skydogenet
Approach ACK jaybny
Approach NACK russeree, ns-xvrn, ChrisMartl
Ignored review john-light

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #28438 (Use serialization parameters for CTransaction by ajtowns)
  • #28051 (Get rid of shutdown.cpp/shutdown.h, use SignalInterrupt directly by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@portlandhodl
Copy link
Contributor

portlandhodl commented Aug 22, 2023 •
edited
Loading

Approach NACK; using bip300 OP_DRIVECHAIN to achieve consensus about the validity of a spend is prone to errors or manipulation by miners as to the state of the sidechain thus introducing additional incentives into bitcoin.

Please don't take this personally, I love the work you do, personally I want to see a more 'trustless' method of pegouts before adding sidechain communication and spend conditions into Bitcoin Core.

rot13maxi
rot13maxi reviewed Aug 22, 2023
View reviewed changes
src/sidechain.cpp
// TODO: Do we want to verify there's only one sidechain involved? BIP300 says yes, but why?

// Lookup sidechain number from CTIP and ensure this is in fact a CTIP to begin with
// FIXME: It might be a good idea to include the sidechain # in the tx itself somewhere?
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you had the tx commit to the sidechain number somewhere, I think you could remove it from CalculateDrivechainWithdrawInternalHash?

@john-light
Copy link

@russeree

Approach NACK; using bip300 OP_DRIVECHAIN to achieve consensus about the validity of a spend is prone to errors or manipulation by miners as to the state of the sidechain thus introducing additional incentives into bitcoin... personally I want to see a more 'trustless' method of pegouts before adding sidechain communication and spend conditions into BitcoinCore.

This comment seems to me like a "Concept NACK", not an "Approach NACK". Per @luke-jr's request:

Many people seem to have opinions, but please keep them to other forums... not looking for concept ACKs/NACKs, just Approach ACKs / constructive criticism.

In case this request was missed, or there was a misunderstanding about the request, by "just Approach ACK / constructive criticism" Luke is saying he only wants feedback on his specific approach taken to implement BIP300 in this PR. If a reviewer likes this approach, or does not like this approach and can suggest a better approach to implementing the BIP300 spec, then that is the kind of feedback Luke is looking for. On the other hand, if a reviewer has feedback about the general concept of BIP300 then Luke requests that that feedback be shared elsewhere -- may I suggest the bitcoin-dev mailing list or the new Delving Bitcoin forum?

@ChrisMartl
Copy link

@luke-jr:
Could you please provide an analysis statement, which effects or how this proposal could increment the exploit exposure for the Bitcoin system due to the loose flexibility of Bitcoin’s script (predicative processing)?

Bitcoin has this predicate issue (since genesis) and it is necessary to perform a risk analysis about this for every proposed change.

This was referenced Aug 22, 2023
Merged
Merged
@petertodd
Copy link
Contributor

petertodd commented Aug 22, 2023 •
edited
Loading

Approach NACK: given that drivechains has fundamental flaws unrelated to the exact implementation, there's no reason to distract Bitcoin Core development with this pull-req, even in draft form. What's holding Drivechains back is the idea itself, not the code.

You haven't even bothered to write or link a high-level BIP-style overview of this take on the idea. Writing a bunch of detailed code is a waste of time.

@Gudnessuche
Copy link

I refute the claim by Storkz and his fan boys that there are no risks or that all MEV risks are solved by Blind Merge Mining.

Plus the peg out reintroduces having to trust, doesn't that seem scammy?

@Gudnessuche
Copy link

"Despite providing and continuing this implementation, I myself do not thereby endorse or otherwise comment on the proposal itself."

How do you reconcile this statement Luke. Pls don't support this misallocation of time, funds and energy. FUCK SYNTHETIC BITCOIN!!!

rot13maxi
rot13maxi reviewed Aug 22, 2023
View reviewed changes
Copy link

@rot13maxi rot13maxi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handful of questions and comment

src/sidechain.cpp
#include <algorithm>
#include <cstdint>

void CreateDBUndoData(CTxUndo &txundo, const uint8_t type, const COutPoint& record_id, const Coin& encoded_data) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we also need to unwind sidechain db operations (like incrementing of DBIDX_SIDECHAIN_WITHDRAW_PROPOSAL_ACKS) in the undo data?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I see now that CreateDbEntry and DeleteDbEntry create undo data, and ModifyDbEntry calls both of them. Nevermind. Leaving this comment here for future reviewers

src/sidechain.cpp
ModifyDBEntry(view, txundo, block_height, record_id, [change](CDataStream& s){
uint16_t counter;
s >> counter;
if (change < 0 && !counter) return; // may be surprising if change is <-1
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the intent here as: the counter will never be < 0. If that's an important correctness property for the sidechain voting, would be nice to spell it out in a comment and/or reify it in an assert after the counter change on line 65

src/sidechain.cpp
}

uint256 CalculateDrivechainWithdrawInternalHash(const uint256& blinded_hash, const uint8_t sidechain_id) {
// Internally, we hash the bundle_hash with the sidechain_id to avoid conflicts between sidechains
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

between this comment and the fact that the first in/out of the tx are nulled for computing the hash, it sounds like the same withdrawal tx could be provided for multiple sidechains. Is that desired?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be voted on because we only see the hash at that stage. But it would never be valid for more than one.

src/sidechain.cpp
// TODO: Block is invalid if there are no bundles proposed at all
// FIXME: Presumably blocks should only be able to vote once - this is missing in the BIP
for (int sidechain_id = 0; sidechain_id < 0x100; ++sidechain_id) {
// FIXME: bounds checking
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably something like out.scriptPubKey.size() >= 6 + (0x100 * data_format) before we start counting votes

src/sidechain.cpp
static constexpr uint8_t BIP300_HEADER_WITHDRAW_PROPOSE[] = {0xd4, 0x5a, 0xa9, 0x43}; // n.b. 67 byte push followed by only 32 bytes
static constexpr uint8_t BIP300_HEADER_WITHDRAW_ACK[] = {0xd7, 0x7d, 0x17, 0x76}; // n.b. 23-byte push followed by variable bytes
if (std::equal(&out.scriptPubKey[1], &out.scriptPubKey[5], BIP300_HEADER_WITHDRAW_ACK)) {
const uint8_t data_format = out.scriptPubKey[6];
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is data_format variable? if it was something fixed, we could statically determine the block weight increase and also check the size of the scriptpubkey above (after line 94) and bail early if ifs not well-formed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I'm not sure what the intent is for it. It seems to be based on a mistaken assumption that serialized bytes are a resource to minimise. But for now, this implements [most of] the current BIP draft.

src/sidechain.cpp
acks_s >> acks;
}
if (acks >= SIDECHAIN_WITHDRAW_THRESHOLD) {
// Overwrite an existing sidechain with a new one
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to also explicitly delete any lingering DBIDX_SIDECHAIN_WITHDRAW_PROPOSAL_LIST entries for the deleted sidechain?

@DrahtBot DrahtBot mentioned this pull request Aug 22, 2023
Merged
@nsvrn
Copy link
Contributor

nsvrn commented Aug 22, 2023 •
edited
Loading

Approach NACK

You yourself have said that this will not work "without significant additional changes to handle an activation". So what's the point of writing, reviewing and merging this code without completely knowing those "significant changes" ahead of time?

And surely people have opinions about Drivechain in general because the big debate around it is about mining pool centralization and valid perverse incentives(and since this will lead a way for that to happen on the Bitcoin system instead of an independent sidechain implementation those opinions are also somewhat valid given this is incomplete work).

@DrahtBot DrahtBot mentioned this pull request Aug 22, 2023
Merged
@psztorc
Copy link

psztorc commented Aug 22, 2023

Approach NACK: given that drivechains has fundamental flaws unrelated to the exact implementation, there's no reason to distract Bitcoin Core development with this pull-req, even in draft form. What's holding Drivechains back is the idea itself, not the code.

I have engaged Peter (and compensated him financially) to write a report on these "fundamental flaws", but I have not yet heard or seen anything.

Peter, until you publish these flaws, we have no way of evaluating them. (Nor would this be the place to do that, even if you had. Per Luke's comment on Concept ACK/NACKs.)

@jaybny
Copy link

jaybny commented Aug 22, 2023 •
edited
Loading

I want to see a more 'trustless' method of pegouts

what exactly do you mean by trustless? what can be more trustless than hash-rate escrow? After years of research, all other approaches rely on actual centralized custodians like liquid does. Hash rate escrow leverages the assumption that sha256 hash rate is sufficiently distributed for bitcoin censorship resistance properties.

@jaybny
Copy link

jaybny commented Aug 22, 2023

Meta Approach ACK - i like the approach of developing an implementation, independent of the concept ack/nack

having said that, regarding the concept.. We need to be laser focused (no pun intended) on scaling bitcoins utxo p2p money utility, and while the idea of a 2way peg sidechains using hash rate escrow via bip300 is one such solution, (in addition to larger block size, bip119 and other covenants), the abstract bling merged mining in bip301, opens bitcoin incentives to things other than p2p money bitcoin.

the solution here is to "limit" sidechains to the p2p money utility. this will keep miner incentives as is, and scale bitcoin with bitcoin script. such a solution can be achieved, but first requires this explicit social consensus intent and explicit designer and implementor intent.

with such intent in place, the miners Nash equilibrium is to follow intent, due to the implied UASF which already implicitly secures bip300 in the first place.

@ChrisMartl
Copy link

Approach NACK

Missing analysis statement, which effects or how this proposal could increment the exploit exposure for the Bitcoin system due to the loose flexibility of Bitcoin’s script (predicative processing).

Missing statement how this proposal will affect the Nash equilibrium between the distribution of affordable archival full nodes and affordable mining devices.

Concerns, that equilibrium is reached by highly capitalized and centralized original node (storage + mining) entities neither addressed nor mitigated.

@CheemsCommander
Copy link

Cheemsburger ACK!

@DrahtBot DrahtBot mentioned this pull request Aug 25, 2023
Merged
@lucasdcf lucasdcf mentioned this pull request Aug 29, 2023
Closed
@aceofbitcoin
Copy link

aceofbitcoin commented Aug 29, 2023 •
edited
Loading

NACK. I say NJET, NADA, NIENTE, NOPE, NO, いいえ I quote @B__T__C "... the miners mine on the layer based & hold it & the users get some shit tokens or shit coins on the drive... " personally I totally agree with Pete Todd This BIP300 should not be accepted for several reasons. Another reason, the rewards system looks like a pyramid scheme if this get through. This will have technical, legal and ethical implications. This is a trojan horse code injection to fundamental things of bitcoin. And yes, belief what You want who I am. Satoshin

@Satoshin-Btc
Copy link

Satoshin-Btc commented Aug 29, 2023 via email

@ariard
Copy link

ariard commented Aug 29, 2023

@luke-jr @petertodd As someone that can claim to be your technical peer and with experience in consensus development, I would appreciate if you can publish on the communication space of your convenience the contractual commitment excerpts linking your work on drivechain to the proposal authors themselves . The amount and all personal matters are no public business, though at the very least I hope you have minimal provisions protecting the autonomy of your creative work or ensuring the intellectual outcome respect FOSS licenses.

With all my respect, I’m not questioning the legitimacy as an independent technical expert who has accumulated years of hard works of being paid to offer a grounded and in-depth technical opinion on a subject in the scope of its competence. Here I’m just asking for transparency on potential conflict of interest that one would request in all walk of life (law, health, energy) when experts are expressing themselves on a complex subject with potential large-scale and serious impact on the end-users (financial) life.

Personally, I have the competence and knowledge to evaluate the proposal both in code and its associated documentation without relying on “domain experts”, though I think other folks in the community would appreciate the ethical effort.

I understand it’s delicate as a remark though as Rusty Russell observed a while back in matters of open-source cryptocurrency development ethics, we’re keeping each other in check as peers. I’ve been in the same situation early last year when I’ve been approached to do a paid security review of the CTV soft-fork and I politely declined. My professional policy for years have been to decline any work commitment related to consensus changes to preserve the independence of my views.

If you would like feedback on how to construct ethically and legally such agreement, I’m staying available out of band to provide my viewpoint and relevant information. I don’t think the discussion is appropriate for the GH repository. I’m staying available to discuss the ethics and ideal development process of consensus changes on the mailing list or other forum of discussions. As a community, I think we’re still paying the trauma of a group of Bitcoin dev experts raising millions in VC-funding almost a decade ago to promise new technology and corresponding consensus changes and finding themselves in a massive situation of conflict of interests with the rest of the ecosystem, whatever the great achievements they have realized on a lot of significant fronts.

@RicYashiroLee
Copy link

This is a (rough draft) clean rewrite of BIP300 (Drivechain) consensus-level code.

Instead of a separate sidechain database (which may be prone to hard-to-review/test consistency issues), instead the unusable 8 MSB of the UTXO index are reserved for non-UTXO database entries, and the existing UTXO db and caching layer is shared. This can be refactored in the future, but I think it is the cleanest and most reviewable approach initially - open to other ideas, though. There's also some ugliness in the undo data to handle restoring the new data, but it's abstracted and shouldn't be too hard to reason about.

Using these new primitives, Drivechains can be reimplemented with a UTXO-like model. Note that there is zero activation logic in the current PR: the protocol changes are always active. Therefore, this will not work (at least not safely) on Bitcoin today, and cannot be deployed without significant additional changes to handle an activation.

A new SERIALIZE_TRANSACTION_FOR_WEIGHT serialization flag is also added, that is meant only for weight counting. This allows for adjusting weight (upward) to fit additional resource requirements by new functionality. In this case, several Drivechain "messages" are expected to have a larger burden than their OP_RETURN encoding would otherwise weigh. However, the specific adjustments are not implemented in this draft.

As a consensus change, this can only be implemented with community support. Many people seem to have opinions, but please keep them to other forums. Despite providing and continuing this implementation, I myself do not thereby endorse or otherwise comment on the proposal itself.

Therefore, not looking for concept ACKs/NACKs (ie, about Drivechains), just Approach ACKs / constructive criticism (ie, about how I'm implementing it).

NACK, concept, approach, all. IMV Bitcoin is NOT made for the BIP/PR mania, Core Devs profit absolutely from. Any Core Devs, are by definition, not the ones to decide anything due to lack of exemption as service providers in Bitcoin, not unbiased customers/node operators(the only unbiased who must decide about their OWN property). It is for long been that Devs keep pushing node operators out of the decisions that belong solely to them as owners of Bitcoin, NOT to Devs, NOT to miners. Instead of coding every time an OPTION in full nodes software to allow (UN)SUPPORT for each non-stop new BIP/PR mania non-bug fixing CHANGE to Bitcoin, they discretely discuss things in a 'only for the experts central Hub' environment, like this one in GitHub and less user friendly, MS-DOS/command prompt like and as geeky as possible, JUST LIKE ALTCOINERS DID when inventing a lot of weird new jargon for things that always existed, so that all the idiots could eat their very shady technical jargon in speculative marvel and fiat dollar signs in their eyes.

@curly60e
Copy link

I emphatically do not support this Pull request.

@amtriorix
Copy link

Approach NACK. Also the promotor does block people who debate on this issue on twitter. If You propose a BIP You defend it with arguments, not with money and propaganda. This proposal paves the way to abuse the reward system. People who contribute to mine bitcoin have the right to receive real bitcoin not some reward on a sidechain. And what happens if the sidechain gets issues with the mainchain to merge etc. This idea is totally unsafe and my eye is on stratum.

@psztorc
Copy link

psztorc commented Aug 30, 2023

I thought that this part was admirably clear:

Many people seem to have opinions, but please keep them to other forums. Despite providing and continuing this implementation, I myself do not thereby endorse or otherwise comment on the proposal itself.

Therefore, not looking for concept ACKs/NACKs (ie, about Drivechains), just Approach ACKs / constructive criticism (ie, about how I'm implementing it).

This area is for discussing the Approach/Implementation. Everything else is off-topic.

Any skeptics or opponents of DC should at least pretend to want to see a real implementation, before dismissing it. After all, pre-implementation the idea is inherently unfinished.

@ariard
Copy link

ariard commented Aug 30, 2023

@psztorc

This area is for discussing the Approach/Implementation. Everything else is off-topic.

There is an uncertainty on the open-source status of the technical contributions due to the apparent mode of financial compensation of the "champions" developers, among other issues. While this might be acceptable for a lot of contributions in other areas of the Bitcoin ecosystem, here we're talking about consensus changes in a $500B ecosystem, any exposure due to uncertain license on key components might taint the rest of the open-source Bitcoin software. I think we've already enough issues with CSW lawsuits from now on to minimize the legal exposure of all ecosystem stakeholders, in my reasonable opinion.

This type of discussion happens, among other forums, on the Github repository. E.g #28175.

Any skeptics or opponents of DC should at least pretend to want to see a real implementation, before dismissing it. After all, pre-implementation the idea is inherently unfinished.

I've never seen any Bitcoin Core commit or substantial review on delicate critical components realized under your pseudonym, or even substantial technical contributions on deployed and with real-world usage multi-party applications or contracting protocols (e.g payment channels), so I don't know your level of understanding of the Bitcoin network, protocols architecture and ecosystem. Even when an idea is fully fleshed out in code and once it deployed you have unmeasurable security, safety and compatibility maintenance costs beared by the whole ecosystem ad vitam aeternam (i.e
as long as Bitcoin is around for the next decaces/centuries hopefully). Additionally, it also increases the development cost on all the affected Bitcoin systems: miner stack, mempool and transaction-relay, lightning, vaults, data carriage cost as investigating for the lack or the finding of potentially harmful interactions due to modified miner incentives is a very high technical bar.

Personally, I don't have strong technical opinion on DC / sidechains, as with any complex technical matter this is far from being a "binary" subject. All I know is we're Aug 30 (depending your timezone) and there is far enough hard technical issues to review and test for the coming year (package relay, assumeutxo, libitcoinkernel, bip324, maybe maybe APO, transaction-relay policy improvement for data carriage usage). Speaking for myself and myself only, this is not worthy to allocate high-caliber technical review time (in a pure FOSS fashion without financial compensation to preserve independence of my judgement) on a consensus changes project with that level of uncertainty in its development process, at the very least until next year Aug 30 2024. By then, I hope project champions will have clarified the development and technical evaluation process of DC.

If you would like to discuss in depth the ethics of Bitcoin consensus changes, what lessons can be sketched out from the failed activation of CTV by its champion Jeremy Rubin last year or the best development practices of critical Bitcoin components, I'm staying available to discuss it during in person at a panel or another public format at a Bitcoin conference during the coming years.

luke-jr and others added 6 commits October 17, 2023 18:57
@luke-jr
sidechain: Setup DBIDX_SIDECHAIN_CTIP_INFO
8420ef8
@luke-jr
sidechain: Detect more edge cases and document TODOs
924e345
@luke-jr
Assert undo data record id > MAX_INDEX vs <=
845fa89 
* Change sidechain.cpp CreateDBUndoData record_id.n assertion
to record_id.n > COutPoint::MAX_INDEX from <= COutPoint::MAX_INDEX
@luke-jr
Create sidechain proposal db entry with valid data
6f8ef16 
* CDataStream is invalidated by test reading the sidechain proposal so
  create a new stream for CreateDBEntry
@CryptAxe @luke-jr
Sidechain activation fixes
5d68fd2 
* Fix CDataStream handling bug

* Remove sidechain number from new_sidechains_activated set after
  activation
@luke-jr
CScript functions to check for drivechain headers
3fda7b3 
* Add functions to CScript to check for drivechain coinbase commitment
  script headers

* Use new functions in sidechain coindb
@luke-jr
Copy link
Member Author

luke-jr commented Oct 17, 2023

Rebased and added some fixes

This was referenced Oct 18, 2023
Closed
Merged
Open
@petertodd
Copy link
Contributor

Note that BIP-301 suffers from an equivocation attack. While there are many other reasons to NACK this pull-req, at minimum the equivocation attack is a sufficient reason alone.

@CryptAxe
Copy link
Contributor

Note that BIP-301 suffers from an equivocation attack. While there are many other reasons to NACK this pull-req, at minimum the equivocation attack is a sufficient reason alone.

If that was an issue then we would add 1 byte... as you mention yourself "An obvious solution would be to tag the OP_Return outputs with some kind of merge-mined chain identifier, and implement a strict rule consensus rule in the blind-merge-mined chain where the first matching tag wins." It isn't an issue though. h* can and in our examples does include information about which chain it belongs to.

@petertodd
Copy link
Contributor

It isn't an issue though. h* can and in our examples does include information about which chain it belongs to.

As BIP-301 states, h* is a 32 byte hash digest. The problem is you can have two valid h*'s in the same coinbase, for the same chain, and without access to the data behind h*, you have no way of detecting that.

@CryptAxe
Copy link
Contributor

The sidechains have access to the data behind h*. The mainchain doesn't care but it can also tell: https://github.com/LayerTwo-Labs/mainchain/blob/3f4d632a90ebd5eb5f94dba24384235043c34a69/src/validation.cpp#L3952-L3990 This is an example of one part of the BMM h* validation from the old version of our code but you get the idea.

@petertodd
Copy link
Contributor

The sidechains have access to the data behind h*. The mainchain doesn't care but it can also tell: https://github.com/LayerTwo-Labs/mainchain/blob/3f4d632a90ebd5eb5f94dba24384235043c34a69/src/validation.cpp#L3952-L3990 This is an example of one part of the BMM h* validation from the old version of our code but you get the idea.

That code allows for additional OP_Returns with the special BMM marker to be put in the set of coinbase outputs, beyond the set of BMMs that should be present due to txs in the block itself.

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

@psztorc
Copy link

psztorc commented Nov 15, 2023

Peter's "equivocation attack" is just him misunderstanding BMM -- specifically wrongly assuming it is like Namecoin (as he says in his linked article).

Unlike Namecoin, which is its own Blockchain and can survive on its own, BMM assumes that L1 can be found -- the L2 therefore has full access to all of L1 already. L2 already sees everything on L1, and its order.

(L2, of course, already sees everything on L2. And it knows what sidechain number it is.)

Unfortunately, I don't think there's anything anyone can do, to actually get Peter to spend 5 minutes engaging with Bip300/301. Instead he is determined to:

  1. misunderstand the idea
  2. make something else up, that is inaccurate
  3. criticize that
  4. pat himself on the back and call it a day

His comments at Baltic Honeybadger indicate he had never visited the top of the project site drivechain.info at all in the past 4+ years. And his tweets before TabConf indicate that he had not yet any rudimentary familiarity with how the idea worked, but was going to declare it broken anyway. Even after paying him for his time, he couldn't be bothered to actually look at the idea, he has to just fabricate something instead -- the writeup is full to the brim of these errors and fabrications.

Not sure what else there is to say.

@petertodd
Copy link
Contributor

petertodd commented Nov 16, 2023 via email

@miketwenty1
Copy link
Contributor

@petertodd

Note that large coinbase transactions have caused a number of problems before,
including issues with ASIC compatibility and p2pool. We should not inflate
coinbase transaction size needlessly.

What responsibilities going forward do devs have with asic compatibility? Seems like a potential conflict of interest in some situations.

@CryptAxe
Copy link
Contributor

Concern over 33 bytes of data being added per block for blind merged mining seems disingenuous to me.

@RicYashiroLee
Copy link

RicYashiroLee commented Nov 16, 2023 •
edited
Loading

@petertodd

Note that large coinbase transactions have caused a number of problems before,
including issues with ASIC compatibility and p2pool. We should not inflate
coinbase transaction size needlessly.

What responsibilities going forward do devs have with asic compatibility? Seems like a potential conflict of interest in some situations.

The reviewers of this and other PRs/BIPs also are in a position of high risk of conflict of interests. Every Dev wants to merge more needless op_code complexity to Bitcoin, 'world computer' alike, but no Dev is ever proposing to ALSO code the respective OPT-OUT script to Full Nodes Core Software, so that the only people unbiased in this mess, the node operators, could sovereignly (UN)support by themselves every new altcoin alike 'scaling' (altcoiners fav word) feature and non-bug fixing CHANGE to Bitcoin. Running an old node, less and less supported is NOT a decentralizing option either at some point, but much less a centralized Bitcoin filled with code complexity and consequently easier data dumping out of Bitcoin's sole goal (=ONE!) = tyranically (SN's terminology) tiny scope.

@petertodd
Copy link
Contributor

@petertodd

Note that large coinbase transactions have caused a number of problems before,
including issues with ASIC compatibility and p2pool. We should not inflate
coinbase transaction size needlessly.

What responsibilities going forward do devs have with asic compatibility? Seems like a potential conflict of interest in some situations.

Obviously we should not do things that are incompatible with existing ASICs without a very good reason. A feature that doesn't actually work is clearly not a good reason.

@ariard
Copy link

ariard commented Dec 10, 2023

My invitation to discuss in person about the topic of Bitcoin consensus change at a conference during the coming years stays open, or on the mailing list if it’s a communication medium you think it’s better suited.

Held my words here. A twitter space did happen end of last week between one of the PR author and myself, which was pleasant overall.

I made it clear I didn’t have any strong thoughts on drivechain, though I took time to express 2 generic concerns I think affecting all bitcoin second-layers designed and developed for scalability or extend use-case expressivity.

Lack of common metrics on L2s performance on multiple dimensions. E.g onboarding scaling (how many users can co-exist off-chain ?), transactional scaling (how many transfers can be performed off-chain per-on-chain transaction ?), fees cost scaling (what is the average / worst-case on-chain fees / off-chain fees on end-user ?), user computing ressources assumptions (e.g what is the average bandwidth cost ?). For now, it sounds to me people are comparing apples with oranges when talking about Bitcoin L2s.

Partial risks and security analysis. Since side-chains have been proposed almost a decade ago, I think the community knowledge in term of L2 vector of attacks has growth a lot, especially from the deployment of Lightning. It sounds very plausible that new vectors e.g things like flood-and-loot, pinning, eclipse and time-dilation attacks, liquidity griefing are affecting all constructions in minor or major ways. E.g the 2014 sidechain paper made the observation that most users might use atomic swaps for coins transfers, a time-sensitive L2 protocol.

My personal flavor in term of bitcoin consensus changes stay the same. Fix old consensus technical debt such as the timewarp attack, or the thundering herd issue affecting all time-sensitive second-layers.

@DrahtBot
Copy link
Contributor

DrahtBot commented Jan 5, 2024

There hasn't been much activity lately and the patch still needs rebase. What is the status here?

  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

@fanquake
Copy link
Member

fanquake commented Mar 6, 2024

Closing. The discussion here has run it's course, and it ultimately turned non-technical (this isn't the correct forum for that).

@fanquake fanquake closed this Mar 6, 2024
@bitcoin bitcoin locked and limited conversation to collaborators Mar 6, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@psztorc psztorc psztorc left review comments

@MurrMcK MurrMcK MurrMcK left review comments

@rot13maxi rot13maxi rot13maxi left review comments

Assignees
No one assigned
Labels
CI failed Needs rebase
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.