Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Aymeric Vitte via bitcoin-dev
??? what do you mean? (https://www.soyoustart.com/fr/serveurs-essential/) Le 20/04/2017 à 17:50, Erik Aronesty via bitcoin-dev a écrit : > Try to find 1TB dedicated server hosting ... > > If you want to set up an ecommerce site somewhere besides your living > room, storage costs are still a conce

[bitcoin-dev] Reference implementation (wip) of bip-genvbvoting (generalized version bits)

2017-04-20 Thread Sancho Panza via bitcoin-dev
Dear all, An initial reference implementation of bip-genvbvoting (spec: [1]) is now available at https://github.com/sanch0panza/bitcoin/commits/genvbvoting-bu-dev-clean1 starting at commit fdd83383436ee43b072c258d4a6feb713902c77e . This development is based against the Bitcoin Unlimited 'dev'

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Andrew Poelstra via bitcoin-dev
On Thu, Apr 20, 2017 at 11:46:33AM +0200, Tom Zander via bitcoin-dev wrote: > On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev > wrote: > > > I suggested something similar which is a much simpler version; > > > https://zander.github.io/scaling/Pruning/ > > > Your proposal ha

[bitcoin-dev] Segwit v2

2017-04-20 Thread Luke Dashjr via bitcoin-dev
Since BIP 141's version bit assignment will timeout soon, and needing renewal, I was thinking it might make sense to make some minor tweaks to the spec for the next deployment. These aren't critical, so it's perfectly fine if BIP 141 activates as-is (potentially with BIP 148), but IMO would be a

Re: [bitcoin-dev] I do not support the BIP 148 UASF

2017-04-20 Thread shaolinfry via bitcoin-dev
Dear Greg, Thank you for taking the time to review the BIP148 proposal. I agree with much of your thoughts. I originally started working on a generalized way to deploy user activated soft forks, in a way that leveraged BIP9 to allow for optional faster MASF activation. BIP148 came about as a wa

[bitcoin-dev] Exploring Network Rule Changes

2017-04-20 Thread Cameron Garnham via bitcoin-dev
I have taken some time to think about consensus systems in-general; and write up a guide that explores the problems space of changing the rules of such systems. Hopefully, this guide will clarify the different options available to the Bitcoin Community. I am posting this to the Bitcoin Develop

Re: [bitcoin-dev] Transaction signalling

2017-04-20 Thread Erik Aronesty via bitcoin-dev
I agree, addresses create vulnerability, an OP_RETURN signal seems the safest way to go for UA signalling. I can model a BIP after BIP9, with some discussion of how to properly collect statistics, and the ability for nodes to activate features based on an "economic majority" defined in this way.

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Erik Aronesty via bitcoin-dev
Try to find 1TB dedicated server hosting ... If you want to set up an ecommerce site somewhere besides your living room, storage costs are still a concern. On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1TB HDD is now available for

Re: [bitcoin-dev] I do not support the BIP 148 UASF

2017-04-20 Thread Erik Aronesty via bitcoin-dev
Bitcoin must level the playing field for mining or it is fundamentally broken. And there are two obvious solutions: 1. WTXID commitment has as a flag day upgrade. It's a fix to a fairly serious security issue - made even worse by the existence of patents on the code. 2. Embed the code for perfo

Re: [bitcoin-dev] I do not support the BIP 148 UASF

2017-04-20 Thread Alphonse Pace via bitcoin-dev
A WTXID commitment would (likely) need to be a UASF. On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The "UASF movement" seems a bit premature to me - I doubt UASF will be > necessary if a WTXID commitment is tried first. I thin

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Tom Zander via bitcoin-dev
On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev wrote: > > I suggested something similar which is a much simpler version; > > https://zander.github.io/scaling/Pruning/ > Your proposal has a significant disadvantage: If every peer is dropping > 75% of all blocks randomly, th

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

2017-04-20 Thread Aymeric Vitte via bitcoin-dev
Thanks but you did not answer all the points and some of your statements look wrong, like the global ideas behind this proposal from my standpoint, which basically is inventing strange things not reusing what is already proven to be working well and could provide the same result, which at the end i