-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is great!! Thank you.
On 08/21/2015 06:24 AM, Christian Decker wrote:
I hacked together a simple tracking page for the 'block votes', it
currently includes the 8MB vote and XT, as well as the /BV\d+/ vote
for generic size:
Don't you mean profits instead of revenue?
On Aug 21, 2015 5:01 PM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
On 8/21/2015 3:21 PM, Peter Todd wrote:
To use a car analogy, Pieter Wuille has shown
On Fri, Aug 21, 2015 at 4:22 AM, odinn odinn.cyberguerri...@riseup.net
wrote:
That's interesting. But in all honesty I don't see most users being
able to pull off what you are describing.
The idea assumes that it is a BIP + soft fork. This means that most
wallets would support/recognise the
On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I like the intend of this attempt to bring more clarity to the blocksize
debate, however it would be more help to make this a information site about
the current outstanding BIPs and summarize
I like the intend of this attempt to bring more clarity to the blocksize
debate, however it would be more help to make this a information site about
the current outstanding BIPs and summarize their differences rather than
voting mechanism.
(ofcourse the author of the BIPs would vote for their own
I hacked together a simple tracking page for the 'block votes', it
currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for
generic size:
http://bitcoinstats.com/network/votes/
On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Yifu Guo via bitcoin-dev:
One thing is for sure though, not increasing the blocksize is not an option.
Why not? The blocksize increase eliminates the pressure to seek durable
solutions. But it will turn out differently. Other than we all think.
I really can not imagine that a 20-year plan will
Keeping the block size at 1mb restricts the number of active users of bitcoin
to around 100,000 people transacting twice a day on blockchain.
BItcoin is a protocol. Protocols are successful because of their network
effect. Capping the block size freezes bitcoin’s network effect, limits
accordingly to public release[1], They.
1. agreed that blocksize increase is needed.
2. opposed original 20mb, suggest 8mb instead as it is more technically
reasonable.
3. do not want blocksize to change in the short term future ( direct
translation. ) and in the document states.
after discussion
My UX skills are lacking a bit. You can edit all your thoughts about each
BIP, HTML is accepted, so you can link to other posts you made somewhere
else.
When you click on a cell in the grid, it forward you to the page that the
dev edited for this BIP.
This website is not only to say approve,
On 8/20/2015 5:37 PM, Peter Todd wrote:
On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote:
I found that small miners were not at all disadvantaged by large
blocks.You used 20% as the size of the large miner, with all the
small miners having good connectivity with
The limits Alex proposed are generous (bordering on obscene!), but dropping
that down to allowing only two levels of chained unconfirmed transactions
is too tight.
Use case: Brokered asset transfers may require sets of transactions with a
dependency tree depth of 3 to be published together. ( N
On Fri, Aug 21, 2015 at 2:13 PM, Sriram Karra karra@gmail.com wrote:
On Thu, Aug 20, 2015 at 1:01 PM, Jorge Timón
bitcoin-dev@lists.linuxfoundation.org wrote:
For the 73th time or so this month on this list:
The maximum block size consensus rule limits mining centralization
(which is
I dont see any problem with such limits. Though, hell, if you limited
entire tx dependency trees (ie transactions and all required unconfirmed
transactions for them) to something like 10 txn, maximum two levels
deep, I also wouldnt have a problem.
Matt
On 08/14/15 19:33, Alex Morcos via
On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
For the 73th time or so this month on this list:
The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).
Instead of posting all these
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
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,
Hector,
I can only say 2 things in the brief time I have now:
1. There is a solution that I proposed for proving you own a copy of the
block-chain. It's using aymmetric-time functions:
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
2. I'm finishing a paper on a
Am 21.08.2015 um 15:34 schrieb Will Madden:
Keeping the block size at 1mb restricts the number of active users of bitcoin
to around 100,000 people transacting twice a day on blockchain.
BItcoin is a protocol. Protocols are successful because of their network
effect. Capping the block
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
decided against it...still, I think we should add the option to select
service bits to DNS seeds
I’m replying all just because my point was changed in your response.
As a protocol Bitcoin could support millions of full nodes. What you
talking about is the number of shareholders. But these are poorly
determined by the block size. The number of shareholders is determined
by many parameter
The proposal will not break any existing clients in the first release.
After sufficient time to upgrade SPV clients, a new version will be
released which will result in older SPV clients finding themselves
disconnected from peers when they send filter* commands, so they can go
find other peers
I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based
On Fri, Aug 21, 2015 at 06:15:16PM -0400, Chris Pacia wrote:
On Aug 21, 2015 2:07 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Also, as I mentioned, just look at the popularity of wallets such as
Mycelium that are not adopting bloom filters, but going with
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
decided against it...still, I
I have tried to solve the maximum block size debate in two different
proposal.
i. Depending only on previous block size calculation.
ii. Depending on previous block size calculation and previous Tx fee
collected by miners.
Proposal 1: Depending only on previous block size calculation
If more
On Aug 21, 2015 2:07 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Also, as I mentioned, just look at the popularity of wallets such as
Mycelium that are not adopting bloom filters, but going with SPV
verification of block headers w/ lookup servers.
Related I
You said:
There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase
From this, my understanding is that you are operating on the principle
that the optimum blocksize is related to popularity/use of Bitcoin.
It seems that
Hi all,
Is there any client or code that currently implements BIP 100? And how will
it be deployed? WIll the initial fork be deployed in the same manner that
the max block size changes are deployed described in the bip?
Thanks
___
bitcoin-dev mailing
BIP Editor: Can I get a BIP # for this?
On 08/21/15 17:55, Matt Corallo via bitcoin-dev wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
On 8/21/2015 3:21 PM, Peter Todd wrote:
To use a car analogy, Pieter Wuille has shown that the brake cylinders
have a fatigue problem, and if used in stop-and-go traffic regularly
they'll fail during heavy braking, potentially
On Sat, Aug 22, 2015 at 01:08:13AM +, Matt Corallo wrote:
Well actually, we can reference the DoS attacks that Bitcoin XT nodes
are undergoing right now - part of the attack is repeated Bloom filter
requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far
as I know they
Interesting.
Unless I misunderstand the proposal, you would have to factor a way to deal
with miner cartel behavior. A few emails every week and the larger miners
could collude to set prices.
With that figured, then your voting proposal could be triggered by a moving
day block average which
On 08/21/15 22:06, Peter Todd wrote:
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this
On Fri, Aug 21, 2015 at 02:01:06AM -0400, Jeff Garzik wrote:
I don't see any link to data backing up Bloom filter usage has declined
significantly
Is there actual data showing this feature's use is declining or
non-existent?
I run a number of high speed nodes and while I don't have
Thinking in Bitcoins only on the level of technology unnecessarily narrows your
view.
OK, I hope to be pleasantly surprised.
Tamas Blummer
On Aug 20, 2015, at 23:35, Matt Corallo lf-li...@mattcorallo.com wrote:
On 08/20/15 21:26, Tamas Blummer wrote:
I know what you mean as I already
On Fri, Aug 21, 2015 at 6:10 AM, Nicolas Dorier via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Decision making is not the goal of this site, it is only a way to see
various pros and cons of various devs on various proposals in a single
place.
This is for the community to have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 20 August 2015 21:45:23 GMT-07:00, Gregory Maxwell via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I think this is a bit well, sad, at the moment-- a basic principle in
sound decision making is that one should try to withhold
On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
What might be valuable is to ask devs to explain what their threat models
are, what should be at the root of their thinking about the blocksize.
That's exactly what the Technical Opinion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 21 August 2015 02:31:51 GMT-07:00, Btc Drak btcd...@gmail.com wrote:
On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
What might be valuable is to ask devs to explain what their threat
I don't see any link to data backing up Bloom filter usage has declined
significantly
Is there actual data showing this feature's use is declining or
non-existent?
On Fri, Aug 21, 2015 at 1:55 AM, Peter Todd p...@petertodd.org wrote:
On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via
41 matches
Mail list logo
