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
We need some game theory experts to analyse this but I see there are 3
major problems:
1. Tragedy of the commons: Some miners have to scarify their income to
increase the block size, and all miners will share the beneficial
outcome of the increase. All miners would like to be free riders.
2.
On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
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.
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
I don't think you'll find much support for introducing a mandatory minimum
block size. It's quite wasteful to "pad" blocks with transactions that the
miner is just sending back to themself. If you want to solve the block
propagation issue, I'd recommend instead working on O(1) block propagation.
T
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
I'd like to submit this paper to the dev-list which analyzes how miner
advantages scale with network and mempool properties in a scenario of
uncapped block sizes. The work proceeds, in a sense, from where Peter R's
work left off correcting a mistake and addressing the critiques made by the
communit
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:?blockh
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 commu
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
wan
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 U
-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
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/3b95
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 supp
I am quite skeptical about any pay-to-increase proposal because it is
difficult to predict the game dynamics and determine the right amount of
penalty. But anyway, here is my response to your revised proposal:
1. I agree with you that there should be a cap in the rate of change,
and also the m
My current idea:
* There's a scheduled hardcap that goes up over time.
* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote
I apologize, you are correct, I should not have used the word "real".
However, if you look at section 3 of the RFC, the first hierarchal level (which
in http is used to describe hosts) can be any "authority", not necessarily a
hostname.
So, you could use tx, block, address, etc. as the authori
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.
blockchain://tx:testnet3/3b95a766d7a99b87188d6875c8484cb2b310b
On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
wrote:
> 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
I would real
On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> 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/201
On Sat, Aug 29, 2015 at 4:22 PM, Jameson Lopp via bitcoin-dev
wrote:
> I don't think you'll find much support for introducing a mandatory minimum
> block size. It's quite wasteful to "pad" blocks with transactions that the
> miner is just sending back to themself. If you want to solve the block
>
I believe it was pointed out previously in the discussion of the Peter R
paper, but I'll repeat it here so that its visible - this seems to
ignore the effects of transaction validation caches and block
compression protocols. Many large miners already have their own network
to relay blocks around th
On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev
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 specified in BIP001, there's an option
On Sat, Aug 22, 2015 at 1:04 PM, Tamas Blummer wrote:
> On Aug 21, 2015, at 21:46, Jorge Timón wrote:
>
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer
> wrote:
>
> Every re-implementation, re-factoring even copy-paste introduces a risk of
> disagreement,
> but also open the chance of doing th
Hello Matt and Daniele,
> this seems to ignore the effects of transaction validation caches and block
> compression protocols.
The effect of block compression protocols is included. This is what I call the
"coding gain" and use the Greek letter "gamma" to represent.
As long as the block sol
I completely agree and I share your frustration.
The importance of modularization is often disregarded but in my
opinion it has a deep positive impact in the long term: more people
are able to contribute with code and review (in the areas they know
better), the risks associated with each change bec
On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer 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 dealing with the Core c
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
wrote:
> I posted a new draft of the proposal:
> http://blockhawk.net/bitcoin-dev/bipwiki.html
>
> The subsections still need to be
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 that proves this fact:
http://pastebin.com/jFgkk8M3].
> Greg wrote to Pete
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
wrote:
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
> /block/0b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=00
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
> wrote:
>
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f49
It is not a purely academic scenario that blocks contain effectively no
information (that was not previously relayed). I'm not aware of any
public code to do so, but I know several large miners who pre-relay the
block(s) they are working on to other nodes of theirs around the globe.
This means at a
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).
Matt
On 08/30/15 02:33, Matt Corallo via bitcoin-dev wrote:
> It
Hello Matt,
> It is not a purely academic scenario that blocks contain effectively no
> information (that was not previously relayed).
The results of my paper hold unless the information about the included
transactions is identically zero. If this information is extremely small, then
I agree t
> 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
On Sun, Aug 30, 2015 at 1:43 AM, Peter R 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 that proves
On 08/30/15 02:49, Peter R wrote:
> Hello Matt,
>
>> It is not a purely academic scenario that blocks contain *effectively* no
>> information (that was not previously relayed).
>
> The results of my paper hold unless the information about the included
> transactions is *identically zero*. If
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 abilit
On Sun, Aug 30, 2015 at 4:13 AM, Peter R 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 errors in your wor
I don't really see any problem with the paper:
All it states is that having the assumption that miners don't
centralize, transaction fees don't go to zero even without the
blocksize limit. I think we can accept this as a nice academic
research, and I believe that it's true.
Still, it doesn't have a
40 matches
Mail list logo
