Gold collapsing. Bitcoin UP.

[freetrader]

you starting self-adjusting mechanism -without understanding how it will works and future, without calculations what it requires.
looks like opening blockchain for spamers/malicious/abuse - like pandora box ?

If you are talking about BU's "emergent consensus", please be clearer ... it seems then you have changed the subject away from Classic 0.12.

Does that mean you retract your claims about Classic inadequate performance?

If not, it comes across that you are scared that other miners might actually consider the potential of BU's consensual approach and find it to be viable, while you have strong reservations. I am not judging you because you are skeptical - it might just be that you lack full information about some things (e.g. Classic 0.12 testing)

You have mentioned some against the proposed Classic adaptive blocksize feature.

Do you have clearer arguments against BU's concept, or is it just a little fear?

I see it as diluting the power of larger miners to just enforce a rapid move away from the greater consensus formed by all users (miners + relay nodes + end user clients). So it should result in *more* stability and *more* justifications from any parties involved to persuade everyone to increase / decrease their settings.

 

[cypherdoc]

What mean's adaptive block-size ? shoot first then think about ? you starting self-adjusting mechanism -without understanding how it will works and future, without calculations what it requires.
looks like opening blockchain for spamers/malicious/abuse - like pandora box ?
Bitcoin is young economy, we should more balanced adjust, like the new car engine - it you just increase or just self-regulate, it may be risky.

p.s. Once again I'm not again block-size increase, but its should be done in more safe and balanced way. not like 1st jump, think later.

the mere fact that @Jihan is controlling his blocksizes via SPV mining is evidence that mining pools can control spam on their own even w/o a cap. that is eocnomics. not a technical issue.

 

[johnyj]

@johnyj

If the segwit softfork is activated, Unlimited and Classic nodes will not fork with respect to Core (at least they shouldn't but it appears some might ). That's why it's described as a soft-fork--nodes the don't support it still get carried along.

The only way we'll get an actual blockchain fork is if a >1MB block gets included into the longest chain and Core nodes still refuse to increase their block size limits.

Yes, in a hard fork, new version can not extend a separate chain without majority of hash power (their blocks will be orphaned), but in a soft fork, old version can not extent a separate chain without majority of hash power. So the minority hash power of old nodes in a soft fork will be forced to upgrade, otherwise blocks they mined will be orphaned. And this is the reason core prefer soft fork, since it has the ability to kill mining nodes with different opinion, more like a political tool of central steering committee (Unfortunately that plan failed during 2015July04 fork because of SPV mining, so it is not as secure as in theory)

But full nodes do not need to upgrade, they just become zombie nodes accepting any new blocks with "any one can spend" transactions from segwit net

 

[SysMan]

Peter Todd ‏@petertoddbtc 2m2 minutes ago
Classic tries to fix congestion by driving faster while Core builds mass transit and bigger, better roads. #lightning #libsecp #segwit

 

[Zangelbert Bingledack]

My thinking is that there are a lot of really undeserving and negative people with huge Bitcoin balances. I think the world is probably a lot better off if those people lose their disproportionate economic power.

Undeserving? Do you have any idea how hard it is to HODL through all the ups and downs in Bitcoin's history? See here to understand about power law distributions and the psychological difficulty of holding through million-percent growth, and here for why Bitcoin's mature ledger state is so important.

People who are pragmatic about cryptocurrency and not religious about the first version of it will be much more likely to see the handwriting on the wall a lot earlier.

The ledger would only need to be started over if there were something wrong with the ledger, not merely something wrong with the protocol that maintains that ledger.

 

[SysMan]

the mere fact that @Jihan is controlling his blocksizes via SPV mining is evidence that mining pools can control spam on their own even w/o a cap. that is eocnomics. not a technical issue.

Did you saw numbers about blocks sizes ? or I should quote it here once again ?
P.s. and now you should ask your-self who helps more for BTC community...

 

[cypherdoc]

@johnyj

no one ever refuted my initial attack proposition back when SWSF was first proposed a few mo ago. that is, if a miner like BTCC with it's know +100 FN's around the world were ever to attack the network by first adopting SW but then later initiating a large spend attack against another exchange or large balance address by first mining a block with the fraudulent tx, then transmitting that fraudulent block thru it's FN's that have been changed back to old code thus relaying the fraud tx b/c of the ANYONECANSPEND.

 

[freetrader]

Did you saw numbers about blocks sizes ? or I should quote it here once again ?
P.s. and now you should ask your-self who helps more for BTC community...

Were you in the room when Core reps sold miners on a promise of 100x revenue if they could suck transactions away onto the LN ?

Why is it that we have to learn about this from @Jihan first?

I think everyone could do with some calming down, and there is no need to lecture anyone here on block sizes, we can all find multiple nicely illustrated sources for statistics or look at our own blockchains.

Peter Todd lost all credibility with me when he posted this on the dev list, which you might care to comment on:

It'd be perfectly reasonable to create an altcoin with a 22-million-coin
limit and an inflation schedule that had smooth, rather than abrupt,
drops. It'd also be reasonable to make that altcoin start with the same
UTXO set as Bitcoin as a means of initial coin distribution.

If miners choose to start mining that altcoin en-mass on the halving,
all the more power to them. It's our choice whether or not we buy those
coins. We may choose not to, but if 95% of the hashing power decides to
go mine something different we have to accept that under our current
chosen rules confirmations might take a long time.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012507.html

I'm done with this subject until you argue factually w.r.t. the points that were made already.

 

[cypherdoc]

Did you saw numbers about blocks sizes ? or I should quote it here once again ?
P.s. and now you should ask your-self who helps more for BTC community...

how could i NOT see it? you've tweeted it more than a half dozen times.

pro-tip: don't criticize your signing partners if you expect them to honor your agreement.

btw, i do think it's an honorable thing to process tx's vs SPV mine, like you're doing. altho, there is a theory that states SPV mining is helpful in keeping avg blocksize down and in preventing orphaning both which helps the network.

 

[SysMan]

My thinking is that there are a lot of really undeserving and negative people with huge Bitcoin balances. I think the world is probably a lot better off if those people lose their disproportionate economic power.

People who are pragmatic about cryptocurrency and not religious about the first version of it will be much more likely to see the handwriting on the wall a lot earlier.

1st - I Just spot some negative man... wuops... Matt
2nd - Who disallow you to buy miners before ? to mine in 2012/2013/2014/2015 and now ? to build business own ? to _earn_ money ?

we not won it in lottery - its was very hard-work for everyone. We start from hobby investing our own money and brain power, working hard. for example chip design team, 8 ppls done work in 6 months vs 35 ppls team do same work 1.5 year, working 18-20 hours per day @ computers, without week-ends... its not about money - we start all this because we believe in bitcoin... its about results ! about willing to won ! we like BTC philosophy !

You want money steal money ? you want revolution ? you want reassign the founds - please create own coin - feel free. We will survive anyway - we are talented.

 

[VeritasSapere]

@SysMan Please do post numbers here, as far as I understand it, increasing the blocksize to two megabytes is perfectly safe. We can increase the blocksize as technology progresses, it is irrelevant who has helped the Bitcoin community more, what matters is the content and the merit of the client we choose to run, who created it is actually irrelevant being open source software.

The idea behind an adaptive blocksize is that the blocksize limit will always be above the average transaction volume, since as @sgbett pointed out most of us here are of the school of thought that the blocksize limit is self limiting by the miners, creating a free market for blockspace as opposed to the "fee market" by Core. The adaptive blocksize limit essentially allows the blocksize limit to serve as an anti spam measure as was always intended as opposed to it becoming an economic policy tool which will have to be adjusted over time.

 

[SysMan]

how could i NOT see it? you've tweeted it more than a half dozen times.

pro-tip: don't criticize your signing partners if you expect them to honor your agreement.

btw, i do think it's an honorable thing to process tx's vs SPV mine, like you're doing. altho, there is a theory that states SPV mining is helpful in keeping avg blocksize down and in preventing orphaning both which helps the network.

Ok may be it when time to calculate block time delays on release ? just do it, fill free...
SPV is pure benefit there are nothing about network safety, avoid orphans or similar... just monetary profit.

 

[cypherdoc]

whoever ran the Bitfury account on BCT in 2013 is a genius. i used to follow his dev threads and they were remarkable. i, in fact, bought several of the first generation BF boards back then. @SysMan is right, Bitcoin is about POW and real work, ie, sweat labor. that's what helps prevent 51% attacks by state actors. but Bitcoin is also about understand economics and game theory, which is what alot of the current miners don't seem to have a good handle on. that's why we're in the mess we're in right now.

 

[Peter R]

Yes, in a hard fork, new version can not extend a separate chain without majority of hash power (their blocks will be orphaned), but in a soft fork, old version can not extent a separate chain without majority of hash power. So the minority hash power of old nodes in a soft fork will be forced to upgrade, otherwise blocks they mined will be orphaned. And this is the reason core prefer soft fork, since it has the ability to kill mining nodes with different opinion, more like a political tool of central steering committee (Unfortunately that plan failed during 2015July04 fork because of SPV mining, so it is not as secure as in theory)

But full nodes do not need to upgrade, they just become zombie nodes accepting any new blocks with "any one can spend" transactions from segwit net

Sorry, @johnyj, I misread your post and thought you were talking about nodes. Yes, all miners will have to support segwit once the soft-fork is activated or risk having their blocks orphaned (e.g., should those blocks include transactions that are valid pre-segwit but invalid post-segwit). Sorry for the mixup.

 

[VeritasSapere]

@SysMan If you are referring to block propagation times you might want to check out Xthin which increases block propagation speeds for mining by a factor of fifteen. This in itself justifies a blocksize increase if that is one of the main reasons for not increasing the blocksize limit for some people. Especially considering the economic advantages of doing so.

https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/

 

[Christoph Bergmann]

Peter Todd ‏@petertoddbtc 2m2 minutes ago
Classic tries to fix congestion by driving faster while Core builds mass transit and bigger, better roads. #lightning #libsecp #segwit

It' more like you're on the highway driving 40 mph and come late to a date. Classic says "let's speed up to 60 mph NOW" while core says: "A car was never made for driving fast. We'll make the car fly!"

// those analogies suck.

// the only teams building bigger roads are currently Unlimited (thinblocks) and classic in plans (see the roadmap).

// for you, SysMan: It's not about Core (team) vs Classic (team). That's a construction, similar when a politician says: My way or I step back. The truth is - it's about one single decision: scaling onchain vs. scaling not onchain.

 

[Peter R]

@SysMan

I was very happy to see that you've joined this forum!

The only thing I want to add to @cypherdoc's points here is to stress that we wouldn't be "firing Core" and "all moving to Classic." Classic is just a vehicle to voice our preference for larger blocks. Once the Classic hard fork looks inevitable, either:

(1) Core will make a change so that Core nodes track consensus,

OR

(2) The majority of developers currently working under the "Core brand" will join Classic, Unlimited, or form new projects.

If you don't want to run Classic, then why not just recompile your Core nodes so that they produce version 0x30000000 blocks (and thus count towards 2MB activation)? If the hard fork activates, then during the 28-day grace period you could upgrade to remain compatible with consensus.

 

[SysMan]

@SysMan Please do post numbers here, as far as I understand it, increasing the blocksize to two megabytes is perfectly safe. We can increase the blocksize as technology progresses, it is irrelevant who has helped the Bitcoin community more, what matters is the content and the merit of the client we choose to run, who created it is actually irrelevant being open source software.

The idea behind an adaptive blocksize is that the blocksize limit will always be above the average transaction volume, since as @sgbett pointed out most of us here are of the school of thought that the blocksize limit is self limiting by the miners, creating a free market for blockspace as opposed to the "fee market" by Core. The adaptive blocksize limit essentially allows the blocksize limit to serve as an anti spam measure as was always intended as opposed to it becoming an economic policy tool which will have to be adjusted over time.

Numbers are here
http://bitfury.com/white-papers-research
Page 4 calc, (very-optimistic aka lower)

2Mb is almost safe, but we need improvements in bitcoind. some of them will affect multiple response time for example bitcoind 0.8.6/0.10x - rpc response time on 2MB blocks operations may vary from 3-45 seconds. for 4Mb - same operations from 8-600+sec rpc timeout... also grow p2p traffic, disk i/o locks, many others param's.
0.12 perform much better. there a lot of similar locks on multiple levels, we can fix them no doubt, just more we should be more accurate and safe on fixing them, before each new step.

 

[sgbett]

1st - I Just spot some negative man... wuops... Matt
2nd - Who disallow you to buy miners before ? to mine in 2012/2013/2014/2015 and now ? to build business own ? to _earn_ money ?

we not won it in lottery - its was very hard-work for everyone. We start from hobby investing our own money and brain power, working hard. for example chip design team, 8 ppls done work in 6 months vs 35 ppls team do same work 1.5 year, working 18-20 hours per day @ computers, without week-ends... its not about money - we start all this because we believe in bitcoin... its about results ! about willing to won ! we like BTC philosophy !

You want money steal money ? you want revolution ? you want reassign the founds - please create own coin - feel free. We will survive anyway - we are talented.

Can't argue with that I hope you keep it up. I've always thought that the people at the head of mining operations are uniquely positioned to understand the risk profile.

What I mean by that is that it's easy for me to say yeah you should just switch to this or that. The amount at stake is much less. So I understand why you and others would be much more cautious.

I don't think anyone here is going to necessarily sway you with arguments. I think each miner will come to their own conclusions in there own time. I wish it were sooner, but I'm patient

 

[SysMan]

@SysMan

I was very happy to see that you've joined this forum!

The only thing I want to add to @cypherdoc's points here is to stress that we wouldn't be "firing Core" and "all moving to Classic." Classic is just a vehicle to voice our preference for larger blocks. Once the Classic hard fork looks inevitable, either:

(1) Core will make a change so that Core nodes track consensus,

OR

(2) The majority of developers currently working under the "Core brand" will join Classic, Unlimited, or form new projects.

If you don't want to run Classic, they why not just recompile your Core nodes so that they produce version 0x30000000 blocks (and thus count towards 2MB activation)? If the hard fork activates, then during the 28-day grace period you could upgrade to remain compatible with consensus.

I'm realist - I listen carefully what other ppls are wrote/say...
there is couple of other aspects outside the technical level from "classic" what make me worry about.
/ block version(I know how it seriously impact the core code, and all version control ideology) and other tech issues looks like just brave small issues out of concept sometime, but that's almost ok/

If we talking just about pure block-size increase and the same offer about HF will be from CORE - then I'm almost 90% in, but I hate politics behind the classic scene, this - makes me worry about...
my IMHO classic is not about block-size changes, its looks more about control...