Re: [bitcoin-dev] AT has effectively banned Bitcoin nodes via utilizing private subnets.

[Matt Whitlock via bitcoin-dev]

I've been trying to keep our discussion off-list because it is off-topic, but 
you keep adding the list back on in your replies.

http://steamforge.net/wiki/images/2/29/Settings-Firewall-Advanced.png

Settings > Firewall > Advanced Configuration > Outbound Protocol Control > All 
Other Protocols

That's all you had to do.


On Wednesday, 2 September 2015, at 9:44 am, Zach G via bitcoin-dev wrote:
> 42 in the whole world, and I'm one of them. Clearly that is a problem, do you 
> even know about AT or are you in another country? Cause that statement is 
> utterly ridiculous given the fact there are hundreds of millions of people 
> using AT I was simply sharing my knowledge on this issue since it poses a 
> threat to the health of the bitcoin network, no need for personal attacks. 
> 
> None of my accusations were false, there is a firewall in the DVR that is 
> uncontrolled and all ports are blocked via private subnets and no fixed 
> public IP allowed unless you pay. I confirmed every one of these details with 
> AT technicians or I wouldn't be saying them.
> 
>  
> 
>  
> 
>  
> 
> -Original Message-
> From: Matt Whitlock 
> To: hurricanewarn1 
> Sent: Wed, Sep 2, 2015 5:34 am
> Subject: Re: [bitcoin-dev] AT has effectively banned Bitcoin nodes via 
> utilizing private subnets.
> 
> 
> According to BitNodes, 42 Bitcoin nodes are running on AT's
> network:
> 
> https://getaddr.bitnodes.io/nodes/?q=AT%26T
> 
> So I'm thinking
> there's nothing wrong with AT's default network configuration.
> 
> Frankly, the
> things you've been writing strongly suggest that you aren't very knowledgeable
> about computer networking. Instead of jumping right into making wild 
> accusations
> about AT, you probably should find someone knowledgeable to verify your
> claims.
> 
> 
> On Wednesday, 2 September 2015, at 5:20 am, Zach G via bitcoin-dev
> wrote:
> > First off I couldn't synch the wallet, it said no block source
> available and there was zero connections. Bitcoin was literally getting 
> thottled
> every second. It would not even allow the connection to get block source. 
> EVERY
> port was blocked, making exceptions in the router firewall did nothing. I was
> forced to use Blockchain.info which is a major security risk.
> > 
> > Secondly, I
> am developing a program using Bitcoin Python modules, so I login to my 
> computer
> like it's a server and it was flat out rejecting the connection. I could not 
> run
> any code until this got fixed, and of course needed the block source to even 
> do
> anything. 
> > 
> > If Bitcoin Core worked but 8333 was blocked I would not be
> emailing the list. Bitcoin Core was crippled and unusable due to the AT
> settings, and they tried hard to get me to buy monthly subscriptions to get 
> the
> answer. This makes it likely that Bitcoin Core is unusable for most AT
> customers and other ISPs, hence the massive node decline. I'm sure this 
> disrupts
> alot of other people besides Bitcoiners too, hence the monthly subscriptions
> geared towards people who can't figure out their connection situation.
> > 
> >
> AT literally blocked access to static IP if you don't buy one, so it wasn't 
> a
> normal network setup. Unfortunately the same security used to stop hackers and
> viruses stops Bitcoin too, so this is probably the settings for almost every
> router in the country. Nodes are in fact declining worldwide, down 15% in the
> past year alone. Community needs to speak up and also educate before this gets
> completely out of control. https://getaddr.bitnodes.io/dashboard/?days=365 
> 6,000
> nodes is pathetic as it is and it's constantly declining.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Matt Whitlock via bitcoin-dev]

Isn't this all backward? The "authority" component of the URL should identify 
the chain, and the "path" component should identify the particular block, tx, 
or address in that chain.

So instead of:

blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

It should be:

blockchain://0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f

And I would agree with allowing well-known chains to register a name, to be 
used as an alternative to the literal, hash syntax:

blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f


On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> >
> > I would really prefer chain= over network=
> > By chainID I mean the hash of the genesis block, see
> >
> > https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > I'm completely fine with doing that using an optional parameter (for
> > backwards compatibility).
> >
> 
> I see that using the genesis block hash would be the perfectly rigorous way
> to do it, but what do you think about the possibility of letting also use
> the name constants, as a simple / more relaxed alternative? That would
> spare a source lookup just to write a correct reference to a tx, maybe in a
> forum or a post.
> 
> So a reference to a certain tx could be either:
> 
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> 
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> 
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
> 
> (or a different element name maybe)
> 
> -- 
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Matt Whitlock via bitcoin-dev]

bitcoin:12345 *is* a real URI. It's just not an absolute, hierarchical URI 
(a.k.a. a URL); rather, it's an opaque URI.

And your suggestion is actually in violation of the URI spec, since 
blockhash, txid, block, and address are not host names.

More correct would be:

blockchain:?blockhash=1003e880d500968d51157f210c632e08a652af3576600198
blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain:?block=189000
blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn

You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986


On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev wrote:
 I like the idea of having a standard for this, that all explorers (and even 
 core, eventually) would understand.
 
 I would recommend 2 changes though. First, using a real URI scheme, 
 blockchain:// so that we can just use normal URL parsing libraries. The 
 bitcoin: thing leads to additional code to mutate it into a proper URI before 
 passing it to URL parsing. And I think it would be fine to include the type 
 looking up. For example:
 
 blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
 blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 blockchain://block/189000
 blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
 
 I think this would help the URI be more human understandable as well as give 
 the explorers the ability to optimize a bit what they are looking for when 
 hitting various databases.
 
 A possible future path could also include blockchain://tx/123000/4 for block 
 height, tx index... Another possibility could be blockchain://version which 
 would return a list of supported paths, version of the BIP supported, etc.
 
 The BIP should also specify little endian searching. I'm not sure, but would 
 it also make sense for this BIP to include what the return results should 
 look like? Maybe another, related BIP.
 
  On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev 
  bitcoin-dev@lists.linuxfoundation.org wrote:
  
  Hi!
  My first post here, hope I'm following the right conventions.
  I had this humble idea for a while, so I thought to go ahead and propose
  it.
  
  BIP: XX
  Title: URI scheme for Blockchain exploration
  Author: Marco Pontello
  Status: Draft
  Type: Standards Track
  Created: 29 August 2015
  
  Abstract
  
  This BIP propose a simple URI scheme for looking up blocks, transactions,
  addresses on a Blockchain explorer.
  
  Motivation
  ==
  The purpose of this URI scheme is to enable users to handle all the
  requests for details about blocks, transactions, etc. with their preferred
  tool (being that a web service or a local application).
  
  Currently a Bitcoin client usually point to an arbitrary blockchain
  explorer when the user look for the details of a transaction (es. Bitcoin
  Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
  Other times resorting to cutpaste is needed.
  The same happens with posts and messages that reference some particular
  txs or blocks, if they provide links at all.
  
  Specification
  =
  The URI follow this simple form:
  
  blockchain: hash/string  
  
  Examples:
  
  blockchain:1003e880d500968d51157f210c632e08a652af3576600198
  blockchain:001949
  blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
  
  Rationale
  =
  I thought about using some more complex scheme, or adding qualifiers to
  distinguish blocks from txs, but in the end I think that keeping it simple
  should be practical enough. Blockchain explorers can apply the same
  disambiguation rules they are already using to process the usual search
  box. 
  
  From the point of view of a wallet developer (or other tool that need to
  show any kind of Blockchain references), using this scheme mean that he
  can simply make it a blockchain: link and be done with it, without having
  to worry about any specific Blockchain explorer or provide a means for the
  user to select one.
  
  Blockchain explorers in turn will simply offer to handle the blockchain:
  URI, the first time the user visit their website, or launch/install the
  application, or even set themselves if there isn't already one.
  
  Users get the convenience of using always their preferred explorer, which
  can be especially handy on mobile devices, where juggling with cutpaste
  is far from ideal.

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

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Matt Whitlock via bitcoin-dev]

That's still not right, since mainnet and testnet are not host names.

You'd have to do something like:

blockchain:?network=testnettxid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a


On Saturday, 29 August 2015, at 7:58 pm, Btc Drak via bitcoin-dev wrote:
 What about supporting different networks? What if I want to look up
 testnet for example?
 
 blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 
 or
 
 blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
 
 On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:
  I like the idea of having a standard for this, that all explorers (and even
  core, eventually) would understand.
 
  I would recommend 2 changes though. First, using a real URI scheme,
  blockchain:// so that we can just use normal URL parsing libraries. The
  bitcoin: thing leads to additional code to mutate it into a proper URI
  before passing it to URL parsing. And I think it would be fine to include
  the type looking up. For example:
 
  blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
  blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
  blockchain://block/189000
  blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
 
  I think this would help the URI be more human understandable as well as give
  the explorers the ability to optimize a bit what they are looking for when
  hitting various databases.
 
  A possible future path could also include blockchain://tx/123000/4 for block
  height, tx index... Another possibility could be blockchain://version which
  would return a list of supported paths, version of the BIP supported, etc.
 
  The BIP should also specify little endian searching. I'm not sure, but would
  it also make sense for this BIP to include what the return results should
  look like? Maybe another, related BIP.
 
  RicMoo
 
  Sent from my self-aware iPhone
 
  .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º
 
  Richard Moore ~ Founder
  Genetic Mistakes Software Inc.
  phone: (778) 882-6125
  email: ric...@geneticmistakes.com
  www: http://GeneticMistakes.com
 
  On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
  bitcoin-dev@lists.linuxfoundation.org wrote:
 
  Hi!
  My first post here, hope I'm following the right conventions.
  I had this humble idea for a while, so I thought to go ahead and propose
  it.
 
  BIP: XX
  Title: URI scheme for Blockchain exploration
  Author: Marco Pontello
  Status: Draft
  Type: Standards Track
  Created: 29 August 2015
 
  Abstract
  
  This BIP propose a simple URI scheme for looking up blocks, transactions,
  addresses on a Blockchain explorer.
 
  Motivation
  ==
  The purpose of this URI scheme is to enable users to handle all the
  requests for details about blocks, transactions, etc. with their preferred
  tool (being that a web service or a local application).
 
  Currently a Bitcoin client usually point to an arbitrary blockchain
  explorer when the user look for the details of a transaction (es. Bitcoin
  Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
  Other times resorting to cutpaste is needed.
  The same happens with posts and messages that reference some particular
  txs or blocks, if they provide links at all.
 
  Specification
  =
  The URI follow this simple form:
 
  blockchain: hash/string
 
  Examples:
 
  blockchain:1003e880d500968d51157f210c632e08a652af3576600198
  blockchain:001949
  blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 
  Rationale
  =
  I thought about using some more complex scheme, or adding qualifiers to
  distinguish blocks from txs, but in the end I think that keeping it simple
  should be practical enough. Blockchain explorers can apply the same
  disambiguation rules they are already using to process the usual search
  box.
 
  From the point of view of a wallet developer (or other tool that need to
  show any kind of Blockchain references), using this scheme mean that he
  can simply make it a blockchain: link and be done with it, without having
  to worry about any specific Blockchain explorer or provide a means for the
  user to select one.
 
  Blockchain explorers in turn will simply offer to handle the blockchain:
  URI, the first time the user visit their website, or launch/install the
  application, or even set themselves if there isn't already one.
 
  Users get the convenience of using always their preferred explorer, which
  can be especially handy on mobile devices, where juggling with cutpaste
  is far from ideal.
 
 
  

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

[Matt Whitlock via bitcoin-dev]

But that's not what this proposal does. They have to pay the difficulty penalty 
merely for a *chance* at later being able to mine larger blocks.

Maybe this could be fixed by allowing miners to produce a larger-than-limit 
block *immediately* by paying a difficulty penalty. Then we can simply take the 
80th-percentile block size in each 2016-block period as the nominal block-size 
limit in the next period.


On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote:
 It is in their individual interests when the larger block that is allowed
 for them grants them more fees.
 
 On Aug 28, 2015 4:35 PM, Chris Pacia via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
  When discussing this with Matt Whitlock earlier we basically concluded the
  block size will never increase under this proposal do to a collective
  action problem. If a miner votes for an increase and nobody else does, the
  blocksize will not increase yet he will still have to pay the difficulty
  penalty.
 
  It may be in everyone's collective interest to raise the block size but
  not their individual interest.
  On Aug 28, 2015 6:24 PM, Gavin via bitcoin-dev 
  bitcoin-dev@lists.linuxfoundation.org wrote:
 
  With this proposal, how much would it cost a miner to include an 'extra'
  500-byte transaction if the average block size is 900K and it costs the
  miner 20BTC in electricity/capital/etc to mine a block?
 
  If my understanding of the proposal is correct, it is:
 
  500/90 * 20 = 0.1 BTC
 
  ... Or $2.50 at today's exchange rate.
 
  That seems excessive.
 
  --
  Gavin Andresen
 
 
   On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev 
  bitcoin-dev@lists.linuxfoundation.org wrote:
  
   This is the best proposal I've seen yet. Allow me to summarize:
  
   • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
  their block-size votes.
   • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
  trying to predict future market needs versus future technological
  capacities.
   • It avoids a large step discontinuity in the block-size limit by
  starting with a 1-MB limit.
   • It throttles changes to ±10% every 2016 blocks.
   • It imposes a tangible cost (higher difficulty) on miners who vote to
  raise the block-size limit.
   • It avoids incentivizing miners to vote to lower the block-size limit.
  
   However, this proposal currently fails to answer a very important
  question:
  
   • What is the mechanism for activation of the new consensus rule? It is
  when a certain percentage of the blocks mined in a 2016-block retargeting
  period contain valid block-size votes?
  
  
   https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
  
  
   On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
   Pull request: https://github.com/bitcoin/bips/pull/187
   ___
   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
 
 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Matt Whitlock via bitcoin-dev]

This is the best proposal I've seen yet. Allow me to summarize:

• It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their 
block-size votes.
• It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to 
predict future market needs versus future technological capacities.
• It avoids a large step discontinuity in the block-size limit by starting with 
a 1-MB limit.
• It throttles changes to ±10% every 2016 blocks.
• It imposes a tangible cost (higher difficulty) on miners who vote to raise 
the block-size limit.
• It avoids incentivizing miners to vote to lower the block-size limit.

However, this proposal currently fails to answer a very important question:

• What is the mechanism for activation of the new consensus rule? It is when a 
certain percentage of the blocks mined in a 2016-block retargeting period 
contain valid block-size votes?


https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki


On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
 Pull request: https://github.com/bitcoin/bips/pull/187
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Uniquely identifying forked chains

[Matt Whitlock via bitcoin-dev]

Why would you use a hash of hashes? Wouldn't it be simpler and just as 
effective to use either:

1) the genesis block hash, or
2) the block hash of the first block in a fork?

Every block hash in a chain implicitly subsumes the genesis block hash of that 
chain, so there's no need to incorporate the genesis block hash again.


On Saturday, 29 August 2015, at 1:27 am, gladoscc via bitcoin-dev wrote:
 There has been discussion of using the genesis block hash to identify
 chains in BIP 21 (bitcoin:// URI scheme). However, this does not allow
 identification between blockchain forks building upon the same genesis
 block. While many see this as undesirable, I think it is inevitable that
 this will eventually happen at some point, and think it is best to build
 systems redundantly.
 
 I propose identifying blockchains for BIP 21 and any other relevant needs
 through:
 
 1) the genesis block hash for a new chain, or
 2) a hash of the genesis block hash,  concatenated with block hash(es) of
 fork point(s) for a fork chain
 
 This would support forks, forks of forks, forks of forks of forks, etc
 while preserving a fixed length chain identifier.
 
 If a user wants to specify whatever chain is the longest with PoW, they
 would use (1). In times where multiple chains are coexisting and being
 actively mined, a user can use (2) to specifically identify a chain.
 
 Thoughts?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Matt Whitlock via bitcoin-dev]

On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
 What would you think of an approach like John Dillon's proposal to
 explicitly give the economic majority of coin holders a vote for the max
 blocksize? Miners could still vote BIP100 style for what max they were
 willing to use, limited in turn by the vote of the economic majority.

What fraction of coin holders do you suppose will vote? And, of those, what 
fraction have the technical knowledge to make an informed vote? It would be 
like polling Toyota truck owners to see whether the 2017 Tacoma should increase 
its engine's cylinder displacement by 10%. Ordinary users just aren't going to 
be able to vote meaningfully, and most won't respond to the poll at all.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Matt Whitlock via bitcoin-dev]

On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote:
 On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
  On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
   What would you think of an approach like John Dillon's proposal to
   explicitly give the economic majority of coin holders a vote for the max
   blocksize? Miners could still vote BIP100 style for what max they were
   willing to use, limited in turn by the vote of the economic majority.
  
  What fraction of coin holders do you suppose will vote? And, of those, what 
  fraction have the technical knowledge to make an informed vote? It would be 
  like polling Toyota truck owners to see whether the 2017 Tacoma should 
  increase its engine's cylinder displacement by 10%. Ordinary users just 
  aren't going to be able to vote meaningfully, and most won't respond to the 
  poll at all.
 
 Note that you can make the % of voters required adapt dyanmically to voter
 interest. Also, your example is rather misleading, as car buyers *do*
 make those kinds of decisions though various market mechanisms.

Yes, car buyers do make those kinds of decisions through market mechanisms. An 
equivalent process for Bitcoin would be that the max block-size limit (and 
other fundamental economic parameters) would be determined via a process of 
forking off altcoins (such as Bitcoin XT will do) and allowing the market to 
decide which coin is most valuable. This is the default mechanism for change 
(because it's what naturally happens when there is a lack of internal 
consensus), but it's not the least painful mechanism.

My point still stands that — just as in democracy in general — the voters are 
really in no position to cast informed votes, nor should they be (cf. rational 
ignorance [1]). I do not oppose opening up the determination of the max 
block-size limit to a popular check via stakeholder vote — actually, I think 
this is an important check on miners' power — but I do argue that the vote is 
likely to have drastically little participation and very low-quality results.

[1] Rational Ignorance: «Ignorance about an issue is said to be rational when 
the cost of educating oneself about the issue sufficiently to make an informed 
decision can outweigh any potential benefit one could reasonably expect to gain 
from that decision, and so it would be irrational to waste time doing so.» 
https://en.wikipedia.org/wiki/Rational_ignorance

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

Re: [bitcoin-dev] Electrum Server Speed Test

[Matt Whitlock via bitcoin-dev]

Great data points, but isn't this an argument for improving Electrum Server's 
database performance, not for holding Bitcoin back?

(Nice alias, by the way. Whimmy wham wham wozzle!)


On Thursday, 23 July 2015, at 5:56 pm, Slurms MacKenzie via bitcoin-dev wrote:
 Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at 
 how the Electrum server software handles under load. The Electrum wallet is 
 extremely popular, and the distributed servers which power it are all hosted 
 by volunteers without budget. The server requires a fully indexed Bitcoin 
 Core daemon running, and produces sizable external index in order to allow 
 SPV clients to quickly retrieve their history. 
 
 3.9Gelectrum/utxo
 67M electrum/undo
 19G electrum/hist
 1.4Gelectrum/addr
 24G electrum/
 
 Based on my own logs produced by the electrum-server console, it takes this 
 server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes per 
 megabyte of block to process into the index. This seems to hold true through 
 the 10 or so blocks I have in my scroll buffer, the contents of blocks seem 
 to be of approximately the same processing load. Continuing this trend with 
 the current inter-block time of 9.8 minutes, an electrum-server instance 
 running on modest-high end dedicated server is able to support up to 2.64 MB 
 block sizes before permanently falling behind the chain. 
 ___
 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] BIP0074 Draft (Dynamic Rate Lookup)

[Matt Whitlock via bitcoin-dev]

You should rename your file to something like bip-draft-dynamic-rate-lookup. 
Using an arbitrary BIP number will cause confusion when that BIP number is 
actually assigned later.


On Friday, 17 July 2015, at 3:50 pm, David Barnes | Bitcoin Co. Ltd. via 
bitcoin-dev wrote:
 I picked up the next available number myself, but can be changed to 
 anything, the 74 is unimportant to the proposal.
 
 David Barnes
 
 On 7/17/2015 2:54 PM, Micha Bailey wrote:
  Did Greg assign this number? He didn't do it here on the ML. You're 
  not supposed to use arbitrary numbers, certainly not numbers that are 
  close/similar to ones already assigned.
 
 
 ___
 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