On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
It may be in everyone's collective interest to raise the block size but
not
their individual interest.
It is clear from
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
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
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
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:
On Aug 29, 2015 9:43 AM, Daniele Pinna via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
This work has vacuumed my entire life for the past two weeks leading me
to lag behind on a lot of work. I apologize for typos which I may not have
seen. I stand by for any comments the community
On 08/29/2015 06: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
What about supporting different networks? What if I want to look up
testnet for example?
blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
or
Yes! Good point, network should be encoded. Not sure I like this format yet,
but what if it was part of the authority, like block:testnet. Like http uses
port 80 by default, you could have block by default refer to block:mainnet.
Eg.
On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
As I understand Github is not to be used for the high-level discussion
of a draft BIP so I will post my thoughts here (is this specified
somewhere? Can we specify this in BIP-0001?).
As
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
That's fine too. Obviously the variable maximum would work just fine
without a minimum. In fact, with the O(1) propagation proposal, a
minimum number of transactions could be enforced, think - a percentage
of the current mempool. That's actually
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
On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak btcd...@gmail.com 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:
On Sun, Aug 30, 2015 at 4:13 AM, Peter R pete...@gmx.com wrote:
I agree that miners may change their level of centralization. This neither
affects the model nor the results presented in the paper.
It has tremdous significance to the real-world impact of your results.
If not for the other
Of course this assumes the network does not change any as a result of
such a system. But such a system provides strong incentives for the
network to centralize in other ways (put all the mining nodes in one DC
for all miners, etc).
If all the mining nodes are in one data center, and if all
Hi Greg,
Unfortunately, your work extensive as it was made at least two
non-disclosed or poorly-disclosed simplifying assumptions and a significant
system understanding error which, I believe, undermined it completely.
In short these were:
* You assume miners do not have the ability to
On Aug 29, 2015 7:02 PM, Chun Wang via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
bitcoin-dev@lists.linuxfoundation.org wrote:
On Sun, Aug 30, 2015 at 1:43 AM, Peter R pete...@gmx.com wrote:
Dear Greg,
I am moving our conversation into public as I've recently learned that
you've been forwarding our private email conversation verbatim without
my permission [I received permission from dpinna to share the email
below
On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer ta...@bitsofproof.com wrote:
I see the huge amount of sweat and love that went into core and it actually
hurts to see that most is expended in friction and lack of a vision for the
software architecture.
To be concrete, this was my plan if
Concept ACK. As suggested in the other thread, maybe it is worth to
start a new BIP draft for this?
On Thu, Aug 27, 2015 at 10:51 PM, Eric Lombrozo via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I posted a new draft of the proposal:
http://blockhawk.net/bitcoin-dev/bipwiki.html
20 matches
Mail list logo
