Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

2017-02-05 Thread Andrew C via bitcoin-dev
On 2/5/2017 6:02 PM, Luke Dashjr wrote: > My BIP draft didn't make progress because the community opposes any block > size > increase hardfork ever. >From what I have observed, it seems to be that people are more so opposed to a hard fork when there is a comparable soft fork available than simpl

Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

2017-02-05 Thread Luke Dashjr via bitcoin-dev
My BIP draft didn't make progress because the community opposes any block size increase hardfork ever. Your version doesn't address the current block size issues (ie, the blocks being too large). So you've retained the only certain- DOA parts of my proposal, and removed the most useful part... I'

[bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

2017-02-05 Thread Andrew C via bitcoin-dev
Hello all, Many people have expressed discontent with Luke-jr's proposed block size BIP, in particular with the decrease in size that would occur if it were to be activated prior to 2024. I have decided to modify the proposal to instead begin the increase steps at the current 100 byte limit.

Re: [bitcoin-dev] Transaction signalling through output address hashing

2017-02-05 Thread Andrew C via bitcoin-dev
Instead of using vanity addresses, the transactions could just use an OP_RETURN output and express the signalling there. However, such a system could be easily gamed by people who simply spam the network with transactions and by miners who choose what transactions to include in their blocks. On

Re: [bitcoin-dev] Transaction signalling through output address hashing

2017-02-05 Thread Natanael via bitcoin-dev
Den 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Currently in order to signal support for changes to Bitcoin, only miners are able to do so on the blockchain through BIP9. One criticism is that the rest of the community is not able to participate

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

2017-02-05 Thread t. khan via bitcoin-dev
On Thu, Feb 2, 2017 at 7:24 PM, Luke Dashjr wrote: > Strongly disagree with buying "votes", or portraying open standards as a > voting process. Also, this depends on address reuse, so it's fundamentally > flawed in design. > The point of this is it's available right now. It's not ideal, but it w

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

2017-02-05 Thread t. khan via bitcoin-dev
On Fri, Feb 3, 2017 at 2:22 PM, alp alp wrote: > These are non-answers. Someone must decide. Someone must decide what > kind of company counts (e.g. does a dark market seller count as a > business? Does some guy who sells $10/year worth of goods using Bitcoin > count the same as large companie

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

2017-02-05 Thread Chris Priest via bitcoin-dev
Personally I think once the blocksize arguments are solved, there will be no more contentious changes for this voting system to deal with. What other contentious issues have come up in the past 3 years or so that wasn't blocksize/scaling related? Do other protocols like TCP/IP and the HTTP protocol

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

2017-02-05 Thread alp alp via bitcoin-dev
These are non-answers. Someone must decide. Someone must decide what kind of company counts (e.g. does a dark market seller count as a business? Does some guy who sells $10/year worth of goods using Bitcoin count the same as large companies like Coinbase/BitPay/Blockstream). Someone must decide

[bitcoin-dev] Transaction signalling through output address hashing

2017-02-05 Thread John Hardy via bitcoin-dev
Currently in order to signal support for changes to Bitcoin, only miners are able to do so on the blockchain through BIP9. One criticism is that the rest of the community is not able to participate in consensus, and other methods of assessing community support are fuzzy and easily manipulated