Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Eric Lombrozo via bitcoin-dev]

Thanks for sending this proposal! I look forward to having a great
discussion around this.

- Eric

On Thursday, June 1, 2017, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> consideration:
>* https://github.com/Roasbeef/bips/blob/master/gcs_light_
> client.mediawiki
>
> This BIP proposal describes a concrete specification (along with a
> reference implementations[1][2][3]) for the much discussed client-side
> filtering reversal of BIP-37. The precise details are described in the
> BIP, but as a summary: we've implemented a new light-client mode that uses
> client-side filtering based off of Golomb-Rice coded sets. Full-nodes
> maintain an additional index of the chain, and serve this compact filter
> (the index) to light clients which request them. Light clients then fetch
> these filters, query the locally and _maybe_ fetch the block if a relevant
> item matches. The cool part is that blocks can be fetched from _any_
> source, once the light client deems it necessary. Our primary motivation
> for this work was enabling a light client mode for lnd[4] in order to
> support a more light-weight back end paving the way for the usage of
> Lightning on mobile phones and other devices. We've integrated neutrino
> as a back end for lnd, and will be making the updated code public very
> soon.
>
> One specific area we'd like feedback on is the parameter selection. Unlike
> BIP-37 which allows clients to dynamically tune their false positive rate,
> our proposal uses a _fixed_ false-positive. Within the document, it's
> currently specified as P = 1/2^20. We've done a bit of analysis and
> optimization attempting to optimize the following sum:
> filter_download_bandwidth + expected_block_false_positive_bandwidth. Alex
> has made a JS calculator that allows y'all to explore the affect of
> tweaking the false positive rate in addition to the following variables:
> the number of items the wallet is scanning for, the size of the blocks,
> number of blocks fetched, and the size of the filters themselves. The
> calculator calculates the expected bandwidth utilization using the CDF of
> the Geometric Distribution. The calculator can be found here:
> https://aakselrod.github.io/gcs_calc.html. Alex also has an empirical
> script he's been running on actual data, and the results seem to match up
> rather nicely.
>
> We we're excited to see that Karl Johan Alm (kallewoof) has done some
> (rather extensive!) analysis of his own, focusing on a distinct encoding
> type [5]. I haven't had the time yet to dig into his report yet, but I
> think I've read enough to extract the key difference in our encodings: his
> filters use a binomial encoding _directly_ on the filter contents, will we
> instead create a Golomb-Coded set with the contents being _hashes_ (we use
> siphash) of the filter items.
>
> Using a fixed fp=20, I have some stats detailing the total index size, as
> well as averages for both mainnet and testnet. For mainnet, using the
> filter contents as currently described in the BIP (basic + extended), the
> total size of the index comes out to 6.9GB. The break down is as follows:
>
> * total size:  6976047156
> * total avg:  14997.220622758816
> * total median:  3801
> * total max:  79155
> * regular size:  3117183743
> * regular avg:  6701.372750217131
> * regular median:  1734
> * regular max:  67533
> * extended size:  3858863413
> * extended avg:  8295.847872541684
> * extended median:  2041
> * extended max:  52508
>
> In order to consider the average+median filter sizes in a world worth
> larger blocks, I also ran the index for testnet:
>
> * total size:  2753238530
> * total avg:  5918.95736054141
> * total median:  60202
> * total max:  74983
> * regular size:  1165148878
> * regular avg:  2504.856172982827
> * regular median:  24812
> * regular max:  64554
> * extended size:  1588089652
> * extended avg:  3414.1011875585823
> * extended median:  35260
> * extended max:  41731
>
> Finally, here are the testnet stats which take into account the increase
> in the maximum filter size due to segwit's block-size increase. The max
> filter sizes are a bit larger due to some of the habitual blocks I
> created last year when testing segwit (transactions with 30k inputs, 30k
> outputs, etc).
>
>  * total size:  585087597
>  * total avg:  520.8839608674402
>  * total median:  20
>  * total max:  164598
>  * regular size:  299325029
>  * regular avg:  266.4790836307566
>  * regular median:  13
>  * regular max:  164583
>  * extended size:  285762568
>  * extended avg:  254.4048772366836
>  * extended median:  7
>  * extended max:  127631
>
> For those that are interested in the raw data, I've uploaded a CSV file
> of raw data for each block (mainnet + 

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Eric Lombrozo via bitcoin-dev]

Can you guys please take this discussion elsewhere? Perhaps to
bitcoin-discuss? This is not the place to rehash discussions that have
taken place a million times already. The behavior of the network under
contentious hard forks has been discussed ad nauseum. This mailing list is
for the discussion of new ideas and proposals.

Much appreciated. Thanks.

On Sat, Jan 7, 2017 at 3:49 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 01/07/2017 03:10 PM, Aymeric Vitte via bitcoin-dev wrote:
> > Still wondering why you guys don't care about the ridiculous number of
> > full nodes, no incentive to run one and what would happen if someone
> > were to control a majority of full nodes
>
> The level of control over a majority of full nodes is irrelevant. If
> this was truly a measure of control over Bitcoin someone would simply
> spin up a bunch of nodes and take control at trivial cost.
>
> e
>
>
> ___
> 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 Classic 1.2.0 released

[Eric Lombrozo via bitcoin-dev]

Your release announcement does not make it clear that Bitcoin Classic is
incompatible with the current Bitcoin network and its consensus rules. It
is a hard fork on mainnet with no safe activation as well as including
other unsafe changes. There is also no BIP for the hard fork. There is also
no evidence of community wide consensus for such a hard fork. This is
dangerous and irresponsible.


It's wrong to announce software without correctly informing people about
the contents or risks. Furthermore, there are no release notes in
https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
changelog. Without those, it is almost impossible for average users to know
what is under the hood or what has changed and time consuming for
developers to assess.

On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin Classic version 1.2.0 is now available from;
>
>  
>
> This is a new major version release, including new features, various
> bugfixes and performance improvements.
>
> This release marks a change in strategy for Bitcoin Classic, moving from
> the
> very conservative block size proposal based on compromise to one where
> Classic truly innovates and provides a long term solution for the market to
> choose and leave behind the restrictions of the old.
>
> The most visible change in this version is the decentralised block size
> solution where node operators decide on the maximum size.
>
> Bitcoin Classic is focused on providing users a way to get onto the Bitcoin
> network using a high quality validating node for a large set of use cases.
> Classic presents top notch quality processes in this release, to help
> anyone
> running Bitcoin.
>
> We include in this release various projects with the beta label. People who
> want to use the Classic node as an on-ramp to Bitcoin will find them
> interesting. These projects will need to be enabled in the config by those
> that want to test them.
>
> More background information on this release and Classic can be seen in this
> video: https://vimeo.com/192789752
> The full release notes are on github at
> https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

[Eric Lombrozo via bitcoin-dev]

Nice!

We’ve been talking about doing this forever and it’s so desperately needed.

> On May 17, 2016, at 3:23 PM, Peter Todd via bitcoin-dev 
>  wrote:
> 
> # Motivation
> 
> UTXO growth is a serious concern for Bitcoin's long-term decentralization. To
> run a competitive mining operation potentially the entire UTXO set must be in
> RAM to achieve competitive latency; your larger, more centralized, competitors
> will have the UTXO set in RAM. Mining is a zero-sum game, so the extra latency
> of not doing so if they do directly impacts your profit margin. Secondly,
> having possession of the UTXO set is one of the minimum requirements to run a
> full node; the larger the set the harder it is to run a full node.
> 
> Currently the maximum size of the UTXO set is unbounded as there is no
> consensus rule that limits growth, other than the block-size limit itself; as
> of writing the UTXO set is 1.3GB in the on-disk, compressed serialization,
> which expands to significantly more in memory. UTXO growth is driven by a
> number of factors, including the fact that there is little incentive to merge
> inputs, lost coins, dust outputs that can't be economically spent, and
> non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles and
> timestamping.
> 
> We don't have good tools to combat UTXO growth. Segregated Witness proposes to
> give witness space a 75% discount, in part of make reducing the UTXO set size
> by spending txouts cheaper. While this may change wallets to more often spend
> dust, it's hard to imagine an incentive sufficiently strong to discourage 
> most,
> let alone all, UTXO growing behavior.
> 
> For example, timestamping applications often create unspendable outputs due to
> ease of implementation, and because doing so is an easy way to make sure that
> the data required to reconstruct the timestamp proof won't get lost - all
> Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
> use-cases like using the UTXO set for key rotation piggyback on the uniquely
> strong security and decentralization guarantee that Bitcoin provides; it's 
> very
> difficult - perhaps impossible - to provide these applications with
> alternatives that are equally secure. These non-btc-value-transfer use-cases
> can often afford to pay far higher fees per UTXO created than competing
> btc-value-transfer use-cases; many users could afford to spend $50 to register
> a new PGP key, yet would rather not spend $50 in fees to create a standard two
> output transaction. Effective techniques to resist miner censorship exist, so
> without resorting to whitelists blocking non-btc-value-transfer use-cases as
> "spam" is not a long-term, incentive compatible, solution.
> 
> A hard upper limit on UTXO set size could create a more level playing field in
> the form of fixed minimum requirements to run a performant Bitcoin node, and
> make the issue of UTXO "spam" less important. However, making any coins
> unspendable, regardless of age or value, is a politically untenable economic
> change.
> 
> 
> # TXO Commitments
> 
> A merkle tree committing to the state of all transaction outputs, both spent
> and unspent, we can provide a method of compactly proving the current state of
> an output. This lets us "archive" less frequently accessed parts of the UTXO
> set, allowing full nodes to discard the associated data, still providing a
> mechanism to spend those archived outputs by proving to those nodes that the
> outputs are in fact unspent.
> 
> Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
> type of deterministic, indexable, insertion ordered merkle tree, which allows
> new items to be cheaply appended to the tree with minimal storage 
> requirements,
> just log2(n) "mountain tips". Once an output is added to the TXO MMR it is
> never removed; if an output is spent its status is updated in place. Both the
> state of a specific item in the MMR, as well the validity of changes to items
> in the MMR, can be proven with log2(n) sized proofs consisting of a merkle 
> path
> to the tip of the tree.
> 
> At an extreme, with TXO commitments we could even have no UTXO set at all,
> entirely eliminating the UTXO growth problem. Transactions would simply be
> accompanied by TXO commitment proofs showing that the outputs they wanted to
> spend were still unspent; nodes could update the state of the TXO MMR purely
> from TXO commitment proofs. However, the log2(n) bandwidth overhead per txin 
> is
> substantial, so a more realistic implementation is be to have a UTXO cache for
> recent transactions, with TXO commitments acting as a alternate for the (rare)
> event that an old txout needs to be spent.
> 
> Proofs can be generated and added to transactions without the involvement of
> the signers, even after the fact; there's no need for the proof itself to
> signed and the proof is not part of the transaction hash. Anyone with access 
> to
> TXO 

Re: [bitcoin-dev] Proposal to update BIP-32

[Eric Lombrozo via bitcoin-dev]

In practice the probability of this case triggering is on the order of 2^-128 
or something astronomically tiny. I've been using BIP32 for a few years already 
as have many others...I don't think we've ever had to handle this case. 
Justifiably, many app developers feel like the additional complexity of 
properly handling this case is not worth the effort.

Having said that, if the handling of this case is simple to implement and easy 
to isolate in the program flow, I am in favor of doing something along the 
lines of what you propose.

- Eric

On April 20, 2016 9:32:25 AM PDT, Jochen Hoenicke via bitcoin-dev 
 wrote:
>Hello Bitcoin Developers,
>
>I would like to make a proposal to update BIP-32 in a small way.
>
>TL;DR: BIP-32 is hard to use right (due to its requirement to skip
>addresses).  This proposal suggests a modification such that the
>difficulty can be encapsulated in the library.
>
>#MOTIVATION:
>
>The current BIP-32 specifies that if for some node in the hierarchy
>the computed hash I_L is larger or equal to the prime or 0, then the
>node is invalid and should be skipped in the BIP-32 tree.  This has
>several unfortunate consequences:
>
>- All callers of CKDpriv or CKDpub have to check for errors and handle
>  them appropriately.  This shifts the burden to the application
>  developer instead of being able to handle it in the BIP-32 library.
>
>- It is not clear what to do if an intermediate node is
>  missing. E.g. for the default wallet layout, if m/i_H/0 is missing
>  should m/i_H/1 be used for external chain and m/i_H/2 for internal
>  chain?  This would make the wallet handling much more difficult.
>
>- It gets even worse with standards like BIP-44.  If m/44' is missing
>  should we use m/45' instead?  If m/44'/0' is missing should we use
>  m/44'/1' instead, using the same addresses as for testnet?
>  One could also restart with a different seed in this case, but this
>  wouldn't work if one later wants to support another BIP-43 proposal
>  and still keep the same wallet.
>
>I think the first point alone is reason enough to change this.  I am
>not aware of a BIP-32 application that handles errors like this
>correctly in all cases.  It is also very hard to test, since it is
>infeasible to brute-force a BIP-32 key and a path where the node does
>not exists.
>
>This problem can be avoided by repeating the hashing with slightly
>different input data until a valid private key is found.  This would
>be in the same spirit as RFC-6979.  This way, the library will always
>return a valid node for all paths.  Of course, in the case where the
>node is valid according to the current standard the behavior should be
>unchanged.
>
>I think the backward compatibility issues are minimal.  The chance
>that this affects anyone is less than 10^-30.  Even if it happens, it
>would only create some additional addresses (that are not seen if the
>user downgrades).  The main reason for suggesting a change is that we
>want a similar method for different curves where a collision is much
>more likely.
>
>#QUESTIONS:
>
>What is the procedure to update the BIP?  Is it still possible to
>change the existing BIP-32 even though it is marked as final?  Or
>should I make a new BIP for this that obsoletes BIP-32?
>
>What algorithm is preferred? (bike-shedding)  My suggestion:
>
>---
>
>Change the last step of the private -> private derivation functions to:
>
> . In case parse(I_L) >= n or k_i = 0, the procedure is repeated
>   at step 2 with
>I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i))
>
>---
>
>I think this suggestion is simple to implement (a bit harder to unit
>test) and the string to hash with HMAC-SHA512 always has the same
>length.  I use I_R, since I_L is obviously not very random if I_L >= n.
>There is a minimal chance that it will lead to an infinite loop if I_R
>is the same in two consecutive iterations, but that has only a chance
>of 1 in 2^512 (if the algorithm is used for different curves that make
>I_L >= n more likely, the chance is still less than 1 in 2^256).  In
>theory, this loop can be avoided by incrementing i in every iteration,
>but this would make an implementation error in the "hard to test" path
>of the program more likely.
>
>The other derivation functions should be updated in a similar matter.
>Also the derivation of the root node from the seed should be updated
>in a similar matter to avoid invalid seeds.
>
>If you followed until here, thanks for reading this long posting.
>
>  Jochen
>___
>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] BIP Classification Process

[Eric Lombrozo via bitcoin-dev]

Codebase forks with nonconsensus features are totally fine! It’s the bitterness 
and resentment that arose out of the need to get everyone to agree on something 
that not everyone really needs to agree on that’s the problem.

> On Jan 28, 2016, at 11:21 PM, Btc Drak <btcd...@gmail.com> wrote:
> 
> Your proposal does not solve the issue related to Mike creating his own fork. 
> He created his own for because he had a non-consensus feature set that 
> Bitcoin Core disagreed with and he wanted. That is to be _encouraged_. I also 
> maintain my own Bitcoin fork with a specific (non-consensus) feature for the 
> same reason and I am perfectly happy with the arrangement, as are my userbase.
> 
> Classification of BIPs is fine, I have no problem with that and I support 
> your BIP, but your proposition it would have stopped Mike from creating his 
> own distribution is false (nor desirable): it was down to a strong differing 
> of technical opinions between Mike and a dozen other developers as well as 
> node security concerns (which were proved correct).
> 
> 
> On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Folks,
> 
> I think the current situation with forks could have been avoided with a 
> better process that can distinguish between different layers for bitcoin 
> modification proposals.
> 
> For instance, BIP64 was proposed by Mike Hearn, which does not affect the 
> consensus layer at all. Many Core devs disliked the proposal and Mike had 
> lots of pushback. Regardless of whether or not you agree with the merits of 
> Mike’s ideas here, fact is having nodes that support BIP64 would not 
> fundamentally break the Bitcoin network.
> 
> This issue prompted Mike to break off from Core and create XT as the 
> applications he was developing required BIP64 to work. With this split, Gavin 
> found a new home for his big block ideas…and the two teamed up.
> 
> We need to have a process that clearly distinguishes these different layers 
> and allows much more freedom in the upper layers while requiring agreement at 
> the consensus layer. Many of these fork proposals are actually conflating 
> different features, only some of which would actually be consensus layer 
> changes. When people proposing nonconsensus features get pushback from Core 
> developers they feel rejected and are likely to team up with others trying to 
> push for hard forks and the like.
> 
> A while back I had submitted a BIP -  BIP123 - that addresses this issue. I 
> have updated it to include all the currently proposed and accepted BIPs and 
> have submitted a PR: https://github.com/bitcoin/bips/pull/311 
> <https://github.com/bitcoin/bips/pull/311>
> 
> I urge everyone to seriously consider getting this BIP accepted as a top 
> priority before we get more projects all trying their hand at stuff and not 
> understanding these critical distinctions.
> 
> 
> - Eric
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
> <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

[bitcoin-dev] BIP Classification Process

[Eric Lombrozo via bitcoin-dev]

Folks,

I think the current situation with forks could have been avoided with a better 
process that can distinguish between different layers for bitcoin modification 
proposals.

For instance, BIP64 was proposed by Mike Hearn, which does not affect the 
consensus layer at all. Many Core devs disliked the proposal and Mike had lots 
of pushback. Regardless of whether or not you agree with the merits of Mike’s 
ideas here, fact is having nodes that support BIP64 would not fundamentally 
break the Bitcoin network.

This issue prompted Mike to break off from Core and create XT as the 
applications he was developing required BIP64 to work. With this split, Gavin 
found a new home for his big block ideas…and the two teamed up.

We need to have a process that clearly distinguishes these different layers and 
allows much more freedom in the upper layers while requiring agreement at the 
consensus layer. Many of these fork proposals are actually conflating different 
features, only some of which would actually be consensus layer changes. When 
people proposing nonconsensus features get pushback from Core developers they 
feel rejected and are likely to team up with others trying to push for hard 
forks and the like.

A while back I had submitted a BIP -  BIP123 - that addresses this issue. I 
have updated it to include all the currently proposed and accepted BIPs and 
have submitted a PR: https://github.com/bitcoin/bips/pull/311 


I urge everyone to seriously consider getting this BIP accepted as a top 
priority before we get more projects all trying their hand at stuff and not 
understanding these critical distinctions.


- Eric


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

[bitcoin-dev] Segregated Witness App Development

[Eric Lombrozo via bitcoin-dev]

Hello, folks.

I wanted to let all of you know a new IRC channel has been created called 
#segwit-dev where we welcome all discussion pertaining to integrating and 
supporting segregated witness transactions in wallets as well as comments or 
suggestions for improvement to the spec. Please come join us. :)


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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Eric Lombrozo via bitcoin-dev]

For simplicity, assume total network hashpower is constant. Also, assume the 
soft fork activates at the beginning of a retarget period.

At the moment the soft fork activates, the effective difficulty is increased 
(by adding a second independent PoW check that must also be satisfied) which 
means more hashes on average (and proportionally more time) are required to 
find a block. At the end of the retarget period,  the difficulty is lowered so 
that if the second PoW difficulty were to be kept constant the block interval 
would again average 10 mins.

If we were to keep the second PoW difficulty constant, we would restore the 
same total PoW-to-time-unit ratio and the retarget difficulty would stabilize 
again so each block would once more require the same number of hashes (and same 
amount of time) on average as before.

But we don't keep the second PoW difficulty constant - we increase it so once 
again more hashes on average are required to find a block by the same 
proportion as before. And we keep doing this.

Now, the assumption that hashpower is constant is obviously unrealistic. If 
this is your bone of contention, then yes, I agree my model is overly 
simplistic.

My larger point was to explore the extent of what's possible with only a soft 
fork - and we can actually go pretty far and even compensate for these economic 
shifts by increasing block size and rewards. The whole thing is clearly a huge 
mess - and I wouldn't recommend actually doing it.



On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jti...@jtimon.cc> wrote:
>On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Unfortunately, this also means longer confirmation times, lower
>throughput, and lower miner revenue. Note, however, that confirmations
>would (on average) represent more PoW, so fewer confirmations would be
>required to achieve the same level of security.
>>
>
>I'm not sure I understand this. If mining revenue per unit of time
>drops,
>total pow per unit of time should also drop. Even if the inter-block
>time
>is increased, it's not clear to me that the pow per block would
>necessarily
>be higher.
>What am I missing?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] We need to fix the block withholding attack

[Eric Lombrozo via bitcoin-dev]

I should have stated that we're assuming the actual total hashrate remains 
constant. Obviously this is not what would actually happen - the rest of the 
post discusses ways to counter the economic forces at play pushing total 
hashrate down using only soft forks. The increased variance is still 
unaccounted for (pool operators would have to deal with this somehow)...and we 
still have larger block intervals even with compensation. And the practicality 
of deployment and usability are clearly problematic, to understate things.

It's merely an exercise seeking the theoretical limit of what's actually 
possible to do with a soft fork.

On December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that
>confirmations
>> would (on average) represent more PoW, so fewer confirmations would
>be
>> required to achieve the same level of security.
>>
>
>
>No, the re-target compensates so that the number of blocks in the last
>two
>weeks is 2016.  If a soft fork forces miners to throw away 25% of their
>blocks, then the difficulty will drop by 75% to keep things balanced.
>Throwing away 75% of blocks has the same effect on difficulty as
>destroying
>75% of mining hardware.
>
>The block interval will only increase until the next re-target.
>
>Slowly increasing the fraction of blocks which are thrown away gives
>the
>re-target algorithm time to adjust, so it is another advantage.
>
>If the rule was instantly changed so that 95% of blocks were thrown
>away,
>then there could be up to 40 weeks until the next retarget and that
>would
>give 200 minute block times until the adjustment.
>
>
>
>
>___
>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] We need to fix the block withholding attack

[Eric Lombrozo via bitcoin-dev]

Note: my stupid email client didn't indent Peter Todd's quote correctly. 
The first paragraph is his, the second is my response.


-- Original Message --
From: "Eric Lombrozo" 
To: "Peter Todd" ; "Emin Gün Sirer" 

Cc: nbvf...@gmail.com; "Bitcoin Dev" 


Sent: 12/26/2015 12:23:38 AM
Subject: Re[2]: [bitcoin-dev] We need to fix the block withholding 
attack



Peter Todd wrote:
 Fixing block withholding is relatively simple, but (so far) requires a
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
do this hard-fork in conjunction with any blocksize increase, which 
will

have the desirable side effect of clearly show consent by the entire
ecosystem, SPV clients included.

I think we can generalize this and argue that it is impossible fix this 
without reducing the visible difficulty and blinding the hasher to an 
invisible difficulty. Unfortunately, changing the retargeting algo to 
compute lower visible difficulty (leaving all else the same) or 
interpreting the bits field in a way that yields a lower visible 
difficulty is a hard fork by definition - blocks that didn't meet the 
visible difficulty requirement before will now meet it.


jl2012 wrote:
After the meeting I find a softfork solution. It is very inefficient 
and I am leaving it here just for record.


1. In the first output of the second transaction of a block, mining 
pool will commit a random nonce with an OP_RETURN.


2. Mine as normal. When a block is found, the hash is concatenated 
with the committed random nonce and hashed.


3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the 
block is invalid. That means about 1% of blocks are discarded.


4. For each difficulty retarget, the secondary target is decreased by 
2 ^ 1/64.


5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ 
252. Therefore only 1 in 16 hash returned by hasher is really valid. 
This should make the detection of block withholding attack much 
easier.


All miners have to sacrifice 1% reward for 10 years. Confirmation will 
also be 1% slower than it should be.


If a node (full or SPV) is not updated, it becomes more vulnerable as 
an attacker could mine a chain much faster without following the new 
rules. But this is still a softfork, by definition.
jl2012's key discovery here is that if we add an invisible difficulty 
while keeping the retarget algo and bits semantics the same, the 
visible difficulty will decrease automatically to compensate. In other 
words, we can artificially increase the block time interval, allowing 
us to force a lower visible difficulty at the next retarget without 
changing the retarget algo nor the bits semantics. There are no other 
free parameters we can tweak, so it seems this is really the best we 
can do.


Unfortunately, this also means longer confirmation times, lower 
throughput, and lower miner revenue. Note, however, that confirmations 
would (on average) represent more PoW, so fewer confirmations would be 
required to achieve the same level of security.


We can compensate for lower throughput and lower miner revenue by 
increasing block size and increasing block rewards. Interestingly, it 
turns out we *can* do these things with soft forks by embedding new 
structures into blocks and nesting their hash trees into existing 
structures. Ideas such as extension blocks 
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html] 
have been proposed before...but they add significant complications to 
the protocol and require nontrivial app migration efforts. Old nodes 
would not get forked off the network but backwards compatibility would 
still be a problem as they would not be able to see at least some of 
the transactions and some of the bitcoins in blocks. But if we're 
willing to accept this, even the "sacred" 21 million asymptotic limit 
can be raised via soft fork!


So in conclusion, it *is* possible to fix this attack with a soft fork 
and without altering the basic economics...but it's almost surely a lot 
more trouble than it's worth. Luke-Jr's solution is far simpler and 
more elegant and is perhaps one of the few examples of a new feature 
(as opposed to merely a structure cleanup) that would be better to 
deploy as a hard fork since it's simple to implement and seems to stand 
a reasonable chance of near universal support...and soft fork 
alternatives are very, very ugly and significantly impact system 
usability...and I think theory tells us we can't do any better.


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

[bitcoin-dev] Segregated Witness BIPs

[Eric Lombrozo via bitcoin-dev]

I've been working with jl2012 on some SEGWIT BIPs based on earlier 
discussions Pieter Wuille's implementation. We're considering submitting 
three separate BIPs:



CONSENSUS BIP: witness structures and how they're committed to blocks, 
cost metrics and limits, the scripting system (witness programs), and 
the soft fork mechanism.


PEER SERVICES BIP: relay message structures, witnesstx serialization, 
and other issues pertaining to the p2p protocol such as IBD, 
synchronization, tx and block propagation, etc...


APPLICATIONS BIP: scriptPubKey encoding formats and other wallet 
interoperability concerns.



The Consensus BIP is submitted as a draft and is pending BIP number 
assignment: https://github.com/bitcoin/bips/pull/265

The other two BIPS will be drafted soon.

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Eric Lombrozo via bitcoin-dev]

Doesn't a good soft fork signaling mechanism along with an activation warning 
system for non-upgraded nodes (i.e. BIP9, or even block version ISM for that 
matter) essentially fix this? I don't quite get why this should be an issue.

On December 17, 2015 10:52:39 AM PST, Jeff Garzik via bitcoin-dev 
 wrote:
>On Thu, Dec 17, 2015 at 1:46 PM, jl2012  wrote:
>
>> This is not correct.
>>
>> As only about 1/3 of nodes support BIP65 now, would you consider CLTV
>tx
>> are less secure than others? I don't think so. Since one invalid CLTV
>tx
>> will make the whole block invalid. Having more nodes to fully
>validate
>> non-CLTV txs won't make them any safer. The same logic also applies
>to SW
>> softfork.
>>
>
>
>Yes - the logic applies to all soft forks.  Each soft fork degrades the
>security of non-upgraded nodes.
>
>The core design of bitcoin is that trustless nodes validate the work of
>miners, not trust them.
>
>Soft forks move in the opposite direction.  Each new soft-forked
>feature
>leans very heavily on miner trust rather than P2P network validation.
>
>
>
>
>___
>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] On the security of softforks

[Eric Lombrozo via bitcoin-dev]

First of all, that's an expensive beer!

Second of all, any consensus rule change risks non-full-validating or 
non-upgraded nodes seeing invalid confirmations...but assuming a large 
supermajority (i.e. > 95%) of hashing power is behind the new rule, it 
is extremely unlikely that very many invalid confirmations will ever be 
seen by anyone. The number of confirmations you require depends on your 
use case security requirements...and especially during a new rule 
activation, it is probably not a good idea for non-validating nodes or 
non-upgraded nodes to accept coins with low confirmation counts unless 
the risk is accounted for in the use case (i.e. a web hosting provider 
that can shut the user out if fraud is later detected).


Third of all, as long as the rule change activation is signaled in 
blocks, even old nodes will be able to detect that something is fishy 
and warn users to be more cautious (i.e. wait more confirmations or 
immediately upgrade or connect to a different node that has upgraded, 
etc...)


I honestly don't see an issue here - unless you're already violating 
fundamental security assumptions that would make you vulnerable to 
exploitation even without rule changes.


- Eric

-- Original Message --
From: "Jonathan Toomim via bitcoin-dev" 


To: "Pieter Wuille" 
Cc: "Bitcoin Dev" 
Sent: 12/17/2015 6:47:14 PM
Subject: Re: [bitcoin-dev] On the security of softforks



On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
 wrote:



1) The risk of an old full node wallet accepting a transaction that is
invalid to the new rules.

The receiver wallet chooses what address/script to accept coins on.
They'll upgrade to the new softfork rules before creating an address
that depends on the softfork's features.

So, not a problem.


Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob 
runs the old rules. Bob creates a p2pkh address for Mallory to use. 
Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob 
cannot properly validate and that pays into one of Mallory's wallets. 
Mallory then immediately spends the unconfirmed transaction into Bob's 
address. Bob sees what appears to be a valid transaction chain which is 
not actually valid.


Clueless Carol is one of the 4.9% of miners who forgot to upgrade her 
mining node. Carol sees that Mallory included an enormous fee in his 
transactions, so Carol makes sure to include both transactions in her 
block.


Mallory gets free beer.

Anything I'm missing?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Eric Lombrozo via bitcoin-dev]

There are no good short-term scaling solutions...this is a very hard problem 
that necessarily requires a lot of out-of-the-box thinking, something 2015 has 
seen a LOT of...and I'm optimistic about the ideas presented thus far.

At least SW *is* a scaling solution (albeit most of the important benefits are 
long term). The issue of fee events has nothing to do with scaling - it has to 
do with economics...specifically whether we should be subsidizing transactions, 
who should pay the bill for it, etc. My own personal opinion is that increasing 
validation costs works against adoption, not for it...even if it artificially 
keeps fees low - and we'll have to deal with a fee event sooner or later 
anyhow. You may disagree with my opinion, but please, let's stop confounding 
the economic issues with actual scaling.

On December 16, 2015 6:21:22 PM PST, Jeff Garzik via bitcoin-dev 
 wrote:
>On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo
>
>wrote:
>
>> A large part of your argument is that SW will take longer to deploy
>than a
>> hard fork, but I completely disagree. Though I do not agree with some
>> people claiming we can deploy SW significantly faster than a hard
>fork,
>> once the code is ready (probably a six month affair) we can get it
>deployed
>> very quickly. It's true the ecosystem may take some time to upgrade,
>but I
>> see that as a feature, not a bug - we can build up some fee pressure
>with
>> an immediate release valve available for people to use if they want
>to pay
>> fewer fees.
>>
>
>That's taking a big risk.  "Build up some fee pressure" is essentially
>risking a Fee Event if uptake is slower than planned, or traffic is
>greater
>than expected.
>
>
>
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>upgrade
>> to, is a 1-2 year affair (after the code is shipped, so at least
>1.5-2.5
>> from today if we all put off heads down and work). One thing that has
>> concerned me greatly through this whole debate is how quickly people
>seem
>> to think we can roll out a hard fork. Go look at the distribution of
>node
>> versions on the network today and work backwards to get nearly every
>node
>> upgraded... Even with a year between fork-version-release and
>> fork-activation, we'd still kill a bunch of nodes and instead of
>reducing
>> their security model, lead them to be outright robbed.
>>
>
>A hard fork will never achieve 100%  There are many credible folks and
>estimates who feel a May hard fork is reasonable and doable.
>
>Further, hard forks restore the full trustless nature of the
>post-hard-fork
>nodes.  Soft forks continually erode that.  That's why SW should come
>via
>hard fork.  The end result is more secure - 100% validation of witness
>transactions.
>
>If regular hard fork plans are proposed in public, many months in
>advance,
>there is plenty of time for the community to react.  Hard forks create
>a
>more predictable market and environment for Users, and a more secure
>network.
>
>Further, even if you believe SW makes hard fork unnecessary, it is the
>responsible thing to code and communicate to users the plan for a Fee
>Event
>just in case SW uptake and extension block use does not match
>theoretical
>projections of SW proponents.
>
>Finally, SW does not eliminate and is orthogonal to Short Term Problem
>#1
>(orig. email - drift into ECE)
>
>
>
>
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo via bitcoin-dev]

After reading Rusty's post, I admit there's something to be said for the fact 
that both the script and the nSequence field play a combined role, and thus, 
making the interaction between the two more clear in the naming make sense.

It is somewhat unfortunate that currently, we can't just have a dedicated field 
for the purpose of relative locktime (or minimum age) without having to 
repurpose the only unused 32 bits in the txin.

HOWEVER...there might be ways around this issue using segwit.

I've been pondering the possibility of adding an extra input vector to the 
prunable extra data that  comprises the witness. Witness structures can provide 
additional data that is used in transaction validation but does not contribute 
to the tx hash.

Currently, the signature checking opcodes in the script already do this 
implicitly for computing the hash that is signed (but not the tx hash used in 
block merkletrees)...and this is the principal cause of undesirable 
malleability issues. Clearly the signatures themselves cannot contribute to the 
hash they are signing. So segwit makes this separation explicit by moving the 
signatures to a structure external to the script. Pieter Wuille's 
implementation (https://github.com/sipa/bitcoin/tree/segwit) generalizes this 
idea using a script witness structure that is a vector of arbitrary inputs. 
Clearly moving the signatures into such structure is an important feature...but 
other types of input to the script could be placed here as well.

I had considered the possibility of placing a minimum age (relative locktime) 
field in the input vector that could be checked for mempool acceptance without 
having to evaluate the script. Of course, the location of such a field would 
have to be known by the mempool and cannot be an arbitrary element of a generic 
input vector, which adds some minor but surmountable complications.

Greg Maxwell pointed out, however, that signing opcodes that sign hashes 
discarding this data would make it trivial for anyone to change this field 
without signing anything. The nSequence fields of txins, being part of the tx 
serialization that gets hashed, is therefore always signed.

This led me to consider the possibility of adding extra opcodes to the script 
that can incorporate additional data in the hash that gets signed. This data 
would go in another structure that does not contribute to the tx hash but is 
outside the witness. Then we could add extra prunable data fields that the 
signer can commit to.

If I've missed something critical in the above analysis, someone please correct 
me...but it seems that such a mechanism would allow adding extra prunable 
signed data fields to transactions, which might ultimately remove scarcity of 
tx data that we can repurpose via soft forks. If this is the case, I would 
suggest turning the nSequence field into a dedicated min age/rlt field to 
simplify the semantics and avoid ugliness in trying to reclaim unused bits.

I may be overlooking something important here, but unless there's a reason such 
data cannot be made prunable, I haven't been able to poke a hole yet.

- Eric



On November 26, 2015 8:02:45 PM PST, Rusty Russell <ru...@rustcorp.com.au> 
wrote:
>Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>writes:
>>>From an app developer's perspective, I think it is pretty blatantly 
>> clear that relative timelock is *the* critical exposed functionality 
>> intended here.
>
>As someone who actually developed scripts using CSV, I agree with Mark
>(and Matt).  The relative locktime stuff isn't in this opcode, it's in
>the nSequence calculation.
>
>So, I vote to keep CSV called as it is.
>
>Thanks,
>Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo via bitcoin-dev]

After a little more though (and some comments from aj), I realize that the 
opcode naming convention is actually CHECK  VERIFY.

Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.

However, this name is ridiculously long, so at least some part will require 
abbreviation.

In typical script example usage, most sensible seems to be to abbreviate both 
CLTV and CRLTV.

- Eric

On November 24, 2015 5:14:55 PM PST, Eric Lombrozo  wrote:
>From a system developer standpoint, CHECKMATURITYVERIFY ties together 
>the semantics of this opcode with another existing feature in the
>system 
>(coinbase maturity).
>
>HOWEVER...
>
>from an application developer standpoint, I think the concept of a 
>timelock is more relevant. Maturity is a concept that was introduced
>for 
>the sake of reducing the disruptive impact of reorgs. Miners would 
>prefer to be able to spend the coins immediately, but instead they are 
>forced to wait due to inherent limitations of the system. Timelocks, on
>
>the other hand, are typically used to control when funds can be moved. 
>In these use cases, one or more of the parties involved explicitly want
>
>there to be a delay even if there were an idealized situation in which 
>consensus is always reached instantaneously and there were never any 
>reorgs.
>
>Moreover, since we already have CLTV, adding RCLTV or some variant 
>thereof makes the relationship between the two more explicit.
>
>So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.
>
>As for whether to explicitly use CHECK_..._VERIFY, consider that with 
>segregated witness it will be possible to add opcodes that can push 
>values onto the stack (rather than just hard failing or NOP), so
>there's 
>something to be said for naming consistency.
>
>- Eric
>
>
>
>-- Original Message --
>From: "Jorge Timón" 
>To: "Btc Drak" 
>Cc: "Bitcoin Dev" 
>Sent: 11/24/2015 4:31:55 AM
>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY 
>(BIP112)
>
>>I agree, I believe the first name that an op with equivalent 
>>functionality had was simply op_maturity.
>>At least I remember we discussed such an opcode when discussing pegged
>
>>sidechains' design.
>>
>>I kind of dislike the check_x_verify naming pattern. We want all new 
>>operands to return if whatever they're checking/verifying fails, fine.
>
>>Do we have to repeat this redundant naming pattern forever due to that
>
>>discovery?
>>I hope not, but if that's the case my vote is for CMV.
>>As said before, I believe the documentation and code comments can 
>>become much more clear with this change.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo via bitcoin-dev]

From a system developer standpoint, CHECKMATURITYVERIFY ties together 
the semantics of this opcode with another existing feature in the system 
(coinbase maturity).


HOWEVER...

from an application developer standpoint, I think the concept of a 
timelock is more relevant. Maturity is a concept that was introduced for 
the sake of reducing the disruptive impact of reorgs. Miners would 
prefer to be able to spend the coins immediately, but instead they are 
forced to wait due to inherent limitations of the system. Timelocks, on 
the other hand, are typically used to control when funds can be moved. 
In these use cases, one or more of the parties involved explicitly want 
there to be a delay even if there were an idealized situation in which 
consensus is always reached instantaneously and there were never any 
reorgs.


Moreover, since we already have CLTV, adding RCLTV or some variant 
thereof makes the relationship between the two more explicit.


So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.

As for whether to explicitly use CHECK_..._VERIFY, consider that with 
segregated witness it will be possible to add opcodes that can push 
values onto the stack (rather than just hard failing or NOP), so there's 
something to be said for naming consistency.


- Eric



-- Original Message --
From: "Jorge Timón" 
To: "Btc Drak" 
Cc: "Bitcoin Dev" 
Sent: 11/24/2015 4:31:55 AM
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY 
(BIP112)


I agree, I believe the first name that an op with equivalent 
functionality had was simply op_maturity.
At least I remember we discussed such an opcode when discussing pegged 
sidechains' design.


I kind of dislike the check_x_verify naming pattern. We want all new 
operands to return if whatever they're checking/verifying fails, fine. 
Do we have to repeat this redundant naming pattern forever due to that 
discovery?

I hope not, but if that's the case my vote is for CMV.
As said before, I believe the documentation and code comments can 
become much more clear with this change.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic Hierarchical Deterministic Key Trees

[Eric Lombrozo via bitcoin-dev]

Tamas,

You could use a key for both signing and for derivation of a deeper 
level (and perhaps there are some applications for this, if you think of 
any please let me know), but the use cases being considered involve 
generation of signing key sequences from seeds that are easy to backup 
and easy to share with others to simplify multidevice synchronization, 
key management, account structures, etc... while also allowing for 
privacy by making it nontrivial to associate transactions for an account 
without knowing the seed/chain code.


As such, we generally refer to such sequences by a path to the immediate 
parent node in the tree and reserve the children themselves for the 
signing keys.



- Eric



-- Original Message --
From: "Tamas Blummer" <ta...@bitsofproof.com>
To: "Eric Lombrozo" <elombr...@gmail.com>; "Eric Lombrozo via 
bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>

Sent: 11/17/2015 5:10:17 AM
Subject: Re: [bitcoin-dev] Dynamic Hierarchical Deterministic Key Trees


Hi Eric,

Would you please enumerate, or point to, arguments that discourage the 
use of a key both for signing and for derivation of a deeper level of 
the hierarchy ?


Tamas Blummer

 On Nov 17, 2015, at 12:40, Eric Lombrozo via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:


 I've submitted a BIP proposal that solves the issue of needing to 
predefine HD wallet structures and not being able to arbitrarily nest 
deeper levels. Comments appreciated.


 https://github.com/bitcoin/bips/pull/242


 - Eric
 ___
 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] Hierarchical Deterministic Script Templates

[Eric Lombrozo via bitcoin-dev]

A while back, I started working with William Swanson on a script 
template format to allow for interoperability in accounts between 
different wallets. We made some progress, but both of us got pretty busy 
with other projects and general interest was still quite low.


It seems interest has picked up again, especially in light of recent 
developments (i.e. CLTV, relative CLTV, bidirectional payment channels, 
lightning), where nongeneralized script formats will not readily support 
the rapidly advancing state-of-the-art in script design.


I have started working on a draft for such a standard: 
https://github.com/bitcoin/bips/pull/246


Comments, suggestions, and collaboration are welcome.

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

[bitcoin-dev] Fw: Making soft forks pluggable

[Eric Lombrozo via bitcoin-dev]

I wanted to clarify that this goal is for AFTER the next release in case 
that didn't come across. The point is just to ascertain interest and 
start thinking ahead. VersionBits can be fully ready to go well before 
then and is well underway.


-- Forwarded Message --
From: "Eric Lombrozo" 
To: "bitcoin-dev" 
Sent: 10/8/2015 8:58:12 PM
Subject: Making soft forks pluggable

Before I scare anyone away, please here me out:

It occurs to me it wouldn't be all that difficult to support the ability 
to define soft forks entirely as standalone units that can be trivially 
merged with Bitcoin Core. It would require a few changes in some places 
in the consensus code, but at least for a very wide class of potential 
soft forks, all cases could be covered via only a small number of hooks, 
primarily in main.cpp, consensus/*, script/interpreter.cpp, and 
primitives/*. (Other hooks could be added in non-consensus code such as 
rpcblockchain.cpp or the wallet). It would be possible to build unit 
tests for each soft fork independently and compare enforcement of 
different combinations (as well as simulate these deployment 
combinations on regtest).


Before I get too heavily invested in this idea, though, I'd like to see 
if there are any reasonable objections to such a thing. Of course, 
refactors are generally disruptive in the short-term...but I think what 
I'm talking about can be done without having to move very large chunks 
of code around, with very specifically defined hooks that can be easily 
documented to make backports fairly simple.


My biggest concern (other than being able to convince everyone that we 
won't break anything, which of course I'd have to do a good job of in 
terms of rigor) is whether supporting this feature is a good idea in the 
first place. There's something to be said for it not being *too* easy to 
write and deploy a soft fork...however, unless we open this up a little 
more and make such deployments more routine (and safe) it will take a 
very long time to deploy stuff. A significant motivation behind 
VersionBits (BIP0009) is to make such deployments faster, so if we're 
already doing that perhaps we might as well take this initiative even 
further.


If others think this is a good idea I'll start writing up a detailed 
plan. (NOTE: The current versionbits deployment plan does not require 
this. I am working on an implementation of versionbits that could 
potentially support this plan but doesn't have to.)


If I'm very wrong, I am all ears to *sincere* objections.


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

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Eric Lombrozo via bitcoin-dev]

You're right about the potential for 1 bad confirmation even with very low 
frequency...but with an overwhelming supermajority of hashpower, 2 bad 
confirmations become quite unlikely, n bad confirmations becomes exponentially 
unlikely in n.

As part of such soft fork deployments, it's true that old nodes might see a bad 
confirmation on occasion (even assuming overwhelming supermajority hashpower 
adoptance). So yes, old nodes and SPV clients should probably require more 
confirmations right around such a transition...or should upgrade. It is 
entirely possible to make clients warn the user if the block version is 
unrecognized, which will help to prevent anyone from accepting bad blocks 
(although SPV security necessarily relies on miners to validate for them).

On October 7, 2015 9:02:14 AM PDT, Eric Lombrozo  wrote:
>That's why it's important to measure miner adoptance. Note that this
>isn't a vote - it's an adoption metric for what is presumably a fairly
>uncontroversial upgrade. If there's contentious controversy amongst
>miner all bets are off.
>
>Our current mechanisms are imperfect in this regard...as we've seen in
>the past, miners have deliberately disabled checks despite signaling
>adoption in their blocks. But a real hashpower supermajority would make
>such attacks hard to pull off in practice.
>
>- Eric
>
>On October 7, 2015 8:46:08 AM PDT, "Jonathan Toomim (Toomim Bros) via
>bitcoin-dev"  wrote:
>>
>>On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev
>> wrote:
>>
>>> *But* a soft fork that only forbids transactions that would
>>previously
>>> not have been mined anyway should be the best of both worlds, as it
>>> automatically reduces the liklihood of old miners building newly
>>invalid
>>> blocks to a vanishingly small probability; which means that upgraded
>>> bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*
>>> continuing to work fine during the upgrade.
>>
>>I agree with pretty much everything you wrote except the above
>>paragraph.
>>
>>An attacker can create a transaction that would be valid if it were an
>>OP_NOP, but not valid if it were any more restrictive transaction. For
>>example, an attacker might send 1 BTC to an address with  . An old
>node
>>would consider that OP_CLTV to be OP_NOP, so no signature is necessary
>>for old nodes. Then the attacker buys something from a merchant
>running
>>old node code or an SPV client, and spends the 1 BTC in that address
>in
>>a way that is invalid according to OP_CLTV but valid according to
>>OP_NOP, and includes a hefty fee. A miner on the old version includes
>>this transaction into a block, thereby making the block invalid
>>according to the new rules, and rejected by new-client miners. The
>>merchant sees the 1-conf, and maybe even 2-conf, rejoices, and ships.
>>The attacker then has until the OP_CLTV matures to double-spend the
>>coin with new nodes using a valid signature.
>>
>>Basically, it's trivial to create transactions that exploit the
>>difference in validation rules as long as miners are still on the old
>>version to mine them. Transactions can be created that are guaranteed
>>to be orphaned and trivially double-spendable. Attackers never have to
>>risk actual losses. This can be done as long as miners continue to
>mine
>>old-version blocks, regardless of their frequency.
>>
>>Those of you who know Script better than me: would this be an example
>>of a transaction that would be spendable with a valid sig XOR with
>(far
>>future date OR old code)?
>>
>>OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIGVERIFY
>>OP_PUSHDATA  OP_CLTV
>>
>>
>>
>>
>>___
>>bitcoin-dev mailing list
>>bitcoin-dev@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Eric Lombrozo via bitcoin-dev]

I prefer the term "clown".

Can we please move on?

-- Original Message --
From: "cipher anthem via bitcoin-dev" 


To: mi...@bitcoins.info
Cc: bitcoin-dev@lists.linuxfoundation.org
Sent: 10/6/2015 12:17:14 AM
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork 
technical debate



 Sent: Monday, October 05, 2015 at 8:21 PM
 From: "Milly Bitcoin via bitcoin-dev" 


 To: bitcoin-dev@lists.linuxfoundation.org
 Subject: Re: [bitcoin-dev] This thread is not about the soft/hard 
fork technical debate

 On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:

 It's pretty clear Mike has turned into concern troll and bully.



 "troll" and, even worse, "concern troll" are terms generally used by
 teenagers on places like Reddit to complain about someone who doesn't
 agree with them.


They should substitute troll for cultist so they appear more 
professional...

___
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] This thread is not about the soft/hard fork technical debate

[Eric Lombrozo via bitcoin-dev]

I agree with you, Sergio, up until the part about someone having won a battle. 
There's a difference between sincere technical objections and someone just 
being a dick. I think in this case this line has been crossed (and I don't 
think I'm alone here).

- Eric

On October 5, 2015 8:56:33 AM PDT, Sergio Demian Lerner via bitcoin-dev 
 wrote:
>Some of the people on this mailing list are blindly discussing the
>technicalities of a soft/hard fork without realizing that is not Mike's
>main intention. At least I perceive (and maybe others too) something
>else
>is happening.
>
>Let me try to clarify: the discussion has nothing to do with technical
>arguments. I generally like more hard forks than soft forks (but I
>won't
>explain why because this is not a technical thread), but for CLTV this
>is
>quite irrelevant (but I won't explain why..), and I want CLTV to be
>deployed asap.
>
>Mike's intention is to criticize the informal governance model of
>Bitcoin
>Core development and he has strategically pushed the discussion to a
>dead-end where the group either:
>
>1) ignores him, which is against the established criteria that all
>technical objections coming from anyone must be addressed until that
>person
>agrees, so that a change can be uncontroversial. If the group moves
>forward
>with the change, then the "uncontroversial" criteria is violated and
>then
>credibility is lost. So a new governance model would be required for
>which
>the change is within the established rules.
>
>2) respond to his technical objections one after the other, on never
>ending
>threads, bringing the project to a standstill.
>
>As I don't want 2) to happen, then 1) must happen, which is what Mike
>wants. I have nothing for or against Mike personally. I just think Mike
>Hearn has won this battle. But having a more formal decision making
>process
>may not be too bad for Bitcoin, maybe it can actually be good.
>
>Best regards
> from a non-developer to my dearest developer friends,
>  Sergio.
>
>
>
>
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Design Competition

[Eric Lombrozo via bitcoin-dev]

I've also got a competition where the object is to build a spaceship 
using only a watermelon, two donkeys, some duct tape, and a fire 
hydrant.


-- Original Message --
From: "Richard Olsen via bitcoin-dev" 


To: "bitcoin-dev" 
Sent: 9/29/2015 11:37:07 PM
Subject: [bitcoin-dev] Design Competition


All,

We are looking for participants in a Bitcoin related competition: the 
aim is to build a trading platform (initially for foreign exchange, 
other assets will follow) which lets participants settle their trades 
through the blockchain via coloured coins. To facilitate a quicker 
trade reconciliation, the use of a sidechain is a suggestion but by no 
means a requirement. There will be an online briefing event today where 
we will outline the requirements in more detail, though much of it we 
have posted on our website www.lykkex.com .


As we want this to be a community driven effort rather than something 
turning into a proprietary technology, all contributions will be made 
available under a MIT license on Github.


I look forward to answering your questions at the online briefing event 
or over email,


Thank you and kind regards,
Richard Olsen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

[Eric Lombrozo via bitcoin-dev]

I can go along with making it optional but recommended for the first deployment 
and making it mandatory later on. It would be purely informational for 
now...but it will give us valuable data.

As has been said before, most of these BIP deployments will likely be 
accompanied by recommended default settings for miners. Assuming the BIP itself 
is not very controversial, the gravest dangers come not so much from miners (or 
pool operators, more accurately) deliberately choosing to lie...but more from 
either shortcuts taken in implementations and/or bugs. Collecting additional 
data will help spot faulty implementations and allow us to intervene.

Eventually, I imagine a much more sophisticated signaling mechanism where 
endusers can be given highly informative messages regarding changes and we can 
have a way of directing people to resources where they can learn more about the 
new features.

- Eric

On September 30, 2015 5:26:51 PM PDT, Rusty Russell  
wrote:
>Gregory Maxwell  writes:
>> I can, however, argue it the other way (and probably have in the
>> past):  The bit is easily checked by thin clients, so thin clients
>> could use it to reject potentially ill-fated blocks from non-upgraded
>> miners post switch (which otherwise they couldn't reject without
>> inspecting the whole thing). This is an improvement over not forcing
>> the bit, and it's why I was previously in favor of the way the
>> versions were enforced.  But, experience has played out other ways,
>> and thin clients have not done anything useful with the version
>> numbers.
>>
>> A middle ground might be to require setting the bit for a period of
>> time after rule enforcing begins, but don't enforce the bit, just
>> enforce validity of the block under new rules.  Thus a thin client
>> could treat these blocks with increased skepticism.
>
>Introducing this later would trigger warnings on older clients, who
>would consider the bit to represent a new soft fork :(
>
>So if we want this middle ground, we should sew it in now, though it
>adds a other state.  Simplest is to have miners keep setting the bit
>for
>another 2016 blocks.  If we want to later, we can make this a consensus
>rule.
>
>"Bitcoin is hard, let's go shopping!"  "With Bitcoin!"  "..."
>Rusty.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Eric Lombrozo via bitcoin-dev]

Mike,

Insults were not really my intention. Let's set aside our differences regarding 
SPV security and assume you understand the different implications for soft 
forks and hard forks.

Other than the fact that doing this as a soft fork requires an extra OP_DROP, 
how would doing this as a hard fork make any difference to SPV clients? If, as 
others have suggested, all clients warn the user on unrecognized nVersion and 
make unknown noops nonstandard, would this satisfy your concerns? The logic 
seems pretty straightforward.

- Eric

On September 28, 2015 5:54:33 AM PDT, Mike Hearn  wrote:
>>
>> we have NO hard fork mechanism in place that isn't highly prone to
>> systemic consensus failure.
>>
>
>Just use an opcode that isn't currently defined. Done. What about that
>mechanism is prone to failure?
>
>Re: coma. No need for insults. Please read my article and address the
>points raised there, which, by the way, do not include any mention of
>SPV
>wallets. Although your belief that SPV wallets are "inherently
>insecure"
>seems needlessly trollish - I certainly would disagree, but it's a
>different debate.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

[Eric Lombrozo via bitcoin-dev]

While I would like to get some form of explicit acknowledgment from 
miners that a new rule is in effect, the truth of the matter is we 
still lack a means to determine whether or not miners are actually 
enforcing these rules...unless someone happens to mine a block that 
breaks the new rule. This is a bit frustrating...but that's just how it 
is.




I should add that hard forks do provide us with a means to determine 
whether or not miners are enforcing the new rules...but generally 
speaking they risk far greater disruption if anything fails to go as 
planned. Between the risk of clients accepting an occasional invalid 
"confirmation" or two and the risk of a total network partition, the 
former seems far less serious. I believe the concerns regarding old 
clients can be remedied to a very large extent by means of a good 
awareness campaign.



- Eric

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

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

[Eric Lombrozo via bitcoin-dev]

Good points, Greg.

The way I see it, this mechanism isn't really about "voting" - it's 
about deployment of fairly uncontroversial changes with the minimum 
amount of negative disruption. If we have reason to believe a particular 
BIP stands little chance of hitting the 95% mark relatively quickly, 
it's probably better not to deploy it...so this mechanism is most useful 
for adding fairly uncontroversial features provided as default settings 
in product releases - and measuring adoption as best we can before 
activating these features.


The current controversies around things like CLTV, CSV, etc... don't 
seem to revolve around these features themselves - there seems to be 
near-unanimous agreement that these features are good (and most 
disagreements regarding functionality are over quite minor nits, 
really). Instead the controversies are much more likely to be around 
deployment strategies.


While I would like to get some form of explicit acknowledgment from 
miners that a new rule is in effect, the truth of the matter is we still 
lack a means to determine whether or not miners are actually enforcing 
these rules...unless someone happens to mine a block that breaks the new 
rule. This is a bit frustrating...but that's just how it is.


To sum up, Version Bits is not a mechanism for vetting proposed changes 
and building consensus (that should take place BEFORE we assign bits). 
This is a deployment mechanism for fairly uncontroversial changes. 
Either a BIP is relatively quickly adopted with overwhelming 
support...or else perhaps it's best to wait until it has sufficient 
support before attempting deployment (or perhaps not deploy it at all) - 
and ultimately we want these transitions to run as smoothly as possible. 
As long as the BIPs are relatively uncontroversial, miners will most 
likely continue to choose to cooperate in the interest of the health of 
the network (and will use recommended default settings). Once clients 
have better support for this, perhaps we can do more sophisticated 
signaling.



- Eric


-- Original Message --
From: "Gregory Maxwell" 
To: "Rusty Russell" 
Cc: "Bitcoin Dev" ; "Peter Todd" 
; "Pieter Wuille" ; "Eric 
Lombrozo" 

Sent: 9/29/2015 7:57:52 PM
Subject: Re: Versionbits BIP (009) minor revision proposal.

On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell  
wrote:

 Hi all,

 Pieter and Eric pointed out that the current BIP has miners
 turning off the bit as soon as it's locked in (75% testnet / 95%
 mainnet).  It's better for them to keep setting the bit until 
activation

 (2016 blocks later), so network adoption is visible.

 I'm not proposing another suggestion, though I note it for future:
 miners keep setting the bit for another 2016 blocks after activation,
 and have a consensus rule that rejects blocks without the bit.  That
 would "force" upgrades on those last miners.  I feel we should see 
how

 this works first.



Actually getting rid of the immediate bit forcing was something I
considered to be an advantage of versionbits over prior work.

Consider,  where possible we carve soft fork features out from
non-standard behavior.  Why do we do this?  Primarily so that
non-upgraded miners are not mining invalid transactions which
immediately cause short lived forks once the soft-fork activates.
(Secondarily to protect wallets from unconfirmed TX that won't ever
confirm).

The version forcing, however, guarantees existence of the same forks
that the usage of non-standard prevented!

I can, however, argue it the other way (and probably have in the
past):  The bit is easily checked by thin clients, so thin clients
could use it to reject potentially ill-fated blocks from non-upgraded
miners post switch (which otherwise they couldn't reject without
inspecting the whole thing). This is an improvement over not forcing
the bit, and it's why I was previously in favor of the way the
versions were enforced.  But, experience has played out other ways,
and thin clients have not done anything useful with the version
numbers.

A middle ground might be to require setting the bit for a period of
time after rule enforcing begins, but don't enforce the bit, just
enforce validity of the block under new rules.  Thus a thin client
could treat these blocks with increased skepticism.


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

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Eric Lombrozo via bitcoin-dev]

Perhaps Adam won't go into the rationale...but I think it is important we 
clarify this.

For better or worse, the only "voting" system available to Bitcoin that cannot 
be trivially attacked is hashing power. Soft forks are essentially 
miner-enforced rule changes...rules they could have decided to enforce without 
the consensus of anyone else. For instance, as far as old nodes are concerned, 
a p2sh output can be redeemed by a simple preimage of the hash...with no 
signatures. The point, however, is that as long as the majority of hashpower 
enforces the new rule, such attempts to redeem the output will never end up on 
the blockchain. Therefore, transactions that attempt to redeem the output with 
a simple preimage are as good as invalid...and effectively have become invalid.

I concede that this mechanism has some issues. Moreover, I agree that it is 
important that the Bitcoin community be aware of these things. I've been 
proposing making these rule changes explicit in the BIPs 
(https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki).
 I believe it is important that people weigh in on such rule changes. However, 
the above stated mechanism does not fall under the definition of "hard fork" 
we've come to accept.

Go ahead and object to soft forks...but at least try not to make arguments 
based on changing the definitions of terms we all generally agree upon.

- Eric

On September 28, 2015 4:40:35 AM PDT, Mike Hearn via bitcoin-dev 
 wrote:
>>
>> The rationale for soft vs hard-forks is well known, so I wont go over
>them.
>>
>
>The rationale of "backwards compatibility" is well known, yet wrong.
>I've
>gone over the arguments here and explained why the concept makes no
>sense:
>
>https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>
>Eric - no, it's not sophisticated humour. I've been objecting to soft
>forks
>since this idea first appeared.
>
>There is no consensus. Now pick. Lose the requirement that everyone
>agree
>for consensus changes, and tell people you've done it. Change the spec.
>Or
>do nothing.
>
>
>
>
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Eric Lombrozo via bitcoin-dev]

My initial reaction is just HUH?!?!? Is this some sophisticated form of humor 
I'm just not getting?

On September 28, 2015 3:48:57 AM PDT, Mike Hearn via bitcoin-dev 
 wrote:
>There is *no* consensus on using a soft fork to deploy this feature. It
>will result in the same problems as all the other soft forks - SPV
>wallets
>will become less reliable during the rollout period. I am against that,
>as
>it's entirely avoidable.
>
>Make it a hard fork and my objection will be dropped.
>
>Until then, as there is no consensus, you need to do one of two things:
>
>1) Drop the "everyone must agree to make changes" idea that people here
>like to peddle, and do it loudly, so everyone in the community is
>correctly
>informed
>
>2) Do nothing
>
>
>
>
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Eric Lombrozo via bitcoin-dev]

SPV wallets in their current form are inherently insecure. Moreover, while we 
at least have a soft fork mechanism that is not trivially exploitable (yes, 
it's got issues...but unlike SPV wallets, it isn't so easily exploitable), we 
have NO hard fork mechanism in place that isn't highly prone to systemic 
consensus failure.

But I think pretty much anyone who hasn't been in a coma for the last several 
years knows this...and I'll stop repeating the obvious.

On September 28, 2015 5:26:17 AM PDT, Mike Hearn  wrote:
>>
>> Go ahead and object to soft forks...but at least try not to make
>arguments
>> based on changing the definitions of terms we all generally agree
>upon.
>>
>
>I don't intend to do that, and I don't think I am - I know what the
>difference between a soft and hard fork is and am not trying to confuse
>or
>blur the two.
>
>To reiterate: this current BIP implements a soft fork. I am not
>debating
>that. I am saying it should use a hard fork instead. This will ensure
>no
>repeat of the P2SH case where invalid blocks were being found for weeks
>(or
>was it months?) after the new rules kicked in, thus exposing SPV
>wallets
>and old nodes to unnecessary risk for no benefit.
>
>Additionally, I am making it clear that there's no consensus for
>rolling
>out the new opcode in this way. As you say, the mechanism has issues.
>If
>you read the comments when I wrote my article, you can see that others
>share the same concerns:
>
>https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo via bitcoin-dev]

-- Original Message --
From: "s7r via bitcoin-dev" 
To: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 2:33:38 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

The general threat model for which we want to scale is: larger user 
base

(not necessarily by increasing the blocksize - just increase the
transactions per second using the best way from all points of view),
more use cases for simple people who only do basic stuff, more
popularity but all these without the possibility for some actor to
control more than he should (like a government agency).


Larger user base won't necessarily protect against governments if we 
still have chokepoints they can go after. Given that as a currency 
Bitcoin  currently represents a negligible portion of the world's 
economy, even growing the user base by some small factor is at best a 
token gesture in our fight against governmental threats. If governments 
successfully take down critical pieces of our network infrastructure, 
Bitcoin will fail and most people will continue doing business as usual 
(using fiat currency), most of them never even noticing anything 
noteworthy happened at all.


What we really need to grow is the number of nodes on the network that 
participate in its basic infrastructure - namely: miners, validators, 
etc...and the more centralized these activities become, the easier it 
will be for governments to clamp down.




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

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo via bitcoin-dev]

-- Original Message --
From: "Milly Bitcoin via bitcoin-dev" 


To: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 3:02:32 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report


Larger user base won't necessarily protect against governments if we
still have chokepoints they can go after.



Bitcoin will always have chokepoints governments can go after.  Hackers 
already targeted routers to divert mining traffic awhile back.  Bitcoin 
traffic is easily seen and blocked by ISP's.  It has already been 
pointed out that laws against merchants and exchanges cannot be 
defended against any other way than to have many people use the system.
Almost none of these merchants depend on Bitcoin in any significant way 
for revenue...and that's likely to remain the case for a good while. 
Merchants that have chosen to accept Bitcoin are typically using a 
handful of payment processors, again...chokepoints. And almost none of 
them are contributing any network resources back to Bitcoin.


Exchanges are indeed serious chokepoints. But increasing the number of 
users will probably have relatively little effect on this unless we also 
increase the number of exchanges and decentralize the exchanges. If all 
we had to do is increase the number of users, the same argument could be 
used to claim that banks would be less susceptible to governmental 
crackdowns if they just had more account holders.


Exchange decentralization is indeed another thing we must work towards - 
but that's probably beyond the scope of the more pressing issue which is 
building consensus in Bitcoin development.


(As a developer you, of course, did not mention the threat of having a 
tiny number of developers who have significant influence over Bitcoin.  
It always amazes me the endless discussion over miners centralization 
and almost zero discussion of developer decentralization.)
I've pointed out this weakness of Bitcoin *numerous* times. That I 
failed to mention it here does not mean it hasn't been discussed 
elsewhere. Some of us have also been actively working towards developing 
a more modular, layered architecture and better implementations that 
will afford greater decentralization in software development with less 
need for critical code reviews, less pushback from downstream developers 
who must continuously rebase, a better process for building consensus in 
the community, and simpler app migration.





Increasing the nodes by a factor of 2 or 3 or keeping the block size 
small to increase the diversity of miners by a few percent will have 
zero effect if those other government threats were to actually happen.


We need to increase the basic infrastructure nodes by a factor much 
larger than 2 or 3...more like 100 or 1000...and it's entirely doable 
with properly aligned incentives.



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] Weekly development meetings on IRC

[Eric Lombrozo via bitcoin-dev]

I love the weekly meeting idea...but timezones might be an issue.

My general preference would be afternoons to late evenings pacific time, but 
that translates to late night/early morning for those in europe.

On September 18, 2015 12:04:58 AM PDT, Jonas Schnelli via bitcoin-dev 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>> On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan
>> via bitcoin-dev wrote:
>>> At Monday's code sprint we had a good idea to schedule a regular
>>> developer meeting in #bitcoin-dev.
>>> 
>>> Attendance is of course voluntary, but it may be good to have a
>>> time that many people are expected to be present and current
>>> issues can be discussed.
>> 
>> I think it's important to make a point that these meetings are for
>>  discussions, and explicitly never decisions, to avoid a repeat of
>> the P2SH events when people have to miss it.
>> 
>>> Any preference for days/times?
>>> 
>>> What about e.g. every week 15:00-16:00 UTC on Thursday?
>
>+1 for the weekly IRC meetings.
>
>For time and date maybe a Doodle could help:
>http://doodle.com/poll/cihug53sa8u4h2in#table
>
>
>- ---
>jonas
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJV+7eaAAoJECnUvLZBb1PsESgQAIQnHDe7owv3OzMvxwupzGaD
>IkTsRtCTSntIb75Wb/KYc0y1L3ilSENRTfZ4nNc4QquqTstkhjU5t+u9T3Mak4D3
>2/5AOiJhV6OLYav1SC7uSJh0B4halnZlTwclU7NOvmnkg40DUpNxmEbf+RvUZup3
>J0EQFxIuhtjIz0HfZTvw6wmstrP3+UJZTbM5fg0FO3TpgmGybAUoQ3eWgRa7v/gR
>OUxnAV//Mus2O80/Z+c5KycZ1Dqc/iN7cQsQFt7kEIK0epkJhkTjoRrW9MyQW04d
>1jv7d0mjEJt+2EiC8UuwpaW2eFmeFnGR0pL4UCY1QsDzGENyHKNbrVg26v1AzIbB
>SNEYN1+fmsXQYosY5t0Z887Ij+u4/GLHciimh5z7fbI5VB1Ng6Wl84maVmP5Zb3L
>MHtkIqQ00RX7GIXUp5+u7eKOO0pH9S08tqo5Ag6ceynJ2lh4Wr8BCNghHzH+ybNJ
>NG3BaSkQmjxnWjW3XplaYyxz6E4qJ8id7qH4s0iaNKchAfXiCaBtbcMfljlyBSn/
>UbzHJk5jlWZEVpxmiMRctFxusk6GI4P+0eRTJrkffskLEjImUN93A8hOLs5Dy+gI
>mm/PZKT2S2qKKa6dlI2kpyPZuRbN7+WSi/FwI0YsUDGl+IoDSqTX7WqRY8cY40ji
>rUgzYTw3Won3BcjHTe9y
>=JsXj
>-END PGP SIGNATURE-
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] libconsensus and bitcoin development process

[Eric Lombrozo via bitcoin-dev]

You're aware that my entire stack was built around this model and I've even 
built a fully fledged desktop GUI, multisig account manager, and servers 
supporting pull and event subscription atop it, right?

On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via 
bitcoin-dev"  wrote:
>On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev
>wrote:
>
>> I've run into a number of cases where companies were maintaining
>forks
>> of Bitcoin Core unnecessarily, where a different, loosely coupled,
>> architecture could do what they needed to do without including the
>new
>> logic in the codebase itself.
>
>This is the same point I have been making to Jeff privately.
>
>Refactors are a means to an end: a more modular, reusable and
>maintainable codebase. This goal is that new functionality can be
>plugged in more easily, and rebase work for e.g. functionality built on
>top can go down, not up, if it just hooks into well-defined interfaces
>here and there.
>
>Although there has been a lot of progress, bitcoind's design is still
>too monolithic. To add a more involved feature, like say a new index
>over the block chain data, code needs to be touched all over the place.
>This change interacts with all other functionality, potentially
>breaking the base node functionality - risk for users that do NOT use
>the functionality. This increases risk and review time.
>
>- *If possible* functionality should be built without changing
>bitcoind's code at all. An external process should be able to keep up
>to date with the chain, notice reorgs, and process block data
>accordingly. If bitcoind's interface does not allow that, or it is too
>difficult, that is what should be fixed. 
>- *if not possible* then a change should at least touch the code in as
>few places as possible, and integrate with e.g. signal notification.
>
>To name an example of it done right, IMO: Monero's 'simplewallet'. It
>is a command-line utility wallet that communicates with the node
>software, and remembers where it was in the chain, and processes
>changes to the chain state since its last invocation when it
>'refreshes'. 
>What is nice is that one can run an arbitary number of simplewallets
>against one node daemon, and unlike bitcoind's wallet it doesn't need
>to run as always-on daemon itself. It can be invoked when the user
>wants to do something with the wallet, or see if there are new
>transactions.
>
>An index could be implemented entirely externally in a similar way,
>while still fully handling reorgs.
>
>What one needs for that, I think, is a library that communicate with
>the node, and which offers functionality abstractly be similar to 'git
>pull': give me the tree path from my current known tip to the best tip,
>and supply the block hashes (and block data) along the way. 
>
>My long-term vision of bitcoind is a P2P node with validation and
>blockchain store, with a couple of data sources that can be subscribed
>to or pulled from.
>
>Wladimir
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

[Eric Lombrozo via bitcoin-dev]

The exact numbers (95% vs. 75% etc) don't need to be completely specified to 
start working on an implementation. What really matters for now is defining the 
states and trigger mechanisms. I'd rather we not argue over the optimal values 
for supermajority requirement at this point.

On September 16, 2015 5:03:43 PM EDT, "Jorge Timón via bitcoin-dev" 
 wrote:
>I understand your proposal, but I don't see what it accomplishes
>compared
>to applying the new rule from the start (in your own blocks) and wait
>for
>95% for consensus activation (which is my preference and it's much
>simpler
>to implement).
>What are the disadvantages of my approach? What are the advantages of
>yours?
>On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón 
>wrote:
>>
>>>
>>> On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > At 75%, if someone sets the bit, then they should be creating
>valid
>>> blocks (under the rule).
>>>
>>> You shouldn't rely on that, some may start applying the restrictions
>in
>>> their own blocks at 0% and others only at 90%. Until it becomes a
>consensus
>>> rule it is just part of the standard policy (and we shouldn't rely
>on nodes
>>> following the standard policy).
>>>
>>
>> It would be a consensus rule.  If >75% of the blocks in the last 2016
>> window have the bit set, then reject all blocks that have the bit set
>and
>> fail to meet the rule.
>>
>>
>> ___
>> 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] libconsensus and bitcoin development process

[Eric Lombrozo via bitcoin-dev]

I basically agree with what has been said here.

Refactoring efforts should be well-coordinated. Their short-term impact can be 
quite disruptive, although if done correctly, longer-term they make it even 
easier for downstream developers to add and merge changes.

By scheduling move-only changes, others can avoid making PRs immediately prior 
to or during these changes (which ironically involve considerable disruption to 
PRs while changing nothing for endusers). Furthermore, it would be useful to 
document the changes in ways that help other developers rebase properly.

On September 15, 2015 11:26:50 AM EDT, Jeff Garzik via bitcoin-dev 
 wrote:
>Drak,
>
>I would say that the refactoring does actually fulfill some conditions
>you
>mention:
>- move-only is almost always clearly separated out
>- the refactoring is not controversial _in minimis_ - meaning, the
>individual pull request is not controversial.
>
>The problem comes with the impact of an unfocused stream of refactors
>to
>key code.
>
>For example, there is much less long term developer impact if
>refactoring
>were _accelerated_, scheduled to be performed in a one-week sprint. 
>There
>is a lot of breakage, yes, but after that week the average level of
>downstream patch breakage is significantly lower.  A "rip the band-aid
>off
>quickly rather than slowly" approach.
>
>
>
>
>On Tue, Sep 15, 2015 at 5:55 AM, Btc Drak  wrote:
>
>> I also share a lot of Jeff's concerns about refactoring and have
>voiced
>> them several times on IRC and in private to Jorge, Wladamir and Greg.
>I
>> meant to do a write up but never got around to it. Jeff has quite
>> eloquently stated the various problems. I would like to share my
>thoughts
>> on the matter because we really do need to come up with a plan on how
>this
>> issue is dealt with.
>>
>> Obviously, Bitcoin Core is quite tightly coupled at the moment and
>> definitely needs extensive modularisation. Such work will inevitably
>> require lots of bulk code moves and then finer refactoring. However,
>it
>> requires proper planning because there are lots of effects and
>consequences
>> for other people contributing to Core and also downstream projects
>relying
>> on Core:
>>
>> 1. Refactoring often causes other pull requests to diverge and
>require
>> rebasing. Continual refactoring can put PRs in "rebase hell" and puts
>a big
>> stress on contributors (many of whom are part time).
>>
>> 2. Version to version, Bitcoin Core changes significantly in
>structure.
>> 0.9 to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This
>makes
>> makes it hard to follow release to release and the net result is less
>> people upgrade (especially think of miners trying to keep their patch
>sets
>> working while trying not to disrupt or risk their mining operations).
>>
>> 3. Continual refactoring increases risk: we're human, and mistakes
>will
>> slip through peer review. This is especially concerning with
>consensus
>> critical code and this makes it difficult to merge such refactoring
>often,
>> which of course exacerbates the problem.
>>
>> The net negative consequence is it is harder to contribute to Core,
>harder
>> for the Core maintainers to merge and harder for downstream/dependent
>> projects/implementations to keep up.
>>
>> Suggested Way Forward
>> -
>>
>> With the understanding that refactored code by definition must not
>change
>> behaviour. There are three major kinds of refactoring:
>>
>> 1. code moves (e.g. separating concerns into different files);
>> 2. code style;
>> 3. structural optimisation and consolidation (reducing LOC,
>separating
>> concerns, encapsulation etc).
>>
>> Code moves(1) and CS(2) are easy to peer review and merge quickly.
>The
>> third kind(3) requires deeper analysis to ensure that while the code
>> changed, the behaviour (including any bugs) did not.
>>
>> We must resist all temptation to fix bugs or tack on minor fixes and
>> tweaks during refactoring: pull requests should only be refactoring
>only,
>> with no net change to behaviour. Keeping discipline makes it much
>easier to
>> verify and peer review and this faster to merge.
>>
>> With respect to Code moves and CS, I believe we should have a
>"refactoring
>> fortnight" where we so the bulk of code move-only refactoring plus CS
>where
>> necessary. This is by fat the most disruptive kind of change because
>it
>> widely affects other PRs mergeability. We should aim to get most of
>this
>> done in one go, so that it's not happening in dribs and drabs over
>months
>> and many releases. Once done, it gives everyone a good idea to the
>overall
>> new structure and where one can expect to find things in the future.
>The
>> idea here is to help orientation and not have to continuously hunt
>for
>> where things have moved to.
>>
>> To be clear, I am strongly suggesting code move-only refactoring PRs
>not
>> be mixed with anything else. Same for CS 

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Eric Lombrozo via bitcoin-dev]

In principle I am sympathetic to dynamic block size proposals...but in
practice it seems we're barking up the wrong tree. Without mechanisms for
incentivizing validators...and checks and balances between the interests of
regular users (who want to reduce fees and confirmation time), miners (who
want to balance hashing and propagation time costs with revenue), and
validator nodes (who currrently lack any direct incentives), I think we're
talking about significant protocol complications with potential benefits
that are hard to model at best.

On Sat, Aug 29, 2015, 3:16 AM Btc Drak via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:
  Ah, then my mistake. It seemed so similar to an idea that was proposed
  before on this mailing list:
 
 
 http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
 
  that my mind just filled in the gaps. I concur -- having miners -- or any
  group -- vote on block size is not an intrinsically good thing. The the
  original proposal due to Greg Maxwell et al was not a mechanism for
 voting
  but rather a feedback control that made the maximum block size that which
  generated the most fees.

 Mark and Jorge,

 I am very glad you have brought up this particular objection because
 it's something I thought about but was unclear if it was an opinion
 that would be shared by others. I chose to omit it from the proposal
 to see if it would come up during peer review.

 I feel that giving miners a blank cheque to increase blocksize, by any
 means, goes against a key design of bitcoin's security model. Full
 nodes keep miners honest by ensuring by validating their blocks. Under
 any voting-only scheme there is no way for full nodes to keep miners
 in cheque because miner have free reign to increase the blocksize.

 This problem can be solved by introducing a hard cap on blocksize. By
 introducing an upper limit miners now have the freedom to increase
 blocksize but only within defined parameters.  Remember my proposal
 allows blocksize to increase and decrease in such a way that miners
 must collectively agree if they want the size to increase.

 I believe the idea of a hard upper limit has become rather politicised
 but is essential to the security model of bitcoin.

 With respect to the flexicap idea where miners can create a larger
 block by paying extra difficulty, I believe that proposal has a
 critical flaw because, as Gavin pointed out, it makes it very
 expensive (and risky) to include a few extra transactions. I believe
 it suffers from tragedy of the commons because there is no incentive
 for the mining community to reach consensus. Each and every block is
 going to be a gamble, should we include a few extra transactions at
 the risk of losing the block?. Under my proposal miners can
 collectively agree to change the blocksize. Let's say they want a 10%
 increase, they can collude together to make that increase and once
 reached, it remains until they want to change it again. Yet, the upper
 hard limit keeps the ultimate control of the maximum block size
 squarely in the hands of full nodes.

 Whilst the exact number may be up for discussion, I would propose an
 initial upper limit of 8MB, so under my proposal the blocksize would
 be flexible between 1MB and 8MB.

 An alternative methodology to voting in the coinbase would be to
 change the vote to be the blocksize itself

 1. miners pay extra difficulty to create a larger block.
 2. every 2016 blocks the average or median of the last 2016 blocks is
 calculated and becomes the new maximum blocksize limit.

 This would retain incentive to collude to increase blocksize, as well
 as the property of costing to increase while being free to propose
 decrease.

 It would still require an upper blocksize limit in order for full
 nodes to retain control. Without an upper limit, any proposal is going
 to break the security model as full nodes give up some oversight
 control over miners.

 Another way of looking at these ideas is we're raising blocksize hard
 limit (to 8MB or whatever is decided), but making a soft of softer
 or inner limit part of consensus. Such a concept is not really
 departing from the current idea of a soft limit except to make it
 consensus enforced. Obviously it's not identical, but I think you can
 see the similarities.

 Does that make sense?
 ___
 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] Splitting BIPs

[Eric Lombrozo via bitcoin-dev]

I posted a new draft of the proposal:
http://blockhawk.net/bitcoin-dev/bipwiki.html

The subsections still need to be fleshed out a bit more. I'd love any
comments or suggestions.

On Mon, Aug 24, 2015, 4:30 PM Eric Lombrozo elombr...@gmail.com wrote:

 Also, the current type attribute needs modification. There are different
 degrees of standard. Just because a lot of people do X doesn't need to
 mean that doing X is officially endorsed by any other devs. At most
 levels below 1, disagreements might be entirely tolerable for many things.

 On Mon, Aug 24, 2015, 2:06 PM Eric Lombrozo elombr...@gmail.com wrote:


 Seems like a lot of effort and goodwill is being wasted on contention
 over things we don't really need to agree upon. In order to help us better
 prioritize, I propose adding an extra attribute to BIPs indicating their
 level which is split into five as follows:

 1. Consensus (hard/soft fork)
 2. Peer Services
 3. RPC
 4. Implementations
 5. Applications

 I posted an example of what such a table might look like here: http://
 blockhawk.net/bitcoin-dev/bipwiki.html

 If other folks also think this is a good idea I'll start working on a BIP
 draft for this.


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

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

[Eric Lombrozo via bitcoin-dev]

It would be very useful to not only be able to switch filtering on and off
globally...but to be able to switch on a per-connection basis. But then
again, perhaps it would be smarter to ditch the whole bloom filter thing in
favor of an actual client/server architecture with proper authentication
and access controls.

The RPC was supposed to be this client/server architecture...but in
practice it sucks so bad for doing anything beyond administering a node
instance you fully control yourself that I eschewed it entirely in my
wallet design.

On Mon, Aug 24, 2015, 11:07 AM Matt Corallo via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 BIP 111 was assigned, pull request (with the proposed changes) available
 at https://github.com/bitcoin/bips/pull/183

 Matt

 On 08/24/15 18:00, Peter Todd wrote:
  On Mon, Aug 24, 2015 at 05:37:51PM +, Matt Corallo via bitcoin-dev
 wrote:
  Its more of a statement of in the future, we expect things to happen
  which would make this an interesting thing to do, so we state here that
  it is not against spec to do so. Could reword it as NODE_BLOOM is
  distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM but
  not NODE_NETWORK (though there is little reason to do so now, some
  proposals may make this more useful in the future)?
 
  ACK
 
 ___
 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] Revisiting NODE_BLOOM: Proposed BIP

[Eric Lombrozo via bitcoin-dev]

Indeed, so I don't really have a problem with this proposal.

On Mon, Aug 24, 2015, 11:30 AM Wladimir J. van der Laan laa...@gmail.com
wrote:

 On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev
 wrote:
  It would be very useful to not only be able to switch filtering on and
 off
  globally...but to be able to switch on a per-connection basis. But then

 You don't necessarily need to send everyone the same nServices bits.
 E.g. you could give whitelisted peers special privileges.

 But only advertize the intersection of your supported services (eg those
 you offer to the general public) in `addr` messages.

 Wladimir

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

Re: [bitcoin-dev] Splitting BIPs

[Eric Lombrozo via bitcoin-dev]

Also, the current type attribute needs modification. There are different
degrees of standard. Just because a lot of people do X doesn't need to
mean that doing X is officially endorsed by any other devs. At most
levels below 1, disagreements might be entirely tolerable for many things.

On Mon, Aug 24, 2015, 2:06 PM Eric Lombrozo elombr...@gmail.com wrote:


 Seems like a lot of effort and goodwill is being wasted on contention over
 things we don't really need to agree upon. In order to help us better
 prioritize, I propose adding an extra attribute to BIPs indicating their
 level which is split into five as follows:

 1. Consensus (hard/soft fork)
 2. Peer Services
 3. RPC
 4. Implementations
 5. Applications

 I posted an example of what such a table might look like here: http://
 blockhawk.net/bitcoin-dev/bipwiki.html

 If other folks also think this is a good idea I'll start working on a BIP
 draft for this.

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

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Eric Lombrozo via bitcoin-dev]

I've been pushing for greater modularization since I first got into
bitcoin. I got quickly frustrated when I was only able to get through very
few things (i.e. moving core structure serialization classes to a separate
unit not called main). Working on Bitcoin has an added layer of frustration
that goes beyond most open source projects: even though we're clearly in
userland working at the application layer, a good layered protocol design
is still lacking. We have no standards process separate from what basically
amount to updates to one specific reference implementation. And we all need
to agree on any major change, since a blockchain that is easily forked in
contentious ways pretty much defeats its own purpose.

I went off to develop my own stack, where I could more easily avoid
politics and focus on engineering. But I now understand the politics are
inevitable. Bitcoin is inherently a cooperative project. Several people
have poured themselves passionately into the reference codebase, most of
whom did it (at least initially) purely as unpaid volunteers. There's a lot
of love that's gone into this. But it's become pretty clear that the
modularization is no longer merely a matter of good engineering - it is
essential to resolving serious political challenges.

Perhaps the most frustrating thing of all is watching people pushing for
relatively superficial yet highly controversial changes while we still lack
the proper infrastructure to handle these kinds of divergences of opinion
without either stagnating or becoming polarized.

I could continue working to reimplement an entire stack from scratch, as
several others have also done - but besides the serious effort duplication
this entails, it doesn't really seem like it will ultimately be a
convergent process. It's too easy to let ego and habit dictate one's
preferences rather than rational engineering considerations.

I know that some might feel I'm just preaching to the choir, but we should
probably take a step back from implementation hackery and try to specify
some core protocol layers, focusing on interfaces. Specifically, we need a
consensus layer that doesn't try to specify networking, storage, wallets,
UI, etc. Let different people improve upon these things independently in
their own implementations. What matters is that we all converge on a common
history and state. At the same time, let's open up more competition on all
these other things that are separate from the consensus layer.

If only we were to dedicate a fraction of the effort we've put into this
whole block size circus into what's actually important...and I blame myself
as well...

On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 On Aug 21, 2015, at 21:46, Jorge Timón jti...@jtimon.cc wrote:

 On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com
 wrote:

 Every re-implementation, re-factoring even copy-paste introduces a risk of
 disagreement,
 but also open the chance of doing the work better, in the sense of
 software engineering.


 But you don't want something better, you want something functionally
 identical.
 You may want to watch sipa's explanation on why the implementation is
 the specification and the reasons to separate libconsensus:
 https://youtu.be/l3O4nh79CUU?t=764


 I do want something better, but not for the focus you have.

 Not because what you produce was not high quality, but because quality is
 achieved at a very
 high cost and is hard to uphold over generations of developer. You focus
 on a single use case
 while there are many out there for distributed ledgers.

 I think in an infrastructure for enterprise applications, building
 consensus on the ledger is a
 cornerstone there, but is only a piece of the solution. I built several
 commercially successful
 deployments where I delegated the consensus building to a border router, a
 Bitcoin Core,
 then interfaced that trusted peer with my  implementation that accepted
 Core’s decisions
 in an SPV manner. One might think of this setup as wasteful and unsuitable
 for “small devices”
 therefore an example of centralization people here try to avoid.

 Enterprises have sufficient resources. Solving the business problem is
 valuable to them even at
 magnitudes higher cost than a hobbyist would bear.

 For mainstream adoption you need to get enterprises on board too, and
  that is what I care of.
 Enterprises want code that is not only high quality, but is easy to
 maintain with a development
 team with high attrition. One has to take whatever help is offered for
 that, and one is modern
 languages and runtimes.

 Bits of Proof’s own implementation of the scripts was not practically
 relevant in my commercially
 successful deployments, because of the use of a border router, but it
 helped development,
 enabling easier debug and precise error feedback esp. end even after Core
 had a reject message.

 I integrated libconsensus only for the hope that is 

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Eric Lombrozo via bitcoin-dev]

One thing it occurs to me (and I don't know if this has been suggested
before) we could do is separate the BIP process into at several distinct
areas:

1) Commit structure changes/consensus rule change proposals
- Consensus-building process (how are proposals debated, improved, vetted,
and selected)
- Update/deployment mechanisms for rule changes
- Specific hard fork proposals
- Specific soft fork proposals

2) Peer policies
- Seeding and discovery mechanisms
- Relay policies
- p2p message support

3) RPC

4) Everything else

On Sat, Aug 22, 2015, 6:28 PM Eric Lombrozo elombr...@gmail.com wrote:

 I've been pushing for greater modularization since I first got into
 bitcoin. I got quickly frustrated when I was only able to get through very
 few things (i.e. moving core structure serialization classes to a separate
 unit not called main). Working on Bitcoin has an added layer of frustration
 that goes beyond most open source projects: even though we're clearly in
 userland working at the application layer, a good layered protocol design
 is still lacking. We have no standards process separate from what basically
 amount to updates to one specific reference implementation. And we all need
 to agree on any major change, since a blockchain that is easily forked in
 contentious ways pretty much defeats its own purpose.

 I went off to develop my own stack, where I could more easily avoid
 politics and focus on engineering. But I now understand the politics are
 inevitable. Bitcoin is inherently a cooperative project. Several people
 have poured themselves passionately into the reference codebase, most of
 whom did it (at least initially) purely as unpaid volunteers. There's a lot
 of love that's gone into this. But it's become pretty clear that the
 modularization is no longer merely a matter of good engineering - it is
 essential to resolving serious political challenges.

 Perhaps the most frustrating thing of all is watching people pushing for
 relatively superficial yet highly controversial changes while we still lack
 the proper infrastructure to handle these kinds of divergences of opinion
 without either stagnating or becoming polarized.

 I could continue working to reimplement an entire stack from scratch, as
 several others have also done - but besides the serious effort duplication
 this entails, it doesn't really seem like it will ultimately be a
 convergent process. It's too easy to let ego and habit dictate one's
 preferences rather than rational engineering considerations.

 I know that some might feel I'm just preaching to the choir, but we should
 probably take a step back from implementation hackery and try to specify
 some core protocol layers, focusing on interfaces. Specifically, we need a
 consensus layer that doesn't try to specify networking, storage, wallets,
 UI, etc. Let different people improve upon these things independently in
 their own implementations. What matters is that we all converge on a common
 history and state. At the same time, let's open up more competition on all
 these other things that are separate from the consensus layer.

 If only we were to dedicate a fraction of the effort we've put into this
 whole block size circus into what's actually important...and I blame myself
 as well...

 On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:

 On Aug 21, 2015, at 21:46, Jorge Timón jti...@jtimon.cc wrote:

 On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com
 wrote:

 Every re-implementation, re-factoring even copy-paste introduces a risk
 of disagreement,
 but also open the chance of doing the work better, in the sense of
 software engineering.


 But you don't want something better, you want something functionally
 identical.
 You may want to watch sipa's explanation on why the implementation is
 the specification and the reasons to separate libconsensus:
 https://youtu.be/l3O4nh79CUU?t=764


 I do want something better, but not for the focus you have.

 Not because what you produce was not high quality, but because quality is
 achieved at a very
 high cost and is hard to uphold over generations of developer. You focus
 on a single use case
 while there are many out there for distributed ledgers.

 I think in an infrastructure for enterprise applications, building
 consensus on the ledger is a
 cornerstone there, but is only a piece of the solution. I built several
 commercially successful
 deployments where I delegated the consensus building to a border router,
 a Bitcoin Core,
 then interfaced that trusted peer with my  implementation that accepted
 Core’s decisions
 in an SPV manner. One might think of this setup as wasteful and
 unsuitable for “small devices”
 therefore an example of centralization people here try to avoid.

 Enterprises have sufficient resources. Solving the business problem is
 valuable to them even at
 magnitudes higher cost than a hobbyist would bear.

 For mainstream 

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Eric Lombrozo via bitcoin-dev]

Unfortunately we have no way of rigorously proving functional equivalence
other than code review and unit testing. The simpler the consensus code
(and the more we can write it in a style that affords provability of
correctness) the easier it will be in the future to compare implementations.

Prior to swapping out implementations, we should at the least run it
through the gauntlet and perhaps run both implementations side-by-side.

All I/O should be treated abstractly in the API.

In C++ I really like using a nearly bare-bones signal template for most
async message handling, i.e.
https://github.com/ciphrex/mSIGNA/blob/master/deps/Signals/src/Signals.h

This greatly facilitates support for async bidirectional I/O, etc...with
minimal overhead.

But others might have other stylistic preferences.

- Eric

On Fri, Aug 21, 2015, 12:46 PM Jorge Timón 
bitcoin-dev@lists.linuxfoundation.org wrote:

 On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com
 wrote:
  Every re-implementation, re-factoring even copy-paste introduces a risk
 of disagreement,
  but also open the chance of doing the work better, in the sense of
 software engineering.

 But you don't want something better, you want something functionally
 identical.
 You may want to watch sipa's explanation on why the implementation is
 the specification and the reasons to separate libconsensus:
 https://youtu.be/l3O4nh79CUU?t=764

  On Aug 20, 2015, at 10:06, Jorge Timón jti...@jtimon.cc wrote:
 
 
  But the goal is not reimplementing the consensus rules but rather
  extract them from Bitcoin Core so that nobody needs to re-implement
  them again.
 
 
 
  My goal is different. Compatibility with Bitcoin is important as I also
 want to deal with Bitcoins,
  but it is also imperative to be able to create and serve other block
 chains with other rules and for those
  I do not want to carry on the legacy of an antique tool set and a
 spaghetti style.
 
  Bits of Proof uses scala (akka networking), java (api service), c++
 (leveledb and now libconsensus)
  and I am eager to integrate secp256k1 (c) as soon as part of consensus.
 The choices were
  made because each piece appears best in what they do.

 Since you already depend on libconsensus for VerifyScript, wouldn't it
 be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
 You would still have complete control over storage, concurrency,
 networking, policy...
 My plan is for the C API to interface with the external storage by
 passing a function pointer to it.
 ___
 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 XT Fork

[Eric Lombrozo via bitcoin-dev]

 On Aug 19, 2015, at 12:12 PM, Santino Napolitano via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Gavin has been very clear about the fact that he's on vacation. I'm not sure 
 what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks 
 are out for him so there isn't really anything he can possibly say which will 
 be constructively received on this highly adversarial and increasingly 
 ridiculous charade of a mailing list. I feel as though they've made their 
 case abundantly clear to anyone paying attention.

It’s good to know that Gavin still manages to keep his priorities straight. Of 
course, vacationing at the moment that the most controversial change in the 
history of Bitcoin which threatens to split the community is officially 
“announced” is probably exactly what he should be doing.

I’m glad to know that we’ll continue to have this amazing leadership under the 
XT fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Eric Lombrozo via bitcoin-dev]

Alex,

With all due respect, right now the biggest challenge facing Bitcoin is not 
technical but political. I would love to see this list go back to technical 
discussions, but unfortunately, until this political stuff is resolved, even 
technical discussion is purely philosophical as there’s little chance of 
actually making good progress on consensus…which in a space where everything 
depends on consensus pretty much makes everything else moot.

 On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 This is a message that I wrote and had hoped that all the core devs would 
 sign on to, but I failed to finish organizing it.  So I'll just say it from 
 myself.
 
 There has been a valuable discussion over the last several months regarding a 
 hard fork with respect to block size.  However the sheer volume of email and 
 proportion of discussion that is more philosophical than technical has 
 rendered this list almost unusable for its primary purpose of technical 
 discussion related to Bitcoin development.  Many of us share the blame for 
 letting the discourse run off topic to such a degree, and we hope that an 
 appeal for individual self restraint will allow this list to return to a 
 higher signal-to-noise ratio.
 -Please consider the degree to which any email you send is related to 
 technical development before sending it.
 -Please consider how many emails you are sending to this list regarding the 
 same topic.
 This list is not appropriate for an endless back and forth debate on the 
 philosophical underpinnings of Bitcoin.  Although such a debate may be 
 worthwhile it should be taken to another forum for discussion.  Every email 
 you send is received by hundreds of developers who value their time as much 
 as you value yours.  If your intended audience isn't really the majority of 
 them, perhaps private communication would be more appropriate.
 
 Thanks,
 Alex
 
 ___
 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 XT Fork

[Eric Lombrozo via bitcoin-dev]

Unfortunately, I think that from a PR angle, removing Gavin from commit 
privileges right now will probably play into his hand. Sadly.

Say what you will regarding Gavin and Mike’s technical merits, they’ve been 
quite clever on the PR front. Framing this issue as “obstructionism from the 
core devs” and relying on the fact that many people out there can’t seem to 
tell the difference between a source code fork and a blockchain fork.



 On Aug 19, 2015, at 12:32 PM, odinn via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Signed PGP part
 re. Gavin and commit access
 
 On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
  On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd p...@petertodd.org
  wrote:
  Normal GitHub users submitting pull-reqs to Bitcoin Core can't
  delete other users' comments on their own pull-reqs...
 
  IMO that's an abuse of the pull-req process, and in turn, Gavin
  Andresens's commit access rights for the Bitcoin Core repo.
 
  For the avoidance of doubt here's the archive link of my comment
  https://archive.is/omvSY#40% (call me paranoid) and here's where he
  tells me he's censored my posts https://archive.is/vym6N#40%
 
  I think this should weigh in favor of Gavin Andresen not having
  commit privileges for the Bitcoin Core repository.
 
  It's time.
 
 I agree, fwiw.  If he's going to censor others then that's
 inconsistent with the responsibility of having commit access.
 
  ___ bitcoin-dev mailing
  list bitcoin-dev@lists.linuxfoundation.org
  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 
 
 --
 http://abis.io ~
 a protocol concept to enable decentralization
 and expansion of a giving economy, and a new social good
 https://keybase.io/odinn
 
 ___
 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] Annoucing Not-BitcoinXT

[Eric Lombrozo via bitcoin-dev]

NxtChg,

In the entire history of Bitcoin we’ve never attempted anything even closely 
resembling a hard fork like what’s being proposed here.

Many of us have wanted to push our own hard-forking changes to the protocol…and 
have been frustrated because of the inability to do so.

This inability is not due to any malice on anyone’s part…it is a feature of 
Satoshi’s protocol. For better or worse, it is *very hard* to change the 
rules…and this is exactly what imbues Bitcoin with one of its most powerful 
attributes: very well-defined settlement guarantees that cannot be suddenly 
altered nor reversed by anyone.

We’ve managed to have a few soft forks in the past…and for the most part these 
changes have been pretty uncontroversial…or at least, they have not had nearly 
the level of political divisiveness that this block size issue is having. And 
even then, we’ve encountered a number of problems with these deployments that 
have at times required goodwill cooperation between developers and mining pool 
operators to fix.

Again, we have NEVER attempted anything even remotely like what’s being 
proposed - we’ve never done any sort of hard fork before like this. If even 
fairly uncontroversial soft forks have caused problems, can you imagine the 
kinds of potential problems that a hard fork over some highly polarizing issue 
might raise? Do you really think people are going to want to cooperate?!?

I can understand that some people would like bigger blocks. Other people might 
want feature X, others feature Y…and we can argue the merits of this or that to 
death…but the fact remains that we have NEVER attempted any hard forking 
change…not even with a simple, totally uncontroversial no-brainer improvement 
that would not risk any sort of ill-will that could hamper remedies were it not 
to go as smoothly as we like. *THIS* is the fundamental problem - the whole 
bigger block thing is a minor issue by comparison…it could be any controversial 
change, really.

Would you want to send your test pilots on their first flight…the first time an 
aircraft is ever flown…directly into combat without having tested the plane? 
This is what attempting a hard fork mechanism that’s NEVER been done before in 
such a politically divisive environment basically amounts to…but it’s even 
worse. We’re basically risking the entire air force (not just one plane) over 
an argument regarding how many seats a plane should have that we’ve never flown 
before.

We’re talking billlions of dollars’ worth of other people’s money that is on 
the line here. Don’t we owe it to them to at least test out the system on a far 
less controversial, far less divisive change first to make sure we can even 
deploy it without things breaking? I don’t even care about the merits regarding 
bigger blocks vs. smaller blocks at this point, to be quite honest - that’s 
such a petty thing compared to what I’m talking about here. If we attempt a 
novel hard-forking mechanism that’s NEVER been attempted before (and which as 
many have pointed out is potentially fraught with serious problems) on such a 
politically divisive, polarizing issue, the result is each side will refuse to 
cooperate with the other out of spite…and can easily lead to a war, tanking the 
value of everyone’s assets on both chains. All so we can process 8 times the 
number of transactions we currently do? Even if it were 100 times, we wouldn’t 
even come close to touching big payment processors like Visa. It’s hard to 
imagine a protocol improvement that’s worth the risk.

I urge you to at least try to see the bigger picture here…and to understand 
that nobody is trying to stop anyone from doing anything out of some desire for 
maintaining control - NONE of us are able to deploy hard forks right now 
without facing these problems. And different people obviously have different 
priorities and preferences as to which of these changes would be best to do 
first. This whole XT thing is essentially giving *one* proposal special 
treatment above those that others have proposed. Many of us have only held back 
from doing this out of our belief that goodwill amongst network participants is 
more important than trying to push some pet feature some of us want.

Please stop this negativity - we ALL want the best for Bitcoin and are doing 
our best, given what we understand and know, to do what’s right.



 On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 
 We should have the highest respect for what these people are doing, and we 
 should try to do something constructive, not waste time with anger and 
 disrespect.
 
 Why, exactly, should I have any respect for what these people are doing (and 
 supposedly not have any respect for what the other side is doing)?
 
 From my point of view, the XT side _does_ something constructive. It's the 
 Core side that resorts to dirty tactics and tries to sabotage community's 
 free choice instead.
 
 
 Nobody 

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Eric Lombrozo via bitcoin-dev]

Or can’t you create a transaction that’s still within the op count and sig ops 
limits but is larger than 1MB?

 On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Wouldn't that require a fork that lasts for more than 100 blocks?
 
 On Mon, Aug 17, 2015, 01:43 Peter Todd p...@petertodd.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 
 
 On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 There are a few ways: here is my favorite (for the moment).
 
 1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
 'BitcoinXT'
 
 Even more direct: use coinbase outputs of  XT blocks to create those
 outputs, as they can't by definition be on the Bitcoin chain.
 
 If you can't get those, using coinbase outputs of Bitcoin blocks to create
 definitely Bitcoin-only outputs, and then spend the inputs to those
 transactions again on the XT chain. This isn't quite as good, as a big
 reorg on the XT chain could in theory spend them, but it's a close second.
 -BEGIN PGP SIGNATURE-
 
 iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS
 AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq
 qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03
 cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq
 2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT
 EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z
 kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90=
 =OD56
 -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] Annoucing Not-BitcoinXT

[Eric Lombrozo via bitcoin-dev]

I should add that in the interest of peace and goodwill, I extend an offer to 
both Mike and Gavin to make their grievances heard…but only on the condition 
that we make a good effort to avoid misrepresentation and misreading of the 
other side’s intentions.

 On Aug 17, 2015, at 9:37 AM, Eric Lombrozo elombr...@gmail.com wrote:
 
 
 On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Great, so how about you go tell theymos to stop censoring XT posts and 
 banning the other side on /r/Bitcoin?
 
 Let users decide what Bitcoin is or isn't.
 
 FWIW,
 
 I don’t think what theymos did is very constructive.I understand his 
 position…but it only hurts the cause, unfortunately - the PR battle is not 
 the same thing as a discussion on technical merits. He hurts the PR battle 
 and plays into Mike’s hand by doing that. The actual underlying issue 
 actually has little to do with block size - it has to do with Mike and Gavin 
 feeling that the core devs are being obstructionist.
 
 Regardless of the technical merits of XT, the fact that we’ve never done a 
 hard fork before, not even for things some other devs have wanted…and not due 
 to any malice on anyone’s part but because simply that’s just the nature of 
 decentralized consensus with well-defined settlement guarantees…this is the 
 problem - Mike and Gavin think they’re somehow special and their fork should 
 be pushed while the rest of us resist pushing our own controversial pet ideas 
 because we want civility and understand that at this stage in Bitcoin’s 
 development trying to fork the blockchain over highly divisive issues is 
 counterproductive and destructive.
 
 But the fact of the matter is that in the PR battle, arguments against the 
 fork actually play into Mike’s hand, and that’s the problem.
 
 The whole block size thing is too nuanced and too easily spun simplistically. 
 It’s too easy to spin resistance to bigger blocks (even though the resistance 
 is actually much more towards untested hardforking mechanisms and serious 
 security concerns) as “obstructionism” and it’s too easy to spin bigger 
 blocks as “scalability” because most of the people can’t tell the fucking 
 difference.
 
 The fact is most of the people don’t really understand the fundamental issue 
 and are taking sides based on charismatic leadership and authority which is 
 actually entirely counter to the spirit of decentralized consensus. It’s 
 beyond ironic.
 
 If you guys want to win the PR battle, the key is to make it clear that you 
 are not obstructionist and are giving everyone equal treatment…Bitcoin was 
 designed such that changing the rules is *hard* and this is a feature. 
 Bitcoin simply does not have a reliable and tested hard forking mechanism…and 
 a hard fork for such a politically divisive issue will almost certainly lead 
 to a lack of cooperation and refusal to work together out of spite. All of us 
 would like to be able to process more transactions on the network. It’s not a 
 matter of whether we think higher capacity is a bad thing - it’s more that 
 some of us are concerned that Bitcoin is not sufficiently mature to be able 
 to handle such a schism with so much hostility.
 
 Let’s face it, folks - from a PR standpoint, the block size issue is 
 irrelevant. Nobody really understands it except for a handful of people - 
 I’ve tried to explain it, I’ve even written articles about it - but most 
 people just don’t get it. Most people don’t really get scalability either - 
 they seem to think that scalability is just doing the same thing you’ve 
 always done manyfold.
 
 Block size is an especially dangerous issue politically because it’s one of 
 those that requires deep understanding yet superficially sounds really 
 simple. It’s perfect Dunning-Kruger bait.
 
 So let’s be a little smarter about this.



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] Annoucing Not-BitcoinXT

[Eric Lombrozo via bitcoin-dev]

 On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Great, so how about you go tell theymos to stop censoring XT posts and 
 banning the other side on /r/Bitcoin?
 
 Let users decide what Bitcoin is or isn't.

FWIW,

I don’t think what theymos did is very constructive.I understand his 
position…but it only hurts the cause, unfortunately - the PR battle is not the 
same thing as a discussion on technical merits. He hurts the PR battle and 
plays into Mike’s hand by doing that. The actual underlying issue actually has 
little to do with block size - it has to do with Mike and Gavin feeling that 
the core devs are being obstructionist.

Regardless of the technical merits of XT, the fact that we’ve never done a hard 
fork before, not even for things some other devs have wanted…and not due to any 
malice on anyone’s part but because simply that’s just the nature of 
decentralized consensus with well-defined settlement guarantees…this is the 
problem - Mike and Gavin think they’re somehow special and their fork should be 
pushed while the rest of us resist pushing our own controversial pet ideas 
because we want civility and understand that at this stage in Bitcoin’s 
development trying to fork the blockchain over highly divisive issues is 
counterproductive and destructive.

But the fact of the matter is that in the PR battle, arguments against the fork 
actually play into Mike’s hand, and that’s the problem.

The whole block size thing is too nuanced and too easily spun simplistically. 
It’s too easy to spin resistance to bigger blocks (even though the resistance 
is actually much more towards untested hardforking mechanisms and serious 
security concerns) as “obstructionism” and it’s too easy to spin bigger blocks 
as “scalability” because most of the people can’t tell the fucking difference.

The fact is most of the people don’t really understand the fundamental issue 
and are taking sides based on charismatic leadership and authority which is 
actually entirely counter to the spirit of decentralized consensus. It’s beyond 
ironic.

If you guys want to win the PR battle, the key is to make it clear that you are 
not obstructionist and are giving everyone equal treatment…Bitcoin was designed 
such that changing the rules is *hard* and this is a feature. Bitcoin simply 
does not have a reliable and tested hard forking mechanism…and a hard fork for 
such a politically divisive issue will almost certainly lead to a lack of 
cooperation and refusal to work together out of spite. All of us would like to 
be able to process more transactions on the network. It’s not a matter of 
whether we think higher capacity is a bad thing - it’s more that some of us are 
concerned that Bitcoin is not sufficiently mature to be able to handle such a 
schism with so much hostility.

Let’s face it, folks - from a PR standpoint, the block size issue is 
irrelevant. Nobody really understands it except for a handful of people - I’ve 
tried to explain it, I’ve even written articles about it - but most people just 
don’t get it. Most people don’t really get scalability either - they seem to 
think that scalability is just doing the same thing you’ve always done manyfold.

Block size is an especially dangerous issue politically because it’s one of 
those that requires deep understanding yet superficially sounds really simple. 
It’s perfect Dunning-Kruger bait.

So let’s be a little smarter about this.


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] Annoucing Not-BitcoinXT

[Eric Lombrozo via bitcoin-dev]

 On Aug 17, 2015, at 8:03 AM, Levin Keller p...@levinkeller.de wrote:
 
 Dear Eric,
 
 thank you for sharing your thoughts.
 
 It obviously boils down to political beliefs, not so much technical 
 arguments. I understand that you are in favor of a guided decentralization 
 and you are most happily invited to follow this path. I don't want to be on 
 it. I want total decentralisation of bitcoin and many other parts of the 
 current system.

I specifically asked you to stop misrepresenting - I’m NOT in favor of guided 
decentralization, I never said anything like that. *THIS* is the problem…you’re 
reading intentions into others that simply are NOT there. If you don’t really 
understand something, ask.

I want complete decentralization - but for practical reasons, which should be 
obvious, we cannot start at this point. Bitcoin came into existence because 
Satoshi wrote a whitepaper and implemented the idea - and it was his rules. 
There was no voting, no committee, no proof-of-work, no nothing…it was a 
complete dictatorship in the beginning.

 
 So in the end the hard fork might be perfect, because people like you will 
 not waste so much more energy and time fighting people like me (and others) 
 who are following different dogmata because we are using different coins and 
 talking about different code. Interestingly enough in the end we will 
 probably have a winner - determined by the price - so I am looking forward to 
 the outcome. It is just the time so make some bets, which I embrace.
 
 Another interesting thing is, that you actually fear problems arising from 
 this. What do you have to loose? Just stick with the old bitcoin version and 
 weather this storm. Bitcoin is not going to vanish or break from this. It is 
 just forking. One fork will come stronger out of this. You just have to 
 choose a side and live with it, if you loose it all. But that is the story of 
 bitcoin since the beginning. If you ask me, you fear the choice, not the 
 change.
 

Again, misrepresentation - “you fear the choice, not the change” - why should 
anyone ask *you* what I fear? Why don’t you ask *me*?


 Cheers
 
 Levin
 
 Adam Back via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org schrieb am Mo., 17. Aug. 2015 
 um 16:37 Uhr:
 Thank you Eric for saying what needs to be said.
 
 Starting a fork war is just not constructive and there are multiple
 proposals being evaluated here.
 
 I think that one thing that is not being so much focussed on is
 Bitcoin-XT is both a hard-fork and a soft-fork.  It's a hard-fork on
 Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
 SPV nodes that did not opt-in.  It exposes those SPV nodes to loss in
 the likely event that Bitcoin-XT results in a network-split.
 
 The recent proposal here to run noXT (patch to falsely claim to mine
 on XT while actually rejecting it's blocks) could add enough
 uncertainty about the activation that Bitcoin-XT would probably have
 to be aborted.
 
 Adam
 
 On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
  NxtChg,
 
  In the entire history of Bitcoin we’ve never attempted anything even 
  closely resembling a hard fork like what’s being proposed here.
 
  Many of us have wanted to push our own hard-forking changes to the 
  protocol…and have been frustrated because of the inability to do so.
 
  This inability is not due to any malice on anyone’s part…it is a feature of 
  Satoshi’s protocol. For better or worse, it is *very hard* to change the 
  rules…and this is exactly what imbues Bitcoin with one of its most powerful 
  attributes: very well-defined settlement guarantees that cannot be suddenly 
  altered nor reversed by anyone.
 
  We’ve managed to have a few soft forks in the past…and for the most part 
  these changes have been pretty uncontroversial…or at least, they have not 
  had nearly the level of political divisiveness that this block size issue 
  is having. And even then, we’ve encountered a number of problems with these 
  deployments that have at times required goodwill cooperation between 
  developers and mining pool operators to fix.
 
  Again, we have NEVER attempted anything even remotely like what’s being 
  proposed - we’ve never done any sort of hard fork before like this. If even 
  fairly uncontroversial soft forks have caused problems, can you imagine the 
  kinds of potential problems that a hard fork over some highly polarizing 
  issue might raise? Do you really think people are going to want to 
  cooperate?!?
 
  I can understand that some people would like bigger blocks. Other people 
  might want feature X, others feature Y…and we can argue the merits of this 
  or that to death…but the fact remains that we have NEVER attempted any hard 
  forking change…not even with a simple, totally uncontroversial no-brainer 
  improvement that would not risk

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Eric Lombrozo via bitcoin-dev]

You deeply disappoint me, Mike.

Not only do you misrepresent many cogent, well thought out positions from a 
great number of people who have published and posted a number of articles 
detailing an explaining in-depth technical concerns…you also seem to fancy 
yourself more capable of reading into the intentions of someone who disappeared 
from the scene years ago, before we even were fully aware of many things we now 
know that bring the original “plan” into question.

I ask of you, as a civilized human being, to stop doing this divisive crap. 
Despite your protestations to the contrary, YOU are the one who is proposing a 
radical departure from the direction of the project. Also, as several of us 
have clearly stated before, equating the fork of an open source project with a 
fork of a cryptoledger is completely bogus - there’s a lot of other people’s 
money at stake. This isn’t a democracy - consensus is all or nothing. The fact 
that a good number of the people most intimately familiar with the inner 
workings of Satoshi’s invention do not believe doing this is a good idea should 
give you pause.

Please stop using Bitcoin as your own political football…for the sake of 
Bitcoin…and for your own sake. Despite your obvious technical abilities (and I 
sincerely do believe you have them) you are discrediting yourself and hurting 
your own reputation.


- Eric

 On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Hello,
 
 As promised, we have released Bitcoin XT 0.11A which includes the bigger 
 blocks patch set. You can get it from
 
  https://bitcoinxt.software/ https://bitcoinxt.software/
 
 I feel sad that it's come to this, but there is no other way. The Bitcoin 
 Core project has drifted so far from the principles myself and many others 
 feel are important, that a fork is the only way to fix things.
 
 Forking is a natural thing in the open source community, Bitcoin is not the 
 first and won't be the last project to go through this. Often in forks, 
 people say there was insufficient communication. So to ensure everything is 
 crystal clear I've written a blog post and a kind of manifesto to describe 
 why this is happening and how XT plans to be different from Core (assuming 
 adoption, of course).
 
 The article is here:
 
 https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 
 https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
 
 It makes no attempt to be neutral: this explains things from our point of 
 view.
 
 The manifesto is on the website.
 
 I say to all developers on this list: if you also feel that Core is no longer 
 serving the interests of Bitcoin users, come join us. We don't bite.
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org 
 mailto: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] Eli Dourado on governance

[Eric Lombrozo via bitcoin-dev]

Rather than speculating on fake markets, why don’t we use theory, empirical 
data, and engineering to fix the damn problems?

 On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 Given there is no money at stake in these prediction games, it is no surprise 
 that the results are implausible.
 
 On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 And the preliminary results of using a prediction market to try to wrestle 
 with the tough tradeoffs looks roughly correct to me, too:
https://blocksizedebate.com/ https://blocksizedebate.com/
 
 ​The scicast prediction market is shutdown atm (since early July?) so those 
 numbers aren't live. But...
 
 Network hash rate
  3,255.17 PH/s  (same block size)
  5,032.64 PH/s  (block size increase)
 
  4,969.68 PH/s  (no replace-by-fee)
  3,132.09 PH/s  (replace-by-fee)
 
 Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the 
 current hashrate ( 400PH/s) in 17 months, when it's taken 12 months for the 
 last doubling, and there's a block reward reduction due in that period too. 
 (That might've been a reasonable prediction sometime in the past year, when 
 doublings were slowing from once every ~45 days to once a year; it just 
 doesn't seem a supportable prediction now)
 
 That the PH/s rate is higher with bigger blocks is surprising, but given that 
 site also predicts USD/BTC will be $280 with no change but $555 with bigger 
 blocks, so I assume that difference is mostly due to price. Also, 12.5btc at 
 $555 each is about 23 btc at $300 each, so if that price increase is 
 realistic, it would compensate for almost all of the block reward reduction.
 
 Daily transaction volume
  168,438.22 tx/day  (same block size)
  193,773.08 tx/day  (block size increase)
 
  192,603.80 tx/day  (no replace-by-fee)
  168,406.73 tx/day  (replace-by-fee)
 
 That's only a 15% increase in transaction volume due to the block size 
 increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% 
 increase in transaction volume from 130k tx/day currently. If that's really 
 the case, then a 1.5MB-2MB max block size would probably be enough for the 
 next two years...
 
 (Predicting that the node count will drop from ~5000 to ~1200 due to 
 increasing block sizes seems quite an indictment as far as centralisation 
 risks go; but given I'm not that convinced by the other predictions, I'm not 
 sure I want to give that much weight to that one either)
 
 Cheers,
 aj
 
 --
 Anthony Towns a...@erisian.com.au mailto:a...@erisian.com.au
 
 
 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



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] A reason we can all agree on to increase block size

[Eric Lombrozo via bitcoin-dev]

 On Aug 3, 2015, at 1:52 AM, Hector Chu hector...@gmail.com wrote:
 
 On 3 August 2015 at 09:38, Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com wrote:
 We already have much more efficient, far more scalable systems that allow 
 this kind of cooperation you speak of without the inconveniences of 
 blockchains and such.
 
 There is a degree of difference between cooperation in day-to-day usage of 
 the system and cooperation in the rare cases the system has a bug.
 

If it’s an as-of-yet unidentified issue that comes up, yes…obviously we can’t 
plan for everything and we’ll make some mistakes. But here we’re talking about 
specific well-known issues (or at least well-known today) for which several 
people have proposed potential solutions. However, these things have been all 
but ignored in the public discourse.

 These incidents do, fortunately, present some of the better sides of 
 humanity…but…the design of the network *broke* - and for reasons that are now 
 well understood to be only worsened by larger blocks. These incidents are 
 *not supposed to happen* - and if they do, it means we’ve botched something 
 up and need to fix it. And by fix it, I mean fix the protocol so that given 
 our best understanding of things in the present we can significantly reduce 
 the potential for its occurrence in the future.
 
 Distribution by consensus is inherently a fragile system. The network will 
 continue to break again and again as long as programmers are fallible. But 
 the types of bugs that occur will change over time as we learn the best 
 practices for maintaining the system.

I agree. But again, once we’ve identified specific issues, it is irresponsible 
to continue to pretend they don’t exist…and to more highly prioritize changes 
that can only make the problem worse.

Again, for the record, I am not against ultimately allowing bigger blocks. I 
think it would be a good thing to be able to do this…and my main concerns are 
not around things like equipment costs or typical household bandwidth. I just 
think security is a more important feature than greater throughput and 
prioritize it thusly.


 The correct incentives here were not due to people potentially losing a lot 
 of money. The incentives here were well-intentioned altruism. Some miners 
 lost money as a result of these actions…and they didn’t put up a fight. if 
 you want to design a system around the assumption that this is how all such 
 incidents will be resolved, please don’t spoil this for the rest of us.
 
 Altruism is a facade that hides other motivations. The party cooperating with 
 the miners losing money were doing so to maintain good relationships with 
 those miners and to make sure those miners stay within the system and not 
 attack it.

I don’t disagree…clearly even the miners that lost money believed that 
consensus was more valuable to them than a few bitcoins. However, it seems to 
be EXTREMELY dangerous to assume that it will always work out this way. What’s 
to stop a mining majority from deciding on-the-fly they want to keep a 
particular consensus rule that benefits them even if the core developers 
disagree?

 
 - Eric
 
 On Aug 3, 2015, at 1:31 AM, Hector Chu hector...@gmail.com 
 mailto:hector...@gmail.com wrote:
 
 What's wrong with a little cooperation to resolve things now and then? Man 
 is not an island unto himself, we compete with each other and we cooperate 
 with each other occasionally if it's mutually beneficial.
 
 You said yourself that a lot of money would have been lost if the two hard 
 forks cited weren't resolved - that's the correct incentives at work again.
 
 On 3 August 2015 at 09:20, Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com wrote:
 There have already been two notable incidents requiring manual intervention 
 and good-faith cooperation between core devs and mining pool operators that 
 would have either never gotten resolved alone or would have ended up costing 
 a lot of people a lot of money had no action been taken (March 2013 and July 
 2015). They were both caused by consensus disagreement that directly or 
 indirectly were brought about by bigger blocks. There is *strong* 
 evidence…and a great deal of theory explaining it…that links larger blocks 
 with the propensity for consensus forks that require manual intervention.
 
 Please, can we stop saying this is merely about decentralization and 
 trustlessness? The very model upon which the security of the system is based 
 *broke*…as in, we were only able to recover because a few individuals 
 deliberately manipulated the consensus rules to fix it manually. Shouldn’t 
 we more highly prioritize fixing the issues that can lead to these incidents 
 than trying to increase throughput? Increasing block size cannot possibly 
 make these forking tendencies better…but it very well could make them worse.
 
 - Eric
 
 On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 

Re: [bitcoin-dev] A reason we can all agree on to increase block size

[Eric Lombrozo via bitcoin-dev]

Bah, I don’t know if you’re just trolling me, Hector…but I’ll give you the 
benefit of the doubt and act like you aren’t.

We already have much more efficient, far more scalable systems that allow this 
kind of cooperation you speak of without the inconveniences of blockchains and 
such. These incidents do, fortunately, present some of the better sides of 
humanity…but…the design of the network *broke* - and for reasons that are now 
well understood to be only worsened by larger blocks. These incidents are *not 
supposed to happen* - and if they do, it means we’ve botched something up and 
need to fix it. And by fix it, I mean fix the protocol so that given our best 
understanding of things in the present we can significantly reduce the 
potential for its occurrence in the future.

The correct incentives here were not due to people potentially losing a lot of 
money. The incentives here were well-intentioned altruism. Some miners lost 
money as a result of these actions…and they didn’t put up a fight. if you want 
to design a system around the assumption that this is how all such incidents 
will be resolved, please don’t spoil this for the rest of us.

- Eric

 On Aug 3, 2015, at 1:31 AM, Hector Chu hector...@gmail.com wrote:
 
 What's wrong with a little cooperation to resolve things now and then? Man is 
 not an island unto himself, we compete with each other and we cooperate with 
 each other occasionally if it's mutually beneficial.
 
 You said yourself that a lot of money would have been lost if the two hard 
 forks cited weren't resolved - that's the correct incentives at work again.
 
 On 3 August 2015 at 09:20, Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com wrote:
 There have already been two notable incidents requiring manual intervention 
 and good-faith cooperation between core devs and mining pool operators that 
 would have either never gotten resolved alone or would have ended up costing 
 a lot of people a lot of money had no action been taken (March 2013 and July 
 2015). They were both caused by consensus disagreement that directly or 
 indirectly were brought about by bigger blocks. There is *strong* 
 evidence…and a great deal of theory explaining it…that links larger blocks 
 with the propensity for consensus forks that require manual intervention.
 
 Please, can we stop saying this is merely about decentralization and 
 trustlessness? The very model upon which the security of the system is based 
 *broke*…as in, we were only able to recover because a few individuals 
 deliberately manipulated the consensus rules to fix it manually. Shouldn’t we 
 more highly prioritize fixing the issues that can lead to these incidents 
 than trying to increase throughput? Increasing block size cannot possibly 
 make these forking tendencies better…but it very well could make them worse.
 
 - Eric
 
 On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 
 On 3 August 2015 at 08:53, Adam Back a...@cypherspace.org 
 mailto:a...@cypherspace.org wrote:
 Again this should not be a political or business compromise model - we
 must focus on scientific evaluation, technical requirements and
 security.
 
 I will assert that the block size is political because it affects nearly all 
 users to some degree and not all those users are technically inclined or 
 care to keep decentralisation in the current configuration as you do. This 
 debate has forgotten the current and future users of Bitcoin. Most of them 
 think the hit to node count in the short term preferable to making it 
 expensive and competitive to transact.
 
 We all need a little faith that the system will reorganise and readjust 
 after the move to big blocks in a way that still has a reasonable degree of 
 decentralisation and trustlessness. The incentives of Bitcoin remain, so 
 everyone's decentralised decision throughout the system, from miners, 
 merchants and users, will continue to act according to those incentives.
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
 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] Incentivising full nodes by having SPV nodes to pay for data requests

[Eric Lombrozo via bitcoin-dev]

The point is that without concrete direct incentives, many might find it
rational to just leech off others...which might actually work for a
while...but this is obviously not stable equilibrium...and it's very hard
to do any game theory on it.

Current SPV implementations necessarily diverge from the p2p model and
strongly tend toward a client/server architecture. It was originally
thought that mining would provide an incentive to run servers...but we all
know that's not at all how things have turned out.

Using offchain protocols with blockchain settlement guarantees, it is
possible for clients to request proofs directly from servers without
requiring any additional authentication layers...and can perhaps even be
onion-routed to hide the client's identity.

Checking SPV proofs is cheap...it only requires downloading headers,
checking PoW, and constructing a lookup table mapping block hashes to
merkle roots. This structure can easily be stored entirely in RAM on
typical consumer devices (it's at most 80 bytes per block, or a little over
30MB right now and grows at a very manageable rate). The most expensive
step to prove inclusion of a specific transaction in the blockchain is then
O(log n) sha256 operations, where n is the number of transactions in the
block.

Using p2sh, we ensure the txout script is a mere 22 bytes. Full validation
nodes can fully prune the partial merkle tree structure when the output is
spent. SPV proof serving nodes would still need to store full blocks...but
as long as they are getting paid for this market forces could lead to a
stable balance between clients and servers...or at least adaptive dynamics
that prevent deficits or surpluses.

If I screwed something up in this analysis someone please correct me.

- Eric
On Aug 3, 2015 10:29 AM, Eric Voskuil via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 The typical interpretation of the tragedy of the commons scenario is
 based on the presumption that a limited resource is controlled by the
 state.

 In a free market there is no such idea, a limited resource becomes
 property and is therefore allocated by customer preference and
 maintained by self-interest.

 Validation is not a resource controlled by the state, which is of course
 the point of Bitcoin.

 It is inaccurate to think of Bitcoin validation a limited resource. The
 scenario in which fewer people validate does not reduce the amount of
 validation available. It increases the risk of loss to those who fail to
 validate. The gain to those who do validate comes from avoiding that loss.

 e


 On 08/03/2015 10:06 AM, Luv Khemani via bitcoin-dev wrote:
  The current block size debate has brought up an important, albeit often
  neglected observation. Full nodes suffer from a tragedy of the commons
  problem and therefore are likely to continue decreasing as a percentage
  of total Bitcoin nodes. This also results in a vicious circle as more
  and more people use SPVs, the burden on existing full nodes will
  increase even without a block size increase, which will further reduce
  the number of full nodes . A few people have mentioned it in blogs or
  reddit, but the topic is generally quickly overshadowed by posts along
  the lines of  RAISE the blocksize already!.
 
  Full nodes bear the full cost of validating/relaying/storing the
  blockchain and servicing SPV clients but gain nothing financially from
  it, yet they serve an important role in validating transactions and
  keeping miner dishonesty in check. If there were few independent full
  nodes, it would be possible for 3-4 of the biggest mining pools to
  collude and do literally whatever they wanted with the protocol,
  including inflating the money supply, freezing funds or even
  confiscating funds, because who would know? And even if someone running
  a full node did voice out, the majority of users on SPV/Coinbase/etc..
  would be powerless to do anything about it and would likely bear with
  the changes to protect status quo, just as is the case with current fiat
  regimes where people bear with QE/Inflation/bail outs because they are
  so dependent on the current system that they would rather tolerate any
  injustice than to have the system go down and bring them with it.
  This is the primary reason why many in the technical community are
  against drastic blocksize increases, as this will only worsen the
  problem of decentralization as this cost increases. And as long as full
  nodes are running on charity, i'm fully in agreement with the
  conservative block size camp.
 
  However, it is important to note that this seems to be an economic
  problem instead of a technical one. I cannot deny the argument from the
  big block side that technically, the hardware/bandwidth required to run
  full nodes supporting considerably larger blocks (4MB-8MB) is not out of
  reach of many individuals around the globe. The core issue in my opinion
  is that of incentive, because at the end of the day, running a 

Re: [bitcoin-dev] Incentivising full nodes by having SPV nodes to pay for data requests

[Eric Lombrozo via bitcoin-dev]

I proposed something along these lines in the lightning-dev mailing list:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/88.html

It's probably a little off-topic there...but I'm very interested in
discussing such ideas.
On Aug 3, 2015 10:06 AM, Luv Khemani via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 The current block size debate has brought up an important, albeit often
 neglected observation. Full nodes suffer from a tragedy of the commons
 problem and therefore are likely to continue decreasing as a percentage of
 total Bitcoin nodes. This also results in a vicious circle as more and more
 people use SPVs, the burden on existing full nodes will increase even
 without a block size increase, which will further reduce the number of full
 nodes . A few people have mentioned it in blogs or reddit, but the topic is
 generally quickly overshadowed by posts along the lines of  RAISE the
 blocksize already!.

 Full nodes bear the full cost of validating/relaying/storing the
 blockchain and servicing SPV clients but gain nothing financially from it,
 yet they serve an important role in validating transactions and keeping
 miner dishonesty in check. If there were few independent full nodes, it
 would be possible for 3-4 of the biggest mining pools to collude and do
 literally whatever they wanted with the protocol, including inflating the
 money supply, freezing funds or even confiscating funds, because who would
 know? And even if someone running a full node did voice out, the majority
 of users on SPV/Coinbase/etc.. would be powerless to do anything about it
 and would likely bear with the changes to protect status quo, just as is
 the case with current fiat regimes where people bear with QE/Inflation/bail
 outs because they are so dependent on the current system that they would
 rather tolerate any injustice than to have the system go down and bring
 them with it.
 This is the primary reason why many in the technical community are against
 drastic blocksize increases, as this will only worsen the problem of
 decentralization as this cost increases. And as long as full nodes are
 running on charity, i'm fully in agreement with the conservative block size
 camp.

 However, it is important to note that this seems to be an economic problem
 instead of a technical one. I cannot deny the argument from the big block
 side that technically, the hardware/bandwidth required to run full nodes
 supporting considerably larger blocks (4MB-8MB) is not out of reach of many
 individuals around the globe. The core issue in my opinion is that of
 incentive, because at the end of the day, running a full node is not free
 and at larger blocks costs will not be trivial. In my opinion, its perhaps
 our insistence that full nodes cant be incentivised that contributes to
 centralization pressures and discourages increasing of blocksize even
 though the technology exists to support it.

 Technically, existing hardware is capable of validating/processing blocks
 in the region of an order of magnitude larger than the current limit.
 Bandwidth requirements for running a validating full node are also not very
 high if you are not mining, as you can afford to wait a couple of minutes
 to download your block. This is obviously not the case for miners who need
 to download new blocks asap to avoid idle hash power or as has been seen in
 the recent fork, SPV mining (which is extremely undesirable for the
 network). IBLT should help greatly in reducing the propagation time of new
 blocks and ease peak bandwidth requirements. But im not worried about the
 miners, they are after all being financially compensated for what they are
 doing and investing in more bandwidth(either locally or running a full node
 remotely) can be seen as a cost of the business as long as the cost of
 running a full node is insignificant to the cost of hashing equipment to
 keep barriers to mining low.

 Before the concept lightning, there did not seem to be any trustless way
 of feasibly paying small micropayments to full nodes for their services.
 However, with payment channels and lightning, this may no longer be an
 issue. A node could advertise it's rates to a SPV nodes upon connection and
 the SPV could either agree or look for another node with lower fees. If
 implemented, fees are likely to be trivial(few satoshis per request) as
 competition will drive down fees close to the cost of running a full node.
 This should spur an increase in the number of full nodes and increase
 decentralization of the network.

 I just wanted to float the idea and hear comments/feedback/critiques of
 this idea.

 ___
 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

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo via bitcoin-dev]

Having said that, I must admit that the complex filtering mechanisms are
pretty clever...they almost make it practical to use SPV...now if only we
were committint to structures that can prove the validity of returned
datasets and miners actually validated stuff, it might also offer some
level of security.
On Jul 31, 2015 1:45 PM, Eric Lombrozo elombr...@gmail.com wrote:

 I would love to be able to increase block size. But I have serious doubts
 about being able to do this safely at this time given what we presently
 know about the Bitcoin network. And I'm pretty sure I'm not alone in this
 sentiment.

 Had we been working on fixing the known issues that most complicate bigger
 blocks in the last six years, or even in the last three years after many
 issues had already been well-identified, perhaps we'd be ready to increase
 the limit. But other things have seemed more important, like specifying the
 use of X.509 overlay protocols or adding complex filtering mechanisms to
 the p2p protocol to make it practical to use tx merkle trees...and as a
 result we're not ready for safely allowing larger blocks.

 - Eric
 On Jul 30, 2015 11:43 PM, Thomas Zander via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:

 On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
   I don’t think it’s really a matter of whether we agree on whether it’s
 good
  to raise the block size limit, Gavin. I think it’s a matter of a
 difference
  in priorities.

 Having different priorities is fine, using your time to block peoples
 attempts
 to increase block size is not showing different priorities, it shows
 conflicting
 priorities.
 Different priorities means you can trust someone else to do things they
 care
 about while you do things you care about.
 --
 Thomas Zander
 ___
 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] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo via bitcoin-dev]

 On Jul 30, 2015, at 5:29 AM, Gavin gavinandre...@gmail.com wrote:
 
 it is hard to have a rational conversation about that when even simple 
 questions like 'what is s reasonable cost to run a full node' are met with 
 silence.

Some of the risks are pretty hard to quantify. But I think this misses the 
bigger point - it very well *might* be possible to safely raise this limit or 
even get rid of it by first fixing some serious issues with the protocol. But 
over six years into the project and these issues continue to be all-but-ignored 
by most of the community (including at least a few core developers). I don’t 
think it’s really a matter of whether we agree on whether it’s good to raise 
the block size limit, Gavin. I think it’s a matter of a difference in 
priorities.

- Eric


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] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo via bitcoin-dev]

 On Jul 30, 2015, at 11:02 AM, Mark Friedenbach via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 It is possible for a decentralized system like bitcoin to scale via 
 distribution in a way that introduces minimal trust, for example by 
 probabilistic validation and distribution of fraud proofs. However changes to 
 bitcoin consensus rules (mostly soft-forks) are required in order to make 
 this possible.

Please, Mark, let’s make this happen.

You can count on my full support.


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] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo via bitcoin-dev]

I agree that the historical reasons are irrelevant from an engineering 
perspective. But they still set a context for the discussion…and might help 
shed some insight into the motivations behind some of the participants. It’s 
also good to know these things to counter arguments that start with “But 
Satoshi said that…”

What’s critically important to note is that several of the assumptions that 
were being made at the time this limit was decided have turned out wrong…and 
that these other issues should probably be of greater concern and more highly 
prioritized in any discussion considering the merits of deploying potentially 
incompatible consensus rule changes. It seems if these other issues were fixed 
perhaps no block size limit would be required at all (as was originally hoped).

- Eric

 On Jul 28, 2015, at 5:46 PM, Mark Friedenbach m...@friedenbach.org wrote:
 
 Does it matter even in the slightest why the block size limit was put in 
 place? It does not. Bitcoin is a decentralized payment network, and the 
 relationship between utility (block size) and decentralization is empirical. 
 Why the 1MB limit was put in place at the time might be a historically 
 interesting question, but it bears little relevance to the present 
 engineering issues.
 
 On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 
  Enter a “temporary” anti-spam measure - a one megabyte block size limit. 
  Let’s test this out, then increase it once we see how things work. So far 
  so good…
 
 
 The block size limit was put in place as an anti-DoS measure (monster 
 blocks), not anti-spam. It was never intended to have any economic effect, 
 not on spam and not on any future fee market.
 
 
 jp
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
 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] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo via bitcoin-dev]

 On Jul 28, 2015, at 7:40 PM, Eric Lombrozo elombr...@gmail.com wrote:
 
 Note: many of these ideas are neither my own nor really all that new, but it 
 seems in the past we’ve given up too easily on actually moving forward on 
 them despite their critical importance.

In retrospect I regret not having made this note more emphatic:

GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR YEARS 
ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…WTF?!?!?!?


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 Roadmap 2015, or If We Do Nothing Analysis

[Eric Lombrozo via bitcoin-dev]

 On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote:
 (Claim of large bitcoin ecosystem companies without full nodes) this
 says to me rather we have a need for education: I run a full node
 myself (intermittently), just for my puny collection of bitcoins.  If
 I ran a business with custody of client funds I'd wake up in a cold
 sweat at night about the security and integrity of the companies full
 nodes, and reconciliation of client funds against them.
 
 However I'm not sure the claim is accurate ($30m funding and no full
 node) but to take the hypothetical that this pattern exists, security
 people and architects at such companies must insist on the company
 running their own full node to depend on and cross check from
 otherwise they would be needlessly putting their client's funds at
 risk.
 
 FWIW, blockchain.info is obviously *not* running a full node as their
 wallet was accepting invalid confirmations on transactions caused by the
 recent BIP66 related fork; blockchain.info has $30m in funding.
 
 Coinbase also was not running a full node not all that long ago, instead
 running a custom Ruby implementation that caused their service to go
 down whenever it forked. (and would have also accepted invalid
 confirmations) I believe right now they're running that implementation
 behind a full node however.
 
 The crypto currency security standards document probably covers
 requirement for fullnode somewhere
 https://cryptoconsortium.github.io/CCSS/ - we need some kind of basic
 minimum bar standard for companies to aim for and this seems like a
 reasonable start!
 
 Actually I've been trying to get the CCSS standard to cover full nodes,
 and have been getting push-back:
 
 https://github.com/CryptoConsortium/CCSS/issues/15
 
 tl;dr: Running a full node is *not* required by the standard right now
 at any certification level.
 
 This is of course completely ridiculous... But I haven't had much much
 time to put into getting that changed so maybe we just need some better
 explanations to the others maintaining the standard. That said, if the
 standard stays that way, obviously I'm going to have to ask to have my
 name taken off it.

For the record, there’s pretty much unanimous agreement that running a full 
node should be a requirement at the higher levels of certification (if not the 
lower ones as well). I’m not sure exactly what pushback you’re referring to.


 In terms of a constructive discussion, I think it's interesting to
 talk about the root cause and solutions: decentralisation (more
 economically dependent full nodes, lower miner policy centralisation),
 more layer 2 work.  People interested in scaling, if they havent,
 should go read the lightning paper, look at the github and participate
 in protocol or code work.  I think realistically we can have this
 running inside of a year.  That significantly changes the dynamic.
 Similarly a significant part of mining centralisation is artificial
 and work is underway that will improve that.
 
 I would point out that lack of understanding of how Bitcoin works, as
 well as a lack of understanding of security engineering in general, is
 probably a significant contributor to these problems. Furthermore
 Bitcoin and cryptocurrencies in general are still small enough that many
 forseeable low probability but high impact events haven't happened,
 making it difficult to explain to non-technical stakeholders why they
 should be listening to experts rather than charlatans and fools.
 
 After a few major centralization related failures have occured, we'll
 have an easier job here. Unfortunately there's also a good chance we
 only get one shot at this due to how easy it is to kill PoW systems at
 birth...
 
 --
 'peter'[:-1]@petertodd.org
 14438a428adfcf4d113a09b87e4a552a1608269ff137ef2d
 ___
 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 Roadmap 2015, or If We Do Nothing Analysis

[Eric Lombrozo via bitcoin-dev]

Thanks for bringing up the CCSS, Adam and Peter.

I was actually working on a post inviting everyone in this mailing list to come 
and participate…but you guys beat me to it. :)

The CCSS is an open standard, born out of the belief that sharing the 
industry's best practices amongst each other and with the community at large 
benefits everyone.

To read more about it and how you can contribute, please visit 
http://blog.cryptoconsortium.org/contributing-to-the-ccss/ 
http://blog.cryptoconsortium.org/contributing-to-the-ccss/

The standard:  https://cryptoconsortium.github.io/CCSS/ 
https://cryptoconsortium.github.io/CCSS/

The github repository: https://github.com/CryptoConsortium/CCSS 
https://github.com/CryptoConsortium/CCSS


- Eric

 On Jul 24, 2015, at 10:43 AM, Peter Todd via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote:
 On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
 It's worth noting that even massive companies with $30M USD of funding don't
 run a single Bitcoin Core node,
 
 I assume you mean that they don't have a Bitcoin Core node that is open to
 incoming connections. Since that is the only thing you can actually test, no?
 
 We can test the fact that blockchain.info's wallet and block explorer
 has behaved in a way consistent with not running a full node - they have
 shown invalid data that any full node would reject on multiple
 occasions, most recently invalid confirmations during the BIP66 fork.
 
 --
 'peter'[:-1]@petertodd.org
 06baf20e289b563e3ec69320275086169a47e9c58d4abfba
 ___
 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

[Eric Lombrozo via bitcoin-dev]

 On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com 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 jti...@jtimon.cc wrote:
 
 On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org 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

[Eric Lombrozo via bitcoin-dev]

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 elombr...@gmail.com wrote:
 
 
 On Jul 23, 2015, at 4:42 PM, Benedict Chan ben...@fragnetics.com 
 mailto:ben...@fragnetics.com 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

[Eric Lombrozo via bitcoin-dev]

 On Jul 23, 2015, at 4:42 PM, Benedict Chan ben...@fragnetics.com 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

[Eric Lombrozo via bitcoin-dev]

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 elombr...@gmail.com 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 jeanpaulkogel...@me.com 
 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 elombr...@gmail.com 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 
 bitcoin-dev@lists.linuxfoundation.org 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 p...@petertodd.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 
 
 On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 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

[Eric Lombrozo via bitcoin-dev]

 On Jul 23, 2015, at 12:35 PM, Gavin Andresen gavinandre...@gmail.com 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

[Eric Lombrozo via bitcoin-dev]

 On Jul 23, 2015, at 11:10 AM, Jameson Lopp jameson.l...@gmail.com 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

[Eric Lombrozo via bitcoin-dev]

 On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 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

[Eric Lombrozo via bitcoin-dev]

 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.

 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


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

[Eric Lombrozo via bitcoin-dev]

 On Jul 22, 2015, at 3:01 PM, Mike Hearn he...@vinumeris.com 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

[Eric Lombrozo via bitcoin-dev]

 On 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.

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

[Eric Lombrozo via bitcoin-dev]

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

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 
 bitcoin-dev@lists.linuxfoundation.org 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
 bitcoin-dev@lists.linuxfoundation.org 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
 bitcoin-dev@lists.linuxfoundation.org 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
 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
 
 ___
 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

[Eric Lombrozo via bitcoin-dev]

 On Jul 22, 2015, at 5:34 PM, Cory Fields li...@coryfields.com wrote:
 
 On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo elombr...@gmail.com wrote:
 
 On Jul 22, 2015, at 5:05 PM, Cory Fields li...@coryfields.com wrote:
 
 On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo elombr...@gmail.com 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

[Eric Lombrozo via bitcoin-dev]

 On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 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