I (instagibbs) was asked to draft a statement, I feel this is a fair summation of the project's direction. I might be wrong
Bitcoin Core’s next release will, by default, relay and mine transactions whose
OP_RETURN outputs exceed 80 bytes and allow any number of these outputs.
The long-standing cap, originally a gentle signal that block space should be used
sparingly for non-payment proof of publication data, has outlived its utility.
Near-stateless, fully parallelizable validation of the Bitcoin blockchain with hints about which outputs remain unspent. All other inputs/outputs are efficiently crossed off inside a single hash aggregate that only reaches zero if validation was successful and the hints were correct.
15-minute talk summarizing the protocol
Validation is at the heart of Bitcoin. Any improvements in validation speed will have a direct impact on the scalability of the system, including everything that is built on top of it. For this reason improving validation performance may be one of the most important things we can do.
Utreexo accumulator is a collection of proper merkle trees. All the merkle trees have 2 children or none.
Below is an example of adding 7 leaves to the tree. You can run the code I used to generate this at https://go.dev/play/p/um5263SDk59
This is an accumulator with 1 leaf. It has 1 root, which is also a leaf.
Hi there,
I'm writing to propose a set of mempool policy changes to enable package validation (in preparation for package relay) in Bitcoin Core. These would not be consensus or P2P protocol changes. However, since mempool policy significantly affects transaction propagation, I believe this is relevant for the mailing list.
My proposal enables packages consisting of multiple parents and 1 child. If you develop software that relies on specific transaction relay assumptions and/or are interested in using package relay in the future, I'm very interested to hear your feedback on the utility or restrictiveness of these package policies for your use cases.
A draft implementation of this proposal can be found in [Bitcoin Core PR#22290][1].
The purpose of the mempool is to store the best candidates for inclusion in a block, i.e., the ones with the highest fees (including fee-bumped ones). Non-mining nodes use the mempool to make block validation faster and to aid transaction relay. If transaction relay and mempool logic are working well, all transactions paying reasonable fees should make it to miners, and all nodes with (even small) mempools should have the transactions that will be in the next blocks.
Currently, we limit the size of our mempool (default 300MB) and only validate transactions one at a time - this creates a limitation in a node's ability to determine which transactions have the highest fees, because a low fee transaction can have a high fee child.
Originally posted on bitcoin-dev.
This post describes a fully decentralized two-way peg sidechain design. Activating new sidechains requires a soft fork, hence the name softchains. The key aspect is that all softchains are validated by everyone via Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mechanism that only requires the validation of disputed blocks. This does increase the validation burden of mainchain full nodes, but only by a minimal amount (~100MB per chain per year). It's similar to [drivechains][0], but without the major downside of having to rely on miners, since all Bitcoin full node users can efficiently validate each sidechain.
Last year I posted the idea of [PoW FP to the Bitcoin mailing list][1] ([follow-up here][2]). The idea is that we can use the existence of a fork in Bitc
