Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Jimmy Song via bitcoin-dev
Jorge, I'll be happy to discuss with you more about whether allowing ASICBoost would actually secure the network more or not, but that's not my main motivation. My main motivation is to get more miners to accept segwit. The version bit usage part, I don't believe requires any code changes as

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Jorge Timón via bitcoin-dev
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev wrote: > I've changed the proposal so only 8 bits are given to grinding so something > like 20 bits are available for signaling. > > I have to say I'm at a loss here as to what's next? Should I make

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Staf Verhaegen via bitcoin-dev
g via bitcoin-dev schreef op ma 10-04-2017 om 20:39 [-0600]: > > However, we need to consider the environmental impact of mining, which > currently consumes a quite exorbitant amount of energy. Any ideas on > this front? Everything is relative. Some months ago I did some investigation and

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Jimmy Song via bitcoin-dev
I've changed the proposal so only 8 bits are given to grinding so something like 20 bits are available for signaling. I have to say I'm at a loss here as to what's next? Should I make a new BIP or try to convince the authors of BIP141 to modify their BIP? Could someone inform me on the next part

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Sancho Panza via bitcoin-dev
Tom Zander wrote: > The version field is still needed to actually allow future block version > upgrades. We would cut off our road forward if that were to be blocked. I tend to agree, if all 32 bits were given up to grinding. But it's worth pointing out that BIP9 is purely informational, and

[bitcoin-dev] Proposed CSV configuration file format for bip-genvbvoting

2017-04-11 Thread Sancho Panza via bitcoin-dev
Hi, The link below includes documentation about a proposed CSV-based file format for fork deployment data (tentative config filename: forks.csv). This is planned to be used by my reference implementation of bip-genvbvoting (which is still in development - TBA later). Other BIP9 improvement

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Jorge Timón via bitcoin-dev
The discussion is going offtopic. Can we please take vague discussions about changing pow, so called "asic resistance", the environment etc to bitcoin-disscuss or some other forum? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Using a storage engine without UTXO-index

2017-04-11 Thread Tomas via bitcoin-dev
On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote: > It's not the headers/tx-hashes of the blocks that I'm referring to, it > is the confirmation and spend information relative to all txs and all > outputs for each branch. This reverse navigation (i.e. utxo > information) is essential, must be

Re: [bitcoin-dev] Using a storage engine without UTXO-index

2017-04-11 Thread Eric Voskuil via bitcoin-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/11/2017 01:43 AM, Tomas wrote: > Splitting transactions only happens *on storage* and is just a > minor optimization compared to storing them in full. Ok > Sure, we can still call switching tips a "reorg". And it is indeed > a trade off as

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Sancho Panza via bitcoin-dev
> I completely agree that it will be in the long term interest of bitcoin to > migrate, gradually, toward a commoditized POW away from the current mass > centralization. There is a big problem here though: Hundreds of millions of > dollars have been spent on the current algorithm, and will be a

Re: [bitcoin-dev] Using a storage engine without UTXO-index

2017-04-11 Thread Tomas via bitcoin-dev
On Tue, Apr 11, 2017, at 03:44, Eric Voskuil wrote: > As I understand it you would split tx inputs and outputs and send them > independently, and that you intend this to be a P2P network > optimization - not a consensus rule change. So my comments are based > on those inferences. If we are

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread Tom Zander via bitcoin-dev
The version field is still needed to actually allow future block version upgrades. We would cut off our road forward if that were to be blocked. On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote: > Currently, the version bits (currently 4 bytes, or 32 bits) in the header >

Re: [bitcoin-dev] A Small Modification to Segwit

2017-04-11 Thread g via bitcoin-dev
Makes sense. I would love if GPUs were back as the main hashing tool. However, we need to consider the environmental impact of mining, which currently consumes a quite exorbitant amount of energy. Any ideas on this front? -- Garrett MacDonald +1 720 515 2248 g...@cognitive.ch GPG Key On Apr