Gold collapsing. Bitcoin UP.

[pekatete]

They definitely are desperate to remain relevant but I am afraid those are the last kicks of a dying horse (look, even the price is wobbling ....).

 

[AdrianX]

I have already explained that without a limit the economics can break down. It appears you have an ideological attachment to the idea of a "free market", even in this very niche and specific situation when it is not relevant.

you haven't explained how without a limit the economics can break down. You're implying a tragedy of the commons, while ignoring a competitive free market exists where those miners who manage the block space responsibly profit more than those who dont.

I understand how you feel about this but I cant take you seriously when you're proposing we need a 95% consensus to change the limit and those who have misguided feeling can hold up the consensus process.

 

[sickpig]

... I cant take you seriously when you're proposing we need a 95% consensus to change the limit and those who have misguided feeling can hold up the consensus process. -- @AdrianX

what's worse is that if you're able to convince miners to follow you, consenus rules can be change at will with a superminority as long as you are able to deploy your code changes via soft forks.

the proof is that SegWit, among other things, will increase the max block size limit.

 

[lunar]

"The meeting also comes ahead of the next instalment of Scaling Bitcoin in October."....

How did it go again in Montreal ? Nothing will be agreed upon here, submit ideas and we'll wait till Hong Kong?

Let me guess the outcome of this 'Meeting'?

I say meeting becasue it sounds more like an intervention, pressgang or straight up ambush.

I mean really at this point what the actual f*ck is there left to discuss?

We need an independent observer present, and probably a professional psychiatrist.

 

[cypherdoc]

... I cant take you seriously when you're proposing we need a 95% consensus to change the limit and those who have misguided feeling can hold up the consensus process. -- @AdrianX

what's worse is that if you're able to convince miners to follow you, consenus rules can be change at will with a superminority as long as you are able to deploy your code changes via soft forks.

the proof is that SegWit, among other things, will increase the max block size limit.

great presentation Andrea! 20MB possible today? wow. whodathunk.

btw, any news on that SW hold up?

 

[Tomothy]

Is there any truth to Blockstream Employees having bonuses stuck on 'this' bitcoin path which would be lost if a hardfork occurred prior to the terms of those transactions having been met? And, re Nullc, anyone know what he wants with Zander? Does anyone know who is going to this Miner/Core meeting where they are not going to discuss scaling? Which seems odd, because it looks like the miners want to talk about scaling...


Is the quote from Jstolfi referencing something about the bstream coins.

 

[cypherdoc]

[doublepost=1468874325][/doublepost]

Is there any truth to Blockstream Employees having bonuses stuck on 'this' bitcoin path which would be lost if a hardfork occurred prior to the terms of those transactions having been met? And, re Nullc, anyone know what he wants with Zander? Does anyone know who is going to this Miner/Core meeting where they are not going to discuss scaling? Which seems odd, because it looks like the miners want to talk about scaling...


Is the quote from Jstolfi referencing something about the bstream coins.

yeah, i'm pretty sure. /u/nullc alluded to it once. won't be able to find it though.

 

[Tomothy]

Thanks, I thought this was the case, but I haven't been able to independently confirm it. I'll keep looking. If the goal was to prevent an increase in bitcoin value prior to a set deadline your handlers had established; what better way then to bind compliance through compensation.

 

[AdrianX]

This point keeps being made. You keep mentioning that the absolute level of orphan risk is low or insignificant. I keep mentioning this is not at all what I am talking about. When you keep mentioning this irrelevant point it gets quite frustrating. I will try to remind you again what I am actually talking about.

I am concerned about the following scenario:

• The block reward is insignificant
• There is no blocksize limit
• Orphan risk costs are used to drive mining fee revenue, in the sense that:
  • Miners keep including more and more transactions in a block up to the point where the fee equals the marginal orphan risk cost, for the most marginal transaction in the block
    
  • Advanced wallets lower the fee to the point where they pay a slight premium over the expected orphan risk cost

In this scenario I am concerned about the following ratio:

• Orphan risk cost / miner fee revenue

In what I consider to be a flawed model, where orphan risk drives the mining revenue, this ratio should be well over 50%, which I consider catastrophic for the network.

@jonny1000 No, I was responding to the argument you were making at the time, that the advantage you get from having a large mining pool that minimizes your orphan risk relative to other competitors I was making the point that it is insignificant. You keep saying it will cause centralization, if that's true and it's not insignificant quantify it?

My feeling are getting frustrated too, so lets move on to your new scenario - now that your old one is mute.

• Miners keep including more and more transactions in a block up to the point where the fee equals the marginal orphan risk cost, for the most marginal transaction in the block
  
• Advanced wallets lower the fee to the point where they pay a slight premium over the expected orphan risk cost

So you are saying that a big miner with 50% hashing power is going to run at a marginal operating cost of about 0.2% profit to stay competitive in order to out compete the rest of the miners and thus grow bigger.

While I think that concern is a legitimate one, it's not one I believe Core developers need worry about changing the bitcoin protocol or limiting block size to mitigate.

There are enough actors in the market on both the supply (priority transaction premium) and demand (processing transactions competition) to prevent that from happening.

Your concern is nothing to get frustrated about, even if miners formed a cartel to manage fees it would never hold as soon as it's more profitable to deviate miners will break from the cartel.

That said, there is one legitimate concern and the Core Developers are ignoring it. In fact they are even developing and driving the bitcoin protocol towards it, and that is if the cartel had to form around propagating blocks outside the bitcoin network and use an off chain network like the Relay Network, then yes it would be a concern. However I dont see how limiting block size could mitigate that.

Gavin has a mitigation plan that will work with his headers first proposal. however Core do not, it seems they are actively developing bitcoin in that direction by putting the relay network on there road map. Core should be researching ways to make only relaying blocks through the bitcoin network possible as a priority.

 

[freetrader]

oh heavens, what a waste of time. and which of the kore devs has the time & money to host a wine & dine event for miners?

A little wine and dine always goes a long way to easing tensions.
This is not their first date.

I'm waiting to see if Junseth and Chris DeRose will be attending with a similar 0-fucks-given attitude as at the Roundtable.

@jonny1000 , are you going to happen in on this?

BitcoinBerg 2016 FTW!

As for how the community may be able to follow the event, organizers said that some materials will be made available to the public in an effort to increase transparency.

Organizers said that transcripts of the event without attribution will be available following the event.

"You are free to take your own written notes and use and the information received but you must not record the identity of any speaker and give no attribution to any ideas or concepts," the materials said.

Kiss, but no tell!

 

[cypherdoc]

how many contradictions can you find here?

http://news.hodlhodl.com/news/55
[doublepost=1468875832][/doublepost]

A little wine and dine always goes a long way to easing tensions.
This is not their first date.

if i were @Jihan and other Chinese miners, i'd cancel my reservation. after what the dipshits pulled and what appears to be a core dev that has been shunned by most of the community?

 

[AdrianX]

Is there any truth to Blockstream Employees having bonuses stuck on 'this' bitcoin path which would be lost if a hardfork occurred prior to the terms of those transactions having been met? And, re Nullc, anyone know what he wants with Zander? Does anyone know who is going to this Miner/Core meeting where they are not going to discuss scaling? Which seems odd, because it looks like the miners want to talk about scaling...


Is the quote from Jstolfi referencing something about the bstream coins.

GMax talks like his Blockstream Bitcoin bonus is tied to their work, and I've posted here log ago a similar observation after chatting with u/nullc I dont think it's far fetched, they probably programmed the transactions themselves as good faith to their overlords and to show commitment.

 

[taxed4ever]

@cypherdoc

Keep the reservation and then right ripp into them

When someone tries to scam me, I let them play right into my hands, it never ends well for them.

Less than 2 weeks until Core is irreverent, finally the madness will come to an end.

 

[cliff]

[doublepost=1468874325][/doublepost]
yeah, i'm pretty sure. /u/nullc alluded to it once. won't be able to find it though.

IIRC, there was a time-lock on BS employee compensation - sort of like a deferred compensation scheme. Initial info about it was the first answer BS provided to initial conflict of interest concerns. specifically, they'd say:

'no, no - there's no conflict of interest because if we do anything to hurt the price of bitcoin, we lose.'​

Of course, the time-lock is totally irrelevant to whether there is a conflict of interest from a legal and biz disclosure POV, but the irrelevance is not a revelation about BS since we can't really expect them to know everything about everything. What might be interesting is whether the explanation about the time-lock deferred compensation vis-a-vis a conflict of interest is why that technique was actually embraced. In other words, is the public explanation different than the private understanding? If so, why?

 

[cypherdoc]

great stats:

http://organofcorti.blogspot.com/2016/07/july-17th-2016-bitcoin-network.html

 

[Christoph Bergmann]

I totally agree. I am perfectly fine with kicking the can down the road several years. I am totally fine with 2MB of non witness data now. However that is also why I opposed XT so strongly, because locking in 8GB now is not sensible either. [b[Now that we agree with this, please can we work to get 2MB in a collaborative way and end the unnecessary and divisive confrontation?[/b]

May I ask why you discuss with this thread for more than a month when both people here and you prefer the same solution for the same problem - bumping to 2 mb? Wouldn't it be more constructive to discuss with that people that hold this solution back?

Just want to ask, since I don't get this.

 

[sickpig]

great presentation Andrea! 20MB possible today? wow. whodathunk.

btw, any news on that SW hold up?

thanks @cypherdoc!

yeah 20MB is pretty impressive, especially taking into account that the bitcoind network stack is not the best piece of software I've ever seen /euphemism.

By the way the lion share here goes to @Peter Tschipper and @theZerg, I merely helped with the testing step.

Speaking of SegWit, I'm not following its development as close as I want to (a lot of non bitcoin tasks is keeping me busy), but from what I can see there's no significant progress on both issues, namely O(n^2) hash sign and mempool DoSing.

 

[cliff]

interesting re-reads:


https://www.reddit.com/r/Bitcoin/comments/37vg8y/is_the_blockstream_company_the_reason_why_4_core/

 

[Inca]

thanks @cypherdoc!

yeah 20MB is pretty impressive, especially taking into account that the bitcoind network stack is not the best piece of software I've ever seen.

By the way the lion share here goes to @Peter Tschipper and @theZerg, I merely helped with the testing step.

Speaking of SegWit, I'm not following its development as close as I want to (a lot of non bitcoin tasks is keeping me busy), but from what I can see there's no significant progress on both issues, namely O(n^2) hash sign and mempool DoSing.

Link to the presentation?

 

[AdrianX]

@Christoph Bergmann I'm not talking for @jonny1000 but I do follow this thread and this is how I understand it. Although I don't start off most of my replies with how frustrating it is talking with jonny1000 I would like to express my feelings on the matter before replying in this case because it is some what frustrating.

I am going to paraphrase Jonny1000 when I say he would like to fork to 2MB as soon as practical however he believes we need 95% consensus to do so.

He has said that the resistance to the existing 2MB fork is fundamentally based on principal and that many developers would consent to it if it wasn't such a political issue.

He has pleaded with us using very kind language to stop supporting Classic or alternate forks to 2MB and he believes that as soon as we stop putting pressure on developers to fork to 2MB that they will consent to a 2MB fork.

It's worth noting that it's irrelevant that the developers opposed to the existing 2MB fork or any 2MB fork for that matter because they have no say in that 95% consensus he advocates as the vote only includes that of the miners that are under their influence.

So in all practicality he is asking us to stop supporting decentralized development and follow the advise of the centralized development BS/Core team by succumbing to political pressure so they may stop blocking the 2MB fork on principal and advise their clients (the miners) that they will in fact move to a 2MB fork.

So you may be able to see how frustrating it is for me knowing it's my support for a 2MB fork that's actually blocking the 2MB fork. And the irony is I dont support a 2MB fork, more over I support decentralized control over the bitcoin protocol and in time as understanding permits gradually removing the limit altogether.