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"
>> :
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>> That would make
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
On Sat, Apr 1, 2017 at 6:58 PM, praxeology_guy <
praxeology_...@protonmail.com> wrote:
> Bram Cohen,
>
> In R&D: 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
Bram Cohen,
In R&D: 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 decide on which to go with.
I'm on the First step still.
If you really want to push me to say
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 talk
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.
With
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 circuits
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 lis
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
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
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 MESSAGE-
Hash: SHA256
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
https://www.amazon.com/gp/aw/d/B01LQQH86A/r
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 limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly
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 de
> 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?
On
> 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
wrot
> 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 debat
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 fin
-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
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 softfork, if done exactly as you say.
>
> Segwit only separates out si
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 continu
I agree with everything Matt said. This "X+Y" "compromise" is not a
new proposal and has been hashed over multiple times in the past
dating back to at least fall 2015, ignores basically all design
considerations and research over the last years, doesn't understand
the real-politic of the delays,
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 limi
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 bi
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
25 matches
Mail list logo