[bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals

In an attempt to reduce developer centralization, and to reduce the risk of forks introduced by implementation other than bitcoin-core, I have drafted a BIP to support changes to the protocol from different implementations. The BIP can be found at:

Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals

> The specification itself looks like an inefficient and bloaty reinvention > of > version bits. The actual assignment of version bits isn't clear from the specification. Are you saying that any implementation that wants to propose a change is encouraged to pick a free version bit and use it?

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Thank you Marcos, Though written in Rust, bitcrust-db is definitely usable as pluggable module as its interface will be roughly some queries, add_tx and add_block with blobs and flags. (Bitcrust internally uses a deserialize-only model, keeping references to the blobs with the parsed data).

Re: [bitcoin-dev] Using a storage engine without UTXO-index

> I don’t fully understand your storage engine. So the following deduction > is just based on common sense. > > a) It is possible to make unlimited number of 1-in-100-out txs > > b) The maximum number of 100-in-1-out txs is limited by the number of > previous 1-in-100-out txs > > c) Since

Re: [bitcoin-dev] Using a storage engine without UTXO-index

> Please no conspiracy theory like stepping on someone’s toes. I believe > it’s always nice to challenge the established model. However, as I’m > trying to make some hardfork design, I intend to have a stricter UTXO > growth limit. As you said "protocol addressing the UTXO growth, might not > be

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Sat, Apr 8, 2017, at 20:27, Tom Harding via bitcoin-dev wrote: > > > On Apr 7, 2017 12:42, "Gregory Maxwell" wrote: >> On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev >> wrote: >> > A network in which many nodes

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Sun, Apr 9, 2017, at 00:12, Gregory Maxwell wrote: > In Bitcoin Core the software _explicitly_ and intentionally does not > exploit mempool pre-validation because doing that very easily leads to > hard to detect consensus faults and makes all mempool code consensus > critical when it

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Thank you for your elaborate response Eric, On Sun, Apr 9, 2017, at 00:37, Eric Voskuil wrote: > My point was that "Using a storage engine without UTXO-index" has been > done, and may be a useful reference, not that implementation details > are the same. I haven't dived into libbitcoin V2/V3

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Tue, Apr 11, 2017, at 03:44, Eric Voskuil wrote: > As I understand it you would split tx inputs and outputs and send them > independently, and that you intend this to be a P2P network > optimization - not a consensus rule change. So my comments are based > on those inferences. If we are

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote: > It's not the headers/tx-hashes of the blocks that I'm referring to, it > is the confirmation and spend information relative to all txs and all > outputs for each branch. This reverse navigation (i.e. utxo > information) is essential, must be

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Sat, Apr 8, 2017, at 02:44, Gregory Maxwell wrote: > As you note that the output costs still bound the resource > requirements. Resource cost is not just a measure of storage requirement; data that needs to be accessed during peak load induce more cost then data only used during base load or

Re: [bitcoin-dev] Using a storage engine without UTXO-index

SAGE----- > Hash: SHA256 > > On 04/06/2017 03:12 PM, Tomas via bitcoin-dev wrote: > > Hi Tomas, > > > I have been working on a bitcoin implementation that uses a > > different approach to indexing for verifying the order of > > transactions. Instead of using

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017, at 02:32, Gregory Maxwell wrote: > Perhaps a simple question would help: > > What is the minimal amount of space your system requires to take a new > block received from the P2P network and verifying that all its spends > were valid spends of existing coins unspent coins

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote: > > How do you deal with validity rules changing based on block height? I expected that one :). Just like the 100 blocks coinbase rule, changes by softforks need to be added as metadata to the transaction-index, but this is not yet in

Re: [bitcoin-dev] Using a storage engine without UTXO-index

also see comparisons with 0.14 which has some > improvements for script validation with more cores. > > On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev d...@lists.linuxfoundation.org> wrote: >> Thank you Marcos, >> >> Though written in Rust, bitcrust-

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Hi Eric, On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote: > Optimization for lower memory platforms then becomes a process of > reducing the need for paging. This is the purpose of a cache. The seam > between disk and memory can be filled quite nicely by a small amount > of

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Answering both, On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev wrote: >> >> I'm still lost on this-- AFAICT your proposals long term resource >> requirements are directly proportional to the amount of >> unspent output >> data, which

[bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold

I have a proposal that would allow each user to optionally configure the maximum block weight at a support threshold. It recognizes that there is no need for off chain bickering, by providing a mechanism that lets each users freely choose their own parameters while still maintaining full

Re: [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold

he user agent signalling isn't very important, and I think that most of us aware that you cannot rely on counting them. > > On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" d...@lists.linuxfoundation.org> wrote:>> I have a proposal that would allow > each user to

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote:> Hi y'all, > > Alex Akselrod and I would like to propose a new light client BIP for > consideration: >* https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki> > Very interesting. I would like to

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

On Fri, Jun 9, 2017, at 05:50, Olaoluwa Osuntokun wrote: > Tomas wrote: > > I don't completely understand the benefit of making the outpoints and > > pubkey hashes (weakly) verifiable. These only serve as notifications and > > therefore do not seem to introduce an attack vector. > > Not sure

[bitcoin-dev] Fraud Proofs with semi SPV

I would like some feedback on the idea to use a node type a bit heavier then SPV (dubbed FSPV) to solve Fraud Proofs. An FSPV node not only downloads block headers, but also the "spend-tree blocks", consisting of all TXIDs and all previous output indices and TXIDs. The latter can be compacted

[bitcoin-dev] Non-confirming block signalling

I propose a method to mark blocks to indicate that they were generated without verifying the previous block. This can be done by using a bit of the version field. This would counter the reduction of security caused by what is known as "SPV-mining". The BIP is here:

Re: [bitcoin-dev] Non-confirming block signalling

Sorry, I wasn't aware. This is indeed the same proposal. On Fri, May 5, 2017, at 15:01, Bryan Bishop wrote: > On Fri, May 5, 2017 at 6:24 AM, Tomas via bitcoin-dev d...@lists.linuxfoundation.org> wrote:>> I propose a method to mark blocks to > indicate that they were >>

Re: [bitcoin-dev] Full node "tip" function

The ones that *could* pay non-mining full nodes are miners/pools, by outsourcing transaction selection using a different PoW. By doing so they could buy proof-of-uncensored-selection and proof-of-goodwill for a small fee. We would allow full nodes to generate and broadcast a template block which:

Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote: > The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment > qr > codes don't cryptographically commit to the identity of the merchant, > which > means a MITM attacker can redirect the payment if they can obtain a

[bitcoin-dev] Partial UTXO tree as commitment

I would like to propose an efficient UTXO commitment scheme. A UTXO commitment can be useful for: 1. Fast syncing a full node, by downloading the UTXO-set 2. Proofing (non) existence of a UTXO.. Various schemes have been proposed: * Merkle/radix trees and variants; all of which have the