[bitcoin-dev] BIP process friction
Hi all, Just under three years ago there was some discussion about the BIPs repo, with the result that Kalle became a BIPs editor in addition to Luke, eg: * https://gnusha.org/bitcoin-core-dev/2021-04-22.log * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html It remains, however, quite hard to get BIPs merged into the repo, eg the following PRs have been open for quite some time: * #1408: Ordinal Numbers; opened 2023-01-21, editors comments: Kalle: https://github.com/bitcoin/bips/pull/1408#issuecomment-1421641390 https://github.com/bitcoin/bips/pull/1408#issuecomment-1435389476 Luke: https://github.com/bitcoin/bips/pull/1408#issuecomment-1429146796 https://github.com/bitcoin/bips/pull/1408#issuecomment-1438831607 https://github.com/bitcoin/bips/pull/1408#issuecomment-1465016571 * #1489: Taproot Assets Protocol; opened 2023-09-07, editors comments: Kalle: https://github.com/bitcoin/bips/pull/1489#issuecomment-1855079626 Luke: https://github.com/bitcoin/bips/pull/1489#issuecomment-1869721535j * #1500: OP_TXHASH; opened 2023-09-30, editors comments: Luke: https://github.com/bitcoin/bips/pull/1500#pullrequestreview-1796550166 https://twitter.com/LukeDashjr/status/1735701932520382839 The range of acceptable BIPs seems to also be becoming more limited, such that mempool/relay policy is out of scope: * https://github.com/bitcoin/bips/pull/1524#issuecomment-1869734387 Despite having two editors, only Luke seems to be able to assign new numbers to BIPs, eg: * https://github.com/bitcoin/bips/pull/1458#issuecomment-1597917780 There's also been some not very productive delays due to the editors wanting backwards compatibility sections even if authors don't think that's necessary, eg: * https://github.com/bitcoin/bips/pull/1372#issuecomment-1439132867 Even working out whether to go back to allowing markdown as a text format is a multi-month slog due to process confusion: * https://github.com/bitcoin/bips/pull/1504 Anyway, while it's not totally dysfunctional, it's very high friction. There are a variety of recent proposals that have PRs open against inquisition; up until now I've been suggesting people write a BIP, and have been keying off the BIP number to signal activation. But that just seems to be introducing friction, when all I need is a way of linking an arbitrary number to a spec. So I'm switching inquisition over to having a dedicated "IANA"-ish thing that's independent of BIP process nonsense. It's at: * https://github.com/bitcoin-inquisition/binana If people want to use it for bitcoin-related proposals that don't have anything to do with inquisition, that's fine; I'm intending to apply the policies I think the BIPs repo should be using, so feel free to open a PR, even if you already know I think your idea is BS on its merits. If someone wants to write an automatic-merge-bot for me, that'd also be great. If someone wants to reform the BIPs repo itself so it works better, that'd be even better, but I'm not volunteering for that fight. Cheers, aj (It's called "numbers and names" primarily because that way the acronym amuses me, but also in case inquisition eventually needs an authoritative dictionary for what "cat" or "txhash" or similar terms refer to) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Sun, Jan 14, 2024 at 10:21 AM Greg Tonoski via bitcoin-dev wrote: > > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > irrespectively of location inside or outside of witness), e.g. 205/205 > > and 767/767 bytes in the examples above. > > > > "Should" ... to what end? > > "Should" in order to avoid hazard of centralization. A single bidder > who takes advantage of "buy 1 get 3 megabytes free" may outcompete a > number of individuals whose simple transactions recieve > anti-preferential treatment - "buy 1 get 0.33 megabytes free" in > aggregate. There is the illustration at: > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf";. It is not sufficient to be a centralized sender to utilize this advanage. The sender has to store data in the blockchain which itself is not the best utilization of money, even given the discount. Also what is the danger of centralization of such senders? The dangerous centralization is the centralization of real bitcoin sending, which has already happened - exchanges utilize batch transaction sending, saving on fees over a regular bitcoin sender, because they avoid change creation. This has nothing to do with witness discount, though. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BitBlend Proposal for 2106
Dear Bitcoin Development Community, I am reaching out to share a solution I have developed to address the anticipated 2106 overflow issue. After a significant development period, I believe the solution is ready for a community review. Below, you will find an abstract summarizing the key aspects of this proposal, which is titled "BitBlend:A Non-Disruptive Solution to the Bitcoin 2106 Timestamp Overflow.” The abstract aims to provide a concise overview of the solution's approach and objectives. For a more detailed understanding, I have also included a link to the full white paper hosted on GitHub. Abstract: The Bitcoin network faces a significant technical challenge as it approaches the year 2106, when the 32-bit field for block timestamps will reach its maximum value. This paper introduces "BitBlend," a solution designed to address this impending overflow without necessitating a coordinated hard fork or consensus change. Similar to the idea by Pieter Wuille [2], BitBlend proposes a novel reinterpretation of the existing 32-bit time field, extending its functionality by representing only the last 32 bits of the full timestamp. The solution incorporates an innovative overflow detection and correction method, named the BitBlend procedure, which seamlessly integrates into the current system. Key to BitBlend is maintaining the original 32-bit format for external communication while employing a 64-bit internal representation for block times. This dual approach ensures backward compatibility and network continuity, allowing nodes to gradually adopt the update without synchronization. Additionally, BitBlend addresses the implications for time locks, advocating for the natural expiration of absolute time locks post-2106 and the continued use of block height and relative time locks. This solution prioritizes minimal alterations to Bitcoin's core components, striving to preserve its foundational principles while ensuring its longevity and functionality. The paper seeks feedback from the Bitcoin development community on the feasibility and potential integration of the BitBlend solution into the Bitcoin protocol. Link to Full White Paper: https://bitblend2106.github.io/bitcoin/BitBlend2106.pdf I would greatly appreciate any thoughtful reviews, comments, or suggestions you may have regarding the BitBlend solution. My user name is BitcoinBitBlend on proton mail. Thank you for your time and consideration. I look forward to your valuable input.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Sat, Jan 13, 2024 at 12:03 PM Greg Tonoski wrote: > > On Wed, Dec 27, 2023 at 8:06 PM Nagaev Boris wrote: > > > > On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev > > wrote: > > > As a result, there are incentives structure distorted and critical > > > inefficiencies/vulnerabilities (e.g. misallocation of block space, > > > blockspace value destruction, disincentivized simple transaction, > > > centralization around complex transactions originators). > > > > > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > > irrespectively of location inside or outside of witness), e.g. 205/205 > > > and 767/767 bytes in the examples above. > > > > Witness data does not contribute to utxo set. The discount on storing > > data in witness creates an incentive to store data exactly in the > > witness and not in the parts contributing to utxo set. > > > > $ du -sh blocks/ chainstate/ > > 569Gblocks/ > > 9.3Gchainstate/ > > > > Witness data is part of the "blocks" directory which is not > > latency-critical and can be stored on a slow and cheap storage device. > > Directory "chainstate" contains the data needed to validate new > > transactions and should fit into a fast storage device otherwise > > initial block download takes weeks. It is important to maintain the > > incentives structure, resulting in a small chainstate. > > I think that the argument "discount on storing data in witness creates > an incentive to store data exactly in the witness (...)" is > fallacious. The "witness discount" does not affect the cost of data > storage in a Bitcoin node. What the "witness discount" affects is the > priority of a transaction pending confirmation only. For example, a > SegWit type of transaction of size of 1MB is prioritized (by miners) > over a non-SegWit transaction of the same size and fee. "Segwit > discount" benefits bloated transactions and puts simple transactions > at disadvantage (demonstrated at > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/comparison-of-costs.html"; > and > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf";). > > The Bitcoin fee is not charged per UTXO set size. It is not charged > from a node operator. Nodes are up and running independently of > Bitcoin fees. > > Any relation between UTXO set size and discount would be artificial > and inefficient, wouldn't it? Node operators are likely to put UTXO set to SSD and blocks to HDD. SSD is more expensive than HDD. It is aligned with the fact that people putting data into blockchain are financially motivated to put it into witness data, i.e. into HDD. If miners charge the same per 1 byte in a transaction output and 1 byte in witness, then people putting data into blockchain could put it into transaction outputs (why not, if the price is the same), inflating the UTXO set and making node operators buy bigger SSD (more costs for node operators). As a node operator, I prefer the current structure. -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Compressed Bitcoin Transactions
Hi, In addition to the use cases listed in the schema, such as steganography, satellite, and radio broadcast, an application can be made for Peer-to-peer communication between Bitcoin nodes. Except when compressing the Txid/Vout, which is optional, Transactions can gain up to 30% size savings while still being completely reversible. Furthermore, in a BIP-324 world, these savings are nontrivial. BIP-324: https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki Compressed Transaction Schema: compressed_transactions.md Thanks- Tom. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Wed, Dec 27, 2023 at 10:43 PM wrote: > > I think it should be fixed. Because now, sending coins into P2WPKH is cheaper > than sending them to P2TR, even though finally, when those coins are spent, > the blockspace usage is cheaper for Taproot (when you spend by key) than for > Segwit, because public key hash is not stored anywhere. But of course, > because the cost is splitted between sender and spender, it is more > profitable to send to P2WPKH, and spend from P2TR. The difference between P2WPKH and P2TR is a different topic, I think. A single bloated transaction would be treated with higher priority than a number of simple transactions of the same total size and fee - irrespectively of P2WPKH and P2TR type. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs
On Mon, Jan 15, 2024 at 4:28 PM Ava Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've also made a change to the PSBT fields BIP where the aggregate > pubkey is included as a plain pubkey rather than as xonly. I think this > change is necessary for to make discovering derived keys easier. The > derivation paths for derived keys contain the fingerprint of the parent > (i.e. the aggregate pubkey) and the fingerprint requires the evenness > bit to be serialized. So the aggregate pubkey in the PSBT fields need to > contain that evenness information in order for something looking at only > the PSBT to be able to determine whether a key is derived from an > aggregate pubkey also specified in the PSBT. > The topic of some challenges in using x-only pubkeys with FROST recently came up in a conversation that I didn't completely understand. It sounds like it may be related to this issue with MuSig2. What are the gotcha's in x-only keys with these multisig protocols? Can you explain a little more? Any other particular things do we need to be careful about with x-only pubkeys? I had mistakenly assumed the technique was just a useful trick, not that it might cause some problems in higher level protocols. Thanks! -- Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
