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

On Sat, Apr 1, 2017 at 5:34 PM, Natanael wrote: > Den 1 apr. 2017 16:07 skrev "Jorge Timón" : > On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: >> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" >>

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

Bram Cohen, My apologies, I guess I glossed over your "The TXO bitfield" because by subject I thought it just had something to do with changing the txo's data structure. Yes what you are proposing with "The TXO bitfield" is pretty much exactly the same as the MMR data structure... EXCEPT yours

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

On Sat, Apr 1, 2017 at 6:58 PM, praxeology_guy < praxeology_...@protonmail.com> wrote: > Bram Cohen, > > In R: First its appropriate to explore all interesting ideas, and help > each other improve their ideas. Last, when there is a deadline that needs > to be met, we compare various options and

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

On Sat, Apr 1, 2017 at 6:10 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > With using the MMR data structure for txo commitments, its preferable that > wallets only keep information pertinent to their own spendable coins. In > previous communication we

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

Not sure if you are BFD or BF Trolling D, BFTD. But I will bite this time. Sorry I mistakenly forgot to change the subject back to "A Better MMR Definition" when I decided to send the email to the dev list instead of directly to Peter. So then you made such a reply without knowing context.

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

On 2017-02-17 11:28, Chris Belcher via bitcoin-dev wrote: I think this committed bloom filter idea is very good and much better than bip37, but for good privacy for when bitcoin is used often still requires certain behavior namely downloading blocks from many different peers with new tor

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

If a wallet is unaware of spends of its own coins (ie, transactions were made it can't have known about), there's probably bigger problems going on. You might enjoy the topic on this mailing list on committed bloom filters however, as this solves a similar issue without needing an ever-growing

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

Bitcoin nodes could also keep a spentness status list, where each bit in the spentness status list corresponds to whether a txo in the MMR is spent. This could make it so that disconnected wallets didn't have to guess the pruned relative spentness status when it reconnects to the network... and

Re: [bitcoin-dev] A Better MMR Definition

gmaxwell told me that most nodes would keep a full copy of the top of the MMR tree. Here I am exploring how this could be policy-ized to solve two problems: - MMR proofs change over time - How to coordinate nodes to get them to keep different portions of the MMR, so that everyone can prune most

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

That's a quoted general statement that is highly subjective, not a description of an attack. If you can't articulate a specific attack vector that we're defending against, such a defense has no value. On Apr 1, 2017 12:41 AM, "Eric Voskuil" wrote: -BEGIN PGP SIGNED

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

One interesting thing to do is to compare how much does it cost to maintain a bank check account and how much does it cost to run a full node. It seems that it is about 120USD/year in USA: http://m.huffpost.com/us/entry/6219730 A 4TB hard drive ~=115USD

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

Den 1 apr. 2017 16:07 skrev "Jorge Timón" : On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: > > > Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" > : > > Segwit replaces the 1 mb size limit with a weight

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

Den 1 apr. 2017 16:35 skrev "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 11:18 PM, Jared Lee Richardson wrote: >> If a typical personal computer cannot run a node there is no >> security. > > If you can't

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

> Remember that the "hashpower required to secure bitcoin" is determined > as a percentage of total Bitcoins transacted on-chain in each block Can you explain this statement a little better? What do you mean by that? What does the total bitcoins transacted have to do with hashpower required?

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

> If a typical personal computer cannot run a node > there is no security. If you can't describe an attack that is made possible when typical personal computers can't run nodes, this kind of logic has no place in this discussion. On Fri, Mar 31, 2017 at 4:13 PM, Eric Voskuil via bitcoin-dev

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

> So your cluster isn't going to need to plan to handle 15k transactions per > second, you're really looking at more like 200k or even 500k transactions per > second to handle peak-volumes. And if it can't, you're still going to see > full blocks. When I first began to enter the blocksize

Re: [bitcoin-dev] A Better MMR Definition

Peter Todd, This MMR structure looks good to me. I really like how wallets keep their MMR proof and txo index instead of requiring the entire network to maintain an index on txids w/ plain old utxo snapshots. Re: "only left or right child of inner node be a fully spent node"... that sounds

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 11:18 PM, Jared Lee Richardson wrote: >> If a typical personal computer cannot run a node there is no >> security. > > If you can't describe an attack that is made possible when typical > personal computers can't run nodes, this kind

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

On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: > > > Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" > : > > Segwit replaces the 1 mb size limit with a weight limit of 4 mb. > > > That would make it a hardfork, not a

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

Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: -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

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

Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Segwit replaces the 1 mb size limit with a weight limit of 4 mb. That would make it a hardfork, not a softfork, if done exactly as you say. Segwit only separates out signature data. The 1 MB

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

Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone MAX_BLOCK2_BASE_SIZE. Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4 mb weight to 8 mb weight. I would also use the hardfork bit (sign

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

Some people have asked me for the current implementation of this patch to review. I remind you that the current patch does not implement the hard-fork signaling, as requested by Matt. The Segwit2Mb patch can be found here: https://github.com/SergioDemianLerner/bitcoin/commits/master For now, the