with the
full blockchain, and a majority of nodes are pruned, able to serve only the
tail of the chains.
On Tue, May 12, 2015 at 8:26 AM, gabe appleton gapplet...@gmail.com
wrote:
Hi,
There's been a lot of talk in the rest of the community about how the
20MB step would increase storage needs
...@bitpay.com wrote:
One general problem is that security is weakened when an attacker can DoS
a small part of the chain by DoS'ing a small number of nodes - yet the
impact is a network-wide DoS because nobody can complete a sync.
On Tue, May 12, 2015 at 12:24 PM, gabe appleton gapplet
0, 1, 3, 4, 5, 6 can be solved by looking at chunks chronologically. Ie,
give the signed (by sender) hash of the first and last block in your range.
This is less data dense than the idea above, but it might work better.
That said, this is likely a less secure way to do it. To improve upon that,
a
I suppose this begs two questions:
1) why not have a partial archive store the most recent X% of the
blockchain by default?
2) why not include some sort of torrent in QT, to mitigate this risk? I
don't think this is necessarily a good idea, but I'd like to hear the
reasoning.
On May 12, 2015
This is exactly the sort of solution I was hoping for. It seems this is the
minimal modification to make it work, and, if someone was willing to work
with me, I would love to help implement this.
My only concern would be if the - - max-size flag is not included than this
delivers significantly
Hi,
There's been a lot of talk in the rest of the community about how the 20MB
step would increase storage needs, and that switching to pruned nodes
(partially) would reduce network security. I think I may have a solution.
There could be a hybrid option in nodes. Selecting this would do the
Background: I'm a CS student quickly approaching his research project, and
I'd like to do something meaningful with it.
Essentially, I'd like to know what issues someone up for their bachelor's
degree might actually be able to help on, and where I can start. Obviously
I'm not going to be able to
not sure I understand the
nuances, where bitcoin XT fits into the scheme of things (or not) etc.
I would have thought that there would be a testnet4 by now using 8mb
blocks... but hey that's just me.
p.
On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com
wrote:
I don't have
Gabe.
https://github.com/gappleto97/BlockSizeDebate
github's reachable via vpn.
p.
On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com
wrote:
Yeah. We made a git repo instead, so we don't have to bother with the
exclusive-by-default wiki policies. It's linked in this email
Nothing to apologize for. And yes, that's the correct one.
On Jun 6, 2015 2:39 AM, Pindar Wong pindar.w...@gmail.com wrote:
OK... sorry for my confusion.
https://github.com/EthanHeilman/BlockSizeDebate
it is.
p.
On Sat, Jun 6, 2015 at 2:37 PM, gabe appleton gapplet...@gmail.com
wrote
Just pushed the template for Arguments 3, 4, 6, and a full Argument 2.
Argument 5 should be pro, but is currently not defined. Argument 6 may be
merged with Argument 4 if you think that's necessary.
On Sat, Jun 6, 2015 at 2:41 AM, gabe appleton gapplet...@gmail.com wrote:
Nothing to apologize
. A summary of the various
positions and arguments would be extremely helpful.
On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com
wrote:
Also, can we try to get a wiki page for the debate? That way we could
condense the information as much as possible. I'll be willing to assist
Also, can we try to get a wiki page for the debate? That way we could
condense the information as much as possible. I'll be willing to assist if
the page gets approval.
On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote:
Hi!
My fingers have been itching many times now, this debate
But don't you see the same trade-off in the end there? You're still
propagating the same amount of data over the same amount of time, so unless
I misunderstand, the costs of such a move should be approximately the same,
just in different areas. The risks as I understand are as follows:
20MB:
Sync time wouldn't be longer compared to 20MB, it would (eventually) be
longer under either setup.
Also, and this is probably a silly concern, but wouldn't changing block
time change the supply curve? If we cut the rate in half or a power of two,
that affects nothing, but if we want to keep it in
15 matches
Mail list logo
