their client would support
larger blocks when there is majority miner consensus, otherwise their
clients will always only support the old rules.
This way the decision is not being forced upon the user in any way.
Just an idea.
On 07/05/15 16:58, Matthew Mitchell wrote:
> In my personal opin
of a fairer way.
Matthew Mitchell
On 07/05/15 15:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>
> In it, I asked people to email m
wrote:
> On 10/09/13 23:03, Matthew Mitchell wrote:
>> Maybe it would have been better without the aggressive words?
>
> I revisited the wordlist and replaced around 67 words that can be
> found offensive in some context.
>
> --
> Best Regards
ious words so I believe all
> three authors mentioned in the BIP are safe against fundamentalist
> bitcoin users :-).
>
> slush
>
> On 9/10/13, Matthew Mitchell wrote:
>> I like this, though maybe sometimes you'll get rude word combinatio
I like this, though maybe sometimes you'll get rude word combinations come out.
Matthew
On 10 Sep 2013, at 17:44, slush wrote:
> Hi all,
>
> we just finalized the draft and reference implementation of BIP39. Regards to
> rules in BIP0001 we're asking for comments.
>
> The aim of the proposa
On 13 Sep 2012, at 19:59, Pieter Wuille wrote:
> You want to parallellize block downloads, while at the same time preventing
> re-download of transactions that are already known.
> To do so, a requesting node would first request (for example) the 8 level-3
> hashes, then start 8 parallel threa
On 13 Sep 2012, at 16:51, Gregory Maxwell wrote:
> I thoroughly understand the value of tree hashes. That wasn't what I
> was asking about.
>
> If you're validating a block you need all the transactions, once you
> have them or their hashes you can build the tree without transferring
> more, e.
On 13 Sep 2012, at 16:16, Gregory Maxwell wrote:
> Sorry, I'm still not seeing what the value is. How is the tree level
> useful to anyone? If you did want to get only parts of the
> transaction list, why not just ranges from the lowest level?
Obtaining a particular tree level allows you to v
On 13 Sep 2012, at 09:42, Mike Hearn wrote:
> For what it's worth I disagree with Gregory on nearly all these
> points, so don't take it as some kind of consensus from the Bitcoin
> community ;)
>
> Matts change is reasonable but I think we all agree it has minimal
> impact at the moment relativ
On 11 Sep 2012, at 20:42, Gregory Maxwell wrote:
> Someone can do that just by pipelining the one at a time requests.
> How much bandwidth do you think you could save over that?
You wouldn't need to pipeline the requests, just place more than one inventory
vector in get data, right? Well my mes
For some reason sourceforge is not sending me updates anymore but I can see the
replies online…
There could be a slightly more simple protocol which gives all the transactions
hashes and nodes can then download the transactions separately. However there
are two problems:
1. Downloading all the
Do you mean getdata? Here is the reason for the 6 new messages:
getseginv,seginv - These are for learning about what segments of a block a node
has. Else you could remove these messages and simply have nodes advertise
blocks via inventory messages. In this case nodes would have to wait until the
Almost forgot...
Begin forwarded message:
> From: Matthew Mitchell
> Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
> Date: 10 September 2012 16:23:45 BST
> To: Gregory Maxwell
>
> By "gettreelevel" and "treelevel" you get the leve
Here is a BIP draft for improving the block relaying and validation so that it
can be done in parallel and so that redundancy can be removed. This becomes
more beneficial the larger the block sizes are.
https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal
Matthew Mitchell
14 matches
Mail list logo
