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?

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

@ 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 ;_;"

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

Not losing money on a volatile system (forum) and gathering my thoughts on *paper* (my blog).

How and why is that chain long dead?

Yes, Bitcoin is limited in that there can only be a maximum number. Allegedly, this is how the P2P put forward by Satoshi is to delimit inflation along with the blockchain (so, arguably, there are two variables of the utmost importance: max. money and record keeping of max money). However, there have been multiple books (blockchains) to keep track of a maximum number of BTC, and for what I understand, there are multiple versions of the blockchain (pre-0.9.5. and post-0.9.5).

I decided to scrap this post. /endthread