subject:"\[bitcoin\-dev\] Bitcoin Core and hard forks"

I agree that the fewer the necessary parties the better - however, some 
entities are much better positioned to offer certain services on the network 
than others - and the fact we can trustlessly negotiate smart contracts with 
them is one of the most significant developments in the cryptospace - it’s one 
of the most revolutionary aspects of this technology…it accomplishes something 
we’ve never really been able to do before.

Notice that third parties can encapsulate complex tasks and provide a far 
simpler interface. Crypto contracts provide the incentives for them to do this. 
And by having competition and transparency, these services automatically get 
optimized via human ingenuity. We don’t need to design top-down for it.

> On Jul 23, 2015, at 6:42 PM, Jean-Paul Kogelman  
> wrote:
> 
> Miners could include their fee tiers in the coinbase, but this is obviously 
> open to manipulation, with little recourse (unless they are a pool and miners 
> move away because of it).
> 
> In any event, I think that trying out a solution that is both simple and 
> involves the least number of parties necessary is preferable.
> 
> Have miners set their tiers, have users select the level of quality they 
> want, ignore the block size.
> 
> Miners will adapt their tiers depending on how many transactions actually end 
> up in them. If for example they set the first tier to be $1 to be included in 
> the current block and no user chooses that level of service, they've 
> obviously priced themselves out of the market. The opposite is also true; if 
> a tier is popular they can choose to increase the cost of that tier.
> 
> jp
> 
>> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo  wrote:
>> 
>> I suppose you can use a timelocked output that is spendable by anyone you 
>> could go somewhat in this direction…the thing is it still means the wallet 
>> must make fee estimations rather than being able to get a quick quote.
>> 
>>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman  
>>> wrote:
>>> 
>>> I think implicit QoS is far simpler to implement, requires less parties and 
>>> is closer to what Bitcoin started out as: a peer-to-peer digital cash 
>>> system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>> 
>>> jp
>>> 
 On Jul 24, 2015, at 9:08 AM, Eric Lombrozo  wrote:
 
 By using third parties separate from individual miners that do bidding on 
 your behalf you get a mechanism that allows QoS guarantees and shifting 
 the complexity and risk from the wallet with little computational 
 resources to a service with abundance of them. Using timelocked contracts 
 it’s possible to enforce the guarantees.
 
 Negotiating directly with miners via smart contracts seems difficult at 
 best.
 
 
> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev 
>  wrote:
> 
> Doesn't matter.
> 
> It's not going to be perfect given the block time variance among other 
> factors but it's far more workable than guessing whether or not your 
> transaction is going to end up in a block at all.
> 
> jp
> 
> 
>> On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> 
>> 
>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
>>>  wrote:
>>> 
>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>> start excluding transactions.
>> 
>> As mining is a random, poisson process, obviously giving guarantees 
>> without a majority of hashing power isn't possible.
>> 
>> 
>> -BEGIN PGP SIGNATURE-
>> 
>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>> =LY1+
>> -END PGP SIGNATURE-
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev

Miners could include their fee tiers in the coinbase, but this is obviously 
open to manipulation, with little recourse (unless they are a pool and miners 
move away because of it). 

In any event, I think that trying out a solution that is both simple and 
involves the least number of parties necessary is preferable.

Have miners set their tiers, have users select the level of quality they want, 
ignore the block size.

Miners will adapt their tiers depending on how many transactions actually end 
up in them. If for example they set the first tier to be $1 to be included in 
the current block and no user chooses that level of service, they've obviously 
priced themselves out of the market. The opposite is also true; if a tier is 
popular they can choose to increase the cost of that tier.

jp 

> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo  wrote:
> 
> I suppose you can use a timelocked output that is spendable by anyone you 
> could go somewhat in this direction…the thing is it still means the wallet 
> must make fee estimations rather than being able to get a quick quote.
> 
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman  
>> wrote:
>> 
>> I think implicit QoS is far simpler to implement, requires less parties and 
>> is closer to what Bitcoin started out as: a peer-to-peer digital cash 
>> system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>> 
>> jp
>> 
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo  wrote:
>>> 
>>> By using third parties separate from individual miners that do bidding on 
>>> your behalf you get a mechanism that allows QoS guarantees and shifting the 
>>> complexity and risk from the wallet with little computational resources to 
>>> a service with abundance of them. Using timelocked contracts it’s possible 
>>> to enforce the guarantees.
>>> 
>>> Negotiating directly with miners via smart contracts seems difficult at 
>>> best.
>>> 
>>> 
 On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev 
  wrote:
 
 Doesn't matter.
 
 It's not going to be perfect given the block time variance among other 
 factors but it's far more workable than guessing whether or not your 
 transaction is going to end up in a block at all.
 
 jp
 
 
> On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
>>  wrote:
>> 
>> And it's obvious how a size cap would interfere with such a QoS scheme.
>> Miners wouldn't be able to deliver the below guarantees if they have to
>> start excluding transactions.
> 
> As mining is a random, poisson process, obviously giving guarantees 
> without a majority of hashing power isn't possible.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
> =LY1+
> -END PGP SIGNATURE-
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

I think it’s pretty clear by now that the assumption that all nodes have pretty 
similar computational resources leads to very misplaced incentives. Ultimately, 
cryptocurrencies will allow direct outsourcing of computation, making it 
possible to distribute computational tasks in an economically sensible way.

Wallets should be assumed to have low computational resources and intermittent 
Internet connections for the foreseeable future if we ever intend for this to 
be a practical payment system, methinks.


> On Jul 23, 2015, at 6:28 PM, Eric Lombrozo  wrote:
> 
> I suppose you can use a timelocked output that is spendable by anyone you 
> could go somewhat in this direction…the thing is it still means the wallet 
> must make fee estimations rather than being able to get a quick quote.
> 
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman  
>> wrote:
>> 
>> I think implicit QoS is far simpler to implement, requires less parties and 
>> is closer to what Bitcoin started out as: a peer-to-peer digital cash 
>> system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>> 
>> jp
>> 
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo  wrote:
>>> 
>>> By using third parties separate from individual miners that do bidding on 
>>> your behalf you get a mechanism that allows QoS guarantees and shifting the 
>>> complexity and risk from the wallet with little computational resources to 
>>> a service with abundance of them. Using timelocked contracts it’s possible 
>>> to enforce the guarantees.
>>> 
>>> Negotiating directly with miners via smart contracts seems difficult at 
>>> best.
>>> 
>>> 
 On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev 
  wrote:
 
 Doesn't matter.
 
 It's not going to be perfect given the block time variance among other 
 factors but it's far more workable than guessing whether or not your 
 transaction is going to end up in a block at all.
 
 jp
 
 
> On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
>>  wrote:
>> 
>> And it's obvious how a size cap would interfere with such a QoS scheme.
>> Miners wouldn't be able to deliver the below guarantees if they have to
>> start excluding transactions.
> 
> As mining is a random, poisson process, obviously giving guarantees 
> without a majority of hashing power isn't possible.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
> =LY1+
> -END PGP SIGNATURE-
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

I suppose you can use a timelocked output that is spendable by anyone you could 
go somewhat in this direction…the thing is it still means the wallet must make 
fee estimations rather than being able to get a quick quote.

> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman  
> wrote:
> 
> I think implicit QoS is far simpler to implement, requires less parties and 
> is closer to what Bitcoin started out as: a peer-to-peer digital cash system, 
> not a peer-to-let-me-handle-that-for-you-to-peer system.
> 
> jp
> 
>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo  wrote:
>> 
>> By using third parties separate from individual miners that do bidding on 
>> your behalf you get a mechanism that allows QoS guarantees and shifting the 
>> complexity and risk from the wallet with little computational resources to a 
>> service with abundance of them. Using timelocked contracts it’s possible to 
>> enforce the guarantees.
>> 
>> Negotiating directly with miners via smart contracts seems difficult at best.
>> 
>> 
>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev 
>>>  wrote:
>>> 
>>> Doesn't matter.
>>> 
>>> It's not going to be perfect given the block time variance among other 
>>> factors but it's far more workable than guessing whether or not your 
>>> transaction is going to end up in a block at all.
>>> 
>>> jp
>>> 
>>> 
 On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 
 
> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
>  wrote:
> 
> And it's obvious how a size cap would interfere with such a QoS scheme.
> Miners wouldn't be able to deliver the below guarantees if they have to
> start excluding transactions.
 
 As mining is a random, poisson process, obviously giving guarantees 
 without a majority of hashing power isn't possible.
 
 
 -BEGIN PGP SIGNATURE-
 
 iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
 AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
 VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
 i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
 DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
 PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
 =LY1+
 -END PGP SIGNATURE-
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev

I think implicit QoS is far simpler to implement, requires less parties and is 
closer to what Bitcoin started out as: a peer-to-peer digital cash system, not 
a peer-to-let-me-handle-that-for-you-to-peer system.

jp

> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo  wrote:
> 
> By using third parties separate from individual miners that do bidding on 
> your behalf you get a mechanism that allows QoS guarantees and shifting the 
> complexity and risk from the wallet with little computational resources to a 
> service with abundance of them. Using timelocked contracts it’s possible to 
> enforce the guarantees.
> 
> Negotiating directly with miners via smart contracts seems difficult at best.
> 
> 
>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev 
>>  wrote:
>> 
>> Doesn't matter.
>> 
>> It's not going to be perfect given the block time variance among other 
>> factors but it's far more workable than guessing whether or not your 
>> transaction is going to end up in a block at all.
>> 
>> jp
>> 
>> 
>>> On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> 
>>> 
 On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
  wrote:
 
 And it's obvious how a size cap would interfere with such a QoS scheme.
 Miners wouldn't be able to deliver the below guarantees if they have to
 start excluding transactions.
>>> 
>>> As mining is a random, poisson process, obviously giving guarantees without 
>>> a majority of hashing power isn't possible.
>>> 
>>> 
>>> -BEGIN PGP SIGNATURE-
>>> 
>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>> =LY1+
>>> -END PGP SIGNATURE-
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

By using third parties separate from individual miners that do bidding on your 
behalf you get a mechanism that allows QoS guarantees and shifting the 
complexity and risk from the wallet with little computational resources to a 
service with abundance of them. Using timelocked contracts it’s possible to 
enforce the guarantees.

Negotiating directly with miners via smart contracts seems difficult at best.


> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev 
>  wrote:
> 
> Doesn't matter.
> 
> It's not going to be perfect given the block time variance among other 
> factors but it's far more workable than guessing whether or not your 
> transaction is going to end up in a block at all.
> 
> jp
> 
> 
>> On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> 
>> 
>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
>>>  wrote:
>>> 
>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>> start excluding transactions.
>> 
>> As mining is a random, poisson process, obviously giving guarantees without 
>> a majority of hashing power isn't possible.
>> 
>> 
>> -BEGIN PGP SIGNATURE-
>> 
>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>> =LY1+
>> -END PGP SIGNATURE-
>> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev

There really isn't any need for a 3rd party here. Those "services" can just be 
the miners themselves.


jp

> On Jul 24, 2015, at 8:56 AM, Eric Lombrozo  wrote:
> 
> 
>> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman  
>> wrote:
>> 
>> Quality of service as in:
>> 
>>> X satoshi / kb = included in block currently worked on;
>> 
>>> Y satoshi / kb = included in next block;
>> 
>>> Z satoshi / kb = included in block after that, etc.
>> 
>> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>> 
>> Market develops when miners start setting different values and adding more 
>> transactions to blocks as opposed to other miners with higher settings.
>> 
>> It basically comes down to the miners themselves if they want a healthy fee 
>> market. If they stick to their guns, their influence on the fees will be 
>> proportional to their hashing power.
>> 
>> jp
> 
> 
> The scheme I’ve been considering is the use of services (separate from 
> miners) that guarantee inclusion for you for some predetermined price and 
> then do the bidding on your behalf. Via contracts you can guarantee you get 
> included within a certain number of blocks or you receive a full refund…or 
> even possibly receive compensation for failure to deliver.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev

Doesn't matter.

It's not going to be perfect given the block time variance among other factors 
but it's far more workable than guessing whether or not your transaction is 
going to end up in a block at all.

jp


> On Jul 24, 2015, at 8:53 AM, Peter Todd  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
>>  wrote:
>> 
>> And it's obvious how a size cap would interfere with such a QoS scheme.
>> Miners wouldn't be able to deliver the below guarantees if they have to
>> start excluding transactions.
> 
> As mining is a random, poisson process, obviously giving guarantees without a 
> majority of hashing power isn't possible.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
> =LY1+
> -END PGP SIGNATURE-
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman  
> wrote:
> 
> Quality of service as in:
> 
>> X satoshi / kb = included in block currently worked on;
> 
>> Y satoshi / kb = included in next block;
> 
>> Z satoshi / kb = included in block after that, etc.
> 
> Block count starts when transaction is first seen. Miners can set X, Y, Z.
> 
> Market develops when miners start setting different values and adding more 
> transactions to blocks as opposed to other miners with higher settings.
> 
> It basically comes down to the miners themselves if they want a healthy fee 
> market. If they stick to their guns, their influence on the fees will be 
> proportional to their hashing power.
> 
> jp


The scheme I’ve been considering is the use of services (separate from miners) 
that guarantee inclusion for you for some predetermined price and then do the 
bidding on your behalf. Via contracts you can guarantee you get included within 
a certain number of blocks or you receive a full refund…or even possibly 
receive compensation for failure to deliver.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Peter Todd via bitcoin-dev

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
 wrote:
>
>And it's obvious how a size cap would interfere with such a QoS scheme.
>Miners wouldn't be able to deliver the below guarantees if they have to
>start excluding transactions.

As mining is a random, poisson process, obviously giving guarantees without a 
majority of hashing power isn't possible.


-BEGIN PGP SIGNATURE-

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
=LY1+
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev


And it's obvious how a size cap would interfere with such a QoS scheme. Miners 
wouldn't be able to deliver the below guarantees if they have to start 
excluding transactions.



> On Jul 24, 2015, at 8:45 AM, Jean-Paul Kogelman via bitcoin-dev 
>  wrote:
> 
> Quality of service as in:
> 
>> X satoshi / kb = included in block currently worked on;
> 
>> Y satoshi / kb = included in next block;
> 
>> Z satoshi / kb = included in block after that, etc.
> 
> Block count starts when transaction is first seen. Miners can set X, Y, Z. 
> 
> Market develops when miners start setting different values and adding more 
> transactions to blocks as opposed to other miners with higher settings. 
> 
> It basically comes down to the miners themselves if they want a healthy fee 
> market. If they stick to their guns, their influence on the fees will be 
> proportional to their hashing power.
> 
> jp
> 
>> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo  wrote:
>> 
>> 
>>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman  
>>> wrote:
>>> 
>>> You are not going to get a fair fee market if your only form of enforcement 
>>> is the threat of exclusion.
>>> 
>>> A more fair fee market will develop if miners start offering quality of 
>>> service, preferably at multiple tiers. At that point any interference from 
>>> a block size cap will only be detrimental. In fact it will only highlight 
>>> what the cap is actually for; to prevent monster blocks.
>>> 
>>> Add better QoS tools for miners and extend the cap (when possible) and 
>>> there's your fee market.
>>> 
>>> jp
>> 
>> Not sure what you mean by QoS here. Either your transaction is included or 
>> it isn’t. It’s not like you can upgrade to a master suite with a view or 
>> anything.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev

Quality of service as in:

> X satoshi / kb = included in block currently worked on;

> Y satoshi / kb = included in next block;

> Z satoshi / kb = included in block after that, etc.

Block count starts when transaction is first seen. Miners can set X, Y, Z. 

Market develops when miners start setting different values and adding more 
transactions to blocks as opposed to other miners with higher settings. 

It basically comes down to the miners themselves if they want a healthy fee 
market. If they stick to their guns, their influence on the fees will be 
proportional to their hashing power.

jp

> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo  wrote:
> 
> 
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman  
>> wrote:
>> 
>> You are not going to get a fair fee market if your only form of enforcement 
>> is the threat of exclusion.
>> 
>> A more fair fee market will develop if miners start offering quality of 
>> service, preferably at multiple tiers. At that point any interference from a 
>> block size cap will only be detrimental. In fact it will only highlight what 
>> the cap is actually for; to prevent monster blocks.
>> 
>> Add better QoS tools for miners and extend the cap (when possible) and 
>> there's your fee market.
>> 
>> jp
> 
> Not sure what you mean by QoS here. Either your transaction is included or it 
> isn’t. It’s not like you can upgrade to a master suite with a view or 
> anything.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

Are you referring to mining contracts?

> On Jul 23, 2015, at 5:32 PM, Eric Lombrozo  wrote:
> 
> 
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman  
>> wrote:
>> 
>> You are not going to get a fair fee market if your only form of enforcement 
>> is the threat of exclusion.
>> 
>> A more fair fee market will develop if miners start offering quality of 
>> service, preferably at multiple tiers. At that point any interference from a 
>> block size cap will only be detrimental. In fact it will only highlight what 
>> the cap is actually for; to prevent monster blocks.
>> 
>> Add better QoS tools for miners and extend the cap (when possible) and 
>> there's your fee market.
>> 
>> jp
> 
> Not sure what you mean by QoS here. Either your transaction is included or it 
> isn’t. It’s not like you can upgrade to a master suite with a view or 
> anything.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman  
> wrote:
> 
> You are not going to get a fair fee market if your only form of enforcement 
> is the threat of exclusion.
> 
> A more fair fee market will develop if miners start offering quality of 
> service, preferably at multiple tiers. At that point any interference from a 
> block size cap will only be detrimental. In fact it will only highlight what 
> the cap is actually for; to prevent monster blocks.
> 
> Add better QoS tools for miners and extend the cap (when possible) and 
> there's your fee market.
> 
> jp

Not sure what you mean by QoS here. Either your transaction is included or it 
isn’t. It’s not like you can upgrade to a master suite with a view or anything.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jean-Paul Kogelman via bitcoin-dev

You are not going to get a fair fee market if your only form of enforcement is 
the threat of exclusion.

A more fair fee market will develop if miners start offering quality of 
service, preferably at multiple tiers. At that point any interference from a 
block size cap will only be detrimental. In fact it will only highlight what 
the cap is actually for; to prevent monster blocks. 

Add better QoS tools for miners and extend the cap (when possible) and there's 
your fee market.

jp


> On Jul 24, 2015, at 8:04 AM, Eric Lombrozo via bitcoin-dev 
>  wrote:
> 
> I should also add that I think those who claim that fee pressure will scare 
> away users and break the industry are *seriously* underestimating human 
> ingenuity in the face of a challenge. We can do this - we can overcome this 
> obstacle…we can find good solutions to a fee market. Unless someone can come 
> up with another way to pay for the operation of the network, we NEED to do 
> this. What makes anyone think it will be easier to do later rather than now? 
> The longer we wait, the lower block rewards get, the larger the deployed 
> infrastructure, the larger our userbase, the HARDER it will be to solve it. 
> We should solve it now - we will be much better off for it…and so will our 
> users.
> 
> 
>>> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo  wrote:
>>> 
>>> 
>>> On Jul 23, 2015, at 4:42 PM, Benedict Chan  wrote:
>>> 
>>> Scaling the network will come in the form of a combination of many
>>> optimizations. Just because we do not know for sure how to eventually
>>> serve 7 billion people does not mean we should make decisions on
>>> global validation that impact our ability to serve the current set of
>>> users.
>> 
>> Agreed. But I believe the economic and security arguments I gave regarding 
>> fees and incentives still hold and are largely separate from the scalability 
>> issue. Please correct me if I overlooked something.
>> 
>> 
>>> Also, blocking a change because it's "more important to address issues
>>> such as..." other improvements will further slow down the discussion.
>>> I believe an increase will not prevent the development of other
>>> improvements that we need - in contrast, the sooner we can get over
>>> the limit (which, as you agree, needs to be changed at some point),
>>> the sooner we can get back to work.
>> 
>> An increase in block size at this time will exacerbate security concerns 
>> around nodes relying on other nodes to validate (particularly miners and 
>> wallets). It’s not really a matter of having limited developer resources 
>> that need to be budgeted, as you seem to suggest.
>> 
>> Regarding developments on properly handling fees, there must exist the 
>> economic need for it before there’s an earnest effort to solve it. 
>> Increasing the block size right now will, in all likelihood, delay this 
>> effort. I’d much prefer to first let the fee market evolve because it’s a 
>> crucial component to the protocol’s design and its security model…and so we 
>> can get a better sense for fee economics. Then we might be able to figure 
>> out better approaches to block size changes in the future that makes sense 
>> economically…perhaps with mechanisms that can dynamically adjust it to 
>> reflect resource availability and network load.
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Simon Liu via bitcoin-dev

Increasing the block size does not hinder research and development of
Lightning or other technologies.


On 07/23/2015 05:04 PM, Eric Lombrozo via bitcoin-dev wrote:
> I should also add that I think those who claim that fee pressure will
> scare away users and break the industry are *seriously* underestimating
> human ingenuity in the face of a challenge. We can do this - we can
> overcome this obstacle…we can find good solutions to a fee market.
> Unless someone can come up with another way to pay for the operation of
> the network, we NEED to do this. What makes anyone think it will be
> easier to do later rather than now? The longer we wait, the lower block
> rewards get, the larger the deployed infrastructure, the larger our
> userbase, the HARDER it will be to solve it. We should solve it now - we
> will be much better off for it…and so will our users.
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

I should also add that I think those who claim that fee pressure will scare 
away users and break the industry are *seriously* underestimating human 
ingenuity in the face of a challenge. We can do this - we can overcome this 
obstacle…we can find good solutions to a fee market. Unless someone can come up 
with another way to pay for the operation of the network, we NEED to do this. 
What makes anyone think it will be easier to do later rather than now? The 
longer we wait, the lower block rewards get, the larger the deployed 
infrastructure, the larger our userbase, the HARDER it will be to solve it. We 
should solve it now - we will be much better off for it…and so will our users.


> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo  wrote:
> 
> 
>> On Jul 23, 2015, at 4:42 PM, Benedict Chan > > wrote:
>> 
>> Scaling the network will come in the form of a combination of many
>> optimizations. Just because we do not know for sure how to eventually
>> serve 7 billion people does not mean we should make decisions on
>> global validation that impact our ability to serve the current set of
>> users.
> 
> Agreed. But I believe the economic and security arguments I gave regarding 
> fees and incentives still hold and are largely separate from the scalability 
> issue. Please correct me if I overlooked something.
> 
> 
>> Also, blocking a change because it's "more important to address issues
>> such as..." other improvements will further slow down the discussion.
>> I believe an increase will not prevent the development of other
>> improvements that we need - in contrast, the sooner we can get over
>> the limit (which, as you agree, needs to be changed at some point),
>> the sooner we can get back to work.
> 
> An increase in block size at this time will exacerbate security concerns 
> around nodes relying on other nodes to validate (particularly miners and 
> wallets). It’s not really a matter of having limited developer resources that 
> need to be budgeted, as you seem to suggest.
> 
> Regarding developments on properly handling fees, there must exist the 
> economic need for it before there’s an earnest effort to solve it. Increasing 
> the block size right now will, in all likelihood, delay this effort. I’d much 
> prefer to first let the fee market evolve because it’s a crucial component to 
> the protocol’s design and its security model…and so we can get a better sense 
> for fee economics. Then we might be able to figure out better approaches to 
> block size changes in the future that makes sense economically…perhaps with 
> mechanisms that can dynamically adjust it to reflect resource availability 
> and network load.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 4:42 PM, Benedict Chan  wrote:
> 
> Scaling the network will come in the form of a combination of many
> optimizations. Just because we do not know for sure how to eventually
> serve 7 billion people does not mean we should make decisions on
> global validation that impact our ability to serve the current set of
> users.

Agreed. But I believe the economic and security arguments I gave regarding fees 
and incentives still hold and are largely separate from the scalability issue. 
Please correct me if I overlooked something.

> Also, blocking a change because it's "more important to address issues
> such as..." other improvements will further slow down the discussion.
> I believe an increase will not prevent the development of other
> improvements that we need - in contrast, the sooner we can get over
> the limit (which, as you agree, needs to be changed at some point),
> the sooner we can get back to work.

An increase in block size at this time will exacerbate security concerns around 
nodes relying on other nodes to validate (particularly miners and wallets). 
It’s not really a matter of having limited developer resources that need to be 
budgeted, as you seem to suggest.

Regarding developments on properly handling fees, there must exist the economic 
need for it before there’s an earnest effort to solve it. Increasing the block 
size right now will, in all likelihood, delay this effort. I’d much prefer to 
first let the fee market evolve because it’s a crucial component to the 
protocol’s design and its security model…and so we can get a better sense for 
fee economics. Then we might be able to figure out better approaches to block 
size changes in the future that makes sense economically…perhaps with 
mechanisms that can dynamically adjust it to reflect resource availability and 
network load.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Benedict Chan via bitcoin-dev

On Thu, Jul 23, 2015 at 1:52 PM, Eric Lombrozo via bitcoin-dev
 wrote:
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo  wrote:
>>
>> Mainstream usage of cryptocurrency will be enabled primarily by direct
>> party-to-party contract negotiation…with the use of the blockchain primarily
>> as a dispute resolution mechanism. The block size isn’t about scaling but
>> about supply and demand of finite resources. As demand for block space
>> increases, we can address it either by increasing computational resources
>> (block size) or by increasing fees. But to do the former we need a way to
>> offset the increase in cost by making sure that those who contribute said
>> resources have incentive to do so.’
>
>
> I should also point out, improvements in hardware and network infrastructure
> can also reduce costs…and we could very well have a model where resource
> requirements can be increased as technology improves. However, currently,
> the computational cost of validation is clearly growing far more quickly
> than the cost of computational resources is going down. There are
> 7,000,000,000 people in the world. Payment networks in the developed world
> already regularly handle thousands of transactions a second. Even with
> highly optimized block propagation, pruning, and signature validation, we’re
> still many orders shy of being able to satisfy demand. To achieve mainstream
> adoption, we’ll have to pass through a period of quasi-exponential growth in
> userbase (until the market saturates…or until the network resources run
> out). Unless we’re able to achieve a validation complexity of O(polylog n)
> or better, it’s not a matter of having a negative attitude about the
> prospects…it’s just math. Whether we have 2MB or 20MB or 100MB blocks (even
> assuming the above mentioned optimizations and that the computational
> resources exist and are willing to handle it) we will not be able to satisfy
> demand if we insist on requiring global validation for all transactions.
>

Scaling the network will come in the form of a combination of many
optimizations. Just because we do not know for sure how to eventually
serve 7 billion people does not mean we should make decisions on
global validation that impact our ability to serve the current set of
users.

Also, blocking a change because it's "more important to address issues
such as..." other improvements will further slow down the discussion.
I believe an increase will not prevent the development of other
improvements that we need - in contrast, the sooner we can get over
the limit (which, as you agree, needs to be changed at some point),
the sooner we can get back to work.

>
> On Jul 23, 2015, at 1:26 PM, Jorge Timón  wrote:
>
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
>  wrote:
>
> Running a node certainly has real-world costs that shouldn't be ignored.
> There are plenty of advocates who argue that Bitcoin should strive to keep
> it feasible for the average user to run their own node (as opposed to
> Satoshi's vision of beefy servers in data centers.) My impression is that
> even most of these advocates agree that it will be acceptable to eventually
> increase block sizes as resources become faster and cheaper because it won't
> be 'pricing out' the average user from running their own node. If this is
> the case, it seems to me that we have a problem given that there is no
> established baseline for the acceptable performance / hardware cost
> requirements to run a node. I'd really like to see further clarification
> from these advocates around the acceptable cost of running a node and how we
> can measure the global reduction in hardware and bandwidth costs in order to
> establish a baseline that we can use to justify additional resource usage by
> nodes.
>
>
> Although I don't have a concrete proposals myself, I agree that
> without having any common notion of what the "minimal target hardware"
> looks like, it is very difficult to discuss other things that depend
> on that.
> If there's data that shows that a 100 usd raspberry pi with a 1 MB
> connection in say, India (I actually have no idea about internet
> speeds there) size X is a viable full node, then I don't think anybody
> can reasonably oppose to rising the block size to X, and such a
> hardfork can perfectly be uncontroversial.
> I'm exaggerating ultra-low specifications, but it's just an example to
> illustrate your point.
> There was a thread about formalizing such "minimum hardware
> requirements", but I think the discussion simply finished there:
> - Let's do this
> - Yeah, let's do it
> - +1, let's have concrete values, I generally agree.
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/list

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo  > wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct 
> party-to-party contract negotiation…with the use of the blockchain primarily 
> as a dispute resolution mechanism. The block size isn’t about scaling but 
> about supply and demand of finite resources. As demand for block space 
> increases, we can address it either by increasing computational resources 
> (block size) or by increasing fees. But to do the former we need a way to 
> offset the increase in cost by making sure that those who contribute said 
> resources have incentive to do so.’

I should also point out, improvements in hardware and network infrastructure 
can also reduce costs…and we could very well have a model where resource 
requirements can be increased as technology improves. However, currently, the 
computational cost of validation is clearly growing far more quickly than the 
cost of computational resources is going down. There are 7,000,000,000 people 
in the world. Payment networks in the developed world already regularly handle 
thousands of transactions a second. Even with highly optimized block 
propagation, pruning, and signature validation, we’re still many orders shy of 
being able to satisfy demand. To achieve mainstream adoption, we’ll have to 
pass through a period of quasi-exponential growth in userbase (until the market 
saturates…or until the network resources run out). Unless we’re able to achieve 
a validation complexity of O(polylog n) or better, it’s not a matter of having 
a negative attitude about the prospects…it’s just math. Whether we have 2MB or 
20MB or 100MB blocks (even assuming the above mentioned optimizations and that 
the computational resources exist and are willing to handle it) we will not be 
able to satisfy demand if we insist on requiring global validation for all 
transactions.

> On Jul 23, 2015, at 1:26 PM, Jorge Timón  wrote:
> 
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
>  wrote:
>> Running a node certainly has real-world costs that shouldn't be ignored.
>> There are plenty of advocates who argue that Bitcoin should strive to keep
>> it feasible for the average user to run their own node (as opposed to
>> Satoshi's vision of beefy servers in data centers.) My impression is that
>> even most of these advocates agree that it will be acceptable to eventually
>> increase block sizes as resources become faster and cheaper because it won't
>> be 'pricing out' the average user from running their own node. If this is
>> the case, it seems to me that we have a problem given that there is no
>> established baseline for the acceptable performance / hardware cost
>> requirements to run a node. I'd really like to see further clarification
>> from these advocates around the acceptable cost of running a node and how we
>> can measure the global reduction in hardware and bandwidth costs in order to
>> establish a baseline that we can use to justify additional resource usage by
>> nodes.
> 
> Although I don't have a concrete proposals myself, I agree that
> without having any common notion of what the "minimal target hardware"
> looks like, it is very difficult to discuss other things that depend
> on that.
> If there's data that shows that a 100 usd raspberry pi with a 1 MB
> connection in say, India (I actually have no idea about internet
> speeds there) size X is a viable full node, then I don't think anybody
> can reasonably oppose to rising the block size to X, and such a
> hardfork can perfectly be uncontroversial.
> I'm exaggerating ultra-low specifications, but it's just an example to
> illustrate your point.
> There was a thread about formalizing such "minimum hardware
> requirements", but I think the discussion simply finished there:
> - Let's do this
> - Yeah, let's do it
> - +1, let's have concrete values, I generally agree.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
 wrote:
> Running a node certainly has real-world costs that shouldn't be ignored.
> There are plenty of advocates who argue that Bitcoin should strive to keep
> it feasible for the average user to run their own node (as opposed to
> Satoshi's vision of beefy servers in data centers.) My impression is that
> even most of these advocates agree that it will be acceptable to eventually
> increase block sizes as resources become faster and cheaper because it won't
> be 'pricing out' the average user from running their own node. If this is
> the case, it seems to me that we have a problem given that there is no
> established baseline for the acceptable performance / hardware cost
> requirements to run a node. I'd really like to see further clarification
> from these advocates around the acceptable cost of running a node and how we
> can measure the global reduction in hardware and bandwidth costs in order to
> establish a baseline that we can use to justify additional resource usage by
> nodes.

Although I don't have a concrete proposals myself, I agree that
without having any common notion of what the "minimal target hardware"
looks like, it is very difficult to discuss other things that depend
on that.
If there's data that shows that a 100 usd raspberry pi with a 1 MB
connection in say, India (I actually have no idea about internet
speeds there) size X is a viable full node, then I don't think anybody
can reasonably oppose to rising the block size to X, and such a
hardfork can perfectly be uncontroversial.
I'm exaggerating ultra-low specifications, but it's just an example to
illustrate your point.
There was a thread about formalizing such "minimum hardware
requirements", but I think the discussion simply finished there:
- Let's do this
- Yeah, let's do it
- +1, let's have concrete values, I generally agree.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jameson Lopp via bitcoin-dev

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo  wrote:

>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp  wrote:
>
> Larger block sizes don't scale the network, they merely increase how much
> load we allow the network to bear.
>
>
> Very well put, Jameson. And the cost of bearing this load must be paid
> for. And unless we’re willing to accept that computational resources are
> finite and subject to the same economic issues as any other finite
> resource, our incentive model collapses the security of the network will be
> significantly at risk. Whatever your usability concerns may be regarding
> fees, when the security model’s busted usability issues are moot.
>
> Larger blocks support more transactions…but they also incur Ω(n) overhead
> in bandwidth, CPU, and space. These are finite resources that must be paid
> for somehow…and as we all already know miners are willing to cut corners on
> all this and push the costs onto others (not to mention wallets and online
> block explorers). And who can really blame them? It’s rational behavior
> given the skewed incentives.
>

Running a node certainly has real-world costs that shouldn't be ignored.
There are plenty of advocates who argue that Bitcoin should strive to keep
it feasible for the average user to run their own node (as opposed to
Satoshi's vision of beefy servers in data centers.) My impression is that
even most of these advocates agree that it will be acceptable to eventually
increase block sizes as resources become faster and cheaper because it
won't be 'pricing out' the average user from running their own node. If
this is the case, it seems to me that we have a problem given that there is
no established baseline for the acceptable performance / hardware cost
requirements to run a node. I'd really like to see further clarification
from these advocates around the acceptable cost of running a node and how
we can measure the global reduction in hardware and bandwidth costs in
order to establish a baseline that we can use to justify additional
resource usage by nodes.

- Jameson

>
> On the flip side, the scalability proposals will still require larger
> blocks if we are ever to support anything close to resembling "mainstream"
> usage. This is not an either/or proposition - we clearly need both.
>
>
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen  wrote:
> 
> There are lots of things we can do to decrease costs, and a lot of things 
> have ALREADY been done (e.g. running a pruned full node).

I also wanted to point out I fully agree with you that there are still many 
optimizations we could do to reduce costs, and think many of these things are 
certainly worth doing. However, there’s only so much we can do in this regard. 
Sooner or later we still run up against theoretical limitations. These 
optimizations can reduce costs by some factor…but they are highly unlikely to 
overcome the Ω(n) validation complexity barring some major algorithmic 
breakthrough (and perhaps allowing for nondeterminism, perhaps accepting a 
negligible but finite error probability).

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 23, 2015, at 12:35 PM, Gavin Andresen  wrote:
> 
> 
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo  > wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct 
> party-to-party contract negotiation…with the use of the blockchain primarily 
> as a dispute resolution mechanism. The block size isn’t about scaling but 
> about supply and demand of finite resources. As demand for block space 
> increases, we can address it either by increasing computational resources 
> (block size) or by increasing fees. But to do the former we need a way to 
> offset the increase in cost by making sure that those who contribute said 
> resources have incentive to do so.
> 
> There are so many things wrong with this paragraph I just can't let it slide.
> 
> "Mainstream usage will be enabled primarily by..."  Maybe. Maybe not, we 
> don't know what use case(s) will primarily take cryptocurrency mainstream. I 
> believe it is a big mistake to pick one and bet "THIS is going to be the 
> winner".
> 
> "we can address it either by... or..."  False dichotomy. There are lots of 
> things we can do to decrease costs, and a lot of things have ALREADY been 
> done (e.g. running a pruned full node).  I HATE the "it must be this or that" 
> "us or them" attitude, it fosters unproductive bickering and negativity.
> 
> (and yes, I'm human, I'm sure you can find instances in the recent past where 
> I did it, too... mea culpa)
> 
> --
> --
> Gavin Andresen
> 

Regarding rhetoric, fair enough, Gavin - I’m human and I could be wrong. It is 
my educated best guess, a conclusion I’ve drawn given my understanding of 
computer science, economics, and what’s been happening in this space.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Gavin Andresen via bitcoin-dev

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo  wrote:

> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.

There are so many things wrong with this paragraph I just can't let it
slide.

"Mainstream usage will be enabled primarily by..."  Maybe. Maybe not, we
don't know what use case(s) will primarily take cryptocurrency mainstream.
I believe it is a big mistake to pick one and bet "THIS is going to be the
winner".

"we can address it either by... or..."  False dichotomy. There are lots of
things we can do to decrease costs, and a lot of things have ALREADY been
done (e.g. running a pruned full node).  I HATE the "it must be this or
that" "us or them" attitude, it fosters unproductive bickering and
negativity.

(and yes, I'm human, I'm sure you can find instances in the recent past
where I did it, too... mea culpa)

-- 
--
Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 11:10 AM, Jameson Lopp  wrote:
> 
> Larger block sizes don't scale the network, they merely increase how much 
> load we allow the network to bear.

Very well put, Jameson. And the cost of bearing this load must be paid for. And 
unless we’re willing to accept that computational resources are finite and 
subject to the same economic issues as any other finite resource, our incentive 
model collapses the security of the network will be significantly at risk. 
Whatever your usability concerns may be regarding fees, when the security 
model’s busted usability issues are moot.

Larger blocks support more transactions…but they also incur Ω(n) overhead in 
bandwidth, CPU, and space. These are finite resources that must be paid for 
somehow…and as we all already know miners are willing to cut corners on all 
this and push the costs onto others (not to mention wallets and online block 
explorers). And who can really blame them? It’s rational behavior given the 
skewed incentives.

> On the flip side, the scalability proposals will still require larger blocks 
> if we are ever to support anything close to resembling "mainstream" usage. 
> This is not an either/or proposition - we clearly need both.

Mainstream usage of cryptocurrency will be enabled primarily by direct 
party-to-party contract negotiation…with the use of the blockchain primarily as 
a dispute resolution mechanism. The block size isn’t about scaling but about 
supply and demand of finite resources. As demand for block space increases, we 
can address it either by increasing computational resources (block size) or by 
increasing fees. But to do the former we need a way to offset the increase in 
cost by making sure that those who contribute said resources have incentive to 
do so.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Mike Hearn via bitcoin-dev

>
> You complained about the lack of quantitative analysis being used, I gave
> it to you. There's nothing "negative" about displaying data which doesn't
> completely back up what your position is, I made a sensible conclusion
> based on the facts I have in front of me. Ignoring the information I
> collected and presented for you is incredibly childish.
>

He hasn't ignored you, and he wasn't responding to your email specifically
but rather the general attitude displayed in this forum for the last
several months (and I'd argue the last year or so).

Your data is interesting but ultimately tell us what we already know - that
the next bottleneck after the hard coded limit could easily be propagation
speed. The solution is likely to be a better protocol. Matt's custom
network already has optimised things, rolling some of those ideas into the
P2P protocol may be a good place to start, or something fancier like IBLTs.

Regardless, the *next* bottleneck is not the protocol, it's the hard cap.

So the conclusion remains unchanged: Bitcoin must grow, and solutions for
scaling it up will be found as the need arises.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 7:14 PM, Robert Learney via bitcoin-dev
 wrote:
> That’s not exactly what’s happened though, is it Cipher? Gavin put forward
> 20Mb then after analysis and discussion has moved to 8Mb, whereas the other
> camp of core developers is firmly stuck in the ‘1Mb or bust’ group.

His proposals actually end up with 20 GB and 8 GB respectively. I'm
not sure if you count me on the ‘1Mb or bust’ group, but I'm not
firmly stuck anywhere.
I've never said that the block size should never be increased, that it
shouldn't change now, that 8 MB is too much or anything like that
because I simply don't have the data (and I don't think anybody has
it). I invite people to collect that data and I've written a patch to
bitcoin to facilitate that task.
Do you really think that's an obstructionist attitude?

My position could be summarized like this:

- We're going to hit the limit tomorrow, and Bitcoin will fail when we do.
- I'm not so sure we will hit the limit tomorrow but even accepting
the premise, this is a non sequitur. Fees will probably rise, but
that's not necessarily a bad thing. A limit that is meaningful in
practice must happen eventually, mustn't it? If not now, when are we
planning to let that "disaster" happen?
- That's too far in the future to worry about it.
- Does that mean waiting, say, 4 more subsidy halvings, 8? 10?
- Just don't worry about it

I'm not opposing to anything, I'm just patiently waiting for some
answers that never seem to arrive.
If people interpret questions or the fact that when people use
fallacious arguments I like to identify the concrete fallacy they're
using and state it so publicly (I do it for sport and "against all
sides") as "opposition", I don't really think I can do anything about
it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev 
>  wrote:
> 
> That’s not exactly what’s happened though, is it Cipher? Gavin put forward 
> 20Mb then after analysis and discussion has moved to 8Mb, whereas the other 
> camp of core developers is firmly stuck in the ‘1Mb or bust’ group.

The issue isn’t really whether it’s 1MB or 2MB or 4MB or 8MB or whatever. First 
of all, the burden of justifying this change should be on those proposing a 
hardfork. The default is to not have a hard fork. Second of all, it’s not 
really about *whether* the block size is increased…but about *when* and *how* 
it is increased. There’s a good argument to be made that right now it is more 
important to address issues such as the fact that validation is so expensive 
(which as others and myself have pointed out has led to a collapse of the 
security model in the past, requiring manual intervention to temporarily 
“fix”)…and the fact that we don’t yet have great solutions to dealing with 
fees, which are a crucial component of the design of the protocol.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Robert Learney via bitcoin-dev

That’s not exactly what’s happened though, is it Cipher? Gavin put forward 20Mb 
then after analysis and discussion has moved to 8Mb, whereas the other camp of 
core developers is firmly stuck in the ‘1Mb or bust’ group.

-Rob.

> On 23 Jul 2015, at 17:50, cipher anthem via bitcoin-dev 
>  wrote:
> 
> Why not help on a project that actually seems to offer great scalability like 
> the lightning network? There have been great progress there.
>  
> Seems like you did your calculations some time ago to prove that your 
> increase is reasonable, yet when others come with different numbers that 
> don't support your position you say it doesn't matter.
>  
> Sent: Thursday, July 23, 2015 at 4:28 PM
> From: "Gavin Andresen via bitcoin-dev" 
> To: "Tom Harding" 
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
> On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev 
>  > wrote:
> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> > they will simply advance the front and start another battle, because
> > their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> > Mike, show me that I'm wrong on this point. Please, answer my question
> > this time. If "not now", then when?
> 
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.
> 
> We haven't tried yet.  I can't answer for the people you asked, but
> personally I haven't thought much about when we should declare failure.
>  
> Yes! Lets plan for success!
>  
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been 
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning 
> disks),
> what if the network is attacked?  (attacked HOW???), current p2p network is 
> using
> the simplest, stupidest possible block propagation algorithm...)"
>  
> ... to "lets work together and work through the problems and scale it up."
>  
> I'm frankly tired of all the negativity here; so tired of it I've decided to 
> mostly ignore
> all the debate for a while, not respond to misinformation I see being spread
> (like "miners have some incentive to create slow-to-propagate blocks"),
> work with people like Tom and Mike who have a 'lets get it done' attitude, and
> focus on what it will take to scale up.
>  
> --
> --
> Gavin Andresen
>  
> ___ bitcoin-dev mailing list 
> bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 1:42 AM, Cory Fields via bitcoin-dev
 wrote:
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.

For what is worth, here's yet another piece of code from the "doing
nothing" side:

https://github.com/bitcoin/bitcoin/pull/6382

It allows you to create a regtest-like testchain with a maximum block
size chosen at run time.
Rusty used a less generic testchain for testing 8 MB blocks:

http://rusty.ozlabs.org/?p=509

Unfortunately I don't know of anybody that has used my patch to test
any other size (maybe there's not that much interest in testing other
sizes after all?).

I'm totally in favor of preemptively adapting the code so that when a
new blocksize is to be deployed, adapting the code is not a problem.
Developers can agree on many changes in the code without users having
to agree on a concrete block size first.
I offer my help to do that. That's what I'm trying to do in #6382 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008961.html
but to my surprise that gets disregarded as "doing nothing" and as
"having a negative attitude", when not simply ignored.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Slurms MacKenzie via bitcoin-dev

> Sent: Thursday, July 23, 2015 at 7:28 PM
> From: "Gavin Andresen via bitcoin-dev" 
> To: "Tom Harding" 
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
> 
> I'm frankly tired of all the negativity here

You complained about the lack of quantitative analysis being used, I gave it to 
you. There's nothing "negative" about displaying data which doesn't completely 
back up what your position is, I made a sensible conclusion based on the facts 
I have in front of me. Ignoring the information I collected and presented for 
you is incredibly childish. 


> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been 
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning 
> disks),

I should stress that I didn't present that timing information as a dig against 
their software, it just happens to be something I have direct access to and can 
prevent clean data about. The point that I was attempting to make is that 
Bitcoin Core isn't the only piece of software in the ecosystem with performance 
problems, given that a large portion of users have Electrum wallets it would be 
insane not to consider the impact changes will have on the people that 
charitably run servers for the community. 

By the way, is that an offer to buy my dedicated server some new SSDs? 


> work with people like Tom and Mike who have a 'lets get it done' attitude, and
> focus on what it will take to scale up.

Scaling up isn't tweaking parameters and ignoring the brickwork falling around 
your head. You mention that you think the merkle tree can hold an unlimited 
amount of information, that's all very well so long as people can actually 
validate the thing. Miners aren't even willing to validate their own blocks at 
the peril of losing $7000 USD (on two occasions now), so why would anybody 
else? 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Jameson Lopp via bitcoin-dev

On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning
> disks),
> what if the network is attacked?  (attacked HOW???), current p2p network
> is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
>
>
> Let’s be absolutely clear about one thing - block size increases are *not*
> about scaling the network. Can we please stop promoting this falsehood? It
> doesn’t matter by what number we multiply the block size…we can NEVER
> satisfy the full demand if we insist on every single transaction from every
> single person everywhere in the world being on the blockchain…it’s just
> absurd.
>
>
Increasing block size only temporarily addresses one significant issue -
> how to postpone having to deal with transaction fees, which by design, are
> how the cost of operating the Bitcoin network (which is already very
> expensive) is supposed to be paid for ultimately. Suggesting we avoid
> dealing with this constitutes a new economic policy - dealing with it is
> the default economic policy we’ve all known about from the beginning…so
> please stop claiming otherwise.
>
>
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear. On the flip side, the scalability
proposals will still require larger blocks if we are ever to support
anything close to resembling "mainstream" usage. This is not an either/or
proposition - we clearly need both.

- Jameson

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Why not help on a project that actually seems to offer great scalability
> like the lightning network? There have been great progress there.
>
>
> Exactly. There’s been tremendous progress here in addressing scalability,
> yet I don’t see you participating in that discussion, Gavin.
>
> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
>
>
> I agree with what you’re saying, Jorge…but It’s even worse than that. The
> July 4th fork illustrated that the security model of the network itself
> could be at risk from the increasing costs in validation causing people to
> rely on others to validate for them…and increasing block size only makes
> the problem worse.
>
> - Eric Lombrozo
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
 wrote:
> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
>
>> If the user expectation is that a price would never arise because
>> supply is going to be increased ad infinitum and they will always be
>> able to send fast in-chain bitcoin transactions for free, just like
>> breath air (an abundant resource) for free, then we should change that
>> expectation as soon as possible.
>
> No.  We should accept that reality may change, and we should promote
> understanding of that fact.
>
> We should not artificially manipulate the market "as soon as possible,"
> since we ourselves don't know much at all about how the market will
> unfold in the future.

We know perfectly well that the system will need to eventually be
sustained by fees.
We should stop misinforming new users talking them about how bitcoin
transactions "are free", because they're clearly not.

>> the criteria for the consensus block size should be purely based on
>> technological capacity (propagation benchmarking, etc) and
>> centralization concerns
>
> Right, purely these.  There is no place for artificially manipulating
> expectations.

Am I "artificially manipulating expectations" ?

>> they will simply advance the front and start another battle, because
>> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
>> Mike, show me that I'm wrong on this point. Please, answer my question
>> this time. If "not now", then when?
>
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.

Timestamping data using the blockchain is not the same as including
that the data in the blockchain itself because the later is a scarce
resource.
The "timestamping space" is already unlimited today with no changes.
You can use a bitcoin transaction to timestamp an unbounded amount of
external data using exactly 0 extra bytes in your transaction!
Here's the code: https://github.com/Blockstream/contracthashtool

And I'm very interested in scaling Bitcoin, I just disagree that
changing a constant is a "scaling solution".

On Thu, Jul 23, 2015 at 6:28 PM, Gavin Andresen via bitcoin-dev
 wrote:
> On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev
>> We haven't tried yet.  I can't answer for the people you asked, but
>> personally I haven't thought much about when we should declare failure.
>
>
> Yes! Lets plan for success!

I extremely disagree that having a block limit is failure. It's a
design decision to protect the system against centralization (which we
will be able to rise as we solve technical and centralization problems
we have today).
But thank you for being more clear about it now, Gavin. You won't stop
on a 8GB or 32GB limit because you think having ANY limit would be a
failure.
Is that correct?
If not, can you please answer clearly when and why you think the
blocksize should be lower than demand (when you will be ok with
bitcoin users having to pay fees for the service they're enjoying)?
If your answer is "never", I would prefer to hear it from you than
just concluding it by the lack of an answer.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev 
>  wrote:
> 
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been 
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning 
> disks),
> what if the network is attacked?  (attacked HOW???), current p2p network is 
> using
> the simplest, stupidest possible block propagation algorithm...)"
> 
> ... to "lets work together and work through the problems and scale it up."

Let’s be absolutely clear about one thing - block size increases are *not* 
about scaling the network. Can we please stop promoting this falsehood? It 
doesn’t matter by what number we multiply the block size…we can NEVER satisfy 
the full demand if we insist on every single transaction from every single 
person everywhere in the world being on the blockchain…it’s just absurd.

Increasing block size only temporarily addresses one significant issue - how to 
postpone having to deal with transaction fees, which by design, are how the 
cost of operating the Bitcoin network (which is already very expensive) is 
supposed to be paid for ultimately. Suggesting we avoid dealing with this 
constitutes a new economic policy - dealing with it is the default economic 
policy we’ve all known about from the beginning…so please stop claiming 
otherwise.

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev 
>  wrote:
> 
> Why not help on a project that actually seems to offer great scalability like 
> the lightning network? There have been great progress there.

Exactly. There’s been tremendous progress here in addressing scalability, yet I 
don’t see you participating in that discussion, Gavin.

> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev 
>  wrote:
> 
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".

I agree with what you’re saying, Jorge…but It’s even worse than that. The July 
4th fork illustrated that the security model of the network itself could be at 
risk from the increasing costs in validation causing people to rely on others 
to validate for them…and increasing block size only makes the problem worse.

- Eric Lombrozo

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread cipher anthem via bitcoin-dev

Why not help on a project that actually seems to offer great scalability like the lightning network? There have been great progress there.

Seems like you did your calculations some time ago to prove that your increase is reasonable, yet when others come with different numbers that don't support your position you say it doesn't matter.

Sent: Thursday, July 23, 2015 at 4:28 PM
From: "Gavin Andresen via bitcoin-dev"
To: "Tom Harding"
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> they will simply advance the front and start another battle, because
> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> Mike, show me that I'm wrong on this point. Please, answer my question
> this time. If "not now", then when?

Bitcoin has all the hash power. The merkle root has effectively
infinite capacity. We should be asking HOW to scale the supporting
information propagation system appropriately, not WHEN to limit the
capacity of the primary time-stamping machine.

We haven't tried yet. I can't answer for the people you asked, but
personally I haven't thought much about when we should declare failure.

Yes! Lets plan for success!

I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been optimized

(by the way: you should run on SSDs, LevelDB isn't designed for spinning disks),

what if the network is attacked? (attacked HOW???), current p2p network is using

the simplest, stupidest possible block propagation algorithm...)"

... to "lets work together and work through the problems and scale it up."

I'm frankly tired of all the negativity here; so tired of it I've decided to mostly ignore

all the debate for a while, not respond to misinformation I see being spread

(like "miners have some incentive to create slow-to-propagate blocks"),

work with people like Tom and Mike who have a 'lets get it done' attitude, and

focus on what it will take to scale up.

--
Gavin Andresen

___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Gavin Andresen via bitcoin-dev

On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> > they will simply advance the front and start another battle, because
> > their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> > Mike, show me that I'm wrong on this point. Please, answer my question
> > this time. If "not now", then when?
>
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.
>
> We haven't tried yet.  I can't answer for the people you asked, but
> personally I haven't thought much about when we should declare failure.

Yes! Lets plan for success!

I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been
optimized
(by the way: you should run on SSDs, LevelDB isn't designed for spinning
disks),
what if the network is attacked?  (attacked HOW???), current p2p network is
using
the simplest, stupidest possible block propagation algorithm...)"

... to "lets work together and work through the problems and scale it up."

I'm frankly tired of all the negativity here; so tired of it I've decided
to mostly ignore
all the debate for a while, not respond to misinformation I see being spread
(like "miners have some incentive to create slow-to-propagate blocks"),
work with people like Tom and Mike who have a 'lets get it done' attitude,
and
focus on what it will take to scale up.

-- 
--
Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Tom Harding via bitcoin-dev

On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:

> If the user expectation is that a price would never arise because
> supply is going to be increased ad infinitum and they will always be
> able to send fast in-chain bitcoin transactions for free, just like
> breath air (an abundant resource) for free, then we should change that
> expectation as soon as possible. 

No.  We should accept that reality may change, and we should promote
understanding of that fact.

We should not artificially manipulate the market "as soon as possible,"
since we ourselves don't know much at all about how the market will
unfold in the future.

> the criteria for the consensus block size should be purely based on
> technological capacity (propagation benchmarking, etc) and
> centralization concerns

Right, purely these.  There is no place for artificially manipulating
expectations.

> they will simply advance the front and start another battle, because
> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> Mike, show me that I'm wrong on this point. Please, answer my question
> this time. If "not now", then when?

Bitcoin has all the hash power.  The merkle root has effectively
infinite capacity.  We should be asking HOW to scale the supporting
information propagation system appropriately, not WHEN to limit the
capacity of the primary time-stamping machine.

We haven't tried yet.  I can't answer for the people you asked, but
personally I haven't thought much about when we should declare failure.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Wed, Jul 22, 2015 at 8:24 PM, Jeff Garzik via bitcoin-dev
 wrote:
> To the user, talk of a fee market is equivalent to talk about block size -
> various opinions are tossed about, but it doesn't really impact them.  Fees
> have been low for 6 years.
>
> We see this with the actual data - no fee pressure on average for the
> entirety of bitcoin's history.  We see this with the recent stress tests,
> which exposed dumb wallet behavior WRT fees.   Users -and software- had the
> expectation

That's because demand for space (transactions) was always lower than
the supply (block space) and no market price (fees) arose.
Now the market (not the supply) has changed: demand has increased.
With a fixed supply, it was perfectly reasonable to expect that fees
would rise (from zero).
If the user expectation is that a price would never arise because
supply is going to be increased ad infinitum and they will always be
able to send fast in-chain bitcoin transactions for free, just like
breath air (an abundant resource) for free, then we should change that
expectation as soon as possible.

> Remember, this is not a judgement on whether or not fee market/pressure
> should exist.  It is simply a factual observation that users/market have not
> experienced this new economic policy.

It is not a new economic policy, it is a new market situation. Please,
stop saying that.

> That opens the question - why now?   Why make bitcoin growth more expensive
> at this time in its young life?  Many smart people would prefer that bitcoin
> continue to grow, rather than making the system more expensive to use right
> now.

If "not now", then when?
I've been asking that question repeatedly and the closest to an answer
that I got from the "not now side" was "the hashrate being paid by
fees instead of subsidy it's too far away in the future to worry about
it now".
That answer is not very satisfying to me.

> Choosing "let a fee market develop" -- today -- is picking economic sides,
> picking winners & losers in the market.

Yes, business plans that rely on free in-chain transactions may fail,
business plans that are planning for a future with fees and without
subsidies may get the advantage they deserve. But "kicking the can" is
just picking winners and losers in opposite way.
You seem to imply that rewarding inertia and laziness is the best
option for short-term bitcoin adoption and you may be right.
I simply think these arguments shouldn't be considered at all: the
criteria for the consensus block size should be purely based on
technological capacity (propagation benchmarking, etc) and
centralization concerns (those in the "not now side" have already seen
this 2-year-old video[1], right?).
But it seems to me that the "not now side" has no centralization
concerns at all and their true position is "not ever hit the blocksize
limit", that's the only explanation I can find to their lack of
answers to the "when do you think we should allow users to notice that
there's a limit in the blocksize to guarantee that the system can be
decentralized?". I've even read that the consensus limit "was just a
temporary measure". Then Gavin lowers his 32 GB limit to an 8 GB
"compromise".
Maybe I'm being paranoid, but I'm really afraid that when the  "not
now side" wins this battle (like they've won for 6 years, as you say)
they will simply advance the front and start another battle, because
their true hidden faction is the "not ever side".
Please, Jeff, Gavin, Mike, show me that I'm wrong on this point.
Please, answer my question this time.
If "not now", then when?

[1] https://www.youtube.com/watch?v=cZp7UGgBR0I
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Gareth Williams via bitcoin-dev




-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've seen a lot of talk on this list debating the role of Bitcoin Core and its 
maintainers WRT consensus, typically focused around whether they can 
technically force anyone to run their code (of course, they can't.)

I've yet to see the discussion framed in terms of influence and leadership. 
Which is why I want to highlight:

>I believe it is the responsibility of the maintainers/developers of
>Bitcoin
>Core to create software which helps guarantee the security and
>operation of
>the Bitcoin network

Perhaps s/helps guarantee/promotes/ , but this stands out as an excellent 
description of Bitcoin Core's relationship to the Bitcoin network.

Defaults are powerful. Users technically /can/ compile and run any code they 
like, but very few even bother to change configurable settings. They just want 
a trusted brand ("Bitcoin Core") that does the right thing out of the box. 
Bitcoin Core and its maintainers play a valuable /leadership/ role for the 
network. Whether they can force people to run their code is uninteresting -- 
people trust them.

That trust is well earned, precisely because they have always promoted the 
operation and security of the network.

In light of this responsibility it seems unreasonable for anyone to expect Core 
maintainers to promote patches that endanger network consensus (e.g. user 
configurable consensus parameters.)

Consensus is order of business #1. If we can't all agree to use the same money 
then the grand experiment is resolved as a failure. Everyone has consensus 
parameters they'd (strongly) prefer. Somebody needs to heard us all toward 
using the same ones, sometimes even in the face of very high costs.

- -Gareth

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFABAEBCgAqBQJVsKPgIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEZuEIAIKC9jTO33y4YC/cl1mO/+ux9YUqBlFUpuElKjNe
NLUIqPANrMV3nTjUm666Hk3tVHk8IpYLUU1pRuYBAT17d1t/2bFC4CpfpWssF9Nw
YhoYOKKVMvLUR4DRlkyhMD4YxorJ/TGiuEaFD4K/1s5uKf1+7Vj/BTi+SP+AIAIW
gTbn2CA3T4n8WjDYADE0dqcYSqzt2M1fjXB+Ld95JGLun8m+6lDPhFy/o5aGhBk6
5j86SITT9UtyyA6oaV5NNNgumcNBievnVwjTxjaWm8CBJlJ5jNpW65PQGkoSnCgz
TpYt/wZHcdSqBeNHyno9XaEBSm99Ylk3i2Z1dGQwrSsZU0Q=
=0pac
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-23 Thread Ross Nicoll via bitcoin-dev

The code so far is fairly limited in scope, essentially making it 
possible to change the values in consensus/params.h based on block 
height. The actual code to interpret those values does need to be 
provided ahead of time, of course, so there's still developer time to 
implement, it just moves consensus arguments to the users.


Loading the values from disk rather than hard-coding them is a 
reasonably straight forward extension to the code, in theory. The 
existing work has application-specific changes that would need stripping 
out, but you can get an idea of what this would look like from 
https://github.com/rnicoll/dogecoin/commit/949b1ccd88ff13c74a3c1a7b9faa7f36c1085904


Ross

On 23/07/2015 01:43, Eric Lombrozo via bitcoin-dev wrote:

On Jul 22, 2015, at 5:34 PM, Cory Fields  wrote:

On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo  wrote:

On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:

On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:

FWIW, I had worked on something similar a while back:
https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf

I like the idea in principle…but we should require a new genesis block,
different magic bytes, and a different network port at the very least. :)


Not sure if serious, so I'll assume you are :)

Only being partly serious - I strongly am in favor of a sufficiently 
modularized codebase that swapping out consensus rules is fairly 
straightforward and easy to test. I’m not in favor of encouraging forking an 
existing blockchain without having mechanisms in place to gracefully merge back 
without significant network disruptions. We do not have this yet.


Again, why? If someone wants to create a scamcoin, they can. If
someone wants to burn money on a scamcoin, equally, they can. I'm not
sure how this is any different. If someone manages to garner realistic
support for a hard-fork, I don't see the benefit in forcing them to
use forked software.. that only leaves Core in the middle because it's
forced to choose a side (not choosing is unfortunately a side as
well). It doesn't remove the reality of the split.

In general, new consensus rules are not trivial to implement. Block size limits 
are exceptional in being so simple to change in the code. So what you’re 
proposing sounds more like a plugin model supporting dynamic linking than a 
configuration file.


Why? The idea in this case would be to allow the user to decide
between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
runtime rather than the likely alternative of "./bitcoind" vs
"./bitcoin-fork”.

That’s exactly what my coinparams_new branch does. Adding a parameter for 
maximum block size would be straightforward.


Chain params may be identical other than the value of some future
event (miner vote for example), in which case the configs would run
identically until that point.

Yes, indeed - this would be a special case.


If your concern is about nodes with different configs communicating
with eachother, I'd like to reiterate: the idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

I do not encourage anyone to try to fork an existing blockchain without first 
securing overwhelming (near unanimous) consensus…or without having yet built a 
mechanism that can merge divergent chains gracefully.

Well of course. It would be a terrible idea. People would try it and
fail, and lose money. But for those crying foul at Core for being the
consensus/policy gatekeeper, it seems to me that user-selectable
params is the only logical solution.

The real problem isn’t so much the difficulty of creating forks of the codebase 
- but the fact that unless a fork has overwhelming support, blockchains cannot 
guarantee irreversibility of transactions…which defeats their entire purpose.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Edmund Edgar via bitcoin-dev

> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.

This is a really interesting thread. Since we're no longer talking
about a consensus of the core committers, which would be central
control, but instead something broader, could you say a bit more about
what this consensus might look like, and how we'll know if we've got
one?

In plain language "no controversy" sounds like very high bar for a
diverse community like this; Even bringing in P2SH kicked up a fair
bit of fur and feathers. Do you have a definition in mind where it
isn't an _impossibly_ high one?

-- 
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
supp...@realitykeys.com
https://www.realitykeys.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 22, 2015, at 3:01 PM, Mike Hearn  wrote:
> 
> Until we’re able to merge blockchain forks like we’re able to merge git repo 
> forks, the safest option is no fork.
> 
> Block chain forks merge in the same way as git forks all the time, that's how 
> the reorg algorithm works. Transactions that didn't make it into the 
> post-reorg chain go back into the mempool and miners attempt to reinclude 
> them: this is the "merge" process. If they now conflict with other 
> transactions they are dropped and this is "resolving merge conflicts".
> 
> However you have to want to merge with the new chain. If your software is 
> programmed not to do that out of some bizarre belief that throttling your own 
> user base is a good idea, then of course, no merge happens. Once you stop 
> telling your computer to do that, you can then merge (reorg) back onto the 
> main chain again.
> 

Mike, you might be surprized to learn that there are other hard fork proposals 
out there besides increasing block size.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Eric Voskuil via bitcoin-dev

On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote:
> Only being partly serious - I strongly am in favor of a sufficiently
modularized codebase that swapping out consensus rules is fairly
straightforward and easy to test...

We (libbitcoin) have taken the time to publish and maintain bitcoind's
"libbitcoinconsensus" source files as an independent C++ library (with
Java and Python bindings).

https://en.bitcoin.it/wiki/Libbitcoin_Consensus

It can be easily verified against bitcoind sources and in builds of
libbitcoin-blockchain it can be swapped out for libbitcoin's native
consensus checks.

https://en.bitcoin.it/wiki/Libbitcoin_Blockchain#Consensus_Validation

So there is really no reason to consider the original client synonymous
with consensus. I initially argued for this library to be natively
isolated from bitcoind, but that didn't seem to be in the cards so we
did it independently.

In any case I agree with your stated need for this isolation (if not the
means) for the reasons you state. The community needs to move beyond a
largely singular and monolithic codebase that is holding that position
in part due to fear about consensus bug forks.

To make choice regarding consensus an actual choice (and thereby actual
consensus) the modularity you suggest is essential. One must be able to
take new developments without having to take consensus changes. The
option to fork the codebase is not reasonable for most people. At this
point there is no defensible reason for coupling consensus checks with
other features.

e




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 22, 2015, at 5:34 PM, Cory Fields  wrote:
> 
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo  wrote:
>> 
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:
>>> 
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
 FWIW, I had worked on something similar a while back:
 https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
 
 I like the idea in principle…but we should require a new genesis block,
 different magic bytes, and a different network port at the very least. :)
 
>>> 
>>> Not sure if serious, so I'll assume you are :)
>> 
>> Only being partly serious - I strongly am in favor of a sufficiently 
>> modularized codebase that swapping out consensus rules is fairly 
>> straightforward and easy to test. I’m not in favor of encouraging forking an 
>> existing blockchain without having mechanisms in place to gracefully merge 
>> back without significant network disruptions. We do not have this yet.
>> 
> 
> Again, why? If someone wants to create a scamcoin, they can. If
> someone wants to burn money on a scamcoin, equally, they can. I'm not
> sure how this is any different. If someone manages to garner realistic
> support for a hard-fork, I don't see the benefit in forcing them to
> use forked software.. that only leaves Core in the middle because it's
> forced to choose a side (not choosing is unfortunately a side as
> well). It doesn't remove the reality of the split.

In general, new consensus rules are not trivial to implement. Block size limits 
are exceptional in being so simple to change in the code. So what you’re 
proposing sounds more like a plugin model supporting dynamic linking than a 
configuration file.

>>> Why? The idea in this case would be to allow the user to decide
>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>> runtime rather than the likely alternative of "./bitcoind" vs
>>> "./bitcoin-fork”.
>> 
>> That’s exactly what my coinparams_new branch does. Adding a parameter for 
>> maximum block size would be straightforward.
>> 
>>> Chain params may be identical other than the value of some future
>>> event (miner vote for example), in which case the configs would run
>>> identically until that point.
>> 
>> Yes, indeed - this would be a special case.
>> 
>>> If your concern is about nodes with different configs communicating
>>> with eachother, I'd like to reiterate: the idea really is no different
>>> than suggesting that someone fork the codebase and implement their own
>>> changes, it just cuts out most of the work required.
>> 
>> I do not encourage anyone to try to fork an existing blockchain without 
>> first securing overwhelming (near unanimous) consensus…or without having yet 
>> built a mechanism that can merge divergent chains gracefully.
> 
> Well of course. It would be a terrible idea. People would try it and
> fail, and lose money. But for those crying foul at Core for being the
> consensus/policy gatekeeper, it seems to me that user-selectable
> params is the only logical solution.

The real problem isn’t so much the difficulty of creating forks of the codebase 
- but the fact that unless a fork has overwhelming support, blockchains cannot 
guarantee irreversibility of transactions…which defeats their entire purpose.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev 
>  wrote:
> 
> On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
>> It would be irresponsible and dangerous to the network and thus the users of 
>> the software to risk forks, or to take a leading role in pushing dramatic 
>> changes.
> 
> Count me among those who see allowing bitcoin to become space-constrained, 
> without technical reason, as a dramatic change. Especially when the reasons 
> cited in support are
> 
> - Various species of vaporware
> - Amateurish economic thinking surrounding fees
> - "We don't support it because not everyone supports it because we don't 
> support it because ..." infinite descent
> 

I take it you mean allowing bitcoin to *not* become space-constrained - because 
all real-world computers are space-constrained…


> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Cory Fields via bitcoin-dev

On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo  wrote:
>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
>>> FWIW, I had worked on something similar a while back:
>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>
>>> I like the idea in principle…but we should require a new genesis block,
>>> different magic bytes, and a different network port at the very least. :)
>>>
>>
>> Not sure if serious, so I'll assume you are :)
>
> Only being partly serious - I strongly am in favor of a sufficiently 
> modularized codebase that swapping out consensus rules is fairly 
> straightforward and easy to test. I’m not in favor of encouraging forking an 
> existing blockchain without having mechanisms in place to gracefully merge 
> back without significant network disruptions. We do not have this yet.
>

Again, why? If someone wants to create a scamcoin, they can. If
someone wants to burn money on a scamcoin, equally, they can. I'm not
sure how this is any different. If someone manages to garner realistic
support for a hard-fork, I don't see the benefit in forcing them to
use forked software.. that only leaves Core in the middle because it's
forced to choose a side (not choosing is unfortunately a side as
well). It doesn't remove the reality of the split.

>> Why? The idea in this case would be to allow the user to decide
>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>> runtime rather than the likely alternative of "./bitcoind" vs
>> "./bitcoin-fork”.
>
> That’s exactly what my coinparams_new branch does. Adding a parameter for 
> maximum block size would be straightforward.
>
>> Chain params may be identical other than the value of some future
>> event (miner vote for example), in which case the configs would run
>> identically until that point.
>
> Yes, indeed - this would be a special case.
>
>> If your concern is about nodes with different configs communicating
>> with eachother, I'd like to reiterate: the idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>
> I do not encourage anyone to try to fork an existing blockchain without first 
> securing overwhelming (near unanimous) consensus…or without having yet built 
> a mechanism that can merge divergent chains gracefully.

Well of course. It would be a terrible idea. People would try it and
fail, and lose money. But for those crying foul at Core for being the
consensus/policy gatekeeper, it seems to me that user-selectable
params is the only logical solution.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Tom Harding via bitcoin-dev


On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
It would be irresponsible and dangerous to the network and thus the 
users of the software to risk forks, or to take a leading role in 
pushing dramatic changes.


Count me among those who see allowing bitcoin to become 
space-constrained, without technical reason, as a dramatic change. 
Especially when the reasons cited in support are


 - Various species of vaporware
 - Amateurish economic thinking surrounding fees
 - "We don't support it because not everyone supports it because we 
don't support it because ..." infinite descent



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:
> 
> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
>> FWIW, I had worked on something similar a while back:
>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>> 
>> I like the idea in principle…but we should require a new genesis block,
>> different magic bytes, and a different network port at the very least. :)
>> 
> 
> Not sure if serious, so I'll assume you are :)

Only being partly serious - I strongly am in favor of a sufficiently 
modularized codebase that swapping out consensus rules is fairly 
straightforward and easy to test. I’m not in favor of encouraging forking an 
existing blockchain without having mechanisms in place to gracefully merge back 
without significant network disruptions. We do not have this yet.

> Why? The idea in this case would be to allow the user to decide
> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
> runtime rather than the likely alternative of "./bitcoind" vs
> "./bitcoin-fork”.

That’s exactly what my coinparams_new branch does. Adding a parameter for 
maximum block size would be straightforward.

> Chain params may be identical other than the value of some future
> event (miner vote for example), in which case the configs would run
> identically until that point.

Yes, indeed - this would be a special case.

> If your concern is about nodes with different configs communicating
> with eachother, I'd like to reiterate: the idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.

I do not encourage anyone to try to fork an existing blockchain without first 
securing overwhelming (near unanimous) consensus…or without having yet built a 
mechanism that can merge divergent chains gracefully.

> Cory
> 
>> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>>  wrote:
>> 
>> I'm not sure why Bitcoin Core and the rules and policies that it
>> enforces are being conflated in this thread. There's nothing stopping
>> us from adding the ability for the user to decide what their consensus
>> parameters should be at runtime. In fact, that's already in use:
>> ./bitcoind -testnet. As mentioned in another thread, the chain params
>> could even come from a config file that the user could edit without
>> touching the code.
>> 
>> I realize that it'd be opening Pandora's Box, and likely met with very
>> loud and reasonable arguments about the obvious terrible implications,
>> but it's at least an alternative to the current status quo of Core's
>> conflation with the consensus rules. The idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>> 
>> With that in place, consensus changes would be more about lobbying and
>> coalitions, and less about pull requests.
>> 
>> Cory
>> 
>> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>>  wrote:
>> 
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>> 
>> 
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference.  If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>> 
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>>  wrote:
>> 
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>> 
>> Quoting BC,
>> 
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>> 
>> 
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>> 
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>> 
>> There are checks-and-balances that make the system work.  Consensus is most
>> strongly measured by user actions after software release.  If the developers
>> fail to reflect user consensus, the network will let us know.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>>  wrote:
>> 
>> Hi Pieter,
>> 
>> I think a core area of disagreement is this:
>> 
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>> 
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have t

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Cory Fields via bitcoin-dev

On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
> FWIW, I had worked on something similar a while back:
> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>
> I like the idea in principle…but we should require a new genesis block,
> different magic bytes, and a different network port at the very least. :)
>

Not sure if serious, so I'll assume you are :)

Why? The idea in this case would be to allow the user to decide
between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
runtime rather than the likely alternative of "./bitcoind" vs
"./bitcoin-fork".

Chain params may be identical other than the value of some future
event (miner vote for example), in which case the configs would run
identically until that point.

If your concern is about nodes with different configs communicating
with eachother, I'd like to reiterate: the idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

Cory

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>  wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>  wrote:
>
> If the developers fail to reflect user consensus, the network will let us
> know.
>
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>  wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>
> Upgrading to a version of Bitcoin Core that is incompatible with your
> ideals is in no way a forced choice, as you have stated in your email;
> forks, alternative clients, or staying on an older version are all valid
> choices. If the majority of the network chooses not to endorse a specific
> change, then the majority of the network will continue to operate just fine
> without it, and properly structured consensus rules will pull the minority
> along as well.
>
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>  wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ___

Re: [bitcoin-dev] Bitcoin Core and hard forks

FWIW, I had worked on something similar a while back: 
https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf 


I like the idea in principle…but we should require a new genesis block, 
different magic bytes, and a different network port at the very least. :)

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev 
>  wrote:
> 
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
> 
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
> 
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
> 
> Cory
> 
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>  wrote:
>>> If the developers fail to reflect user consensus, the network will let us
>>> know.
>> 
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference.  If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>> 
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>>  wrote:
>> 
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>> 
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with your
>>> ideals is in no way a forced choice, as you have stated in your email;
>>> forks, alternative clients, or staying on an older version are all valid
>>> choices. If the majority of the network chooses not to endorse a specific
>>> change, then the majority of the network will continue to operate just fine
>>> without it, and properly structured consensus rules will pull the minority
>>> along as well.
>> 
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>> 
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>> 
>> There are checks-and-balances that make the system work.  Consensus is most
>> strongly measured by user actions after software release.  If the developers
>> fail to reflect user consensus, the network will let us know.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>>  wrote:
>> 
>> Hi Pieter,
>> 
>> I think a core area of disagreement is this:
>> 
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>> 
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>> 
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>> 
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>> 
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> 
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Cory Fields via bitcoin-dev

I'm not sure why Bitcoin Core and the rules and policies that it
enforces are being conflated in this thread. There's nothing stopping
us from adding the ability for the user to decide what their consensus
parameters should be at runtime. In fact, that's already in use:
./bitcoind -testnet. As mentioned in another thread, the chain params
could even come from a config file that the user could edit without
touching the code.

I realize that it'd be opening Pandora's Box, and likely met with very
loud and reasonable arguments about the obvious terrible implications,
but it's at least an alternative to the current status quo of Core's
conflation with the consensus rules. The idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

With that in place, consensus changes would be more about lobbying and
coalitions, and less about pull requests.

Cory

On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
 wrote:
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>  wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>  wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Raystonn via bitcoin-dev

> If the developers fail to reflect user consensus, the network will let us know.
This is true with the caveat that there must be more than one option present for the network to show it's preference.  If developers discourage anything that forks from the rules enforced by Bitcoin Core, they harm the network's ability to inform us of a failure to reflect user consensus.
On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev  wrote:I wouldn't go quite that far.  The reality is somewhere in the middle, as Bryan Cheng noted in this thread:Quoting BC,> Upgrading to a version of Bitcoin Core that is incompatible with your ideals is in no way a forced choice, as you have stated in your email; forks, alternative clients, or staying on an older version are all valid choices. If the majority of the network chooses not to endorse a specific change, then the majority of the network will continue to operate just fine without it, and properly structured consensus rules will pull the minority along as well.The developers propose a new version, by publishing a new release.  The individual network nodes choose to accept or reject that.So I respectfully disagree with "core devs don't control the network" and "core devs control the network" both.There are checks-and-balances that make the system work.  Consensus is most strongly measured by user actions after software release.  If the developers fail to reflect user consensus, the network will let us know.On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev  wrote:Hi Pieter,I think a core area of disagreement is this:Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. In fact Bitcoin Core is running the Bitcoin economy, and its developers do have the authority to set its rules. This is enforced by the reality of ~100% market share and limited github commit access.You may not like this situation, but it is what it is. By refusing to make a release with different rules, people who disagree are faced with only two options:1. Swallow it even if they hate it2. Fork the project and fork the block chain with it (XT)There are no alternatives. People who object to (2) are inherently suggesting (1) is the only acceptable path, which not surprisingly, makes a lot of people very angry.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

I wouldn't go quite that far.  The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:

Quoting BC,
> Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or staying on an older version are all valid
choices. If the majority of the network chooses not to endorse a specific
change, then the majority of the network will continue to operate just fine
without it, and properly structured consensus rules will pull the minority
along as well.

The developers *propose* a new version, by publishing a new release.  The
individual network nodes choose to accept or reject that.

So I respectfully disagree with "core devs don't control the network" and
"core devs control the network" both.

There are checks-and-balances that make the system work.  Consensus is most
strongly measured by user actions after software release.  If the
developers fail to reflect user consensus, the network will let us know.











On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Pieter,
>
> I think a core area of disagreement is this:
>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have
>> no authority to set its rules.
>>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make
> a release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 22, 2015, at 3:01 PM, Mike Hearn  wrote:
> 
> Until we’re able to merge blockchain forks like we’re able to merge git repo 
> forks, the safest option is no fork.
> 
> Block chain forks merge in the same way as git forks all the time, that's how 
> the reorg algorithm works. Transactions that didn't make it into the 
> post-reorg chain go back into the mempool and miners attempt to reinclude 
> them: this is the "merge" process. If they now conflict with other 
> transactions they are dropped and this is "resolving merge conflicts".
> 

Blockchain reorgs are part of the consensus rules. We’re talking not about 
forks caused by network partitions…but forks caused by the use of distinct 
consensus rules.

> However you have to want to merge with the new chain. If your software is 
> programmed not to do that out of some bizarre belief that throttling your own 
> user base is a good idea, then of course, no merge happens. Once you stop 
> telling your computer to do that, you can then merge (reorg) back onto the 
> main chain again.
> 

You cannot merge two chains that have incompatible transactions in them without 
throwing away one of the two conflicting transactions (along with all 
dependencies). In the reorg process, this occurs naturally…and we allow for it 
by using confirmation count as a metric of irreversibility. Until one chain 
wins (by overwhelming consensus) or all chains include a particular transaction 
in question, we cannot treat that transaction as irreversible. Propose a model 
in which we can still reliably measure irreversibility in the presence of 
multiple chains and you might have a point.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Mike Hearn via bitcoin-dev

>
> Until we’re able to merge blockchain forks like we’re able to merge git
> repo forks, the safest option is no fork.
>

Block chain forks merge in the same way as git forks all the time, that's
how the reorg algorithm works. Transactions that didn't make it into the
post-reorg chain go back into the mempool and miners attempt to reinclude
them: this is the "merge" process. If they now conflict with other
transactions they are dropped and this is "resolving merge conflicts".

However you have to want to merge with the new chain. If your software is
programmed not to do that out of some bizarre belief that throttling your
own user base is a good idea, then of course, no merge happens. Once you
stop telling your computer to do that, you can then merge (reorg) back onto
the main chain again.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks


> On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev 
>  wrote:
> 
> Hi Pieter,
> 
> I think a core area of disagreement is this:
> Bitcoin Core is not running the Bitcoin economy, and its developers have no 
> authority to set its rules.
> 
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do 
> have the authority to set its rules. This is enforced by the reality of ~100% 
> market share and limited github commit access.
> 
> You may not like this situation, but it is what it is. By refusing to make a 
> release with different rules, people who disagree are faced with only two 
> options:
> 
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
> 
> There are no alternatives. People who object to (2) are inherently suggesting 
> (1) is the only acceptable path, which not surprisingly, makes a lot of 
> people very angry.

It would be truly awesome to be able to give people more choice on consensus 
rules. Unfortunately, cryptoledgers do not fork gracefully (yet). Until we’re 
able to merge blockchain forks like we’re able to merge git repo forks, the 
safest option is no fork.

> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Mike Hearn via bitcoin-dev

Hi Pieter,

I think a core area of disagreement is this:

> Bitcoin Core is not running the Bitcoin economy, and its developers have
> no authority to set its rules.
>
In fact Bitcoin Core is running the Bitcoin economy, and its developers do
have the authority to set its rules. This is enforced by the reality of
~100% market share and limited github commit access.

You may not like this situation, but it is what it is. By refusing to make
a release with different rules, people who disagree are faced with only two
options:

1. Swallow it even if they hate it
2. Fork the project and fork the block chain with it (XT)

There are no alternatives. People who object to (2) are inherently
suggesting (1) is the only acceptable path, which not surprisingly, makes a
lot of people very angry.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev 
>  wrote:
> 
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev 
>  > wrote:
> Some people have called the prospect of limited block space and the 
> development of a fee market a change in policy compared to the past. I 
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin 
> economy, and its developers have no authority to set its rules. Change in 
> economics is always happening, and should be expected. Worse, intervening in 
> consensus changes would make the ecosystem more dependent on the group taking 
> that decision, not less.
> 
> 
> 
> This completely ignores reality, what users have experienced for the past ~6 
> years.
> 
> "Change in economics is always happening" does not begin to approach the 
> scale of the change.
> 
> For the entirety of bitcoin's history, absent long blocks and traffic bursts, 
> fee pressure has been largely absent.

This is only because of the fact that only a negligible portion of miner income 
comes from fees - the vast majority still continues to be subsidized by block 
rewards. The original design of the protocol was such that this subsidy would 
be decreased over time to let fees become the predominant source of income for 
miners. Until we have fee pressures, there’s no incentive for the industry to 
find solutions to real problems that need solving. I think you underestimate 
the ingenuity of people when pressed for real solutions. The main barrier to 
Bitcoin adoption is NOT this issue…and I believe the priorities are misplaced 
here. We’ve had over six years to start working on solutions but we keep 
“kicking the can down the road” - until when?!?! I believe unless there’s a 
strong need to find a solution no solutions will really be found.

> 
> Moving to a new economic policy where fee pressure is consistently present is 
> radically different from what users, markets, and software have experienced 
> and lived.
> 
> Analysis such as [1][2] and more shows that users will hit a "painful" "wall" 
> and market disruption will occur - eventually settling to a new equilibrium 
> after a period of chaos - when blocks are consistently full.
> 
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin 
> 
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent 
> 
> 
> First, users & market are forced through this period of chaos by "let a fee 
> market develop" as the whole market changes to a radically different economic 
> policy, once the network has never seen before.
> 
> Next, when blocks are consistently full, the past consensus was that block 
> size limit will be increased eventually.  What happens at that point?
> 
> Answer - Users & market are forced through a second period of chaos and 
> disruption as the fee market is rebooted again by changing the block size 
> limit.
> 
> The average user hears a lot of noise on both sides of the block size debate, 
> and really has no idea that the new "let a fee market develop" Bitcoin Core 
> policy is going to raise fees on them.
> 
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon them
> 

The current userbase and market is still tiny - we have to think bigger than 
this. We already go through loads of pain to use the current system…and quite 
frankly, there are a number of other significant issues that I think are far 
bigger obstacles to widespread adoption than “I have to pay a fee”. For 
example, the current cost of verification is too high to continue to ensure the 
security of the network (as the July 4th fork clearly illustrated)…and places 
huge centralization pressures on validation…and simply will not support 
hundreds of millions of users or billions of users. Increasing block size 
actually worsens the scaling properties, it does not improve them. We need 
better scaling solutions - almost certainly this will require avoiding the need 
for global consensus for the vast majority of transactions (nested consensus or 
off-chain direct party-to-party contract negotiation, the lightning network, 
etc. The focus on reducing fee pressure by increasing block size is a 
distraction from far more fundamental issues, IMHO.

> 
> So to point out what I consider obvious: if Bitcoin requires central control 
> over its rules by a group of developers, it is completely uninteresting to 
> me. Consensus changes should be done using consensus, and the default in case 
> of controversy is no change.
> 
> 
> False.
> 
> All that has to do be done to change bitcoin to a new economic policy - not 
> seen in the entire 6 year history of bitcoin - is to

Re: [bitcoin-dev] Bitcoin Core and hard forks

Addendum:

Please do not interpret - as many have - my points as advocating against
letting a fee market ever develop(!).

Fees are useful against DoS, increasing cost of attack etc.  Further,
continuing the artificially-low fee policy ad infinitum is unsustainable
and constitutes a moral hazard.

Examine from the user's point of view.  If you want to develop a fee
market, think it through in the context of user expectation/experience -
which translates to how software is written and users behave, the context
of market disruption, and the context of further block size increases.

Transition to a new economic policy should be planned.  It should give
users and markets time to adjust.

It is grossly irresponsible to simply drop users into a new economic policy
with no warning and no preparation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Bryan Cheng via bitcoin-dev

Pieter, I agree with the overall gist of your statement (that Bitcoin is a
consensus-driven protocol that's incompatible with certain forms of central
governance) but I respectfully disagree with some of the conclusions you're
drawing.

> Consensus changes should be done using consensus, _and the default in
case of controversy is no change_.

(emphasis mine)

I think that there's a disconnect between the idea that Bitcoin Core making
a consensus-driven change in turn means that the network is being forced
down a certain path. This takes away a great deal of the individual agency
that makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core
that is incompatible with your ideals is in no way a forced choice, as you
have stated in your email; forks, alternative clients, or staying on an
older version are all valid choices. If the majority of the network chooses
not to endorse a specific change, then the majority of the network will
continue to operate just fine without it, and properly structured consensus
rules will pull the minority along as well. (For example, re: block sizes,
if the majority of hashing power remains on a version or fork that does not
mine >1MB blocks, a chain of <1MB blocks will continue to be the longest,
and up to date clients will still respect that. That is consensus at work,
pure and simple.)

Obviously Core is in a unique position as a reference client and ignoring
that would be irresponsible. If broad consensus among the developers cannot
be reached, then Core should not make a given change. However, freezing
Core's ability to make changes in light of _any_ controversy is allowing a
few voices to dictate direction and is counter to any kind of
consensus-driven decision making.

Placing Core and its developers on some sort of pedestal where we believe
that they dictate policy and therefore shouldn't be allowed to take any
risks will create the very situation that you're advocating against- that a
small group of developers have control over Bitcoin's policies. Instead, we
should strive to treat Core as _just another Bitcoin Client_, we should
educate users to make informed choices about the version of software they
are running and the choices implicit in that, and we should allow consensus
at the protocol level to make the decisions on the overall direction of the
network.

> My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later

I will keep this brief because this is straying off topic of the idea of
this thread- but I don't believe that increasing Bitcoin's capacity as a
network is inherently incompatible with the development of a fee market,
and considering a fee market to be formed of only a single set of variables
(transaction rate versus block size) is not sound economic analysis.

On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> default in case of controversy is no change.
>>
>
> I think the result of this would probably be that no controversial changes
> ever get implemented via this process so others will hard fork the code and
> eventually make this process irrelevant.  Since you need close to 100%
> agreement the irrelevance would have to come as a step function which will
> manifest itself in a rather disruptive manner.
>
> The question is really is this hark-forking disruption worse than coming
> up with some kind of process to handle controversial changes.
>
> Russ
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Wed, Jul 22, 2015 at 11:03 AM, Alex Morcos  wrote:

> Over the last 6 years there may not have been fee pressure, but certainly
> there was the expectation that it was going to happen.  Look at all the
> work that has been put into fee estimation, why do that work if the
> expectation was there would be no fee pressure?
>

There is a vast difference between what software developers have been
chattering about in the background versus what the users actually
experience in the field.

To the user, talk of a fee market is equivalent to talk about block size -
various opinions are tossed about, but it doesn't really impact them.  Fees
have been low for 6 years.

We see this with the actual data - no fee pressure on average for the
entirety of bitcoin's history.  We see this with the recent stress tests,
which exposed dumb wallet behavior WRT fees.   Users -and software- had the
expectation

Remember, this is not a judgement on whether or not fee market/pressure
should exist.  It is simply a factual observation that users/market have
not experienced this new economic policy.

That opens the question - *why now?*   Why make bitcoin growth more
expensive at this time in its young life?  Many smart people would prefer
that bitcoin continue to grow, rather than making the system more expensive
to use right now.

Choosing "let a fee market develop" -- *today* -- is picking economic
sides, picking winners & losers in the market.

This new policy should be debated and consensus achieved, not simply rolled
out by fiat without user notification.

Otherwise it is engaging in precisely the economic wizardry that this
thread opened with decrying.

Just like block size, there are multiple sides to the fee market debate.
However, Bitcoin Core has (unfortunately) outsized decision making power in
that simply avoiding progress on block size limit will achieve the "let a
fee market develop" economic policy change.  Ironic but true - sitting
around and doing nothing dumps users into a new economic policy.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

2015-07-22 Thread Alex Morcos via bitcoin-dev

Jeff I respectively disagree with many of your points, but let me just
point out 2.

Over the last 6 years there may not have been fee pressure, but certainly
there was the expectation that it was going to happen.  Look at all the
work that has been put into fee estimation, why do that work if the
expectation was there would be no fee pressure?

I know you respect Pieter's work, so I don't want to twist your words, but
for the clarity of other people reading these posts, it sounds like you're
accusing Pieter and others of stonewalling size increases and not
participating in planning for them.  Without debate, no one has done more
for this project to make eventual size increases technically feasible than
Pieter.  We only have the privilege of even having this debate as a result
of his work.



On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Some people have called the prospect of limited block space and the
>> development of a fee market a change in policy compared to the past. I
>> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
>> economy, and its developers have no authority to set its rules. Change in
>> economics is always happening, and should be expected. Worse, intervening
>> in consensus changes would make the ecosystem more dependent on the group
>> taking that decision, not less.
>>
>>
> This completely ignores *reality*, what users have experienced for the
> past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the
> scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic
> bursts, fee pressure has been largely absent.
>
> Moving to a new economic policy where fee pressure is consistently present
> is radically different from what users, markets, and software have
> experienced and *lived.*
>
> Analysis such as [1][2] and more shows that users will hit a "painful"
> "wall" and market disruption will occur - eventually settling to a new
> equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> First, users & market are forced through this period of chaos by "let a
> fee market develop" as the whole market changes to a radically different
> economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block
> size limit will be increased eventually.  What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and
> disruption as the fee market is rebooted *again* by changing the block
> size limit.
>
> The average user hears a lot of noise on both sides of the block size
> debate, and really has no idea that the new "let a fee market develop"
> Bitcoin Core policy is going to *raise fees* on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon
> them
>
>
>
>> So to point out what I consider obvious: if Bitcoin requires central
>> control over its rules by a group of developers, it is completely
>> uninteresting to me. Consensus changes should be done using consensus, and
>> the default in case of controversy is no change.
>>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy -
> not seen in the entire 6 year history of bitcoin - is to stonewall work on
> block size.
>
> Closing size increase PRs and failing to participate in planning for a
> block size increase accomplishes your stated goal of changing bitcoin to a
> new economic policy.
>
> "no [code] change"... changes bitcoin to a brand new economic policy,
> picking economic winners & losers.  Some businesses will be priced out of
> bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
> move as increasing the hard limit by hard fork.
>
>
>
>> My personal opinion is that we - as a community - should indeed let a fee
>> market develop, and rather sooner than later, and that "kicking the can
>> down the road" is an incredibly dangerous precedent: if we are willing to
>> go through the risk of a hard fork because of a fear of change of
>> economics, then I believe that community is not ready to deal with change
>> at all. And some change is inevitable, at any block size. Again, this does
>> not mean the block size needs to be fixed forever, but its intent should be
>> growing with the evolution of technology, not a panic reaction because a
>> fear of change.
>>
>> But I am not in any position to force this view. I only hope that people
>> don't think a fea

Re: [bitcoin-dev] Bitcoin Core and hard forks