Topic: I'm still having trouble understanding BIP66 fork and Bitcoin's legitimacy (Read 1244 times)

It's very simple Dennis

Step 1.

Validate the entire Bitcoin blockchain using OpenSSL ECDSA validation

Step 2.

Validate the entire Bitcoin blockchain using secp256k validation


And behold, not only are the results identical, but consequently, both nodes will happily join the Bitcoin network, which itself is comprised of a mixture of nodes with their individual blockchains validated with entirely OpenSSL ECDSA, entirely secp256k ECDSA, or even mixed OpenSSL & secp256k ECDSA validation.


Whether you decide to exercise appropriate compunction (and hush), is, of course, entirely up to you

OpenSSL was fine, but not ideal. Everyone would have had to use OpenSSL's implementation of BER in order to be consistent. However there were certainly multiple implementations prior to BIP 66's activation that did not use OpenSSL but rather other crypto libraries. There could have been chain forks and inconsistency if someone had used a BER signature, but no one ever did.

What is this "inaccuracy"? How does libsecp256k1 force inaccuracy?

The Core devs wanted to move away from OpenSSL for multiple reasons. First of all, OpenSSL has been known in the past to have several severe vulnerabilities. Secondly, OpenSSL contained a lot of extra code that Bitcoin does not utilize. And thirdly, libsecp256k1 is far more efficient than OpenSSL and is more resistant to attacks specifically on ECDSA.

BIP 66 guaranteed that every single piece of Bitcoin software did not have to rely on the way that OpenSSL decoded BER signatures. It forces all signatures to use strict DER, which has a well defined specification. This means that any software that does ECDSA signing or verification can use any implementation that follows the ECDSA and DER specifications. For example, Armory uses the crypto++ library for all of its cryptography stuff (which includes ECDSA and DER signatures) ever since it was created.

There are not multiple prior ledgers. Why do you think that would be the case? If there were, then any transactions made on those ledgers either also happened on the current Bitcoin blockchain, or are completely invalid on the current Bitcoin blockchain. There is not inflation of Bitcoin as defined by the current blockchain.

Well, you also didn't seem to answer a lot of my questions, either. So, I'm inclined to believe you're not willing to talk about this issue. For instance,

1. So, on one hand, supposedly OpenSSL was fine for being used?
2. Yet dev wanted to move away from OpenSSL for libsecp256k1 while keeping the ledger prior to libsecp256k1 implementation at the expense of keeping the prior ledger, thus forcing inaccuracy on it?
3. ...I'm under the impression that inflation has occurred (sure, there is a max coin limit, but how long until enough trading occurs to resolve the issue with there being multiple prior ledgers to the point that they're ridiculously insignificant if but no longer existent and no one has a pre-libsecp256k1 ledger?

No you did not. You said there was a fork and you think that fork caused inflation. You did not explain in what way that fork causes inflation. You did not explain how previous forks are involved in inflation in any way whatsoever. You have not explained what mechanism causes inflation. Forks by themselves do not cause inflation, they have to change the consensus rules governing the money supply in order to do that. All you have said is that "there were forks and it seems like they caused inflation" but you haven't actually said anything as to how a fork causes inflation.

I am inclined to believe that you are trolling given that you fail to understand how Bitcoin, forks, and BIP 66 even work even after I explained it to you.

Very interesting. I think I've already answered your questions. I think I will see what the P2Pool has to say about this.

Inflation is controlled by the consensus rules. Inflation in Bitcoin is done through the block subsidy, which follows a strict schedule. If you were to mine a block which does not follow these consensus rules, then everyone else who is following them will reject your block as invalid. Given that everyone is using the same consensus rules, the Bitcoin mined in that block would be completely worthless since you cannot spend it anywhere.

By definition, BIP 66 is a soft fork. It makes something previously valid, invalid. That is the definition of a soft fork. BIP 66 made DER, a subset of BER, the only valid signature format. This does not break anything since prior to BIP 66's activation, DER was still the only signature format that was actually used, even though BER could have been too.

Where is this inflation coming from? What caused it to happen? Can you please explain that, because BIP 66 does not change the money supply at all. How did any of the past forks cause more inflation when they don't even touch the block subsidy schedule (which would require a hard fork anyways, and no hard fork has been executed in Bitcoin)?

I firmly believe that you have no idea what you are talking about, are spreading FUD, and pumping Ethereum.

@ First replier
I'm not a registered officer with any current local, state, or federal governmental system while residing in U.S. as citizen of the U.S. rather than world. I didn't find the first reply helpful, but I appreciate it.

@ achow101

I am on about the possibility that there is inflation in the current Bitcoin system. It appears that it has been controlled so far by social contracts and the social cohesion of the miners.

"... What BIP 66 did was that it required every ECDSA signature following the soft fork's activation to follow the strict DER signature format. There are not multiple Bitcoin blockchains because of this and it does not affect any Bitcoin prior to the soft fork since no signature used the BER format. BIP 66 only removes the vulnerability so that it cannot be exploited..." - achow101

I'm talking about prior to BIP66 that there are forks and that after BIP66 implemented libsecp256k1, a hard fork of the blockchain was for sure. I'm now repeating myself, I believe and do not understand why you have said what you have said.

I firmly believe that someone is in denial here. Regardless, a stronger blockchain will resolve this. You said "soft fork," thus making this an issue of semantics. I have read that people call what happened to the Blockchain post-BIP66 a fork, even a hard fork. I'm under the impression that whoever crafted BIP66 is now profiting from it but experiencing a bubble that will soon burst.

In relation to the inflation issue, I don't know much about Ethereum Classic, but I've studied accounting and money. I took a look at the Ethereum Classic price chart, and it looks like Bitcoin has engaged in inflation due to the forks and this issue is being noticed more and more as Ethereum Classic approaches December 2017, whereby I have read that the Ethereum Classic community will but a cap on its max. ether(?) supply: https://coinmarketcap.com/currencies/ethereum-classic/

It appears to me that the Bitcoin forks from the Bitcoin genesis block prior to the implementation of libsecp256k1 are involved in the Bitcoin inflation.

I think this bug can be fixed. I propose something for the miners to vote on: "Blockchain Reboot"

Like the unlimited (I guess, because I wasn't around for it) and Segwit (I've been around to see it at 34% approval), put up some code to have the community (even if but miners, but I'm not sure if they'll be greedy and resistant) vote whether or not they think there is an inflation issue and have the blockchain scrapped in vote for a new blockchain with genesis block BUT to use the libsecp256k1 library(?) rather than OpenSSL. Otherwise, I perceive Bitcoin getting messed up and backed by Ethereum Classic in the future until this issue is resolved.

- Also, I don't support the idea of Segwit being used.

Thanks for the replies.

Sincerely,
Dennis Francis Blewett

P.S.

I would suggest IMMEDIATELY discussing the use of a P2Pool (or something like it) for Bitcoin miners directly after a blockchain scrap and reboot. Otherwise, you'll have to wait a long time, I think, for Bitcoin to get back to where it was in terms of BTC/USD.

P.P.S.

And if y'all just goona stay in denial, then I think Ethereum Classic in December will take care of the issue, whereby people will hang their heads and be like, "yeah.... yeah, we were just being greedy... we're sorry ;_;"

death, taxes & forks.


http://qntra.net/2015/07/another-post-bip-66-fork-dies-after-3-blocks/

BIP 66 fork "incident": http://qntra.net/2015/07/chain-fork-reveals-bip-process-broken/

What are you going on about?

ASN.1 BER is a specification for a way to format ECDSA signatures. DER is a subset of BER which Bitcoin uses. However, prior to BIP 66's activation, signatures could be in the BER signature format, but no signatures actually were. What BIP 66 did was that it required every ECDSA signature following the soft fork's activation to follow the strict DER signature format. There are not multiple Bitcoin blockchains because of this and it does not affect any Bitcoin prior to the soft fork since no signature used the BER format. BIP 66 only removes the vulnerability so that it cannot be exploited.

The OpenSSL dependency is because no known software decoded all BER signatures in the exact same way, so if BER were to be used, then everyone would have to use the same software, which, at the time, was OpenSSL.

There is no "more accurate blockchain" or anything like that. Changing to strict DER signature format only effects the signature format, nothing else. It does not effect the money supply, difficulty, "accuracy" (whatever the hell that means), or whatever. BIP 66 only effects the signature format and enforces that all signatures must follow the format that everyone was already using.

Hello Officer!

We are very sorry that our developers removed the dependence on OpenSSL and the backdoors that you've planted there. The community felt it would be better without backdoors or with backdoors that are controlled by us.

Sincerely,

/* illegible signature */

By the way: how is the coffee being served nowadays at NSA/CIA/other TLAs?

One of the main reasons for this thread is because I'm interested in getting involved with Bitcoin. Another main reason is because this thread is related to alleged code being used and dev mailing lists.

I started with reading Satoshi Nakamoto's white paper. One of the important things is accuracy of the ledger, if I recall the whitepaper correctly. However, from some technical reads from devs, it would appear there have been multiple Bitcoin ledgers over time. Furthermore, I'm under the impression that all past ledgers should have been scrapped directly after libsecp256k1 was initiated. As such, Bitcoin should have started anew with a fresh ledger and using libsecp256k1 and all past investors would have to write things off as a loss if but a gain in finding a different security protocol to remove an alleged Bitcoin vulnerability. Also, I'm getting contradicting information from the maillist I'm reading, whereby it seems OpenSSL could have still been used but the issue with using OpenSSL was that there would be an architecture dependency; as such, dev wanted to escape the architecture dependency by switching to libsecp256k1.

As a note, I'm not too familiar with BER, DER, and some of the other abbreviations. However, for what I understand the ledger is inaccurate. I got that much out of it. I've been trying to make sense of how that affects the value of Bitcoins mined prior to BIP66 being implemented in contrast to Bitcoins mined after BIP66 and how the multiple ledgers and the BTC value relates, but that might be for a different thread.

Why should I not think that the Bitcoin ledger is inaccurate?

BIP66:

1. The Bitcoin Project had a vulnerability (1)

2. The vulnerability was considered to be OpenSSL (1)

3. "OpenSSL is ... inconsistent with itself across different platforms." (1)
4. Libsecp256k1 was opted for use instead of OpenSSL via majority vote (1)

However, the developer said:

1. The problem is related to the signature encoding rules. (1)

2. This on itself would not be a problem, as full nodes on the network
currently use OpenSSL. (1)

3. 2014-Sep-01: While analysing OpenSSL's source code for BER parsing, I
discovered the architecture dependency listed above and the associated
vulnerability. The best means to fix it at the time was by getting
BIP62 adopted. (1 -- underlining added for emphasis)

It would appear:

1. libsecp256k1 results in a huge increase in signature validation performance (4)



I'm under the impression that the following would have to occur:

1. Bitcoin ledger gets scrapped in favor of the new encoding library and uses a fresh ledger: Thus uses libsecp256k1

2. Or... Bitcoin becomes dependent on architecture for immutability of the ledger while using OpenSSL

However, the Bitcoin team decided to keep the ledger and use libsecp256k1...


The issue is that the ledger wasn't scrapped when they started to use a system different from OpenSSL. Not only that but it looks like tons of forks were made, thus the Bitcoin ledger is stupid wrong in record-keeping.

" Worse, it seemed that
there was again a small (1%) number of blocks being created with
non-DER signatures in it, resulting in actual forks."

So, on one hand, supposedly OpenSSL was fine for being used?
- "This on itself would not be a problem, as full nodes on the network currently use OpenSSL." (1)

Somehow that quote and the quote before it seem to contradict. There were 1% number of blocks with non-DER and making forks but then I read that supposedly OpenSSL was not a problem?

Yet dev wanted to move away from OpenSSL for libsecp256k1 while keeping the ledger prior to libsecp256k1 implementation at the expense of keeping the prior ledger, thus forcing inaccuracy on it?

I'm being a stickler about the ledger. It would have been one thing if various transactions from various ledgers could have been brought into one main Bitcoin ledger post-libsecp256k1; but that's not what happened. And because of that, it brings me to the issue I mentioned previously: I've been trying to make sense of how that affects the value of Bitcoins mined prior to BIP66 being implemented in contrast to Bitcoins mined after BIP66 and how the multiple ledgers and the BTC value relates.

I'm under the impression that someday, it might be valuable to just roll-back prior to libsecp25k1 being implemented for when OpenSSL was being used, even if that means it requires an architecture dependency. And that's because the ledger(s) prior to libsecp25k1 are more accurate, if I'm interpreting things correctly. Otherwise, I'm under the impression that inflation has occurred (sure, there is a max coin limit, but how long until enough trading occurs to resolve the issue with there being multiple prior ledgers to the point that they're ridiculously insignificant if but no longer existent and no one has a pre-libsecp256k1 ledger? That's how I can see this bug being fix: Get rid of all Bitcoin ledgers prior to libsecp256k1 implementation. There was definitely a lack of a scientific control on this Bitcoin project forking issue. I've read that Ethereum Classic plans on putting in a max. coin limit in December, so that should act as a decent scientific control against inflation.


sources:
(1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html
(4) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html