Wall Observer BTC/USD - Bitcoin price movement tracking & discussion

[BitUsher]

Unlike Coinbase, their employees and founders (currently) have and are exercising the power to veto any hardfork, even a bump to 2MB.

You are very confused. Core cannot force the miners , nodes, processors, and users what code to use. The veto is completely within our power. All I have to do I download a copy of Bitcoin XT or unlimited and I vetoed Core. A 12 year old child can create and alternative implementation and we can collectively veto core. Core only has power insomuch as we give them power and it can be taken away quickly in a moments notice.

Soft forks don't require consensus.

They require consensus with adoption. If you don't upgrade you don't adopt segwit.

Do you know what happens to the (real, verifying) node count when segwit happens?

Sure... but let me guess a few of your disagreements. Segwit Soft fork is voluntary but than the old nodes won't get the lower fees and won't be able to verify properly new segwit txs making them obsolete. A soft fork forces nodes to upgrade to insure they get bug fixes otherwise they will be vulnerable.

Let me address these two concerns:

1) The tx fees comparing now to after segwit on non-upgraded nodes will remain the same unless a fee event occurs which is the exact same scenario with or without segwit. If you don't like the bundling of the other features with capacity improvement than that is what other implementations are for.

2) We are discussing open source code here, which means we can take all the bugfixes and backpatch them to previous versions so they remain segwit free and secure.

[Cconvert2G36]

big blockers seem too well acquainted with random bad luck ... or maybe they are just losers who don't know squat?

Weak. Try harder.

yawn ..  you guys are just a bunch of jealous blowhards who've never actually produced anything, except lots of noise and fanboy hero worship for the Gav and Hearn the huckster.

same old, same here it seems ... why bother dropping in to listen to broken record troll-hards?

We've had news, you can now add Jeff Garzik to the list of hucksters. 

https://twitter.com/jgarzik/status/687352747465830400

[BitUsher]

If First Mover advantage is lost, whether it takes years or months, it will be gone forever.  Yeah, Bitcoin will still be around. Hell, MySpace is still around, but The escape route from Bankster tyranny will have been blocked.

Goldman sachs and govcoin can never replicate some of bitcoins best attributes:soverign, immutable, no KYC. and extremely unlikely to replicate other features that make bitcoin so great : limited , disinflationary.

Once you know this , you will have no fear of these private blockchains.

[Cconvert2G36]

Unlike Coinbase, their employees and founders (currently) have and are exercising the power to veto any hardfork, even a bump to 2MB.

You are very confused. Core cannot force the miners , nodes, processors, and users what code to use. The veto is completely within our power. All I have to do I download a copy of Bitcoin XT or unlimited and I vetoed Core. A 12 year old child can create and alternative implementation and we can collectively veto core. Core only has power insomuch as we give them power and it can be taken away quickly in a moments notice.

I'll forego the introductory insult. You're right in explicit terms, I was speaking in practical terms. What you describe may be exactly what will happen, aside from the 12 year old child part and swapping an overambitious BIP101 with BIP102.

Soft forks don't require consensus.

They require consensus with adoption. If you don't upgrade you don't adopt segwit.

And your former full node is knocked back to SPV+ mode without your request or permission.

Do you know what happens to the (real, verifying) node count when segwit happens?

Sure... but let me guess a few of your disagreements. Soft forks are voluntary but than the old nodes won't get the lower fees and won't be able to verify properly new segwit txs making them obsolete. A soft fork forces nodes to upgrade to insure they get bug fixes otherwise they will be vulnerable.

Let me address these two concerns:

1) The tx fees comparing now to after segwit on non-upgraded nodes will remain the same unless a fee event occurs which is the exact same scenario with or without segwit. If you don't like the bundling of the other features with capacity improvement than that is what other implementations are for.

2) We are discussing open source code here, which means we can take all the bugfixes and backpatch them to previous versions so they remain segwit free and secure.

A hard fork is the honest way to force nodes to upgrade. A soft fork is a way to break them and suggest they upgrade.

1) Segwit isn't optional for a full node. And it gives only 0.4 to 0.75MB gain for a full bushel of complexity via an opcode hack.

2) We are talking open source code here where miners can get the modest increase in max_block_size they requested without all the extra "benefits", Classic.

 

[ChartBuddy]

Coin



Explanation

[BitUsher]

A hard fork is the honest way to force nodes to upgrade. A soft fork is a way to break them and suggest they upgrade.

1) Segwit isn't optional for a full node. And it gives only 0.4 to 0.75MB gain for a full bushel of complexity via an opcode hack.

How does a softfork break old nodes? The bugs exist with or without the new changes and one can backport any bugfixes to previous versions that don't want new features like segwit. Yes, segwit is indeed optional for full nodes, non-upgraded full nodes will continue to work and verify non segwit tx's,if and when you are the last non-segwit node than that is one of the most ideal examples of consensus we can have, where 99.99% of other nodes have switched over and you are the only one remaining , much fairer and flexible than a hard fork with lower consensus numbers.

2) We are talking open source code here where miners can get the modest increase in max_block_size they requested without all the extra "benefits", Classic.

Are you suggesting the miners aren't excited about the features and benefits of segwit and are instead merely salivating over the extra tx fees from a mere 0-0.3 MB in capacity increase that classic is possibly proposing above segwit?  

Hopefully you are not suggesting that only the variable maxBlockSize needs to be changed for Classic either- CVE-2013-2292.

 

[Cconvert2G36]

A hard fork is the honest way to force nodes to upgrade. A soft fork is a way to break them and suggest they upgrade.

1) Segwit isn't optional for a full node. And it gives only 0.4 to 0.75MB gain for a full bushel of complexity via an opcode hack.

How does a softfork break old nodes? The bugs exist with or without the new changes and one can backport any bugfixes to previous versions that don't want new features like segwit. Yes, segwit is indeed optional for full nodes, non-upgraded full nodes will continue to work and verify non segwit tx's,if and when you are the last non-segwit node than that is one of the most ideal examples of consensus we can have, where 99.99% of other nodes have switched over and you are the only one remaining , much fairer and flexible than a hard fork with lower consensus numbers.

You have a strange definition of bugs. After segwit activation, formerly full nodes not running the latest release will not be verifying signatures on witness data. Period. Full stop.
 

2) We are talking open source code here where miners can get the modest increase in max_block_size they requested without all the extra "benefits", Classic.

Are you suggesting the miners aren't excited about the features and benefits of segwit and are instead merely salivating over the extra tx fees from a mere 0-0.3 MB in capacity increase that classic is possibly proposing above segwit?  

Hopefully you are not suggesting that only the variable maxBlockSize needs to be changed for Classic either- CVE-2013-2292.

I'm not sure how excited miners are about segwit. If you have any statements or acknowledgements from Pool admins stating that they support segwit as a solution well into 2017 I'm open to read them, is eloipool still a thing?

My personal opinion is that segwit would be cleaner, more thoroughly analyzed, and be better prepared for if released without the time crunch and soft fork provisos. In the end, my opinion doesn't matter much, that's why I bitch on these fora so much. The only influence I have is my node, a few rigs, my funds, and my words. Classic seems to be more collaborative in the way they approach miners and users about these issues... I agree that they are not fully fleshed out in terms of the distant future, but collaboration is messier than dictatorship, and this is the important issue of the day... imo.

jtoomim goes into more detail here: https://np.reddit.com/r/Bitcoin/comments/3ygu5d/blocksize_consensus_census/cydpcob

[ChartBuddy]

Coin



Explanation

[BitUsher]

You have a strange definition of bugs. After segwit activation, formerly full nodes not running the latest release will not be verifying signatures on witness data. Period. Full stop.

Yes this is what I explained, but they will still verify tx from non-upgraded nodes.
The bugs I refer to are in reference to concerns of some that may prefer security patches and not some features like segwit /or RBF.

but collaboration is messier than dictatorship, and this is the important issue of the day... imo.

jtoomim goes into more detail here: https://np.reddit.com/r/Bitcoin/comments/3ygu5d/blocksize_consensus_census/cydpcob

https://bitcoinclassic.consider.it/ gives the appearance of consensus forming through democracy but in the end  there is little difference as jtoomim or gavin has veto power or can push through a change the community disagrees with -

[Cconvert2G36]

You have a strange definition of bugs. After segwit activation, formerly full nodes not running the latest release will not be verifying signatures on witness data. Period. Full stop.

Yes this is what I explained, but they will still verify tx from non-upgraded nodes.
The bugs I refer to are in reference to concerns of some that may prefer security patches and not some features like segwit /or RBF.

So... half-broken, fine, not a distinction that matters to me. Can you give a "for example" on the security patches nodes want besides not being half-broken?

but collaboration is messier than dictatorship, and this is the important issue of the day... imo.

jtoomim goes into more detail here: https://np.reddit.com/r/Bitcoin/comments/3ygu5d/blocksize_consensus_census/cydpcob

https://bitcoinclassic.consider.it/ gives the appearance of consensus forming through democracy but in the end  there is little difference as jtoomim or gavin has veto power or can push through a change the community disagrees with -

The only real democracy in Bitcoin is measured in PH/s, other elements of the economy may influence them, and rightly so... their business depends on it.

[ChartBuddy]

Coin



Explanation

[BitUsher]

Can you give a "for example" on the security patches nodes want besides not being half-broken?

Small sample..


    #6438 2531438 openssl: avoid config file load/race
    #6571 100ac4e libbitcoinconsensus: avoid a crash in multi-threaded environments
    #6694 834e299 [QT] fix thin space word wrap line break issue
    #6703 1cd7952 Backport bugfixes to 0.11
    #6750 5ed8d0b Recent rejects backport to v0.11
    #6769 71cc9d9 Test LowS in standardness, removes nuisance malleability vector.
    #6789 b4ad73f Update miniupnpc to 1.9.20151008
    #6785 b4dc33e Backport to v0.11: In (strCommand == “tx”), return if AlreadyHave()
    #6795 4dbcec0 net: Disable upnp by default

[Cconvert2G36]

Can you give a "for example" on the security patches nodes want besides not being half-broken?

Small sample..


    #6438 2531438 openssl: avoid config file load/race
    #6571 100ac4e libbitcoinconsensus: avoid a crash in multi-threaded environments
    #6694 834e299 [QT] fix thin space word wrap line break issue
    #6703 1cd7952 Backport bugfixes to 0.11
    #6750 5ed8d0b Recent rejects backport to v0.11
    #6769 71cc9d9 Test LowS in standardness, removes nuisance malleability vector.
    #6789 b4ad73f Update miniupnpc to 1.9.20151008
    #6785 b4dc33e Backport to v0.11: In (strCommand == “tx”), return if AlreadyHave()
    #6795 4dbcec0 net: Disable upnp by default

I would rather have all those issues than be half broken. Simple fix for upnp... don't allow it.

Imagine if "we" could be not broken and have bug fixes at the same time, plus 2MB blocks, why didn't anyone think of this...?

[ChartBuddy]

Coin



Explanation

[marcus_of_augustus]

Can you give a "for example" on the security patches nodes want besides not being half-broken?

Small sample..


    #6438 2531438 openssl: avoid config file load/race
    #6571 100ac4e libbitcoinconsensus: avoid a crash in multi-threaded environments
    #6694 834e299 [QT] fix thin space word wrap line break issue
    #6703 1cd7952 Backport bugfixes to 0.11
    #6750 5ed8d0b Recent rejects backport to v0.11
    #6769 71cc9d9 Test LowS in standardness, removes nuisance malleability vector.
    #6789 b4ad73f Update miniupnpc to 1.9.20151008
    #6785 b4dc33e Backport to v0.11: In (strCommand == “tx”), return if AlreadyHave()
    #6795 4dbcec0 net: Disable upnp by default

I would rather have all those issues than be half broken. Simple fix for upnp... don't allow it.

Imagine if "we" could be not broken and have bug fixes at the same time, plus 2MB blocks, why didn't anyone think of this...?

Imagine if you could code (or pay someone to code) you could actually fix all those things you perceive as being broken, make changes to your hearts content ... instead of sitting on the sidelines, back-seat driving, monday morning quarter-backing and generally sounding like a pompous know-it-all.

Why didn't you think of that?

[Cconvert2G36]

I would rather have all those issues than be half broken. Simple fix for upnp... don't allow it.

Imagine if "we" could be not broken and have bug fixes at the same time, plus 2MB blocks, why didn't anyone think of this...?

Imagine if you could code (or pay someone to code) you could actually fix all those things you perceive as being broken, make changes to your hearts content ... instead of sitting on the sidelines, back-seat driving, monday morning quarter-backing and generally sounding like a pompous know-it-all.

Why didn't you think of that?

Thankfully, like-minded people... investors, coders, miners, and exchanges are beginning to coalesce around something I agree with. Our mutual self interests align... Imagine that... could it be possible?

[ChartBuddy]

Coin



Explanation

[ChartBuddy]

Coin



Explanation

[Andre#]

Thanks for the explanation on the fullness of the block

So those few hours with totally full blocks are the sign of the beginning of the end of btc?  

Well I suppose it will be fixed in a way or another.

No, the periods of totally full blocks show that we are hitting the ceiling of the transaction capacity. It's not the beginning of the end of Bitcoin (yet).

It will be fixed. Either by raising the transaction capacity of the network. Or the service becomes too expensive for a part of the users, and the growth of Bitcoin will come to a halt at a quarter of a million transactions per day. And that (given a current user base of only about 1 million) may be the beginning of the end of Bitcoin if the current users (like me, who are expecting growth) lose confidence and start selling their stashes.

Note, the latter situation can develop quite quickly, since the price of Bitcoin is almost entirely based on speculation about its future. Once the hoodlers lose their faith in Bitcoin's future, the price will collapse.

[sAt0sHiFanClub]

Can you give a "for example" on the security patches nodes want besides not being half-broken?

Small sample..


    #6438 2531438 openssl: avoid config file load/race
    #6571 100ac4e libbitcoinconsensus: avoid a crash in multi-threaded environments
    #6694 834e299 [QT] fix thin space word wrap line break issue
    #6703 1cd7952 Backport bugfixes to 0.11
    #6750 5ed8d0b Recent rejects backport to v0.11
    #6769 71cc9d9 Test LowS in standardness, removes nuisance malleability vector.
    #6789 b4ad73f Update miniupnpc to 1.9.20151008
    #6785 b4dc33e Backport to v0.11: In (strCommand == “tx”), return if AlreadyHave()
    #6795 4dbcec0 net: Disable upnp by default

0.11.1 Change log
Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

#6438 2531438 openssl: avoid config file load/race
#6439 980f820 Updated URL location of netinstall for Debian
#6384 8e5a969 qt: Force TLS1.0+ for SSL connections
#6471 92401c2 Depends: bump to qt 5.5
#6224 93b606a Be even stricter in processing unrequested blocks
#6571 100ac4e libbitcoinconsensus: avoid a crash in multi-threaded environments
#6545 649f5d9 Do not store more than 200 timedata samples.
#6694 834e299 [QT] fix thin space word wrap line break issue
#6703 1cd7952 Backport bugfixes to 0.11
#6750 5ed8d0b Recent rejects backport to v0.11
#6769 71cc9d9 Test LowS in standardness, removes nuisance malleability vector.
#6789 b4ad73f Update miniupnpc to 1.9.20151008
#6785 b4dc33e Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave()
#6412 0095b9a Test whether created sockets are select()able
#6795 4dbcec0 net: Disable upnp by default
#6793 e7bcc4a Bump minrelaytxfee default