Re: [Bitcoin-development] Meta suggestions for this block size debate

2015-06-07 Thread gabe appleton
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 wrote: > Nothing to apologize for. And yes

Re: [Bitcoin-development] Meta suggestions for this block size debate

2015-06-05 Thread gabe appleton
Nothing to apologize for. And yes, that's the correct one. On Jun 6, 2015 2:39 AM, "Pindar Wong" wrote: > OK... sorry for my confusion. > > https://github.com/EthanHeilman/BlockSizeDebate > > it is. > > p. > > > On Sat, Jun 6, 2015 at 2:37 PM, gabe ap

Re: [Bitcoin-development] Meta suggestions for this block size debate

2015-06-05 Thread gabe appleton
Wong" wrote: > Thanks Gabe. > > https://github.com/gappleto97/BlockSizeDebate > > github's reachable via vpn. > > p. > > > On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton > wrote: > >> Yeah. We made a git repo instead, so we don't have to both

Re: [Bitcoin-development] Meta suggestions for this block size debate

2015-06-05 Thread gabe appleton
eed to do it myself anyways since I'm 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. > > > > &g

Re: [Bitcoin-development] Meta suggestions for this block size debate

2015-06-01 Thread gabe appleton
ate. A summary of the various > positions and arguments would be extremely helpful. > > On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton > 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'

Re: [Bitcoin-development] Meta suggestions for this block size debate

2015-06-01 Thread gabe appleton
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" wrote: > Hi! > > My fingers have been itching many times now, this debate > drives me n

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread gabe appleton
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

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread gabe appleton
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:

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread gabe appleton
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 les

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread gabe appleton
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 4:11

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread gabe appleton
arzik" 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 a

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread gabe appleton
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

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread gabe appleton
; 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 > wrote: > >> Hi, >> >> There's been a lot of talk in the rest of the community about how the >> 20MB ste

[Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread gabe appleton
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 follo

[Bitcoin-development] Where do I start?

2015-04-15 Thread gabe appleton
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 j