Greg Sanders [ARCHIVE] / is on Nostr

📅 Original date posted:2022-05-17
📝 Original message:Hi Gloria,
Thanks for working on this important proposal!
Still a lot to digest, but I just had on area of comment/question:
> A child-with-unconfirmed-parents package sent between nodes must abide by
the rules below, otherwise the package is malformed and the sender should
be disconnected.
> However, if the child has confirmed parents, they must not be in the
package.
If my naive understanding is correct, this means things like otherwise
common situations such as a new block will result in disconnects, say when
the sender doesn't hear about a new block which makes the relay package
superfluous/irrelevant. Similar would be disconnection
when confirmed gets turned into unconfirmed, but those situations are
extremely uncommon. The other rules are entirely under the control
of the sender, which leads me to wonder if it's appropriate.
Cheers,
Greg
On Tue, May 17, 2022 at 12:09 PM Gloria Zhao via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everybody,
>
> I’m writing to propose a set of p2p protocol changes to enable package
> relay, soliciting feedback on the design and approach. Here is a link
> to the most up-to-date proposal:
>
> https://github.com/bitcoin/bips/pull/1324
>
> If you have concept or approach feedback, *please respond on the
> mailing list* to allow everybody to view and participate in the
> discussion. If you find a typo or inaccurate wording, please feel free
> to leave suggestions on the PR.
>
> I’m also working on an implementation for Bitcoin Core.
>
>
> The rest of this post will include the same contents as the proposal,
> with a bit of reordering and additional context. If you are not 100%
> up-to-date on package relay and find the proposal hard to follow, I
> hope you find this format more informative and persuasive.
>
>
> ==Background and Motivation==
>
> Users may create and broadcast transactions that depend upon, i.e.
> spend outputs of, unconfirmed transactions. A “package” is the
> widely-used term for a group of transactions representable by a
> connected Directed Acyclic Graph (where a directed edge exists between
> a transaction that spends the output of another transaction).
>
> Incentive-compatible mempool and miner policies help create a fair,
> fee-based market for block space. While miners maximize transaction
> fees in order to earn higher block rewards, non-mining users
> participating in transaction relay reap many benefits from employing
> policies that result in a mempool with the same contents, including
> faster compact block relay and more accurate fee estimation.
> Additionally, users may take advantage of mempool and miner policy to
> bump the priority of their transactions by attaching high-fee
> descendants (Child Pays for Parent or CPFP). Only considering
> transactions one at a time for submission to the mempool creates a
> limitation in the node's ability to determine which transactions have
> the highest feerates, since it cannot take into account descendants
> until all the transactions are in the mempool. Similarly, it cannot
> use a transaction's descendants when considering which of two
> conflicting transactions to keep (Replace by Fee or RBF).
>
> When a user's transaction does not meet a mempool's minimum feerate
> and they cannot create a replacement transaction directly, their
> transaction will simply be rejected by this mempool. They also cannot
> attach a descendant to pay for replacing a conflicting transaction.
> This limitation harms users' ability to fee-bump their transactions.
> Further, it presents a security issue in contracting protocols which
> rely on **presigned**, time-sensitive transactions to prevent cheating
> (HTLC-Timeout in LN Penalty [1] [2] [3], Unvault Cancel in Revault
> [4], Refund Transaction in Discreet Log Contracts [5], Updates in
> eltoo [6]). In other words, a key security assumption of many
> contracting protocols is that all parties can propagate and confirm
> transactions in a timely manner.
>
> In the past few years, increasing attention [0][1][2][3][6] has been
> brought to **pinning attacks**, a type of censorship in which the
> attacker uses mempool policy restrictions to prevent a transaction
> from being relayed or getting mined. TLDR: revocation transactions
> must meet a certain confirmation target to be effective, but their
> feerates are negotiated well ahead of broadcast time. If the
> forecasted feerate was too low and no fee-bumping options are
> available, attackers can steal money from their counterparties. I walk
> through a concrete example for stealing Lightning HTLC outputs at
> ~23:58 in this talk [7][8]. Note that most attacks are only possible
> when the market for blockspace at broadcast time demands much higher
> feerates than originally anticipated at signing time. Always
> overestimating fees may sidestep this issue temporarily (while mempool
> traffic is low and predictable), but this solution is not foolproof
> and wastes users' money. The feerate market can change due to sudden
> spikes in traffic (e.g. huge 12sat/vB dump a few days ago [9]) or
> sustained, high volume of Bitcoin payments (e.g. April 2021 and
> December 2017).
>
> The best solution is to enable nodes to consider packages of
> transactions as a unit, e.g. one or more low-fee parent transactions
> with a high-fee child, instead of separately. A package-aware mempool
> policy can help determine if it would actually be economically
> rational to accept a transaction to the mempool if it doesn't meet fee
> requirements individually. Network-wide adoption of these policies
> would create a more purely-feerate-based market for block space and
> allow contracting protocols to adjust fees (and therefore mining
> priority) at broadcast time. Some support for packages has existed in
> Bitcoin Core for years. Since v0.13, Bitcoin Core has used ancestor
> packages instead of individual transactions to evaluate the incentive
> compatibility of transactions in the mempool [10] and select them for
> inclusion in blocks [11].
>
> Package Relay, the concept of {announcing, requesting, downloading}
> packages between nodes on the p2p network, has also been discussed for
> many years. The earliest public mention I can find is from 2015 [12].
> The two most common use cases for package relay are fee-bumping
> otherwise-too-low-fee transactions and reducing the amount of orphans.
> It seems uncontroversial to say that everybody desires package relay
> conceptually, with varying degrees of urgency. Lots of work has been
> done by others over the past few years, from which I've taken
> inspiration from [13][14][15][16].
>
> My approach has been to split the project into two components: (1) Package
> Mempool Accept, which includes validation logic and mempool policy.
> (3) Package Relay, which includes the p2p protocol changes.
>
> Progress so far:
> After discussions with various developers of contracting protocols
> (with heavier emphasis towards LN), it was determined that a
> package containing a child with all of its unconfirmed parents
> (child-with-unconfirmed-parents or 1-child-multi-parent package) would
> be sufficient for their use case, i.e. fee-bumping presigned
> transactions. A child-with-unconfirmed-parents package has several
> properties that make many things easier to reason about.
>
> A few months ago, I proposed a set of policies for safe package
> validation and fee assessment for packages of this restricted
> topology [17]. A series of PRs implementing this proposal have
> been merged into Bitcoin Core [18].
>
> Theoretically, developing a safe and incentive-compatible package
> mempool acceptance policy is sufficient to solve this issue. Nodes
> could opportunistically accept packages (e.g. by trying combinations
> of transactions rejected from their mempools), but this practice would
> likely be inefficient at best and open new Denial of Service attacks
> at worst. Additional p2p messages may enable nodes to request and
> share package validation-related information with one another in a
> more communication-efficient way.
>
> Given that only package RBF remains for package mempool accept, and we
> can make progress on p2p and mempool in parallel, I think it’s
> appropriate to put forward a package relay proposal.
>
> ==Proposal==
>
> This proposal contains 2 components: a “generic” package relay
> protocol and an extension of it, child-with-unconfirmed-parents
> packages, as version 1 package relay. Another version of packages,
> “tx-with-unconfirmed-ancestors” can be created to extend package relay
> for eliminating orphans.
>
> ===Generic Package Relay===
>
> Two main ideas are introduced:
>
> Download and validate packages of transactions together.
>
> Provide information to help peers decide whether to request and/or how
> to validate transactions which are part of a package.
>
> ====Intended Protocol Flow====
>
> Due to the asynchronous nature of a distributed transaction relay
> network, nodes may not receive all of the information needed to
> validate a transaction at once. For example, after a node completes
> Initial Block Download (IBD) and first starts participating in
> transaction relay with an empty mempool, it is common to receive
> orphans. In such scenarios where a node is aware that it is missing
> information, a ''receiver-initiated'' dialogue is appropriate:
>
> 1. Receiver requests package information.
>
> 2. The sender provides package information, including the wtxids of
> the transactions in the package and anything else that might be
> relevant (e.g. total fees and size).
>
> 3. The reciever uses the package information to decide how to request
> and validate the transactions.
>
> Sometimes, no matter what order transactions are received by a node,
> validating them individually is insufficient. When the sender is aware
> of additional information that the receiver needs to accept a package,
> a proactive ''sender-initiated'' dialogue should be enabled:
>
> 1. Sender announces they have package information pertaining to a
> transaction that might otherwise be undesired on its own.
>
> 2. The receiver requests package information.
>
> 3. The sender provides package information, including the wtxids of
> the transactions in the package and anything else that might be
> relevant (e.g. total fees and size).
>
> 4. The reciever uses the package information to decide how to request
> and validate the transactions.
>
> Package relay is negotiated between two peers during the version
> handshake. Package relay requires both peers to support wtxid-based
> relay because package transactions are referenced by their wtxid.
>
> ====New Messages====
>
> Three new protocol messages are added for use in any version of
> package relay. Additionally, each version of package relay must define
> its own inv type and "pckginfo" message version, referred to in this
> document as "MSG_PCKG" and "pckginfo" respectively. See
> BIP-v1-packages for a concrete example.
>
> =====sendpackages=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |version || uint32_t || 4 || Denotes a package version supported by the
> node.
> |-
> |max_count || uint32_t || 4 ||Specifies the maximum number of transactions
> per package this node is
> willing to accept.
> |-
> |max_weight || uint32_t || 4 ||Specifies the maximum total weight per
> package this node is willing
> to accept.
> |-
> |}
>
> 1. The "sendpackages" message has the structure defined above, with
> pchCommand == "sendpackages".
>
> 2. During version handshake, nodes should send a "sendpackages"
> message indicate they support package relay and may request
> packages.
>
> 3. The message should contain a version supported by the node. Nodes
> should send a "sendpackages" message for each version they support.
>
> 4. The "sendpackages" message MUST be sent before sending a "verack"
> message. If a "sendpackages" message is received afer "verack", the
> sender should be disconnected.
>
> 5. If 'fRelay==false' in a peer's version message, the node must not
> send "sendpackages" to them. If a "sendpackages" message is
> received by a peer after sending `fRelay==false` in their version
> message, the sender should be disconnected.
>
> 6.. Upon receipt of a "sendpackages" message with a version that is
> not supported, a node must treat the peer as if it never received the
> message.
>
> 7. If both peers send "wtxidrelay" and "sendpackages" with the same
> version, the peers should announce, request, and send package
> information to each other.
>
> =====getpckgtxns=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |txns_length||CompactSize||1 or 3 bytes|| The number of transactions
> requested.
> |-
> |txns||List of wtxids||txns_length * 32|| The wtxids of each transaction
> in the package.
> |}
>
> 1. The "getpckgtxns" message has the structure defined above, with
> pchCommand == "getpckgtxns".
>
> 2. A "getpckgtxns" message should be used to request all or some of
> the transactions previously announced in a "pckginfo" message,
> specified by witness transactiosome id.
>
> 3. Upon receipt of a "getpckgtxns" message, a node must respond with
> either a "pckgtxns" containing the requested transactions or a
> "notfound" message indicating one or more of the transactions is
> unavailable. This allows the receiver to avoid downloading and storing
> transactions that cannot be validated immediately.
>
> 4. A "getpckgtxns" message should only be sent if both peers agreed to
> send packages in the version handshake. If a "getpckgtxns" message
> is received from a peer with which package relay was not negotiated,
> the sender should be disconnected.
>
> =====pckgtxns=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |txns_length||CompactSize||1 or 3 bytes|| The number of transactions
> provided.
> |-
> |txns||List of transactions||variable|| The transactions in the package.
> |}
>
> 1. The "pckgtxns" message has the structure defined above, with
> pchCommand == "pckgtxns".
>
> 2. A "pckgtxns" message should contain the transaction data requested
> using "getpckgtxns".
>
> 3. A "pckgtxns" message should only be sent to a peer that requested
> the package using "getpckgtxns". If a node receives an unsolicited
> package, the sender should be disconnected.
>
> 4. A "pckgtxns" message should only be sent if both peers agreed to
> send packages in the version handshake. If a "pckgtxns" message is
> received from a peer with which package relay was not negotiated, the
> sender should be disconnected.
>
> ===Version 1 Packages: child-with-unconfirmed-parents===
>
> This extends package relay for packages consisting of one transaction
> and all of its unconfirmed parents,by defining version 1 packages, a
> pckginfo1 message, and a MSG_PCKG1 inv type. It enables the use case
> in which a child pays for its otherwise-too-low-fee parents and their
> mempool conflict(s).
>
> ====Intended Protocol Flow====
>
> When relaying a package of low-fee parent(s) and high-fee child, the
> sender and receiver do the following:
>
> 1. Sender announces they have a child-with-unconfirmed-parents package
> for a child that pays for otherwise-too-low-fee parent(s) using
> "inv(MSG_PCKG1)".
>
> 2. The receiver requests package information using
> "getdata(MSG_PCKG1)".
>
> 3. The sender provides package information using "pckginfo1",
> including the blockhash of the sender's best block, the wtxids of
> the transactions in the package, their total fees and total weight.
>
> 4. The reciever uses the package information to decide how to request
> the transactions. For example, if the receiver already has some of
> the transactions in their mempool, they only request the missing ones.
> They could also decide not to request the package at all based on the
> fee information provided.
>
> 5. Upon receiving a "pckgtxns", the receiver submits the transactions
> together as a package.
>
> ====New Messages====
>
> A new inv type, "MSG_PCKG1", and new protocol message, "PCKGINFO1",
> are added.
>
> =====pckginfo1=====
>
> {|
> | Field Name || Type || Size || Purpose
> |-
> |blockhash || uint256 || 32 || The chain tip at which this package is
> defined.
> |-
> |pckg_fee||CAmount||4|| The sum total fees paid by all transactions in the
> package.
> |-
> |pckg_weight||int64_t||8|| The sum total weight of all transactions in the
> package.
> |-
> |txns_length||CompactSize||1 or 3 bytes|| The number of transactions
> provided.
> |-
> |txns||List of wtxids||txns_length * 32|| The wtxids of each transaction
> in the package.
> |}
>
>
> 1. The "pckginfo1" message has the structure defined above, with
> pchCommand == "pckginfo1".
>
> 2. A "pckginfo1" message contains information about a version 1
> package (defined below), referenced by the wtxid of the transaction
> it pertains to and the current blockhash.
>
> 3. Upon receipt of a "pckginfo1" message, the node should decide if it
> wants to validate the package, request transaction data if
> necessary, etc.
>
> 4. Upon receipt of a malformed "pckginfo1" message or package that
> does not abide by the max_count, max_weight, or other rules
> specified by the version agreed upon in the initial negotiation, the
> sender should be disconnected. If a node receives a "pckginfo1"
> message for which the "pckg_fee" or "pckg_weight" do not reflect the
> true total fees and weight, respectively, or the transactions in the
> package, the message is malformed.
>
> 5. A node MUST NOT send a "pckginfo1" message that has not been
> requested by the recipient. Upon receipt of an unsolicited
> "pckginfo1", a node should disconnect the sender.
>
> 6. A "pckginfo1" message should only be sent if both peers agreed to
> send version 1 packages in the version handshake. If a "pckginfo1"
> message is received from a peer with which package relay was not
> negotiated, the sender should be disconnected.
>
> =====MSG_PCKG1=====
>
> 1. A new inv type (MSG_PCKG1 == 0x6) is added, for use in inv messages
> and getdata requests pertaining to version 1 packages.
>
> 2. As an inv type, it indicates that both transaction data and version
> 1 package information are available for the transaction. The
> transaction is referenced by its wtxid. As a getdata request type, it
> indicates that the sender wants package information for the
> transaction.
>
> 3. Upon receipt of a "getdata" request for "MSG_PCKG1", the node
> should respond with the version 1 package corresponding to the
> requested transaction and its current chain tip, or with NOTFOUND.
> The node should not assume that the sender is requesting the
> transaction data as well.
>
> ====Child With Parent Packages Rules====
>
> A child-with-unconfirmed-parents package sent between nodes must abide
> by the rules below, otherwise the package is malformed and the sender
> should be disconnected.
>
> A version 1 or ''child-with-unconfirmed-parents'' package can be
> defined for any transaction that spends unconfirmed inputs. The child
> can be thought of as the "representative" of the package. This package
> can be uniquely identified by the transaction's wtxid and the current
> chain tip block hash.
>
> A ''child-with-unconfirmed-parents'' package MUST be:
>
> 1. ''Sorted topologically.'' For every transaction t in the package,
> if any of t's parents are present in the package, the parent must
> appear somewhere in the list before t. In other words, the
> transactions must be sorted in ascending order of the number of
> ancestors present in the package.
>
> 2. ''Only 1 child with unconfirmed parents.'' The package must consist
> of one transaction and its unconfirmed parents. There must not be
> any other transactions in the package. Other dependency relationships
> may exist within the package (e.g. one parent may spend the output of
> another parent) provided that topological order is respected.
>
> 3. ''All unconfirmed parents.'' All of the child's unconfirmed parents
> must be present.
>
> 4. ''No conflicts.'' None of the transactions in the package may
> conflict with each other (i.e. spend the same prevout).
>
> 5. ''Total fees and weight.'' The 'total_fee' and 'total_weight'
> fields must accurately represent the sum total of all transactions'
> fees and weights as defined in BIP141, respectively.
>
> Not all of the child's parents must be present; the child transaction
> may also spend confirmed inputs. However, if the child has confirmed
> parents, they must not be in the package.
>
> While a child-with-unconfirmed-parents package is perhaps most
> relevant when the child has a higher feerate than its parents, this
> property is not required to construct a valid package.
>
> ====Clarifications====
>
> ''Q: Under what circumstances should a sender announce a
> child-with-unconfirmed-parents package?''
>
> A child-with-unconfirmed-parents package for a transaction should be
> announced when it meets the peer's fee filter but one or more of its
> parents don't; a "inv(MSG_PCKG1)" instead of "inv(WTX)" should be sent
> for the child. Each of the parents which meet the peer's fee filter
> should still be announced normally.
>
> ''Q: What if a new block arrives in between messages?''
>
> A child-with-unconfirmed-parents package is defined for a transaction
> based on the current chain state. As such, a new block extending the
> tip may decrease the number of transactions in the package (i.e. if
> any of the transaction's parents were included in the block). In a
> reorg, the number of transactions in the package may decrease or
> increase (i.e. if any of the transaction's parents were included in a
> block in the previous chain but not the new one).
>
> If the new block arrives before the "getdata" or "pckginfo1", nothing
> needs to change.
>
> If the new block arrives before "getpckgtxns" or before "pckgtxns",
> the receiver may need to re-request package information if the block
> contained a transaction in the package. If the block doesn't contain
> any transactions in the package, whether it extends the previous tip
> or causes a reorg, nothing needs to change.
>
> ''Q: Can "getpckgtxns" and "pckgtxns" messages contain only one
> transaction?''
>
> Yes.
>
> ===Further Protocol Extensions===
>
> When introducing a new type of package, assign it a version number "n"
> and use an additional "sendpackages" message during version handshake
> to negotiate support for it. An additional package information message
> "pckginfon" and inv type "MSG_PCKGn" should be defined for the type of
> package. However, "getpckgtxns" and "pckgtxns" do not need to be
> changed.
>
> Example proposal for tx-with-unconfirmed-ancestors package relay: [19]
>
> ===Compatibility===
>
> Older clients remain fully compatible and interoperable after this
> change. Clients implementing this protocol will only attempt to send
> and request packages if agreed upon during the version handshake.
>
> ===Package Erlay===
>
> Clients using BIP330 reconciliation-based transaction relay (Erlay)
> are able to use package relay without interference. In fact, a package
> of transactions may be announced using both Erlay and package relay.
> After reconciliation, if the initiator would have announced a
> transaction by wtxid but also has package information for it, they may
> send "inv(MSG_PCKG)" instead of "inv(WTX)".
>
> ===Rationale===
>
> ====P2P Message Design====
>
> These p2p messages are added for communication efficiency and, as
> such, one should measure alternative solutions based on the resources
> used to communicate (not necessarily trustworthy) information: We
> would like to minimize network bandwidth, avoid downloading a
> transaction more than once, avoid downloading transactions that are
> eventually rejected, and minimize storage allocated for
> not-yet-validated transactions.
>
> Consider these (plausible) scenarios in transaction relay:
>
> Alice (the "sender") is relaying transactions to Bob (the "receiver").
> Alice's mempool has a minimum feerate of 1sat/vB and Bob's has a
> minimum feerate of 3sat/vB. For simplicity, all transactions are
> 1600Wu in virtual size and 500 bytes in serialized size. Apart from
> the spending relationships specified, all other inputs are from
> confirmed UTXOs.
>
> 1. Package {A, B} where A pays 0 satoshis and B pays 8000 satoshis in
> fees.
>
> 2. Package {C, D} where C pays 0 satoshis and D pays 1200 satoshis in
> fees.
>
> 3. Package {E, F, G, H, J} that pays 4000, 8000, 0, 2000, and 4000
> satoshis in fees, respectively.
>
> ====Alternative Designs Considered====
>
> ''Package Information Only:'' Just having "pckginfo" gives enough
> information for the receiver to accept the package. Omit the
> "getpckgtxns" and "pckgtxns" messages. While this option is a good
> fallback if batched transaction download fails for some reason, it
> shouldn't be used as the default because it 'always' requires storage
> of unvalidated transactions.
>
> ''No Package Information Round:'' Instead of having a package
> information round, just use the child's wtxid to refer to the package
> and always send the entire package together. This would cause nodes to
> redownload duplicate transactions.
>
> I have also created a slidedeck exploring various alternative designs
> and some examples in which they fall flat [20]. Please feel free to
> suggest other alternatives.
>
> ====Versioning System====
>
> This protocol should be extensible to support multiple types of
> packages based on future desired use cases. Two "flavors" of
> versioning were considered:
>
> 1. When package mempool acceptance is upgraded to support more types
> of packages, increment the version number (similar to Erlay).
> During version handshake, peers negotiate which version of package
> relay they will use by each sending one "sendpackages" message.
>
> 2. When introducing another type of package, assign a version number
> to it and announce it as an additional supported version (similar
> to Compact Block Relay). During version handshake, peers send one
> "sendpackages" message for each version supported.
>
> The second option was favored because it allows different parameters
> for different versions. For example, it should be possible to support
> both "arbitrary topology but maximum 3-transaction" package as well as
> "child-with-unconfirmed-parents with default mempool ancestor limits"
> packages simultaneously.
>
> ==Acknowledgements==
>
> I hope to have made it abundantly clear that this proposal isn’t
> inventing the concept of package relay, and in fact builds upon years
> of work by many others, including Suhas Daftuar and Antoine Riard.
>
> Thank you to John Newbery and Martin Zumsande for input on the design.
>
> Thank you to Matt Corallo, Christian Decker, David Harding, Antoine
> Poinsot, Antoine Riard, Gregory Sanders, Chris Stewart, Bastien
> Teinturier, and others for input on the desired interface for
> contracting protocols.
>
> Looking forward to hearing your thoughts!
>
> Best,
> Gloria
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html
> [2]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
> [3]:
> https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
> [4]:
> https://github.com/revault/practical-revault/blob/master/transactions.md#cancel_tx
> [5]:
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#refund-transaction
> [6]: https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1
> [7]:
> https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/#lightning-attacks
> [8]: https://youtu.be/fbWSQvJjKFs?t=1438
> [9]:
> https://www.reddit.com/r/Bitcoin/comments/unew4e/looks_like_70_mvb_of_transactions_just_got_dumped/
> [10]: https://github.com/bitcoin/bitcoin/pull/7594
> [11]: https://github.com/bitcoin/bitcoin/pull/7600
> [12]: https://github.com/bitcoin/bitcoin/pull/6455#issuecomment-122716820
> [13]: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
> [14]: https://github.com/bitcoin/bitcoin/issues/14895
> [15]: https://github.com/bitcoin/bitcoin/pull/16401
> [16]: https://github.com/bitcoin/bitcoin/pull/19621
> [17]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
> [18]: https://github.com/users/glozow/projects/5/views/4?layout=board
> [19]: https://gist.github.com/glozow/9b321cd3ef6505135c763112033ff2a7
> [20]:
> https://docs.google.com/presentation/d/1B__KlZO1VzxJGx-0DYChlWawaEmGJ9EGApEzrHqZpQc/edit?usp=sharing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220517/06bd18af/attachment-0001.html>

📅 Original date posted:2017-04-05
📝 Original message:I'd appreciate the authors chiming in, but I read the PASDA differently:
1) If a transaction is mined with a certain bit set, it reserves 700 bytes
for that particular block.
2) In that space, 2 transactions may happen:
a) First, a transaction penalizing the "parent" transaction for fraud by
spending the funds immediately
b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
window
This means during systematic flooding of closing transactions by
Goldfinger, vigilant watchers of their channels can immediately punish the
fraud in the same block using (a), and if they are unable to, need to find
space within two weeks in (b).
This is really in the LN weeds however, so I'll refrain from evaluating the
efficacy of such a solution.
On Wed, Apr 5, 2017 at 10:05 AM, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Y'all,
>
> Thanks to luke-jr and jl2012 for publishing your analysis of the
> xblocks proposal. I'd like to also present some analysis but instead focus
> on the professed LN safety enhancing scheme in the proposal. It's a bit
> underspecified, so I've taken the liberty of extrapolating a bit to fill
> in the gaps to the point that I can analyze it.
>
> TLDR; The xblock proposal includes a sub-proposal for LN which is
> essentially a block-size decrease for each open channel within the network.
> This decrease reserves space in blocks to allow honest parties guaranteed
> space in the blocks to punish dishonest channel counter parties. As a
> result
> the block size is permanently decreased for each channel open. Some may
> consider this cost prohibitively high.
>
> >> If the second highest transaction version bit (30th bit) is set to to
> `1`
> >> within an extension block transaction, an extra 700-bytes is reserved on
> >> the transaction space used up in the block.
>
> > Why wouldn't users set this on all transactions?
>
> As the proposal stands now, it seems that users _are_ able to unilaterally
> use this for all their Bitcoin transactions, as there's no additional cost
> to using the smart-contract safety feature outlined in the proposal.
>
> The new safety measures proposed near the end of this xblock proposal
> could itself consume a dedicated document outlining the prior background,
> context, and implications of this new safety feature. Throughout the rest
> of this post, I'll be referring to the scheme as a Pre-Allocated
> Smart-contract Dispute arena (PASDA, chosen because it sounds kinda like
> "pasta", which brings me many keks). It's rather insufficiently described
> and
> under specified as it stands in the proposal. As a result, if one doesn't
> have the necessary prior context, it might've been skipped over entirely
> as it's difficult to extract the sub-proposal from the greater proposal. I
> think I possess the necessary prior context required to required to
> properly analyze the sub-proposal. As a result, I would like to illuminate
> the readers of the ML so y'all may also be able to evaluate this
> sub-proposal independently.
>
>
> ## Background
>
> First, some necessary background. Within LN as it exists today there is
> one particularly nasty systematic risk related to blockchain availability
> in the case of a channel dispute. This risk is clearly outlined in the
> original white paper, and in my opinion a satisfactory solution to the
> risks which safe guard the use of very high-value channels has yet to be
> presented.
>
>
> ### Chain Spam/Censorship Attack Vector
>
> The attack vector mentioned in the original paper is a reoccurring attack
> in systems of this nature: DoS attacks. As it stands today, if a channel
> counterparty is able to (solely, or in collaboration with other attackers)
> prevent one from committing a transaction to the chain, they're able to
> steal money from the honest participant in the channel. The attack
> proceeds something like this:
>
> * Mallory opens a very large channel with me.
> * We transfer money back and forth in the channel as normal. The nature
> of these transfers isn't very important. The commitment balances may
> be modified due to Mallory making multi-hop payments through my
> channel, or possibly from Mallory directly purchasing some goods I
> offer, paying via the channel.
> * Let's call the current commitment number state S_i. In the lifetime
> of the channel there may exist some state S_j (i < j) s.t Mallory's
> balance in S_i, is larger than S_j.
> * At this point, depending on the value of the channel's time-based
> security parameter (T) it may be possible for Mallory to broadcast
> state S_i (which has been revoked), and prevent me being able to
> include by my punishment transaction (PTX) within the blockchain.
> * If Mallory is able to incapacitate me for a period of time T, or
> censor my transactions from the chain (either selectively or via a
> spam attack), then at time K (K > T + B, where B is the time the
> commitment transaction was stamped in the chain), then she'll be free
> to walk away with her settled balance at state S_i. For the sake of
> simplicity, we're ignoring HTLC's.
> * Mallory's gain is the difference between the balance at state S_i and
> S_j. Deepening on the gap between the states, my settled balance at
> state S_i and the her balance delta, she may be able to fully recoup
> the funds she initially place in the channel.
>
>
> ### The Role of Channel Reserves as Partial Mitigation
>
> A minor mitigation to this attack that's purely commitment transaction
> policy is to mandate that Mallory's balance in the channel never dips
> below some reserve value R. Otherwise, if at state S_j, Mallory has a
> settled balance of 0 within he channel (all the money if on my side), then
> the attack outline above can under certain conditions be _costless_ from
> her PoV. Replicate this simultaneously across the network in a synchronized
> manner (possibly getting some help from your miner friends) and this
> becomes a bit of a problem (to say the least).
>
> Taking this a step further another mitigation that's been proposed is to
> also use the channel reserve to implement a _ceiling_ on the maximum size
> of _any_ in flight HTLC. Similar to the scheme above, this is meant to
> eliminate the possibility of a "costless" attack, as if channel throughput
> is artificially constrained, then the value of pending HTLC's isn't
> enticing enough to launch a channel breach attack.
>
>
> ### Analysis of Attack Feasibility/Difficulty
>
> The difficulty of the attack is dependant on the time-denominated security
> parameter T, and the adversaries ability to collude with miners. Purely
> spamming the chain given a very larger T value may be prohibitively
> expensive for the attacker and their profit from launching the attack
> would need to outweigh the cost in transaction fees and idle bitcoin
> required to launch the attack. Considering the case of colluding with
> miners, if mining is highly centralized (as it is now), then that may be a
> more attractive attack avenue. In a world of highly decentralized mining
> (let's say a lofty goal of no pool commanding > 5% of the hash power),
> then the attack is much more difficult.
>
> (as an aside schemes that involve transactions committing to the inputs
> they're spending and revealing them at a later date/block (committed
> transactions) may address the miner censorship attack vector)
>
> Depending one's target use of channels, the individuals they open channels
> with, the applications that run on top of the channels, the amount of
> coins within the channel, and the choice of the time parameter T, the
> attack outline above may or may not be an issue from your PoV. However,
> in order to realize LN's maximum potential of being able to enter a
> smart-contract with a complete stranger on the internet trustlessly,
> without fearing conditions that may lead to monetary losses, the attack
> vector should be mitigated if possible.
>
> In the words of The Architect of the Matrix (and referenced by Tadge at
> his "Level of LN" talk at Scaling Bitcoin Hong Kong: "There are levels of
> survival we are prepared to accept". There exist levels of LN and usage of
> channels, that may not consider this a dire issue.
>
> OK, with the necessary background and context laid out, I'll now analyze
> the solution proposed within the greater xblock proposal, making a brief
> detour to briefly described another proposed solution.
>
> ### Timestop
>
> A prior proposed solution to the failure scenario described above is
> what's known as "time stop". This was proposed by gmaxwell and was briefly
> touched upon in the original LN white paper. The mechanism of the
> time-denominated security parameter T in today's channel construction is
> enforced using OpCheckSequenceVerify. After broadcasting a commitment
> transaction, all outputs paying to the broadcaster of the commitment are
> encumbered with a relative time delay of T blocks, meaning they are unable
> to claim the funds until time T has elapsed. This time margin gives the
> honest party an opportunity to broadcast their punishment transaction
> iff, the broadcaster has broadcast a prior revoked state.
>
> The idea of time stomp is to introduce a special sequence-locks block
> height to the system. This block height would increase with each block
> along with the regular block height _unless_ the block reaches a certain
> sustained "high water mark". As an example, let's assume that when 3
> blocks in row are above 75% capacity, then the sequence-lock clock stops
> ticking.
>
> The effect of this change is to morph the security risk into simply a
> postponement of the judgment within the contract. With this, DoS attacks
> simply delay the (seemingly) inevitable punishment of the dishonest party
> within the contract.
>
> Aside from some informal discussions and the brief section within the
> original white paper, many details of this proposal are left
> underspecified. For example: how do miners signal to full nodes that the
> sequence-lock clock has stopped? What's the high water mark threshold? Can
> it go on indefinitely? Should this feature be opt-in?
>
> I think this proposal should be considered in tandem with the proposal
> within the xblock proposal as both have a few unanswered questions that
> need to be further explored.
>
> ## Pre-Allocated Smart-Contract Dispute Area (PASDA)
>
> Aight, now to the LN enhancing proposal that's buried within the
> greater xblock proposal. Introducing some new terminology, I've been
> calling this a: Pre-Allocated Smart-contract Dispute Arena or (PASDA) for
> short. In a nut shell, the key idea of the proposal is this: transactions
> that mark the commencement of a smart contract who's security depends on
> availability of block space for disputes are able to _pre allocate_ a
> section of the block that will _always_ be _reserved_ for dispute
> transactions. With this, contracts is _guaranteed_ space in blocks to
> handle disputes in the case that the contract breaks down. As an analogy:
> when you enter in a contract with a contractor to build your dream
> kitchen, you _also_ go to a court and reserve a 1-hour block in their
> scheduled to handle a dispute _just in case_ one arises. In the event of a
> peaceful resolution to the contract, the space is freed up.
>
> The description in the paper is a bit light on the details, so I'll say up
> front that I'm extrapolating w.r.t to some mechanisms of the construction.
> However, I've been involved in some private conversations where the idea
> was thrown around, so I think I have enough context to _maybe_ fill in
> some of the gaps in the proposal.
>
> I'll now restate the proposal. Smart contract transactions set a certain
> bit in their version number. This bit indicates that they wish to
> pre-allocate N bytes in _all_ further blocks _until_ the contract has been
> reserved. In the specific context of payment channels, this means that
> once a channel is open, until it has been closed, it _decreases_ the
> available block size for all other transactions. As this is a very
> aggressive proposal I think the authors took advantage of the new design
> space within xblocks to include something that may not be readily accepted
> as a modification to the rules of the main chain.
>
> The concrete parameters chosen in the proposal are: each channel opening
> transaction reserves 700-bytes within _each_ block in the chain until the
> transaction has been closed. This pre-allocation has the following
> constraint: a transaction can _only_ take advantage of this allocation iff
> it's spending the _first_ output of a smart-contract transaction (has a
> particular bit in the version set). This means that only dispute
> resolution transactions can utilize this space.
>
> The proposal references two allocations, which I've squinted very hard at
> for half a day in an attempt to parse the rules governing them, but so far
> I've been unable to glean any further details. From my squinting, I
> interpret that half of the allocation is reserved for spending the
> self-output of a transaction in the last 2016 blocks (two weeks) and the
> other half is dedicated to spending the first output of a commitment
> transaction in the _same_ block.
>
> I'm unsure as to why these allocations are separate, and why they aren't
> just combined into a single allocation.
>
> ### Modification to LN Today
>
> This change would require a slight modification to LN as it's currently
> defined today. ATM, we use BIP 69 in order the inputs and outputs of a
> transaction. This is helpful as it lets us just send of signatures for new
> states as both sides already know the order of the inputs and outputs.
> With PASDA, we'd now need to omit the to-self-output (the output in my
> commitment transaction paying to myself my settled balance) from this
> ordering and _always_ make it the first output (txid:0).
>
> The second change is that this proposal puts a ceiling on on the CSV value
> allowed by any channel. All CSV delays _must-weeks otherwise, they're
> unable to take advantage of the arena.
>
> ### Modifications to Bitcoin
>
> In order to implement this within Bitcoin, a third utxo set (regular
> block, xblock) must be maintained by all full nodes. Alternatively, this
> can just be a bit in the xblock utxo set. The implementation doesn't
> really matter. Before attempting to pack transactions into a block, the
> total allocation within the PASDA utxo-set must be summed up, and
> subtracted from the block size cap. Only transactions which validly spend
> from one of these UTXO's are able to take advantage of the new space in
> the block.
>
> ## Analysis of PASDA
>
> OK, now for some analysis. First, let's assume that transactions which
> create PASDA UTXO's aren't subject to any additional constraints. If so,
> then this means that _any_ transaction can freely create PASDA UTXO's and
> _decrease_ the block size for _all_ transactions until the UTXO has been
> spent. If my interpretation is correct, then this introduces a new attack
> vector which allows _anyone_ to nearly permanently decrease the block size
> for all-time with next to zero additional cost. If this is correct, then
> it seems that miners have _zero_ incentive to _ever_ include a transaction
> that creates a PASDA output in their blocks as it robs them of future
> revenue and decreases the available capacity in the system, possibly
> permanently proportionally to _each_ unspent PASDA output in the chain.
>
> Alternatively, let's say the transactions which create PASDA outputs
> _must_ pay a disproportionately high fee in order to pay up front for
> their consumption of the size within all future blocks. If so, then a
> question that arises is: How large a fee? If the fee is very large, then
> the utilization of the smart-contract battling arena is only reserved to
> very high valued channels who can afford very high fees. This may be
> acceptable as if you have a $5 channel, then are you really at risk at
> such a large scale attack on Bitcoin just to steal $5 from you? It's
> important to note that many attacks on LN's contract resolution
> capabilities are also a direct attack on Bitcoin. However, in a world of
> dynamic fees, then it may be the case that the fee paid 6 months ago is
> now a measly fee an no longer covers the costs to miners (and even the
> entire system...).
>
> Finally, here's something I thought of earlier today that possibly
> mitigates the downside from the PoV of the miners (everyone else must
> still accept the costs of a permanent block size decrease). Let's say that
> in order to create a PASDA output fees are paid as normal. However, for
> _each_ subsequent block, the participants of the contract _must_ pay a
> tribute to miners to account for their loss in revenue due to the
> reduction in block size. Essentially, all PASDA outputs must pay _rent_
> for their pre-allocated space. If rent isn't paid sufficiently and on-time,
> then the pre-allocate arena space is revoked by miners. There're a few
> ways to construct this payment, but I'll leave that to follow up work as I
> just want to shed some light on the PASDA and its implications.
>
> ## Conclusion
>
> I've attempted to fill in some gaps for y'all w.r.t exactly what the
> sub-proposal within the greater xblock proposal consists of and some
> possible implications. I'd like to note that I've taken the liberty of
> filling on some gaps within the sub-proposal as only a single section
> within the greater proposal has been allocated to it. PASDA itself could
> likely fill up an entirely distinct propsal by itself spanning several
> pages. To the authors of the proposal: if my interpretation is inaccurate
> please correct me as I'd also like to better understand the proposal. It's
> possible that everything I've said in this (now rather long) email is
> incorrect.
>
> If you've made it this far, thank you for taking the time out of your day
> to consider my thoughts. It's my hope that we can further analyze this
> sub-proposal in detail and discuss its construction as well as its
> implications on smart-contracts like payment channels on top of Bitcoin.
>
> PASDA purports to address one half of the systematic risks in LN by
> possibly eliminating the DoS vector attack against LN. However, the costs
> of PASDA are very high, and possibly prohibitively so. In my opinion, the
> second attack vector lies in the ability of miners to arbitrarily censor
> transactions spending a particular output. Fungibility enhancing
> techniques such as Committed Transactions may be a viable path forward to
> patch this attack vector.
>
> -- roasbeef
>
>
> On Tue, Apr 4, 2017 at 8:35 PM Johnson Lau via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I feel particularly disappointed that while this BIP is 80% similar to my
>> proposal made 2 months ago ( https://lists.linuxfoundation.
>> org/pipermail/bitcoin-dev/2017-January/013490.html ), Matt Corallo was
>> only the person replied me. Also, this BIP seems ignored the txid
>> malleability of the resolution tx, as my major technical critique of xblock
>> design.
>>
>> But anyway, here I’m only making comments on the design. As I said in my
>> earlier post, I consider this more as an academic topic than something
>> really ready for production use.
>>
>> > This specification defines a method of increasing bitcoin transaction
>> throughput without altering any existing consensus rules.
>>
>> Softforks by definition tighten consensus rules
>>
>> > There has been great debate regarding other ways of increasing
>> transaction throughput, with no proposed consensus-layer solutions that
>> have proven themselves to be particularly safe.
>>
>> so the authors don’t consider segwit as a consensus-layer solution to
>> increase transaction throughput, or not think segwit is safe? But logically
>> speaking if segwit is not safe, this BIP could only be worse. OTOH, segwit
>> also obviously increases tx throughput, although it may not be as much as
>> some people wish to have.
>>
>> > This specification refines many of Lau's ideas, and offers a much
>> simpler method of tackling the value transfer issue, which, in Lau's
>> proposal, was solved with consensus-layer UTXO selection.
>>
>> The 2013 one is outdated. As the authors are not quoting it, not sure if
>> they read my January proposal
>>
>> > extension block activation entails BIP141 activation.
>>
>> I think extension block in the proposed form actually breaks BIP141. It
>> may say it activates segregated witness as a general idea, but not a
>> specific proposal like BIP141
>>
>> > The merkle root is to be calculated as a merkle tree with all extension
>> block txids and wtxids as the leaves.
>>
>> It needs to be more specific here. How are they exactly arranged? I
>> suggest it uses a root of all txids, and a root of all wtxids, and combine
>> them as the commitment. The reason is to allow people to prune the witness
>> data, yet still able to serve the pruned tx to light wallets. If it makes
>> txid and wtxid as pairs, after witness pruning it still needs to store all
>> the wtxids or it can’t reconstruct the tree
>>
>> > Outputs signal to exit the extension block if the contained script is
>> either a minimally encoded P2PKH or P2SH script.
>>
>> This hits the biggest question I asked in my January post: do you want to
>> allow direct exit payment to legacy addresses? As a block reorg will almost
>> guarantee changing txid of the resolution tx, that will permanently
>> invalidate all the child txs based on the resolution tx. This is a
>> significant change to the current tx model. To fix this, you need to make
>> exit outputs unspendable for up to 100 blocks. Doing this, however, will
>> make legacy wallet users very confused as they do not anticipate funding
>> being locked up for a long period of time. So you can’t let the money sent
>> back to a legacy address directly, but sent to a new format address that
>> only recognized by new wallet, which understands the lock up requirement.
>> This way, however, introduces friction and some fungibility issues, and I’d
>> expect people using cross chain atomic swap to exchange bitcoin and xbitcoin
>>
>> To summarise, my questions are:
>> 1. Is it acceptable to have massive txid malleability and transaction
>> chain invalidation for every natural happening reorg? Yes: the current
>> spec is ok; No: next question (I’d say no)
>> 2. Is locking up exit outputs the best way to deal with the problem? (I
>> tried really hard to find a better solution but failed)
>> 3. How long the lock-up period should be? Answer could be anywhere from 1
>> to 100
>> 4. With a lock-up period, should it allow direct exit to legacy address?
>> (I think it’s ok if the lock-up is short, like 1-2 block. But is that safe
>> enough?)
>> 5. Due to the fungibility issues, it may need a new name for the tokens
>> in the ext-block
>>
>> > Verification of transactions within the extension block shall enforce
>> all currently deployed softforks, along with an extra BIP141-like ruleset.
>>
>> I suggest to only allow push-only and OP_RETURN scriptPubKey in xblock.
>> Especially, you don’t want to replicate the sighash bug to xblock. Also,
>> requires scriptSig to be always empty
>>
>> > This leaves room for 7 future soft-fork upgrades to relax DoS limits.
>>
>> Why 7? There are 16 unused witness program versions
>>
>> > Witness script hash v0 shall be worth the number of accurately counted
>> sigops in the redeem script, multiplied by a factor of 8.
>>
>> There is a flaw here: witness script with no sigop will be counted as 0
>> and have a lot free space
>>
>> > every 73 bytes in the serialized witness vector is worth 1 additional
>> point.
>>
>> so 72 bytes is 1 point or 0 point? Maybe it should just scale everything
>> up by 64 or 128, and make 1 witness byte = 1 point . So it won’t provide
>> any “free space” in the block.
>>
>> > Currently defined witness programs (v0) are each worth 8 points.
>> Unknown witness program outputs are worth 1 point. Any exiting output is
>> always worth 8 points.
>>
>> I’d suggest to have at least 16 points for each witness v0 output, so it
>> will make it always more expensive to create than spend UTXO. It may even
>> provide extra “discount” if a tx has more input than output. The overall
>> objective is to limit the UTXO growth. The ext block should be mainly for
>> making transactions, not store of value (I’ll explain later)
>>
>> > Dust Threshold
>>
>> In general I think it’s ok, but I’d suggest a higher threshold like 5000
>> satoshi. It may also combine the threshold with the output witness version,
>> so unknown version may have a lower or no threshold. Alternatively, it may
>> start with a high threshold and leave a backdoor softfork to reduce it.
>>
>> > Deactivation
>>
>> It is a double-edged sword. While it is good for us to be able to discard
>> an unused chain, it may create really bad user experience and people may
>> even lose money. For example, people may have opened Lightning channels and
>> they will find it not possible to close the channel. So you need to make
>> sure people are not making time-locked tx for years, and require people to
>> refresh their channel regularly. And have big red warning when the
>> deactivation SF is locked in. Generally, xblock with deactivation should
>> never be used as long-term storage of value.
>>
>> ————
>> some general comments:
>>
>> 1. This BIP in current form is not compatible with BIP141. Since most
>> nodes are already upgraded to BIP141, this BIP must not be activated unless
>> BIP141 failed to activate. However, if the community really endorse the
>> idea of ext block, I see no reason why we couldn’t activate BIP141 first
>> (which could be done in 2 weeks), then work together to make ext block
>> possible. Ext block is more complicated than segwit. If it took dozens of
>> developers a whole year to release segwit, I don’t see how ext block could
>> become ready for production with less time and efforts.
>>
>> 2. Another reason to make this BIP compatible with BIP141 is we also need
>> malleability fix in the main chain. As the xblock has a deactivation
>> mechanism, it can’t be used for longterm value storage.
>>
>> 3. I think the size and cost limit of the xblock should be lower at the
>> beginning, and increases as we find it works smoothly. It could be a
>> predefined growth curve like BIP103, or a backdoor softfork. With the
>> current design, it leaves a massive space for miners to fill up with non-tx
>> garbage. Also, I’d also like to see a complete SPV fraud-proof solution
>> before the size grows bigger.
>>
>>
>> > On 5 Apr 2017, at 02:03, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Recently there has been some discussion of an apparent work-in-progress
>> > extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor
>> Indutny,
>> > and Steven Pair. Since this hasn't been formally posted on the ML yet,
>> perhaps
>> > it is still in pre-draft stages and not quite ready for review, but in
>> light
>> > of public interest, I think it is appropriate to open it to discussion,
>> and
>> > toward this end, I have reviewed the current revision.
>> >
>> > For reference, the WIP proposal itself is here:
>> > https://github.com/tothemoon-org/extension-blocks
>> >
>> > ==Overall analysis & comparison==
>> >
>> > This is a relatively complicated proposal, creating a lot of additional
>> > technical debt and complexity in comparison to both BIP 141 and
>> hardforks. It
>> > offers no actual benefits beyond BIP 141 or hardforks, so seems
>> irrational to
>> > consider at face value. In fact, it fits much better the inaccurate
>> criticisms
>> > made by segwit detractors against BIP 141.
>> >
>> > That being said, this proposal is very interesting in construction and
>> is for
>> > the most part technically sound. While ill-fit to merely making blocks
>> larger,
>> > it may be an ideal fit for fundamentally different block designs such as
>> > Rootstock and MimbleWimble in absence of decentralised non-integrated
>> > sidechains (extension blocks are fundamentally sidechains tied into
>> Bitcoin
>> > directly).
>> >
>> > ==Fundamental problem==
>> >
>> > Extension blocks are a risk of creating two classes of "full nodes":
>> those
>> > which verify the full block (and are therefore truly full nodes), and
>> those
>> > which only verify the "base" block. However, because the extension is
>> > consensus-critical, the latter are in fact not full nodes at all, and
>> are left
>> > insecure like pseudo-SPV (not even real SPV) nodes. This technical
>> nature is
>> > of course true of a softfork as well, but softforks are intentionally
>> designed
>> > such that all nodes are capable of trivially upgrading, and there is no
>> > expectation for anyone to run with pre-softfork rules.
>> >
>> > In general, hardforks can provide the same benefits of an extension
>> block, but
>> > without the false expectation and pointless complexity.
>> >
>> > ==Other problems & questions==
>> >
>> >> These outpoints may not be spent inside the mempool (they must be
>> redeemed
>> > from the next resolution txid in reality).
>> >
>> > This breaks the ability to spend unconfirmed funds in the same block
>> (as is
>> > required for CPFP).
>> >
>> > The extension block's transaction count is not cryptographically
>> committed-to
>> > anywhere. (This is an outstanding bug in Bitcoin today, but impractical
>> to
>> > exploit in practice; however, exploiting it in an extension block may
>> not be
>> > as impractical, and it should be fixed given the opportunity.)
>> >
>> >> The merkle root is to be calculated as a merkle tree with all extension
>> > block txids and wtxids as the leaves.
>> >
>> > This needs to elaborate how the merkle tree is constructed. Are all the
>> txids
>> > followed by all the wtxids (tx hashes)? Are they alternated? Are txid
>> and
>> > wtxid trees built independently and merged at the tip?
>> >
>> >> Output script code aside from witness programs, p2pkh or p2sh is
>> considered
>> > invalid in extension blocks.
>> >
>> > Why? This prevents extblock users from sending to bare multisig or other
>> > various possible destinations. (While static address forms do not exist
>> for
>> > other types, they can all be used by the payment protocol.)
>> >
>> > Additionally, this forbids datacarrier (OP_RETURN), and forces spam to
>> create
>> > unprovably-unspendable UTXOs. Is that intentional?
>> >
>> >> The maximum extension size should be intentionally high.
>> >
>> > This has the same "attacks can do more damage than ordinary benefit"
>> issue as
>> > BIP141, but even more extreme since it is planned to be used for future
>> size
>> > increases.
>> >
>> >> Witness key hash v0 shall be worth 1 point, multiplied by a factor of
>> 8.
>> >
>> > What is a "point"? What does it mean multiplied by a factor of 8? Why
>> not just
>> > say "8 points"?
>> >
>> >> Witness script hash v0 shall be worth the number of accurately counted
>> > sigops in the redeem script, multiplied by a factor of 8.
>> >
>> > Please define "accurately counted" here. Is this using BIP16 static
>> counting,
>> > or accurately counting sigops during execution?
>> >
>> >> To reduce the chance of having redeem scripts which simply allow for
>> garbage
>> > data in the witness vector, every 73 bytes in the serialized witness
>> vector is
>> > worth 1 additional point.
>> >
>> > Is the size rounded up or down? If down, 72-byte scripts will carry 0
>> > points...)
>> >
>> > ==Trivial & process==
>> >
>> > BIPs must be in MediaWiki format, not Markdown. They should be
>> submitted for
>> > discussion to the bitcoin-dev mailing list, not social media and news.
>> >
>> >> Layer: Consensus (soft-fork)
>> >
>> > Extension blocks are more of a hard-fork IMO.
>> >
>> >> License: Public Domain
>> >
>> > BIPs may not be "public domain" due to non-recognition in some
>> jurisdictions.
>> > Can you agree on one or more of these?
>> > https://github.com/bitcoin/bips/blob/master/bip-0002.
>> mediawiki#Recommended_licenses
>> >
>> >> ## Abstract
>> >>
>> >> This specification defines a method of increasing bitcoin transaction
>> > throughput without altering any existing consensus rules.
>> >
>> > This is inaccurate. Even softforks alter consensus rules.
>> >
>> >> ## Motivation
>> >>
>> >> Bitcoin retargetting ensures that the time in between mined blocks
>> will be
>> > roughly 10 minutes. It is not possible to change this rule. There has
>> been
>> > great debate regarding other ways of increasing transaction throughput,
>> with
>> > no proposed consensus-layer solutions that have proven themselves to be
>> > particularly safe.
>> >
>> > Block time seems entirely unrelated to this spec. Motivation is unclear.
>> >
>> >> Extension blocks leverage several features of BIP141, BIP143, and
>> BIP144 for
>> > transaction opt-in, serialization, verification, and network services,
>> and as
>> > such, extension block activation entails BIP141 activation.
>> >
>> > As stated in the next paragraph, the rules in BIP 141 are fundamentally
>> > incompatible with this one, so saying BIP 141 is activated is
>> confusingly
>> > incorrect.
>> >
>> >> This specification should be considered an extension and modification
>> to
>> > these BIPs. Extension blocks are _not_ compatible with BIP141 in its
>> current
>> > form, and will require a few minor additional rules.
>> >
>> > Extension blocks should be compatible with BIP 141, there doesn’t
>> appear to be
>> > any justification for not making them compatible.
>> >
>> >> This specification prescribes a way of fooling non-upgraded nodes into
>> > believing the existing UTXO set is still behaving as they would expect.
>> >
>> > The UTXO set behaves fundamentally different to old nodes with this
>> proposal,
>> > albeit in a mostly compatible manner.
>> >
>> >> Note that canonical blocks containing entering outputs MUST contain an
>> > extension block commitment (all zeroes if nothing is present in the
>> extension
>> > block).
>> >
>> > Please explain why in Rationale.
>> >
>> >> Coinbase outputs MUST NOT contain witness programs, as they cannot be
>> > sweeped by the resolution transaction due to previously existing
>> consensus
>> > rules.
>> >
>> > Seems like an annoying technical debt. I wonder if it can be avoided.
>> >
>> >> The genesis resolution transaction MAY also include a 1-100 byte
>> pushdata in
>> > the first input script, allowing the miner of the genesis resolution to
>> add a
>> > special message. The pushdata MUST be castable to a true boolean.
>> >
>> > Why? Unlike the coinbase, this seems to create additional technical
>> debt with
>> > no apparent purpose. Better to just have a consensus rule every input
>> must be
>> > null.
>> >
>> >> The resolution transaction's version MUST be set to the uint32 max
>> (`2^32 -
>> > 1`).
>> >
>> > Transaction versions are signed, so I assume this is actually simply -1.
>> > (While signed transaction versions seemed silly to me, using it for
>> special
>> > cases like this actually makes sense.)
>> >
>> >> ### Exiting the extension block
>> >
>> > Should specify that spending such an exit must use the resolution txid,
>> not
>> > the extblock's txid.
>> >
>> >> On the policy layer, transaction fees may be calculated by transaction
>> cost
>> > as well as additional size/legacy-sigops added to the canonical block
>> due to
>> > entering or exiting outputs.
>> >
>> > BIPs should not specify policy at all. Perhaps prefix "For the
>> avoidance of
>> > doubt:" to be clear that miners may perform any fee logic they like.
>> >
>> >> Transactions within the extended transaction vector MAY include a
>> witness
>> > vector using BIP141 transaction serialization.
>> >
>> > Since extblock transactions are all required to be segwit, why wouldn't
>> this
>> > be mandatory?
>> >
>> >> - BIP141's nested P2SH feature is no longer available, and no longer a
>> > consensus rule.
>> >
>> > Note this makes adoption slower: wallets cannot use the extblock until
>> the
>> > economy has updated to support segwit-native addresses.
>> >
>> >> To reduce the chance of having redeem scripts which simply allow for
>> garbage
>> > data in the witness vector, every 73 bytes in the serialized witness
>> vector is
>> > worth 1 additional point.
>> >
>> > Please explain why 73 bytes in Rationale.
>> >
>> >> This leaves room for 7 future soft-fork upgrades to relax DoS limits.
>> >
>> > How so? Please explain.
>> >
>> >> A consensus dust threshold is now enforced within the extension block.
>> >
>> > Why?
>> >
>> >> If the second highest transaction version bit (30th bit) is set to to
>> `1`
>> > within an extension block transaction, an extra 700-bytes is reserved
>> on the
>> > transaction space used up in the block.
>> >
>> > Why wouldn't users set this on all transactions?
>> >
>> >> `default_witness_commitment` has been renamed to
>> > `default_extension_commitment` and includes the extension block
>> commitment
>> > script.
>> >
>> > `default_witness_commitment` was never part of the GBT spec. At least
>> describe
>> > what this new key is.
>> >
>> >> - Deployment name: `extblk` (appears as `!extblk` in GBT).
>> >
>> > Should be just `extblk` if backward compatibility is supported (and
>> `!extblk`
>> > when not).
>> >
>> >> The "deactivation" deployment's start time...
>> >
>> > What about timeout? None? To continue the extension block, must it be
>> > deactivated and reactivated in parallel?
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/7864e3c1/attachment-0001.html>