So who the hell is still supporting BU?

[franky1]

lauda do you think that dynamic blocksizes are untested?

ok here is somenews for you

2009-2016

there was the 1mb rule right.
but did you know that pools had a variable which until recently was set at or below 0.75mb

yep even though the consensus rule was 1mb.. the pools had a dynamic variable below that which incremented over the years

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h

Code:

/** Default for -blockmaxsize, which controls the maximum size of block the mining code will create **/
static const unsigned int DEFAULT_BLOCK_MAX_SIZE = 750000;

in older versions it was called MAX_BLOCK_SIZE_GEN
which in version 0.7 (which sipa screwed up when he tweaked 0.8 ) the

Code:

static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;

(0.5mb)
pools now have this setting set to 0.999mb but this 'policy' was infact dynamic.

even now the devs can happily play with the setting all they like blow the upper limit..

EG in 2013, there was a bug caused by Sipa.
they had a choice either
keep blocks below a 'policy'(MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;) of 0.5mb and fix the issue later meaning todays 'we need more' drama would have happened in 2013 and devs screaming doomsday if blocks went passed a 0.5mb policy limit. (even with the 1mb consensus limit)
or
they looked at the cause of the orphans risks, and then allowed blocks to grow beyond it.

guess what happened.. (hint: we are not at 0.5mb after 2013 event)

yep thats right from 2009-2016 we had a large upper limit and then a dynamic limit below it.

the problem now is the dynamic limit is at the upper limit. so the upper limit needs to be moved.

[1714049803]

1714049803

[1714049803]

1714049803

[hv_]

Sadly bitcoin is far of having ANY proper testing, integration staging as you know from big style software devs for banking, insurance, industry...

We only have some test net, but this is close to some dev playground.

A really needed UAT net is completely missing, where other than devs are doing proper user acceptance testing and these have to be as close as possible done in productive like conditions to find out about bugs or other things that might go wrong after deployment into production.

Even having this all in place nothing can be as similar as the real world = production and more issues will pop up thats 100% sure (seen in every Windoof release).

Having comprehended this you can get the Problem with SW (tested ?, but complex) and some simple change to the max block limit (could be done by reducing 1 line of code - very nice and very Austrian!)

We might need both this time to get along and compromise, but we HAVE to move, or others move:

https://mobile.twitter.com/ErikVoorhees/status/830197808573587457

You might need to go back to playground and watch what happens when 2 are fighting
A third will come and grep all the nice toys.

[Lauda]

lauda do you think that dynamic blocksizes are untested?

That's not exactly a dynamic block size and you should know this.

Sadly bitcoin is far of having ANY proper testing, integration staging as you know from big style software devs for banking, insurance, industry...

Bitcoin Core has extensive testing and peer review. You can't make statements about "bitcoin is far from having". You're generalizing Bitcoin as an single entity that can be 'tested'.

We only have some test net, but this is close to some dev playground.

No.

A really needed UAT net is completely missing, where other than devs are doing proper user acceptance testing and these have to be as close as possible done in productive like conditions to find out about bugs or other things that might go wrong after deployment into production.

You can join the testnet at any time, and nightly builds are constantly being provided with the latest changes.

Having comprehended this you can get the Problem with SW (tested ?, but complex) and some simple change to the max block limit (could be done by reducing 1 line of code - very nice and very Austrian!)

Changing the block size with current != 1 line of code. As an example, first look at the HF proposal in Bitcoin Classic. With BU this becomes even worse with thousands of lines of code.

[franky1]

extensive testing and peer review.

your reading a script
think logically

litecoin has extensive testing and peer review. right!
does that mean we should throw litecoin keypairs into bitcoin and then block nodes that dont understand these new keypairs that enter the bitcoin code.
... no

until you see a segwit keypair being used within the bitcoin main net. you know nothing.
research this
“anyone can spend”

please spend time reading it.

here use the link that YOU provided but failed to read passd the 6th paragraph
https://bitcoincore.org/en/2016/10/28/segwit-costs/

use the browsers 'find' function for “anyone can spend”

and you will see why segwit nodes are setting themselves up as the gate keepers (upstream filters) and only whitelisting native nodes as downstream nodes(if they white list at all)

Miners could simply use software that does not recognise segwit rules (such as earlier versions of Bitcoin Core) to mine blocks on top of a chain that has activated segwit. This would be a hard-fork as far as segwit-aware software is concerned, and those blocks would consequently be ignored by Bitcoin users using segwit-aware validating nodes. If there are sufficiently many users using segwit nodes, such a hard-fork would be no more effective than introducing a new alt coin.

if native bitcoin nodes made a block.. its treated as an attack on segwit. even if the block is valid.

its not propaganda if its something YOU provided but YOU fail to understand.

research. read. learn. understand.
fail to, just leads to your opinion on things you dont know, being meaningless.


also thanks to _hv
https://medium.com/@DCGco/scaling-bitcoin-reflections-from-the-dcg-portfolio-35b9a065b2a4#.k125iopmo

DCG
has ownership stake in
coinbase, btcc, bitpay, blockstream, and many dozens of bitcoin entities..
they concluded that they are on the fense because they are waiting..
they state that only the core devs have been playing around with segwit on testnet not independently reviewed by all the different independent nodes/community


lastly. it was me. before segwit even got tested on the testnets i stated that there was a bug in segwit.
yep back as far as april last year i have highlighted the issue.
and it was me that caused devs to rethink their strategy and lead to them realising that segwit is not 'backward compatible'

but instead of them fixing this. they decided that after activation. they would bilateral split the network so that native bitcoin nodes cant attack this bug because they are thrown into an altcoin, or downgraded into not being a upstream node or allowed to even make a block in the network.
(facepalm)

[hv_]

lauda do you think that dynamic blocksizes are untested?

That's not exactly a dynamic block size and you should know this.

Sadly bitcoin is far of having ANY proper testing, integration staging as you know from big style software devs for banking, insurance, industry...

Bitcoin Core has extensive testing and peer review. You can't make statements about "bitcoin is far from having". You're generalizing Bitcoin as an single entity that can be 'tested'.

We only have some test net, but this is close to some dev playground.

No.

A really needed UAT net is completely missing, where other than devs are doing proper user acceptance testing and these have to be as close as possible done in productive like conditions to find out about bugs or other things that might go wrong after deployment into production.

You can join the testnet at any time, and nightly builds are constantly being provided with the latest changes.

Having comprehended this you can get the Problem with SW (tested ?, but complex) and some simple change to the max block limit (could be done by reducing 1 line of code - very nice and very Austrian!)

Changing the block size with current != 1 line of code. As an example, first look at the HF proposal in Bitcoin Classic. With BU this becomes even worse with thousands of lines of code.

Sigh

You just dont want to get it?

Who needs to do UAT testing?

Me?

Hahhaaaa

Miners need to do and in depth, they have Millions at risk.

Common youre not that slow.

[hv_]

Here comes what I assume a compromis could look like.


Given the fact there was an agreement about 8 Mb is fine for all and the calcs I ve seen for SW might using up to 4 Mb there is space for an increase by 4  MB for the MAX BLock Size upper limit.

I guess there you d get more votes for and majority for tesing ?

And SW allone is already tested ( by devs).

And yes it is a HF, but I assume all would be fine with this since it is a compromis.

[franky1]

8 Mb is fine for all and the calcs I ve seen

yep 8mb is safe for "raspberry Pi" based min specs.
where a 32mb was a old benchtest (normal pc) done years ago where dataloss 'could' start to occur. (protocol limit (above consensus limit(above policy limit)))

this is where the debates began in 2015 where random numbers started coming up, like 32mb 16mb 8mb 2mb.
late 2015 2mb was the ultimate compromise, just to try and get the ball rolling.. but the blockstream paid devs even back tracked on that ultimate compromise

i think what is needed is
protocol limit 32mb. hard coded(reviewed every 4 years as technology grows)
consensus limit 8mb. soft coded. can be adjusted by nodes, to show what they can cope with(maybe have a speed test algo to autoset upper limit)
preference limit start 2mb. which reacts DYNAMICALLY to what the nodes can cope with and supply/demand

we should not be thinking of hard coding 2mb, because we are just being spoon fed by devs and needing to debate for years before dev kings decide.

it needs to be the nodes that decide because the nodes are paramount not devs

[hv_]

8 Mb is fine for all and the calcs I ve seen

yep 8mb is safe for "raspberry Pi" based min specs.
where a 32mb was a old benchtest (normal pc) done years ago where dataloss 'could' start to occur. (protocol limit (above consensus limit(above policy limit)))

this is where the debates began in 2015 where random numbers started coming up, like 32mb 16mb 8mb 2mb.
late 2015 2mb was the ultimate compromise, just to try and get the ball rolling.. but the blockstream paid devs even back tracked on that ultimate compromise

i think what is needed is
protocol limit 32mb. hard coded(reviewed every 4 years as technology grows)
consensus limit 8mb. soft coded. can be adjusted by nodes, to show what they can cope with(maybe have a speed test algo to autoset upper limit)
preference limit start 2mb. which reacts DYNAMICALLY to what the nodes can cope with and supply/demand

we should not be thinking of hard coding 2mb, because we are just being spoon fed by devs and needing to debate for years before dev kings decide.

it needs to be the nodes that decide because the nodes are paramount not devs

A compromise could also look like BU injects SW. They have at least recognized that....

I don t care exactly how, but I predict first movers take it all!

[BurtW]

DELETED because you guys have lost all sense of humor.  Happy now?

[Lauda]

until you see a segwit keypair being used within the bitcoin main net. you know nothing.
research this
“anyone can spend”

Facepalm. "Anyone can spend" doesn't actually mean anyone can spend that TX. This is used to describe a transaction without specific conditions on how its output can be spent. I've heard a lot of nonsense (I'm not sure if you're trying to imply this?) claiming that Segwit is insecure because "anyone-can-spend" transactions, which is utterly false. Segwit TXs would appear as 'anyone-can-spend' to old nodes, but due to protocol rules these transactions can't be spent without valid signatures.

Anything that both jbreher and franky1 can agree to must be a great idea.

I do hope that my sense of sarcasm isn't letting me down.

[manselr]

I'm supporting Bitcoin unlimited. I'm not a BU extremist like some others on the forum, but it's obvious that Segwit has its flaws. Bitcoin Unlimited is the best fork available right now. If you think otherwise, convince me.

If you understand that segwit is needed for Lightning, this should convince you.

Money, blockchains, and social scalability

http://unenumerated.blogspot.hr/2017/02/money-blockchains-and-social-scalability.html

If you need some specific context to understand why BU sucks, this article is ideal.

Meet the Man Running the Only [Full] Bitcoin Node In West Africa | Running costs are 12% of GDP per capita in Nigeria

https://www.reddit.com/r/Bitcoin/comments/5t44pd/meet_the_man_running_the_only_full_bitcoin_node/

icebreaker still doing a good job refuting all those gavinista hard fork attempts I see. I remember you posting about XT and classic back in the day, now they are back with unlimited.

Very nice Nick Szabo article in his blog. Lays it down nicely. I would add this one by Andreas too:

https://medium.com/segwit-co/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.ui14y1ffm

Im sure if there was a better team than Core, we would have no problems admitting it if they showed superior code and a realistic vision, but as of today, im sorry but anyone not supporting Core + LN roadmap is simply delusional, they are the best.

Until somebody can come up with a coin that scales onchain to visa level volume transactions, without node centralization, with near instant and cheap transactions... Core + LN (with segwit) is the best thing we have, so don't get fooled.

[franky1]

until you see a segwit keypair being used within the bitcoin main net. you know nothing.
research this
“anyone can spend”

Facepalm. "Anyone can spend" doesn't actually mean anyone can spend that TX. This is used to describe a transaction without specific conditions on how its output can be spent.

lauda you dont understand.

i checked post history and as far back as last april i told you about the bug.. and still you have not even bothered to learn a damn thing

Segwit TXs would appear as 'anyone-can-spend' to old nodes,

i told you this last year!!!

and its why blockstream want to not fix the bug, but to split the network after activation(to stop old nodes from messing with anyoncanspend) and why they have propped up their nodes as the gate keepers of pools(FIBRE - upstream filters) and going to cut off any pools that make blocks using 'old nodes'

wake up. read something. learn something. even try extra hard to read the very links you provide yourself

you have had your head in the sand since april last year and still dont accept the truth even when core themselves wrote it in the very link you provided to this topic.

[gmaxwell]

wake up. read something.

"Jet fuel can't melt steel beams!"

Please.

Old nodes do not relay, display as unconfirmed, or mine segwit transactions. At no point are they cut off from the network in any way.  By contrast, your desperately proposed hardforks would force all non-participating systems into a separate network.

But keep on, I enjoy watching you turn red faced as people simply laugh off your constant misinformation.

It's confidence inspiring to be so opposed by the dishonest and the deranged.

[franky1]

Old nodes do not relay, display as unconfirmed, or mine segwit transactions. At no point are they cut off from the network in any way.  By contrast, your desperately proposed hardforks would force all non-participating systems into a separate network.

But keep on, I enjoy watching you turn red faced as people simply laugh off your constant misinformation.

It's confidence inspiring to be so opposed by the dishonest and the deranged.

lol gmaxwell we both know that you are the one that wants a network split.
the majority want true consensus (nodes first, pools second) .. its why pools are holding back from signaling for segwit. they wont make blocks unless the majority of nodes can accept and fully validate segwit.

your segwit nodes have already been highlighted as being (YOUR WORDS) 'upstream filters', where they whitelist downstream nodes and ignore blocks made by old nodes

you can try stroking sheep all you want. but people can read passed your half answers and word twisting

you say

Old nodes do not relay, display as unconfirmed, or mine segwit transactions.

you know why, i know why and so do smart people. but it is such a shame your not big enough guy to explain it to your own sheep with honesty.

maxwell.. here is a mindblowing experiment for you
make a segwit transactions and get BTCC to mine the transaction into a segwit block.
prove to the network and everyone how 'backward compatible segwit blocks are'.

go on, dare you
afterall its all utopia and nothing can go wrong..hmmm
(note: sarcasm in last sentence)
if you want node confidence and pool confidence.. do it.

[BiTZeD]

What I do not understand from BU people is why they prefer to secede and possibly totally fuck Bitcoin instead of working on Core or just maybe better shut up.

[hv_]

Old nodes do not relay, display as unconfirmed, or mine segwit transactions. At no point are they cut off from the network in any way.  By contrast, your desperately proposed hardforks would force all non-participating systems into a separate network.

But keep on, I enjoy watching you turn red faced as people simply laugh off your constant misinformation.

It's confidence inspiring to be so opposed by the dishonest and the deranged.

lol gmaxwell we both know that you are the one that wants a network split.
the majority want true consensus (nodes first, pools second) .. its why pools are holding back from signaling for segwit. they wont make blocks unless the majority of nodes can accept and fully validate segwit.

your segwit nodes have already been highlighted as being (YOUR WORDS) 'upstream filters', where they whitelist downstream nodes and ignore blocks made by old nodes

you can try stroking sheep all you want. but people can read passed your half answers and word twisting

you say

Old nodes do not relay, display as unconfirmed, or mine segwit transactions.

you know why, i know why and so do smart people. but it is such a shame your not big enough guy to explain it to your own sheep with honesty.

maxwell.. here is a mindblowing experiment for you
make a segwit transactions and get BTCC to mine the transaction into a segwit block.
prove to the network and everyone how 'backward compatible segwit blocks are'.

go on, dare you
afterall its all utopia and nothing can go wrong..hmmm
(note: sarcasm in last sentence)
if you want node confidence and pool confidence.. do it.

Don t mind. He might have the illusion once he got you convinced of SW in soft fogg the entire network will adopt it over midnight...

 

[franky1]

Don t mind. He might have the illusion once he got you convinced of SW in soft fogg the entire network will adopt it over midnight...
 

yep thats my thought.
him thinking if everyone adopts it then no one will notice the blacklisting.

Eg if 95% of pools go for segwit no one will notice the 5% no longer winning blocks (because they are automatically ignored/rejected)

afterall with a few rejects/orphans each week(natural occurrence) how many people actually check to see why they get rejected/orphaned. usually its a 2 second decision of 'invalid, throw aside and forget'
and who actually notices which pools just stop mining over night and not produce blocks.

i guarantee you gmaxwell has already wrote the scripts to pass out to sheep to explain why segwit auto bans native pools making blocks
im guessing its ' dont worry they are opposers trying to force a split'..

even though its segwit doing the ignoring and splitting.. not the other way round

core have already set up the ring fense around the pools to 'validate and filter' blocks (the Fibre network) so core are starting to not care about native/non-core nodes.. they just think the sheep will follow and no one will notice. or if they do notice, it would be too late as nodes cant do nothing to defend against it.

last point maxwell fails to honestly explain is that the benefits of segwit (linear sigops and tx count boost) only occur if malicious people cant make native transaction types. where everyone has to make p2wpkh tx's (which he knows not everyone will)

he cant explain his way out of people who use native tx types (p2pkh NOT p2wpkh) will still spam the network meaning segwit wont fix the things it promises to fix

[jbreher]

Still have not found how I can set my block size limit, it is a command line parameter or do I have to rebuild?

If you're running the GUI, you can set EB and AD from the Preferences dialog:



I don't know whether or not a restart is required.

Anything that both jbreher and franky1 can agree to must be a great idea.

I do hope that my sense of sarcasm isn't letting me down.

Read 'em and weep, Lauda.

[RealBitcoin]

Nonsense.

Lightning (off-chain) uses blockchain as a reference, it's impossible to make BTC out of nothing. Who would seriously suggest open source code that did that?


Your descriptions of Lightning are so unreal, you're basically talking about a different system that doesn't even exist. How long do you spend reading up on all this, only to become less educated than you were before?   

Utter bullshit. Having several secondary layer solutions -> decentralization. You also can't create out of thin air on a sidechain due to two-way peg.

Several suggestions have included removing the entire transaction data from a block and only keep it's hash.

And then store the TX data on some other blockchain or servers.

This idea gets thrown around every now and then, that you can see one idea on reddit today:
https://twitter.com/SDLerner/status/830911111209824256
https://www.reddit.com/r/Bitcoin/comments/5tphbt/sergio_demian_lerner_thinking_lumino_as_a_bitcoin/

They claim that by removing TX data they can have 100 TPS.

So all this cunning plotting and scheming that goes behind the backdoors is what worries me. The block is not a lab rat to try out all sorts of crazy ideas on. If we want a stable system with pre defined constants (21 m coin limit, SHA256 based mining algo, etc), then we also need to agree on one thing.

Which is that the transaction code should not be stripped away.

You do realize that by putting the blockchain data on a 2nd layer, you are essentially creating a centralized database.

What would then be the difference between BTC, and Visa with a handful of servers around the world?

The point of the blockchain is to store all data for reference, and that data should not be treated as trash, because that is the whole point of the blockchain.

You should already be gone according to that logic. Yet you're still here.

While the IOU's at the exchanges are worrying me, it's mostly a problem for the idiots who will get their coins stolen at the next exchange hack.

But when the entire Bitcoin protocol will work on IOU's, and the blockchain will just be a checkpoint.

Well that is no different than the banking system with 4 day settling period, and inbetween trading REPOS and other fake IOU's inbetween them on overnight basis.

[Carlton Banks]

They claim that by removing TX data they can have 100 TPS.

So all this cunning plotting and scheming that goes behind the backdoors is what worries me. The block is not a lab rat to try out all sorts of crazy ideas on. If we want a stable system with pre defined constants (21 m coin limit, SHA256 based mining algo, etc), then we also need to agree on one thing.

Which is that the transaction code should not be stripped away.

You do realize that by putting the blockchain data on a 2nd layer, you are essentially creating a centralized database.

You're still talking about a system called Lightning that is nothing like the actual proposed Lightning Network from Poon & co. When will you release this alternative Lightning of yours? When you release your altcoin too, huh?




The real Lightning network is still possible today, and you said you'd leave in an instant if you thought it was even a possibility.

So why are you still here trolling? Leave Bitcoin, as per your threat, or stop being a vacuous drama queen (yet more justification not to take your words seriously)