Gold collapsing. Bitcoin UP.

[cypherdoc]

face it. there is just no hope of convincing these guys:

On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
wrote:
> The repo: https://github.com/jgarzik/bip100

What is the purpose of the newly added 1 MB floor? It seems clear from the
current information available that 1 MB is presently too high for the limit,
and it is entirely one-sided to only allow increases when decreases are much
more likely to be needed in the short term.

Must the new size limit votes use 11 bytes of coinbase? Why not just use a
numeric value pushed after height? Since this is a hardfork, I suggest
increasing the coinbase length to allow for 100 bytes *in addition* to the
pushed height and size-vote.

I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 MB
(or whatever value is deemed appropriate) to make it clear that the limit
remains a part of the consensus protocol and p2p protocol limits are not to
have an effect on consensus rules.

Furthermore, I suggest modifying the voting to require 50% to set the limit
floor. This has the effect of merely coordinating what miners can already
effectively do today by rejecting blocks larger than some collusion-
determined limit.

Thoughts?

Luke

 

[cypherdoc]

I'm amazed at how Bitcoin is handling yet another major spam attack. It seems that the large size of the spam tx means that smaller low fee tx are still being selected by miners. Not seeing complaints about stuck tx.

since miners are actively demonstrating their ability to process the tx's of their choice, remind me again why we need a limit?

 

[Melbustus]

since miners are actively demonstrating their ability to process the tx's of their choice, remind me again why we need a limit?

Yeah. The argument that blocksize must be capped *assumes* that miners will not be rational. Well, if one assumes that miners are not, on balance, rational over the longrun, then one must conclude that bitcoin can never work in the first place since miners' rationally responding to economic incentives is key.

In short, supporting a blocksize limit effectively requires believing that the free market doesn't work.

 

[Peter R]

...The argument that blocksize must be capped *assumes* that miners will not be rational...

Just playing devil's advocate here: what if the limit is removed, miners *are* rational, and the block size grows over time so that users with raspberry-pi's and 56k modems can no longer run full nodes? What if it continues to grow and users with old laptops and 1 Mbit connections can no longer run full nodes?

I personally see this as inevitable (and not as a bad thing): if Bitcoin is wildly successful, users may need specialized hardware ($$$) to operate Bitcoin full nodes. I have no problem with such a future. But I think part of the argument of the small blockers is that such an outcome would be bad. I guess I'm pointing out that what I think they imagine as a bad outcome could still occur if miners are rational.

 

[cypherdoc]

that is in NO WAY a bad outcome.

if that kinda usage occurs, a single BTC will be in the tens and maybe hundreds of thousand of USD. if that's the case, i bet everyone here would still be able to afford running a super node even if it is required to be housed in a datacenter. so what? poor Lukey?

 

[Peter R]

>>that is in NO WAY a bad outcome.

I completely agree. But I think this is the only argument the small blockers have left. And it's half true: assuming a success case for Bitcoin, it would be more costly to operate a full node if the transaction volume significantly increased. So how do we convince more of them that that's not a bad thing?

I guess one question is: What would a success case look like where anyone could run a full node on a raspberry-pi and a slow internet connection? Try to imagine millions of nodes around the world connected with cheap hardware and slow connections, processing extremely expensive transactions a few times per second. Now imagine that this strange network is somehow serving as a backbone for trillions of dollars of economic activity taking place on Lightning Networks and Side Chains. The visualization seems completely preposterous to me! And furthermore, why would anyone other than Lightning and Side Chain operators (and a few diehards) want to run full nodes in such a future anyways?

 

[solex]

https://getaddr.bitnodes.io/hardware/

ticket price $168

How many tens of thousands of these would sell if the network had JR's node services payment channels software built in and people could earn a little BTC income by keeping one running?

 

[awemany]

Hmm, Peter, did you try eMailing Gavin about your paper? I guess if tree chains as a totally half-baked idea get air time there, they can't really hide behind 'we only accept quality, and Greg says your paper is not quality enough'.


I think your paper is by far the best work on orphan cost and all the central and fundamental limits in the Bitcoin system and so is IMO a *must* to be presented at the conference.

I could imagine that Gavin, though very non-confrontational in style, would say a word or two about your paper (not) being presented at the conference!

 

[awemany]

One thing I am wondering: bitco.in is registered to 399 Park Ave, New York (according to WHOIS). That is the head quarters of citygroup. Bloomie, can you explain this relationship?

 

[Erdogan]

I agree that no block size limit is best, BIP 101 is a good compromise.

Blocks will increase in size in small steps, as making a block bigger than the previous biggest is a costly risk.

The hard fork/soft fork schism is a nonissue. There are chain forks, and there are software forks. A so called soft fork can also be viewed as a stealth fork.

The "software defines the protocol" meme is ok if you do not have a definition, but the software can have bugs.

Economics of scale will both work for concentration and limit the miner size at the same time, the market will find the right size.

I don't care about some people having low capacity equipment and bandwith, enough people have adequate.

The tragedy of the commons, is not applicable for blockchain space. If very large blocks should reduce total transaction rate compared to somewhat smaller blocks, the individual miner will be the one who is hurt, not the total. If this should prove to be wrong, a new rule could be implemented, not necessarily through a max block size, to fix the problem.

 

[Peter R]

Hmm, Peter, did you try eMailing Gavin about your paper? I guess if tree chains as a totally half-baked idea get air time there, they can't really hide behind 'we only accept quality, and Greg says your paper is not quality enough'.


I think your paper is by far the best work on orphan cost and all the central and fundamental limits in the Bitcoin system and so is IMO a *must* to be presented at the conference.

I could imagine that Gavin, though very non-confrontational in style, would say a word or two about your paper (not) being presented at the conference!

Awemany and Solex: the papers listed on the ScalingBitcoin website are just examples the committee felt were relevant to the topic. No presentation proposals have (apparently) been accepted yet. I exchanged emails with Andrew Miller today and he hasn't heard back either. I wouldn't be surprised to see an announcement tomorrow.

(Strange to not let speakers know if they're invited to speak with only 1 week to book flights, reserve accomodations and prepare PowerPower slides.)

 

[Erdogan]

In this article, David Stockman propose that every bubble bursts.

I happen to disagree - there is always one bubble that does not burst - the best money. The best money is similar to any bubble in the inflation phase: It is worth more because you think other people think that it will be worth more in the future, a circular argument. But the best money will always stand. Bitcoin will inflate in value and stay on top, until some better money comes around.

http://davidstockmanscontracorner.com/4-charts-show-why-this-rally-will-become-a-rout/

 

[theZerg]

@peterR: The forced-centralization due to scaling problem may be another debate that we have to have, BUT it should not affect the decision to move to 8MB blocks, since those are well within reach of current technology. Also, I believe that limiting the usefulness of Bitcoin will cause centralization simply because few will run a full node if they cannot afford a txn in it. In essence, there are arguments in both directions that depend on the unknowable future so we basically just have to say "I don't know" INRE centralization, for both 1MB and BIP101 solutions.

@solex: I do not think that centralization forces applying to the LN have been considered, but I believe they are significant. So I'm guessing your idea of 10k LN nodes is unlikely. First of all, does a LN node qualify as a money transmitter? And other legal issues that have been mostly resolved for bitcoin but would need to be rediscovered for LN. Second, there will be large cost savings if your LN node handles both sides (S -> LN.1 -> D -- 2 hops) rather than a 3 hop (S -> LN.1 -> LN.2 -> D) because the 3 hop requires more Bitcoins to be held in abeyance during the transaction. There is an opportunity cost associated with this (that money isn't being invested in something else) which translates into real costs that need to be expressed as LN fees.

 

[Bloomie]

@awemany the domain is registered through a proxy, because the Indian registry does not allow Whois privacy (.in is technically an Indian ccTLD). Citigroup is not involved with this site.

 

[theZerg]

Hmm, Peter, did you try eMailing Gavin about your paper? I guess if tree chains as a totally half-baked idea get air time there, they can't really hide behind 'we only accept quality, and Greg says your paper is not quality enough'.


I think your paper is by far the best work on orphan cost and all the central and fundamental limits in the Bitcoin system and so is IMO a *must* to be presented at the conference.

I could imagine that Gavin, though very non-confrontational in style, would say a word or two about your paper (not) being presented at the conference!

Does anyone understand tree-chains, who can ELI5? I've read the "papers" and they seem confused and full of practical impossibilities. For example, right in the first page:

So how can we do better? Start with the "big picture" idea and take the linear blockchain and turn it into a tree

It would be very hard to make the blockchain into a mostly-balanced tree -- you'd have to continually be reshuffling the blocks over a massive database of blocks consistently across all nodes in the network.


I've mostly baked a paper I'm calling "Distributed, Trustless, Merkle Tree Implementation and its Application to Cryptocurrencies" which solves scalability. You can probably figure out what I'm doing just by the title! But grafting it into Bitcoin would be a monster hard fork, essentially akin to creating a new cryptocurrency that uses the Bitcoin Blockchain as the initial distribution...

 

[cypherdoc]

Look, it's here. Bandwidth is and will not be a problem;

While business pricing varies based on the deployment, residents would pay about $400 a month for 10Ggbps service.

http://arstechnica.com/business/2015/09/city-run-isp-makes-10gbps-available-to-all-residents-and-businesses/

 

[cypherdoc]

100

https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki

 

[awemany]

@awemany the domain is registered through a proxy, because the Indian registry does not allow Whois privacy (.in is technically an Indian ccTLD). Citigroup is not involved with this site.

Thanks for the note! So did you just enter the Citigroup address into the registration form for fun and they accepted it or is the registrar housed in the same building as citygroup?

 

[lunar]

Mark your calenders, Sept 10th at 10am GMT. Stress
https://bitcoinmagazine.com/21842/coinwallet-begins-pre-test-bitcoin-network-schedules-largest-stress-test-begin-september-10/

Shortly followed by the scaling workshops on the 12th /13th. Some people might find it hard to make transactions at the conference.?

 

[cypherdoc]

interesting discussion going on re: 100

https://www.reddit.com/r/Bitcoin/comments/3jhnck/bip_100_technical_specification_initial_draft/