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

pull luke-jr wants to merge 21 commits into bitcoin:master from luke-jr:bip300 changing 25 files +814 −65
  1. luke-jr commented at 1:17 am on August 22, 2023: member

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

  2. DrahtBot commented at 1:17 am on August 22, 2023: contributor

    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.

  3. russeree commented at 2:15 am on August 22, 2023: contributor

    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.

  4. DrahtBot added the label CI failed on Aug 22, 2023
  5. in src/sidechain.cpp:367 in afc975bb60 outdated 
    358+bool VerifyDrivechainSpend(const CTransaction& tx, const unsigned int sidechain_input_n, const std::vector<CTxOut>& spent_outputs, const CCoinsViewCache& view, TxValidationState& state) {
359+    const CTxIn& sidechain_input = tx.vin[sidechain_input_n];
360+    // TODO: Do we want to verify there's only one sidechain involved? BIP300 says yes, but why?
361+
362+    // Lookup sidechain number from CTIP and ensure this is in fact a CTIP to begin with
363+    // FIXME: It might be a good idea to include the sidechain # in the tx itself somewhere?
    rot13maxi commented at 3:04 am on August 22, 2023:
    if you had the tx commit to the sidechain number somewhere, I think you could remove it from CalculateDrivechainWithdrawInternalHash?
  6. john-light commented at 4:57 am on August 22, 2023: none

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

  7. ChrisMartl commented at 8:35 am on August 22, 2023: none

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

  8. petertodd commented at 10:27 am on August 22, 2023: contributor

    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.

  9. Gudnessuche commented at 1:10 pm on August 22, 2023: none

    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?

  10. Gudnessuche commented at 1:14 pm on August 22, 2023: none

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

  11. in src/script/interpreter.cpp:596 in afc975bb60 outdated 
    590@@ -591,6 +591,8 @@ bool EvalScript(std::vector<std::vector<unsigned char> >& stack, const CScript&
591                     break;
592                 }
593 
594+                // NOTE: OP_DRIVECHAIN (OP_NOP5) is enforced in VerifyDrivechainSpend
595+
596                 case OP_NOP1: case OP_NOP4: case OP_NOP5:
    rot13maxi commented at 1:21 pm on August 22, 2023:
    OP_NOP2 is no longer here because of CLTV. should we have the case OP_NOP5: in the same arm of the switch as OP_DRIVECHAIN? Would make it more clear to future readers that OP_NOP5 is the same
    luke-jr commented at 7:32 pm on October 17, 2023:
    There is no OP_DRIVECHAIN in the switch, and nothing different to be done here. The comment is added simply to ensure clarity in this code.
  12. in src/sidechain.cpp:19 in afc975bb60 outdated 
    14+#include <util/check.h>
15+
16+#include <algorithm>
17+#include <cstdint>
18+
19+void CreateDBUndoData(CTxUndo &txundo, const uint8_t type, const COutPoint& record_id, const Coin& encoded_data) {
    rot13maxi commented at 1:24 pm on August 22, 2023:
    do we also need to unwind sidechain db operations (like incrementing of DBIDX_SIDECHAIN_WITHDRAW_PROPOSAL_ACKS) in the undo data?
    rot13maxi commented at 1:40 pm on August 22, 2023:
    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
  13. in src/sidechain.cpp:64 in afc975bb60 outdated 
    59+
60+void IncrementDBEntry(CCoinsViewCache& view, CTxUndo &txundo, const int block_height, const COutPoint& record_id, const int change) {
61+    ModifyDBEntry(view, txundo, block_height, record_id, [change](CDataStream& s){
62+        uint16_t counter;
63+        s >> counter;
64+        if (change < 0 && !counter) return;  // may be surprising if change is <-1
    rot13maxi commented at 1:27 pm on August 22, 2023:
    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
  14. in src/sidechain.cpp:79 in afc975bb60 outdated 
    74+    mtx.vout[0].SetNull();
75+    return mtx.GetHash();
76+}
77+
78+uint256 CalculateDrivechainWithdrawInternalHash(const uint256& blinded_hash, const uint8_t sidechain_id) {
79+    // Internally, we hash the bundle_hash with the sidechain_id to avoid conflicts between sidechains
    rot13maxi commented at 1:32 pm on August 22, 2023:
    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?
    luke-jr commented at 7:41 pm on October 17, 2023:
    It could be voted on because we only see the hash at that stage. But it would never be valid for more than one.
  15. in src/sidechain.cpp:107 in afc975bb60 outdated 
    106+                // TODO: data format 3 upvotes any bundle leading its rivals by at least 50 ACKs -- also encourages blind upvoting :/
107+            // TODO: How is vote vector actually encoded?
108+            // TODO: Block is invalid if there are no bundles proposed at all
109+            // FIXME: Presumably blocks should only be able to vote once - this is missing in the BIP
110+            for (int sidechain_id = 0; sidechain_id < 0x100; ++sidechain_id) {
111+                // FIXME: bounds checking
    rot13maxi commented at 1:35 pm on August 22, 2023:
    probably something like out.scriptPubKey.size() >= 6 + (0x100 * data_format) before we start counting votes
  16. in src/sidechain.cpp:98 in afc975bb60 outdated 
     97+        static constexpr uint8_t BIP300_HEADER_SIDECHAIN_PROPOSE[] = {0xd5, 0xe0, 0xc4, 0xaf};  // n.b. 20 sigops
 98+        static constexpr uint8_t BIP300_HEADER_SIDECHAIN_ACK[]     = {0xd6, 0xe1, 0xc5, 0xbf};
 99+        static constexpr uint8_t BIP300_HEADER_WITHDRAW_PROPOSE[]  = {0xd4, 0x5a, 0xa9, 0x43};  // n.b. 67 byte push followed by only 32 bytes
100+        static constexpr uint8_t BIP300_HEADER_WITHDRAW_ACK[]      = {0xd7, 0x7d, 0x17, 0x76};  // n.b. 23-byte push followed by variable bytes
101+        if (std::equal(&out.scriptPubKey[1], &out.scriptPubKey[5], BIP300_HEADER_WITHDRAW_ACK)) {
102+            const uint8_t data_format = out.scriptPubKey[6];
    rot13maxi commented at 1:37 pm on August 22, 2023:
    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
    luke-jr commented at 7:32 pm on August 22, 2023:
    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.
  17. in src/sidechain.cpp:255 in afc975bb60 outdated 
    250+                CDataStream acks_s = GetDBEntry(view, record_id);
251+                Assert(!acks_s.empty());
252+                acks_s >> acks;
253+            }
254+            if (acks >= SIDECHAIN_WITHDRAW_THRESHOLD) {
255+                // Overwrite an existing sidechain with a new one
    rot13maxi commented at 1:44 pm on August 22, 2023:
    do we want to also explicitly delete any lingering DBIDX_SIDECHAIN_WITHDRAW_PROPOSAL_LIST entries for the deleted sidechain?
  18. rot13maxi commented at 1:46 pm on August 22, 2023: none
    handful of questions and comment
  19. nsvrn commented at 3:21 pm on August 22, 2023: contributor

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

  20. psztorc commented at 4:26 pm on August 22, 2023: none

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

  21. jaybny commented at 7:21 pm on August 22, 2023: none

    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.

  22. jaybny commented at 7:45 pm on August 22, 2023: none

    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.

  23. ChrisMartl commented at 5:33 am on August 23, 2023: none

    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.

  24. CheemsCommander commented at 4:11 pm on August 23, 2023: none
    Cheemsburger ACK!
  25. aceofbitcoin commented at 6:11 pm on August 29, 2023: none
    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
  26. Satoshin-Btc commented at 6:34 pm on August 29, 2023: none

    Look drivechains are good for only a couple of things such as security, and deploying a token possibly while being backed by Bitcoin. It’s not a good idea as a side chain to run simultaneously because it would slow transactions as well as screw with the parsing and verification. How ever creating a personal drive chain can add a layer of security but can be messed up if you don’t pay attention to how the drive chain is configured.

    On Mon, Aug 21, 2023, 6:20 PM Luke Dashjr @.***> wrote:

    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, just Approach ACKs / constructive criticism.

    You can view, comment on, or merge this pull request online at:

    #28311 Commit Summary

    File Changes

    (23 files https://github.com/bitcoin/bitcoin/pull/28311/files)

    Patch Links:

    — Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/28311, or unsubscribe https://github.com/notifications/unsubscribe-auth/AORL367L5NQUE7TACLIEHOTXWQCODANCNFSM6AAAAAA3ZE4L3M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

  27. ariard commented at 6:51 pm on August 29, 2023: member

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

  28. RicYashiroLee commented at 8:06 pm on August 29, 2023: none

    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.

  29. curly60e commented at 8:17 pm on August 29, 2023: none
    I emphatically do not support this Pull request.
  30. amtriorix commented at 6:21 am on August 30, 2023: none
    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.
  31. psztorc commented at 7:09 am on August 30, 2023: none

    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.

  32. ariard commented at 3:56 pm on August 30, 2023: member

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

  33. psztorc commented at 6:02 pm on August 30, 2023: none

    There is an uncertainty on the open-source status…

    Not to me. The source code is in the pull request.

    ….due to the apparent mode of financial compensation of the “champions” developers

    You are referring to disclosed financial compensation, only. But everyone here may have undisclosed financial compensation, including you. Plus, we all own different amounts of Bitcoin.

    The appropriate way to handle such un-resolv-able issues, is to discuss the idea on its merits only.

    I think we’ve already enough issues with CSW lawsuits

    FYI I personally donated thousands of $ to fight such lawsuits, some of which provably so – in public at Bitcoin events.

    Speaking for myself and myself only, this is not worthy to allocate high-caliber technical review time

    Why not speak openly, of whatever is really on your mind? Clearly we don’t expect a review from every single person on Earth – as you must know. So either say whatever it is you want to say, or go back to reviewing whatever you think is important.

  34. amtriorix commented at 12:06 pm on August 31, 2023: none

    There is an uncertainty on the open-source status…

    Not to me. The source code is in the pull request.

    Anyone who can read your code can see this is pretty dangerous for bitcoin.

    Bitcoin is not only about the award system for miners. In future mining will be done for a big part by pools. Creating drivechains and give them the possibility to create their own chain, pegged on the mainchain, can create huge legal implications. Pools can also ask contributing miners to cooperate, give them a reward on their sidechain but hodl the bitcoin for themselves. Then about voting. A minority of them can just push changes through on their chain. This is pretty much centralisation.

    You are clearly affiliated with RogerVer having bitcoincash. Well You have another path to go with this altcoin imo

    ….due to the apparent mode of financial compensation of the “champions” developers

    You are referring to disclosed financial compensation, only. But everyone here may have undisclosed financial compensation, including you. Plus, we all own different amounts of Bitcoin.

    The appropriate way to handle such un-resolv-able issues, is to discuss the idea on its merits only.

    I think we’ve already enough issues with CSW lawsuits

    FYI I personally donated thousands of $ to fight such lawsuits, some of which provably so – in public at Bitcoin events.

    This is not a free ticket or a BUY IN so to speak to push your own agenda through the bitcoin core project. Bitcoin is not for sale it is an open source project. Refering to this can be translated as, look I donated in the defensive case against faketoshi CSW.

    We all know that Craig Wright does hoax. Clearly not Satoshi Nakamoto, because he lacks not only the technical skills but also he has NO SINGLE private key related to the genesisblock (block 0), block 1 and not even the PGP key.
    Signing is key. And he has for sure not the mentality of an open source developer…

    It was very generous of You to help that teacher in the trails seen he was clearly bullied by CSW who’s intention is clearly to grab income from legal pursuits, while the same time he seems not to pay his lawyers or when he loses his case. That all is possible in the UK, maybe the USA, but I want to see that happen in West-Europe…

    But that does not mean You can push through, imo, a pretty dirty hack to centralise bitcoin, to peg on the blockchain and to leak away bitcoin in a sidechain.

    That is like to use a cherry trunk, branch other fruit on it…when the fruit is rotten or the branch is rot….cut. And those on the branch end up with a trash reward…

    Everyone can fork bitcoin and create their own altcoin. But to create drivechains, to have indirectly an altcoin, own rules, own power, own votes, piggy backing on bitcoin…until there is a huge issue and they will all claim. it’s bitcoin core that made the error…. I am totally against that idea

    Speaking for myself and myself only, this is not worthy to allocate high-caliber technical review time

    Why not speak openly, of whatever is really on your mind? Clearly we don’t expect a review from every single person on Earth – as you must know. So either say whatever it is you want to say, or go back to reviewing whatever you think is important.

    First Stratum improvement….

    BTW why all those people like You want always change things and ‘improve’ things?! Currently bitcoin is safe, robust and all those new idea’s clearly not well thought through, experimental, unsafe like Peter Todd said, we can miss this totally.

    Personally I also see this as a very dangerous way to ruin bitcoin. I explain in detail.

    And I quote Satoshi (whatever you think about this claim, and it’s not CSW)

    They can create a #drivechain, convince, force (by law) people to move their bitcoin to the sidechain. Now their terms. That’s like creating fiat backed by gold so to speak, an altcoin or CBDC. Then force people by law or defacto to use theirs ?!

    BTW You did block that account on twitter, i hope there will be no digital sign or You will look like a…, including a big amount of people inside the bitcoin community. You push like a merchant with full force propaganda your idea… Many did state already…this is stinky.

    So is your purpose to leak out bitcoin to a sidechain to finally have your own terms, control, tracking, whatever? This is IMO a major attack (again) on bitcoin just like the blocksize war was, reason Satoshi did revoke his repo key at that time, if nobody did notice.

    I warn you personnally, if bitcoin is again attacked in such way, some will not deal with the ridiculous claims of Craig Wright but You will have your answer in text SIGNED with the genesis block. And when this need to happen, you and those people should provide a huge budget to defend their case because the whale wallet of the early blocks is pretty useful in such case to defend bitcoin.

    Bitcoin is not to hijack for commercial reasons, to soft or hard fork in a centralised solution to finally leak out bitcoin to an alternative form of an altcoin, but now on a drivechain.

    Thanks for your proposal but my vote is, as you know, NACK including the one of Ace of Bitcoin You did block btw.

    Btw when You mine have a full node… bitcoin-cli -generate 1 2147483647

  35. krisgrm commented at 12:32 pm on August 31, 2023: none
    How do I run/test on my local machine using local chain ?
  36. JackJin2014 commented at 1:06 pm on August 31, 2023: none

    How do I run/test on my local machine using local chain ?

  37. krisgrm commented at 1:30 pm on August 31, 2023: none

    But the code here is a new implementation of the same thing ? I’d like to run both and compare

    On Thu, Aug 31, 2023, 15:07 JackJin @.***> wrote:

    How do I run/test on my local machine using local chain ? https://layertwolabs.com/download

    — Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/28311#issuecomment-1701006485, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7Z3AFMHBP4AQB6GIXSQBTXYCD7RANCNFSM6AAAAAA3ZE4L3M . You are receiving this because you commented.Message ID: @.***>

    – CONFIDENTIAL: The information and any files contained in this e-mail are confidential and intended solely for the addressee. If you have received it in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking action in reliance on the contents of this information is strictly prohibited. Thank you for your cooperation.

  38. ariard commented at 6:34 pm on August 31, 2023: member

    @psztorc

    Not to me. The source code is in the pull request.

    Publishing the code is in the open does not minimize intellectual property hostile claims towards the project in the future. Whatever one think about the philosophical legitimacy of patent and intellectual property, especially in the Internet world, under US patent law, software might sadly be eligible_ to patent protection. If this consensus change and the corresponding source code has been funded by incorporated entities they can very claim resulting licensing to enter into their corporate assets, and from then make a lot of claims. I don’t assume hostile intentions, though in case of future dispute with shareholders in this DC project, it’s hard to predict what can happen.

    At the very least, I think a reasonable and ethical practice could be for any affiliated corporate entity sponsoring the project to pledge any intellectual rights arising from DC development to be pledged in an open patent organization, e.g https://www.opencrypto.org/about/

    You are referring to disclosed financial compensation, only. But everyone here may have undisclosed financial compensation, including you. Plus, we all own different amounts of Bitcoin.

    Undisclosed financial compensation is the ethical issue at stake. If you’re have or expect financial compensation (equity valuation or capital investment) from the successful deployment of DC (which might have technical and economics risks on the stability of the Bitcoin network and therefore the value of the coins themselves), I think you’re in a situation of conflict of interests with all the passive intelligent Bitcoin investors, of which the financial portfolio strategy can be to wait a slow appreciation of their Bitcoin digital assets. Without playing wizardry with the fundamentals of the system.

    On the past okcoin funding grant, this contract framework explicitly includes a provision of technical autonomy in the area of Bitcoin consensus changes, on the model of Bitmex bitcoin developer grant agreement (cf. 2.2): https://github.com/jonathanbier/Bitcoin-Developer-Grant-Agreement/blob/master/Bitcoin-Developer-Grant-Agreement.md Though I can take opportunity to say, in matters of technical neutrality open-source funding, from the viewpoint of a developer I can only recommend to work with the set of historical people I’ve been collaborating with at okcoin as part of their open-source funding program. From my knowledge some historical developers at Blockstream had a similar legal provision of autonomy in their employment agreement.

    Ethics and integrity of scientific research are quite well understood in established scientific and software engineering practice. The IETF has rules on conflict of interests, the NASA has guidelines for promoting scientific and research integrity and the ACM has a pretty well-reasoned code of ethics. Of course ethics is evolutionary, and there is always a sense of proportion and contextualization to keep.

    The appropriate way to handle such un-resolv-able issues, is to discuss the idea on its merits only.

    I think this is a hard issue where we’re diverging. While those issues are “un-resolv-able” (“Men are not angels” - James Madison iirc), though it doesn’t mean principles and ethics have nevertheless been developed and nurtured by technical and scientific communities all around the world, as decades of history is showing it (cf. examples above).

    Discussing in depth an idea as complex as a Bitcoin consensus changes related to miners incentives would consume hundreds of hours of review time, if you have high-caliber technical eyes and you do not wish to give a simple “binary” answer. A displayed low-level of ethics by a technical idea propoent is not appealing and it appears as a hint of a potential waste of time, when such open-source time could be invested in the review of other sensible technical projects such as package relay, bip324 or libbitcoinkernel.

    FYI I personally donated thousands of $ to fight such lawsuits, some of which provably so – in public at Bitcoin events.

    I think this is appreciated by the community and you have my own thanks for it, sincerely. I’m not defendant on the CSW lawsuits (at least for now - fingers crossed) though from my looking on the database rights case this is crazy how someone can make such dubious claims on weak materials. And this is a reason of concern from my point above establishing clear open-source and no-patent/defensive patent status of all technical contributions on critical areas like consensus changes.

    And as it sounds you have been in Bitcoin since a while, I think you also remember the ASICBOOST scandal, and related issues about patent.

    Why not speak openly, of whatever is really on your mind? Clearly we don’t expect a review from every single person on Earth – as you must know. So either say whatever it is you want to say, or go back to reviewing whatever you think is important.

    I would appreciate a more respectful tone from someone (to the best of my knowledge) who has never contributed a line of cpp or find a noteworthy bug in the sensible areas of Bitcoin Core, or equivalent full-node software so far.

    To speak my mind, I think this will be more efficient in term of review, testing and quality assurance of the proposed consensus changes to have this BIP300 PR be opened in bitcoin-inquisition fork: https://github.com/bitcoin-inquisition/bitcoin/wiki Bitcoin inquisition purpose as a community R&D platform has been discussed here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html

    Additionally, about reviewing Bitcoin consensus changes in 2023, I think this is pointless to review only the consensus primitives changes, without proof-of-concept on associated application software (at least an experimental side-chain, wallet, nodes) to enable giving a judgement on the whole end-to-end usage. Such end-to-end technical bar is at least experimentally followed for APO: https://github.com/instagibbs/lightning/commits/eltoo_support

    Beyond on the ethics of Bitcoin consensus changes, and a wish in the community to have a flat development from centralized companies and their own time agenda ensuring we “give a chance and time” to maybe-not-every-single-person -on-Earth though to as much people has we can to have their say on a consensus change, I think it has been discussed here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-August/020819.html

    All that said, I’m maintaining that personally I won’t have time to review proposed DC consensus changes before August 2024 as doing it correctly would take at least 3 months of intense review work, and I think this is quite invariant for any skilled Bitcoin reviewers I know. From my appreciation, there has been a trend to have a more public list (package relay / bip324 / libbitcoinkernel) of shared technical priorities in Bitcoin Core and an aim to follow them. I think this is a waste of time and the door towards real ossification of the protocol if skilled technical eyes have to interrupt their monthly-long review cycle every time someone shows up with a consensus change idea, neither build serenity of conservations.

    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. I won’t have time to comment or reply further on this PR at least until December of this year.

  39. melvincarvalho commented at 9:18 pm on September 3, 2023: none

    Thank you for the proposed BIP on drivechains. I have some concerns regarding the approach:

    1. Coins held in hashrate escrow might become enticing for miners as time progresses.
    2. Over time, users could develop a misplaced confidence when seeing drive chain coins in BTC denomination. Any coin losses might prompt calls for forks, with users naturally wanting to recover their funds.

    A potentially more robust solution could be inspired by the demurrage concept from @petertodd. Consider incorporating an escrow fee of 0.01% per day (144 blocks) into the coinbase, possibly emulated as a transaction self-spent with FLOOR(satoshis / 10000). This could ensure:

    • A consistent income stream for miners, enhancing the coinbase indefinitely without favoring individual miners.
    • Managed user expectations, promoting chain utility and transaction volume. A reduced market cap on the chain could also yield a more game-theoretically stable environment. Moreover, users might be inclined to transact with their coins on the sidechain and regard L1 as a secure value store.

    Just a suggestion. Appreciate the work being done here!

  40. DrahtBot added the label Needs rebase on Sep 5, 2023
  41. in src/sidechain.cpp:362 in d4eb444f6b outdated 
    178@@ -171,4 +179,116 @@ void UpdateDrivechains(const CTransaction& tx, CCoinsViewCache& view, CTxUndo &t
179     proposal_list << withdraw_proposal_list;
180     COutPoint record_id{ArithToUint256(arith_uint256{uint64_t{block_height}}), DBIDX_SIDECHAIN_PROPOSAL_LIST};
181     CreateDBEntry(view, txundo, block_height, record_id, MakeByteSpan(proposal_list));
182+
183+    // TODO: clean up expiring stuff
184+    // TODO: activate sidechains and assign CTIPs
185+}
186+
187+bool VerifyDrivechainSpend(const CTransaction& tx, const unsigned int sidechain_input_n, const std::vector<CTxOut>& spent_outputs, const CCoinsViewCache& view, TxValidationState& state) {
    MurrMcK commented at 1:42 am on September 7, 2023:

    It seems here that one has to spend the CTIP in order to deposit to a sidechain. And if there are multiple deposits in a block then each deposit after the first one must spend the previous unconfirmed CTIP in order to be accepted.

    If the fee rate required to be included in a block is higher than the minimum fee to be included in miner mempools, this seems to open the door for “freeloaders” who pay the minimum fee to be included in the mempool, hoping to be subsidised by subsequent depositors within the same block - as subsequent depositors are forced to spend the freeloader’s unconfirmed CTIP in order to be accepted into mempools. This seems like it could result in a bad user experience.

    Is it not possible to make it so that deposits do not have to spend the CTIP, but rather make an additional output to the sidechain address? Then, when a block is mined, there can be a different rule where the miner is forced to make a consolidation transaction merging all the sidechain UTXOs into one. So essentially, the “only one CTIP allowed” rule is only checked based on the final state once all transactions in the block are accounted for.

    I’m not sure how this would affect the overall size of the deposits, but it seems that it would be minimal. There’d be 1 more transaction, 1 more input and 1 more output in total compared to the current method. We could also allow both methods of depositing and users can choose based on the circumstances.

    luke-jr commented at 7:48 pm on October 17, 2023:
    I believe the end goal, if Bitcoin moves forward with this, is to have miners rewrite deposits on the fly to update the CTIP as appropriate.
  42. in src/sidechain.cpp:370 in afc975bb60 outdated 
    361+
362+    // Lookup sidechain number from CTIP and ensure this is in fact a CTIP to begin with
363+    // FIXME: It might be a good idea to include the sidechain # in the tx itself somewhere?
364+    uint8_t sidechain_id;
365+    {
366+        CDataStream ctip_info = GetDBEntry(view, {sidechain_input.prevout.hash, DBIDX_SIDECHAIN_CTIP_INFO});
    rot13maxi commented at 12:11 pm on September 7, 2023:

    I think we need to update DBIDX_SIDECHAIN_CTIP_INFO with the new CTIP identified below either after deposit (L409) or withdrawal (L464). Otherwise we won’t get the ctip_info here.

    Also, if we spend the current ctip to do a deposit, then that would mean a deposit would invalidate any current withdrawals in-flight because the withdrawal also has to spend the ctip?

    psztorc commented at 12:20 pm on September 7, 2023:
    No, to the second question. The withdrawal has a version of APO (called the “blinded hash”, with the CTIP input zeroed out).
    rot13maxi commented at 12:30 pm on September 7, 2023:
    Yep, you’re right
  43. bitcoin deleted a comment on Sep 13, 2023
  44. bitcoin deleted a comment on Sep 13, 2023
  45. bitcoin deleted a comment on Sep 13, 2023
  46. bitcoin deleted a comment on Sep 13, 2023
  47. bitcoin deleted a comment on Sep 13, 2023
  48. bitcoin deleted a comment on Sep 13, 2023
  49. bitcoin deleted a comment on Sep 13, 2023
  50. bitcoin deleted a comment on Sep 13, 2023
  51. bitcoin deleted a comment on Sep 13, 2023
  52. bitcoin deleted a comment on Sep 13, 2023
  53. bitcoin deleted a comment on Sep 13, 2023
  54. bitcoin deleted a comment on Sep 13, 2023
  55. skydogenet commented at 11:39 pm on September 26, 2023: none

    As the first mainnet implementation of Drivechain, we are proud to say that we support BIP300 and BIP301 activation on Bitcoin!

    Cheemsburgerking ACK!

  56. dbwrapper: Restore `CDBIterator::GetValueSize()` 
    This partially reverts commit fb38c6e21f064e23b63a46d15adb873029463cff.
Original code written in 3499ce1e1ad87a86598d00b7124072c91ddad833.
    b4c7dfd76c
  57. txdb: Support for flags which prevent opening with incompatible software d5a5bb07b2
  58. Hide COutPoint with n > 0x00ffffff from consensus/transaction handling 
    This should be safe since it is impossible for transactions to have more than ~0x0001c000 outputs.
0xffffffff is used for the coinbase COutPoint n, but wouldn't be looked up in the coins db.
    835a869dbf
  59. WIP Drivechain via UTXOs c4d7865f55
  60. primitives/transaction: Implement CTxIn::SetNull 9b76e19539
  61. Implement OP_DRIVECHAIN-based sidechain deposits/withdraws 144af6773f
  62. Add SERIALIZE_TRANSACTION_FOR_WEIGHT flag b6ab4471e7
  63. primitives/transaction: Stub weight increases for drivechains e0a68aeff6
  64. sidechain: Expire sidechain/withdraw proposals 3a64800993
  65. fixups, simplify record_id confusion in various places 4b80318f40
  66. sidechain: Hash blinded withdraw hashes with the sidechain id to avoid conflicts d6f78a492a
  67. sidechain: INCOMPLETE sidechain activation 9458c77d23
  68. fixups, cast changes to avoid narrowing conversion warnings 0a9fe1eb8e
  69. sidechain: Detect several invalid conditions 20118e8348
  70. Add push1[sidechain id] OP_TRUE after OP_DRIVECHAIN 8d5f681649
  71. sidechain: Setup DBIDX_SIDECHAIN_CTIP_INFO 8420ef83c7
  72. sidechain: Detect more edge cases and document TODOs 924e345c3a
  73. Assert undo data record id > MAX_INDEX vs <= 
    * Change sidechain.cpp CreateDBUndoData record_id.n assertion
to record_id.n > COutPoint::MAX_INDEX from <= COutPoint::MAX_INDEX
    845fa896bd
  74. Create sidechain proposal db entry with valid data 
    * CDataStream is invalidated by test reading the sidechain proposal so
  create a new stream for CreateDBEntry
    6f8ef16f9d
  75. Sidechain activation fixes 
    * Fix CDataStream handling bug

* Remove sidechain number from new_sidechains_activated set after
  activation
    5d68fd2bb1
  76. CScript functions to check for drivechain headers 
    * Add functions to CScript to check for drivechain coinbase commitment
  script headers

* Use new functions in sidechain coindb
    3fda7b30ae
  77. luke-jr force-pushed on Oct 17, 2023
  78. luke-jr commented at 8:42 pm on October 17, 2023: member
    Rebased and added some fixes
  79. DrahtBot removed the label Needs rebase on Oct 17, 2023
  80. petertodd commented at 8:33 pm on November 13, 2023: 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.
  81. CryptAxe commented at 11:46 pm on November 13, 2023: 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.

  82. petertodd commented at 4:49 am on November 14, 2023: 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.

  83. CryptAxe commented at 5:07 am on November 14, 2023: 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.
  84. petertodd commented at 5:49 am on November 14, 2023: 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.

  85. DrahtBot added the label Needs rebase on Nov 15, 2023
  86. DrahtBot commented at 3:33 pm on November 15, 2023: contributor

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

  87. psztorc commented at 9:04 pm on November 15, 2023: none

    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.

  88. petertodd commented at 3:29 am on November 16, 2023: contributor

    On Wed, Nov 15, 2023 at 01:05:13PM -0800, Paul Sztorc wrote:

    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.

    If that is your design assumption, forcing BMM commitments to be put in the coinbase is redundant and accomplishes nothing. The only reason to do that is for the sake of SPV-type validation, in which case there is a equivocation attack.

    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.

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

    Given that I’m far from the only person who believes Drivechains are a broken idea, I’d suggest you take a step back and reconsider what you are saying here.

  89. miketwenty1 commented at 5:14 pm on November 16, 2023: 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.

  90. CryptAxe commented at 5:38 pm on November 16, 2023: contributor
    Concern over 33 bytes of data being added per block for blind merged mining seems disingenuous to me.
  91. RicYashiroLee commented at 5:56 pm on November 16, 2023: none

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

  92. petertodd commented at 12:52 pm on November 23, 2023: 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.

  93. ariard commented at 6:37 pm on December 10, 2023: member

    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.

  94. DrahtBot commented at 10:39 am on January 5, 2024: contributor

    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.
  95. fanquake commented at 1:52 pm on March 6, 2024: member
    Closing. The discussion here has run it’s course, and it ultimately turned non-technical (this isn’t the correct forum for that).
  96. fanquake closed this on Mar 6, 2024


luke-jr DrahtBot russeree rot13maxi john-light ChrisMartl petertodd Gudnessuche nsvrn psztorc jaybny CheemsCommander aceofbitcoin Satoshin-Btc ariard RicYashiroLee curly60e amtriorix krisgrm JackJin2014 melvincarvalho MurrMcK skydogenet CryptAxe miketwenty1 fanquake

Labels
Needs rebase CI failed

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-06-29 10:13 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me