Gold collapsing. Bitcoin UP.

[theZerg]

@awemany I have started fooling around in my own fork of Core.

However, there are some issues:

1. Somebody else created a BitcoinUnlimited organization in GitHub and did quite a bit of clerical work rebranding XT to to BU. It would be great if that person could identify, introduce him/herself, and join this conversation officially.

2. We don't know what we are doing. There are 3 proposals out there:
a) Just unlimited
b) force user to initially configure
c) unlimited by default, but user can configure
d) beginning discussion of a transport policy plugin architecture

Before getting formally started, I want some small document saying THIS is what Bitcoin Unlimited will be and broad agreement. Because (for all you non-engineers out there) it takes (say) 10x the time to actually DO it than say it.

3. What if the guy who grabbed github BitcoinUnlimited says "no" I don't want that to be in BU? What if the guy who grabbed bitcoinunlimited.com/.org/.info says "no" to this other change? What if this does not happen today, but 6 months from now.

If you really don't want the devs to have all the power here, I think that its more important for us to get organized than for us to deliver a feature.

 

[Erdogan]

Just make a simple clone of core, remove limit. After that, add changes from core as they come.

 

[Mengerian]

Thanks for the Hat Tip @Peter R !

Your diagram looks great.

By the way, did you read my more recent post on the subject in this thread? https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-33#post-1101

I think I've shown that we can get rid of the block reward term in the formulas, by substituting R/T with ηH.

 

[sickpig]

this is priceless

https://github.com/bitcoin/bitcoin/pull/6622#issuecomment-137490859

 

[Peter R]

By the way, did you read my more recent post on the subject in this thread? https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-33#post-1101

I think I've shown that we can get rid of the block reward term in the formulas, by substituting R/T with ηH.

Yes, I agree with both of your graphs (that there would come a transition point where the hashing cost > block reward and thus we should see the emergence of the mining gap as depicted in my last chart).

However, I haven't been able to wrap my head around your proposed substitution. Perhaps I need to think more about it.

 

[AdrianX]

@sickpig just amazing I'd think if he wanted good VOIP quality he'd enable Quality of Service (QoS) setting on his router to priorities VOIP over Bitcoin.

It seems asinine to suggest adding a user controlled limit to manage bandwidth when the user has that ability tied to the service they pay for.

Makes me think users limiting the block size is a similar idea. (Don't like big blocks run a trimmed node or don't run a node) don't insist on crippling the network.

 

[cypherdoc]

@AdrianX

these are reasons why i've come around to @rocks idea.

one step at a time; just remove the limit. that stands the greatest chance for acceptance with the community. if it's successful, there will be plenty of individual opportunities to add in good ideas.

 

[AdrianX]

this is priceless

https://github.com/bitcoin/bitcoin/pull/6622#issuecomment-137490859

jonasschnelli
about 1 month ago
Agree with @gmaxwell. I think we should reconsider that people shutting down nodes because nodes do create uncontrollable heigh amount of outbound traffic. If we could keep nodes alive – even if they don't server historical and filtered blocks for a limited timeframe – it's much better than seeing nodes get shut down because of missing traffic limiting options.

Not saying that this is the ultimative solution. But i think it's effective and can be merge without taking high risks

Reading further it's crazy Core Developers suggestions a centralized controle system to limit bandwidth usage so non viable nodes don't need to upgrade. (QoS or update your ISP. My ISP adds 50% capacity to the second most viable plan every year. If you don't call them and ask to be upgrade they charge the old higher price for less service.)

Core shouldn't be in the business of managing consumer behavior.

 

[AdrianX]

https://www.reddit.com/r/Bitcoin/comments/3qauv4/maxuploadtarget_for_bitcoincore_just_got_merged/

So.... "just in" noticed this on reddit - we can't get consensus on increasing the block size but merging in a change to limit bandwidth is accepted with little resistance - Core's consensus and decision making process looks a little broken to me. Reading the discourse in that earlier thread - Mike H is ignored and the developers just do whatever they want.

Good news Luke-Jr can now make clear VOIP calls without adjusting the setting on his router and central control can set a default at will. Maybe it's time for some profit taking.

 

[cypherdoc]

/u/fuckotheclown lol!

 

[cypherdoc]

wow. great news.

we knew about this but i don't recall hearing that 3M was involved:

http://investors.3m.com/news/press-release-details/2015/3M-Novec-7100-Fluid-Used-in-Worlds-Largest-Two-Phase-Immersion-Cooling-Project/default.aspx

 

[sickpig]

@sickpig just amazing I'd think if he wanted good VOIP quality he'd enable Quality of Service (QoS) setting on his router to priorities VOIP over Bitcoin.

It seems asinine to suggest adding a user controlled limit to manage bandwidth when the user has that ability tied to the service they pay for.

Makes me think users limiting the block size is a similar idea. (Don't like big blocks run a trimmed node or don't run a node) don't insist on crippling the network.

if you're interested in more dev madness just have a look to the last PR made by Gavin 3 days ago:

https://github.com/bitcoin/bitcoin/pull/6880

eventually Gavin simply close it, just to avoid a bike shedding storm that was forming.

regardless you should watch(*) Bitcoin core repo for a few days, it gives quite a lot of insightful details on the status of the "affairs".

to make a long story short: from the outside it seems that you have to belong to the holy circle if you want your code contributions move smoothly into the tree.

and what happens if you don't belong to it? well, prepare yourself to endless criticism, nit picks and if your particularly unfortunate multiple lessons imparted by Greg. At that point you should rest assured, your code won't go in.

(*) "watch" in the github way. it clutters your inbox with tones of email but it's worthy IMHO, at least temporarily.

 

[Justus Ranvier]

regardless you should watch(*) Bitcoin core repo for a few days, it gives quite a lot of insightful details on the status of the "affairs".

If you start encouraging too much sunlight (as in it being the best disinfectant) you'll be accused of inciting an internet mob and Nick Szabo will start posting pictures of the Challenger blowing up on Twitter again.

 

[Mengerian]

However, I haven't been able to wrap my head around your proposed substitution. Perhaps I need to think more about it.

I arrived at the substitution simply by solving equation (5) in your paper, setting profit to zero. Just doing that and working through the math will yield similar equations to yours, but with ηH appearing where your equations have R/T. I did not use any calculus.

It also makes sense intuitively. Think about it this way: ηH and R/T are both values in bitcoins per unit time. ηH is the cost per unit time to produce the total hash rate of the network ignoring orphaning risk, i.e., for empty blocks. R/T is the revenue for per unit time, also for empty blocks. So it makes sense that they are related in some fixed relation accounting for return on capital for miners.

The hashing cost per block is ηHT, so the "production cost" curve should intersect the y-axis at ηHT (where you have written "hashing cost"), and curve up to the right accounting for orphaning risk. The equation for the production cost curve, as you've drawn it, is M=ηHTe^(τ(Q)/T).

Similarly, your "available revenue" curve hits the y-axis at R, where you have labelled "Block Reward".

 

[awemany]

Just make a simple clone of core, remove limit. After that, add changes from core as they come.

I believe the mandatory configuration option for blocksize is doing essentially that, but with the added benefit that it probably boils down to the least amount of changes in the code paths checking for consensus. I believe that changing the value of a variable that is tested for in various locations is an even more careful change than removing those checks altogether.

That said, I would, however, be fine to also support BU w/o any limit as I believe in compromise more than consensus
[doublepost=1445901472][/doublepost]

@awemany I have started fooling around in my own fork of Core.

However, there are some issues:

1. Somebody else created a BitcoinUnlimited organization in GitHub and did quite a bit of clerical work rebranding XT to to BU. It would be great if that person could identify, introduce him/herself, and join this conversation officially.

2. We don't know what we are doing. There are 3 proposals out there:
a) Just unlimited
b) force user to initially configure
c) unlimited by default, but user can configure
d) beginning discussion of a transport policy plugin architecture

Before getting formally started, I want some small document saying THIS is what Bitcoin Unlimited will be and broad agreement. Because (for all you non-engineers out there) it takes (say) 10x the time to actually DO it than say it.

3. What if the guy who grabbed github BitcoinUnlimited says "no" I don't want that to be in BU? What if the guy who grabbed bitcoinunlimited.com/.org/.info says "no" to this other change? What if this does not happen today, but 6 months from now.

If you really don't want the devs to have all the power here, I think that its more important for us to get organized than for us to deliver a feature.

I think one of the users who started to use the name Bitcoin Unlimited is /u/seweso on reddit. I just PMed him and asked him to come over here. Incidentally, he made me a mod for /r/bitcoin_unlimited on reddit. Let's hope we can coordinate things.

 

[Peter R]

There's a @seweso already on this forum too.

 

[cypherdoc]

I believe the mandatory configuration option for blocksize is doing essentially that, but with the added benefit that it probably boils down to the least amount of changes in the code paths checking for consensus. I believe that changing the value of a variable that is tested for in various locations is an even more careful change than removing those checks altogether.

That said, I would, however, be fine to also support BU w/o any limit as I believe in compromise more than consensus
[doublepost=1445901472][/doublepost]

I think one of the users who started to use the name Bitcoin Unlimited is /u/seweso on reddit. I just PMed him and asked him to come over here. Incidentally, he made me a mod for /r/bitcoin_unlimited on reddit. Let's hope we can coordinate things.

great to see you back @awemany. esp since you were one of the original proposers of the BU idea.

some of the concerns with the configurable setting is the unknown complexities of such a thing. @rocks has elucidated some of them and i worry about them as well. my main goal is introducing an option that has the greatest chance of acceptance by the community. the experience with XT imo is that the community worries greatly about any change to the code that might introduce unpredictability. this is understandable. in that vein, the fewer the changes, the better. also, personal projects also introduce worry. those are to be avoided.

this would be the thinking and reasoning for simply lifting the limit in BU and leaving it at that. one could then simply make the argument that we are returning the code back to Satoshi's original vision and no more. that would avoid any pretences of COI and complexity.

 

[cypherdoc]

it's time for fiat to be diverted into the currency unit itself:

 

[ladoga]

this is priceless

https://github.com/bitcoin/bitcoin/pull/6622#issuecomment-137490859

I have to wonder why doesn't he limit bitcoin traffic with QoS on his router and give higher priority to his VOIP calls.

For example: http://wiki.openwrt.org/doc/uci/qos

 

[sickpig]

Anthony Towns (http://www.erisian.com.au/wordpress/) just post a mail on LN and fees on LN dev mailing list:

http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000289.html

It's quite lengthy but worth reading. He says think that I agree with:

"lightning depends on the security of the blockchain to be functional, but the blockchain will eventually rely on transaction fees to be secure, so lightning had better leave sufficient transactions for the blockchain!"

and others which I don't:

"If blocks were unlimited, miners would accept every transaction, no matter how small the fee (2), which would set the per-tx fee to ~1 satoshi (3). Rational miners will thus limit the number of txs they accept (1) to ensure fees don't go to zero."

regardless I liked his analytical approach.