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

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] 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.» 


___
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] 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] 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/900000 * 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] 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 
> >  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 cut&paste 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:   
> > 
> > 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 cut&paste
> > 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=testnet&txid=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
>  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
> >  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 cut&paste 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: 
> >
> > 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
> > ca

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]

The authority part in a URI is optional.

blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f

Notice the lack of a double-slash.


On Tuesday, 1 September 2015, at 11:38 pm, Marco Pontello wrote:
> I see your point. But I personally like that the chain part could be
> optional, given that the vast majority of the references in the end will be
> to Bitcoin main net.
> 
> On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock 
> wrote:
> 
> > 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
> >
> 
> 
> 
> -- 
> 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]

On Wednesday, 2 September 2015, at 12:46 am, Jorge Timón wrote:
> But again, the main issue is that we don't want a central authority to
> register unique unique and memorable chain name strings.

Why not? There's a central registry of MIME types. And there's a central 
registry of TCP/UDP port number assignments. The BIP describing the 
"blockchain" URI scheme is published by a central authority. For cases where 
assigning names to numbers is uncontroversial, central authorities don't cause 
any problems.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] AT&T 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&T or are you in another country? Cause that statement is 
> utterly ridiculous given the fact there are hundreds of millions of people 
> using AT&T. 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&T 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&T has effectively banned Bitcoin nodes via 
> utilizing private subnets.
> 
> 
> According to BitNodes, 42 Bitcoin nodes are running on AT&T's
> network:
> 
> https://getaddr.bitnodes.io/nodes/?q=AT%26T
> 
> So I'm thinking
> there's nothing wrong with AT&T'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&T, 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&T
> 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&T
> 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&T 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