Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Even if the proposal involves a political compromise, any change to the code must be technically evaluated. The patch was made to require the least possible time for auditing. I'm talking about reviewing 120 lines of code (not counting comments or space) which 30 of them are changes to constants.

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

A compromise for the sake of compromise doesn't merit technical discussions. There are no benefits to be gained from a 2MB hard-fork at this time and it would impose an unnecessary cost to the ecosystem for testing and implementation. On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

I didn't say typical, I said every. Currently a raspberry pi on shitty adsl can run a full node. What's wrong with needing a high end pc and good connectivity to run a full node? People that want to, can. People that don't want to, won't, no matter how low spec the machine you need. If nobody

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote: > If the obsession with every personal computer being able to run a > fill node continues then bitcoin will be consigned to the dustbin > of history, The cause of the block size debate is

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo wrote: > Hey Sergio, > > You appear to have ignored the last two years of Bitcoin hardfork > research and understanding, recycling instead BIP 102 from 2015. There > are many proposals which have pushed the state of hard

[bitcoin-dev] The TXO bitfield

Looking forward in node scaling we can envision a future in which blocks are required to come with proofs of their validity and nodes can be run entirely in memory and never have to hit disk. Ideally we'd like for proofs to be able to be stored in client wallets which plan to spend their utxos

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Praxelogy_guy, Yes I understand that segwit2mb represents a "potential" 4Mb block size increase. But Segwit does not immediately lead to 2 Mb blocks, but can only achieve close to a 2Mb increase if all Bitcoin wallets switch to segwit, which will take a couple of years. Therefore I don't expect

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Sergio Demian Lerner: Please confirm that you understand that: The current SegWit being proposed comes bundled with an effective 2MB block size increase. Are you proposing the remove this bundled policy change, and then have a different BIP that increases the block size? Not quite clear if you

Re: [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal

> That would have the unfortunate effect of incentivizing miners to not > completely fill blocks, because low fee marginal transactions could cost them > money. Look at the fee distribution. The vast majority of fee income comes from txs w/ fees near the LIFB. The blocks will be full... but I

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

You guessed wrong. Multiple data centres are as much about redundancy and resiliency, and latency. As for the cost, data centre space, business grade communication lines, and staff are orders of magnitude more expensive than the physical hardware they support. I'd like to call you out on your

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hey Sergio, You appear to have ignored the last two years of Bitcoin hardfork research and understanding, recycling instead BIP 102 from 2015. There are many proposals which have pushed the state of hard fork research much further since then, and you may wish to read some of the posts on this

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hey Sergio, You appear to have ignored the last two years of Bitcoin hardfork research and understanding, recycling instead BIP 102 from 2015. There are many proposals which have pushed the state of hard fork research much further since then, and you may wish to read some of the posts on this

[bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hi everyone, Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to untangle the current conflict between different political positions regarding segwit activation vs. an increase of the on-chain blockchain space through a standard block size increase. It is not a new

Re: [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal

On Fri, Mar 31, 2017 at 1:29 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Change the fee policy to cause all fee/byte in a block to be reduced to > the lowest included fee/byte. Change transactions to specify how/which > outputs get what portions of

[bitcoin-dev] Refund Excesss Fee Hard Fork Proposal

TL;DR (In layman terms): Refund any excess fee amounts higher than the lowest included fee in a block. === Proposed Hard Fork Change === LIFB: Lowest Included Fee/Byte Change the fee policy to cause all fee/byte in a block to be reduced to the lowest included fee/byte. Change transactions to

Re: [bitcoin-dev] A Better MMR Definition

On Wed, Mar 1, 2017 at 2:31 PM, Peter Todd wrote: > > A better way to present your work would have been to at least explain that > at > the top of the file, and perhaps even better, split the reference > implementation and optimized implementation into two separate files. If

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

As an independently verifiable, decentralized store of public information, the Bitcoin block tree and transaction DAG do have an advantage over systems such as Visa. The store is just a cache. There is no need to implement reliability in storage or in communications. It is sufficient to be able

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Sure, your math is pretty much entirely irrelevant because scaling systems to massive sizes doesn't work that way. At 400B transactions per year we're looking at block sizes of 4.5 GB, and a database size of petabytes. How much RAM do you need to process blocks like that? Can you fit that much

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

I guess I should caveat, a rounding error is a bit of exaggeration - mostly because I previously assumed that it would take 14 years for the network to reach such a level, something I didn't say and that you might not grant me. I don't know why paypal has multiple datacenters, but I'm guessing it

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> Peter Todd has demonstrated this on mainstream SPV wallets, > https://www.linkedin.com/pulse/peter-todds-fraud-proofs-talk-mit-bitcoin-expo-2016-mark-morris Correct me if I'm wrong, but nothing possible if the client software was electrum-like and used two independent sources for verification.

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

No one is suggesting anything like this. The cost of running a node that could handle 300% of the 2015 worldwide nonbitcoin transaction volume today would be a rounding error for most exchanges even if prices didn't rise. Then explain why PayPal has multiple datacenters. And why Visa has

[bitcoin-dev] Proposing the SiTAH-fork, a mechanism for compromise.

Soft-fork - A soft-fork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a soft-fork is backward-compatible. Hard-fork - A hard-fork is a change to the bitcoin protocol that makes

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> Err, no, that's what happens when you double click the Ethereum icon instead of the Bitcoin icon. Just because you run "Bitcoin SPV" instead of "Bitcoin Verify Everyone's Else's Crap" doesn't mean you're somehow going to get Ethereum payments. Your verification is just different and the risks

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> Node operation is making a stand on what money you will accept. > Ie Your local store will only accept US Dollars and not Japanese Yen. Without > being able to run a node, you have no way to independently determine what you > are receiving, you could be paid Zimbawe Dollars and wouldn't know