question

[adamstgBit]

Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101

Maybe we should think about 8MB proposal from miners

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.

that didnt stop XT from trying.  

they must really suck at hiding if they use github and comment their commits and even make websites explaining what they do?

ahh now i understand: YOU are the one hiding your agenda and trying to spread FUD

they hoped it would go unnoticed, or that the NEED to change the limit would force poeple to use XT even tho they disagreed with IP blacklisting and the checkpoint thingy.

[onemorexmr]

Merchants tend to favor BIP101 and miners tend to favor BIP100.

BIP100 give too much power for miners while BIP101 hide many things from us
But, BIP101 would fail if miners won't support BIP101

Maybe we should think about 8MB proposal from miners

I think you confuse BIP101 and XT. Nonetheless both are open source so can’t really hide anything.

that didnt stop XT from trying.  

they must really suck at hiding if they use github and comment their commits and even make websites explaining what they do?

ahh now i understand: YOU are the one hiding your agenda and trying to spread FUD

they hoped it would go unnoticed, or that the NEED to change the limit would force poeple to use XT even tho they disagreed with IP blacklisting and the checkpoint thingy.

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud

[Klestin]

they hoped it would go unnoticed, or that the NEED to change the limit would force poeple to use XT even tho they disagreed with IP blacklisting and the checkpoint thingy.

Prioritizing != blacklisting.
Checkpoint discussion != code change.

[marky89]

a dev should make a BIP that makes block limit increase the same way difficulty increases

I always thought something like this would be ideal. I have been told, however, that a dynamic solution based on actual volume vs. capacity would be easy to attack and lead to more orphaned blocks. Don't really know the details, though. Can anyone help with those?

[meono]

a dev should make a BIP that makes block limit increase the same way difficulty increases

I always thought something like this would be ideal. I have been told, however, that a dynamic solution based on actual volume vs. capacity would be easy to attack and lead to more orphaned blocks. Don't really know the details, though. Can anyone help with those?

You're right, its not easy to measure the parameter that determines the blocksize limit, which is technology available.

One think blocksize limit can be treated as difficulty, one is completely delusional.

[johnyj]

I have noticed that even at today's average 400kb per block transaction data, the synchronization is already painfully slow on a normal PC if you missed several weeks of data. 8MB block will make most of the commercially available computer unable to catch up with the network. The problem is not on the network bandwidth, CPU just can not finish verifying a large block in 10 minutes before the next one arrives

[alani123]

Well, with even Mike Hearn saying that BIP100 is just an idea, I think that we should wait before making harsh assumptions. There's a chance to rethink weaknesses, discuss and implement afterwards. What's good about that however, is that support towards the basis of this proposal has already started forming and it's quite strong. This way I think that there are going to be decent efforts at creating what was expressed in the papers. It's also notable that Jeff is having an 'open' approach for the development.

[Klestin]

The problem is not on the network bandwidth, CPU just can not finish verifying a large block in 10 minutes before the next one arrives

This just isn't correct.  CPU is not the bottleneck, and will not be the bottleneck.  Your CPU is capable of processing vastly more transaction data than your network card can throw at it.

[valkir]

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud

http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-exits-may-reveal-users-ip-addresses

https://github.com/mikehearn/bitcoinxt/commit/5e62628118e7e5df2c19093911d04d197a12d0e7

and here is the list right now. 

[Klestin]

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud

http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-exits-may-reveal-users-ip-addresses

https://github.com/mikehearn/bitcoinxt/commit/5e62628118e7e5df2c19093911d04d197a12d0e7

and here is the list right now.  

That code does not blacklist IPs. It reduces priority of TOR exit node IPs so that in the event of a denial of service attack against that node, clearnet IPs are prioritized higher.  After the attack is over, any disconnected nodes can reconnect.  Does that really sound like a blacklist to you?

[marky89]

lol.... there is no need to run xt if you want to vote for bip101.

please show me code which does blacklist ip's. you cant...

fudfudfud

http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-exits-may-reveal-users-ip-addresses

https://github.com/mikehearn/bitcoinxt/commit/5e62628118e7e5df2c19093911d04d197a12d0e7

and here is the list right now.  

That code does not blacklist IPs. It reduces priority of TOR exit node IPs so that in the event of a denial of service attack against that node, clearnet IPs are prioritized higher.  After the attack is over, any disconnected nodes can reconnect.  Does that really sound like a blacklist to you?

The most common definition of "blacklist" is "a list of people or products viewed with suspicion or disapproval." That's exactly what it is. Hearn's justification is that "jamming attacks via Tor have been observed" -- therefore, isolate and compile a list of said [suspicious] IPs. Now we can speculate all day about which IP addresses will end up on that list in the end (whether that means virtually all known proxies, specific regions, etc) or whether there are more nefarious plans at hand.

At the end of the day, trusting a third party to compile a list of suspicious IPs is the definition of centralization and trust.

Nodes are perfectly capable of recognizing IPs that are DDOSing them, and deprioritizing them accordingly. There is no need for a centralized list. There is no need to isolate TOR. There is ZERO justification to push such a centralized solution. So why do people keep doing it?

I can't help but feel ashamed of the bitcoin community when I see these basic things -- which are antithetical to bitcoin -- justified for no reason.

[Amph]

maybe 2MB now - 4 MB in 2 years and 8MB in 4 years is not that bad...

wasn't this the initial gavin proposal? it was discarded because of the need to fork every time, if i'm not mistaken

[Lauda]

If we actually had to give anyone some power, it would be the miners. Don't tell me that you would want to give power to random people who aren't actually doing anything for the network (compared to them).
BIP100 is better than BIP101 in any case. However, since BIP100 isn't implemented changes are possible. Someone needs to tell Jeff to implement the dynamic block size from the other proposal into BIP100 (and the 'problem' would be solved).

[Mickeyb]

Why not mix up those ideas and come up with a better solution? Politics or power wasn't the problem here in the first place, it was about the block size. Those problems about who controls, voting power etc. were just brought up because of who proposes what BIP. Each proposal has their own uniqueness and may help bitcoin in any way, so why not mix all of those and come up with a better solution?

Well this will eventually happen and this is a decision making process that is taking place at the moment.

For God's sake, why doesn't one of these devs doesn't come up with a BIP that just increases block size, on a fixed or a dynamic schedule with no add-ons, with no giving power to anybody more or less.

Now, after reading more and more, it seems to me that every BIP proposal favors someone, gives advantages to someone, and saves somebody's a**. Even BIP100, after reading more about it.

[LiteCoinGuy]

yep. maybe that proposal is just too complicated and will bring too many problems with it.
iam still in favor of a smooth increase over time 2MB, 4 MB, 8MB, 14 MB...

it should be an easy design.

[alani123]

yep. maybe that proposal is just too complicated and will bring too many problems with it.
iam still in favor of a smooth increase over time 2MB, 4 MB, 8MB, 14 MB...

it should be an easy design.

We have no evidence to indicate that Moore's law is applicable on bitcoin's blockchain Why would anyone want to force the blockchain expanding at pre-set dates. The concept behind an increasing block size has no basis other than speculating that bitcoin's use will grow (and expecting the new users would want to use in-chain transactions. The vote mechanism of BIP100 is much more rational. It's good that Jeff wants to be open about development so possible weaknesses not thought out in the papers can be addressed while developing.

[Klestin]

For God's sake, why doesn't one of these devs doesn't come up with a BIP that just increases block size, on a fixed or a dynamic schedule with no add-ons, with no giving power to anybody more or less.

You mean like BIP 101?  It does exactly that.  And it's already designed, coded, and tested.

[TibanneCat]

We have no evidence to indicate that Moore's law is applicable on bitcoin's blockchain Why would anyone want to force the blockchain expanding at pre-set dates. The concept behind an increasing block size has no basis other than speculating that bitcoin's use will grow (and expecting the new users would want to use in-chain transactions. The vote mechanism of BIP100 is much more rational. It's good that Jeff wants to be open about development so possible weaknesses not thought out in the papers can be addressed while developing.

That is the main issue with 101
I think what Bobby Lee said sounds reasonable

Our perspective is that the Internet today, in China and also globally, is not yet ready for unrestrained, automatic increases of the block size. A global network of bitcoin miners and mining pools requires tremendous levels of network connectivity to relay large blocks around the world in a timely manner. If block sizes get too big, too fast, orphan rates will certainly increase, disadvantaging smaller miners and mining pools. Furthermore, the risks of larger forks would increase substantially, which will cause real devastation to bitcoin. ... For these technical reasons, we strongly believe that adopting BIP 100 is the more responsible choice.

Unbalance or not, we are finally heading toward consensus as BIP100 has 64% support and steadily increasing
not a single block has been mined under BIP101 in the past 24h

[knight22]

We have no evidence to indicate that Moore's law is applicable on bitcoin's blockchain Why would anyone want to force the blockchain expanding at pre-set dates. The concept behind an increasing block size has no basis other than speculating that bitcoin's use will grow (and expecting the new users would want to use in-chain transactions. The vote mechanism of BIP100 is much more rational. It's good that Jeff wants to be open about development so possible weaknesses not thought out in the papers can be addressed while developing.

That is the main issue with 101
I think what Bobby Lee said sounds reasonable

Our perspective is that the Internet today, in China and also globally, is not yet ready for unrestrained, automatic increases of the block size. A global network of bitcoin miners and mining pools requires tremendous levels of network connectivity to relay large blocks around the world in a timely manner. If block sizes get too big, too fast, orphan rates will certainly increase, disadvantaging smaller miners and mining pools. Furthermore, the risks of larger forks would increase substantially, which will cause real devastation to bitcoin. ... For these technical reasons, we strongly believe that adopting BIP 100 is the more responsible choice.

Unbalance or not, we are finally heading toward consensus as BIP100 has 64% support and steadily increasing
not a single block has been mined under BIP101 in the past 24h

Consensus toward miners but not from payment processors and market markers that strongly support BIP101 for obvious reasons. Both should go in an agreement otherwise it's not a consensus, it's a miners take over.

[marky89]

We have no evidence to indicate that Moore's law is applicable on bitcoin's blockchain Why would anyone want to force the blockchain expanding at pre-set dates. The concept behind an increasing block size has no basis other than speculating that bitcoin's use will grow (and expecting the new users would want to use in-chain transactions. The vote mechanism of BIP100 is much more rational. It's good that Jeff wants to be open about development so possible weaknesses not thought out in the papers can be addressed while developing.

That is the main issue with 101
I think what Bobby Lee said sounds reasonable

Our perspective is that the Internet today, in China and also globally, is not yet ready for unrestrained, automatic increases of the block size. A global network of bitcoin miners and mining pools requires tremendous levels of network connectivity to relay large blocks around the world in a timely manner. If block sizes get too big, too fast, orphan rates will certainly increase, disadvantaging smaller miners and mining pools. Furthermore, the risks of larger forks would increase substantially, which will cause real devastation to bitcoin. ... For these technical reasons, we strongly believe that adopting BIP 100 is the more responsible choice.

Unbalance or not, we are finally heading toward consensus as BIP100 has 64% support and steadily increasing
not a single block has been mined under BIP101 in the past 24h

Consensus toward miners but not from payment processors and market markers that strongly support BIP101 for obvious reasons. Both should go in an agreement otherwise it's not a consensus, it's a miners take over.

That's not really how bitcoin works. Consensus works because of economic incentives, and forks happen because of hashing power -- not the opinions of Bitpay, etc. which may change now that new alternatives to BIP 101 are emerging. Who are these market makers that you speak of, anyway?