Topic: The blockchain does not know its code but the code knows the blockchain? - page 2. (Read 489 times)

The link to the "paper" was mentioned in an earlier post:

---

This seems fundamentally flawed... the Genesis block is just a data block... it's not a "code".

So, it seems their entire premise rests on this really bad interpretation of what a "genesis" block is?

Sorry is the author banned from the bitcointalk group (or a certain section or a certain moderator),
or the paper itself is banned from the internet???
How is that?

I reject any such frobidding of ideas/info/knowledge

I tried to Google search it out of curiosity, only found this about Dissociative Social media platforms,
https://bettermarketing.pub/social-media-is-dissociative-ac1b3c67b5d3
But it didn't upload either

This is about the Connection Layer Protocol (CLP).

There is nothing in the "paper" about this - all it says about updates to the code is "Other blocks of code can be seen as applications on the solid blockchain, as well as updates of the genesis code."

Can you please quote the part of the white paper that explains how code updates are approved and included in the chain?

Aside from the person, where's a link to the paper itself?


I'm not sure which of the 2 ideas that came into my mind, or none?,  u r referring too:

1- A scenario where a hacker manipulates a Bitcoin Core update for example and more than 51% of full nodes download it; a situation that I think a Cryptographic code checksum or  a Core signature on the update would solve it.

2-A situation where a whole country software is manipulated, which could isolate its Blockchain from the true International one without individuals noticing it; either for a common virus with lack of security measures, or for political reasons an enemy tries to obfuscate population data. In both cases I don't think ur method will help, still Solution 1 of a global code hash/integrity only "may" help
(I'm talking hypothetical here, I mean if there data on a global Blockchain they can retrieve the last Internationally saved copy, but if the fact is discovered after some time they will lose some data and have to get back to the last integrity verified point)

Sorry, that's kind of frightening &  I'm not sure if it's related to the white paper u r talking about.

post canceled due to lack of interest and support.

Apparently the OP and friend think that in all the time Bitcoin has existed no one has tried attacking it in every way possible both in theory and actual attempts? It is a very safe bet that probably hundreds if not thousands of bad actors including no doubt more than a few State-sponsored players have tried and to-date, all failed.

As I said earlier, it is the constant self-checking of results from the massively distributed mining process that ensures corrupt blocks do not make it very far before the bad fork is terminated. It would take a prolonged 51% attack based on the corrupt block(s) lasting through the full 101 block confirmation rule to have any chance of working.

That would very soon be caught by the rest of the network and in one of the rare moments of all the major players acting together - stopped. It has been done a few times before. Just google "billion bitcoin bug" or refer to here for a short description of what happened when someone tried it.

That said, I wonder if there any tools to look at the 'fuzz' of failed blocks/chains that branched off the main chain before being terminated?

OK, I kind of get your idea. But usually, when someone makes a consensus change to the Bitcoin client that affects how they create blocks, transactions, etc, the honest nodes are programmed to reject these items of data. This makes the rebelling node orphaned from the rest of the network so the blockchain can't be manipulated from this avenue.

I'm definitely not saying it's not possible but perhaps with more subtle consensus rule changes that don't directly alter the blockchain content the blockchain could be manipulated, but it's usually a researcher that discovers these first and it becomes a CVE.

To me, the only way a bad-actor node could even possibly inject a corrupted block into the chain is:
a) submit a corrupted block it claims has been solved to the network.
b) have a confirmation of the corrupted block because a pool (or one helluva private solo farm) used SPV mining and so did not check that it is a valid block with results that matches the inputs to it.
c) have that first 'confirmation' validated by several other SPV nodes in a row lengthening the now corrupted chain.

With 'c' therein lies the biggest hurdle: By The Book a block is not considered 100% validated until it has 101 confirmations by the network. IF at any time a node that properly validates the block data tags it as invalid it can and most likely WILL be kicked out the the blockchain and treated as the start of an invalid fork. More than enough nodes do that and even the pools like Poolin, ViaBTC, etc that are known for pushing empty (SPV) blocks do do full block validations often enough to catch bad-actors.

I'm not talking about Bitcoin, I'm talking about the stupid "associative blockchain code" idea the original poster is pushing, which explicitly wants to have validation code in the blocks themselves: https://medium.com/@mocciaro.smz/associative-blockchain-code-f84f385c45ec

No, blocks contain just raw data, you can see who owns what, but it can be executed in any way, using any Turing-complete language you want. It has to be compatible with the rest of the network, that's the only required thing to reach consensus.

There is no official "bytecode", you just have some data in the chain and that data can be accepted or rejected by your node. If you ask about the format of the data in the chain, then all users running full nodes. You can release new version, but you have to convince people to install that version to bring your changes into reality. If developers will start doing some things that people don't like, then they can always switch to another coin (or simply stick with the old version).

For some coins, the blockchain is identical to some point in time, that's probably the easiest way to see that there is no single version matching the blockchain. Also, many miners use their own custom software (and hardware) to mine blocks more efficiently, using "generatetoaddress" will work, but using specially optimized software is better.

I don't agree with that. If the blockchain is disconnected from the binary code, it can be updated and changed easier than if it is connected, because you don't have to stick to some processor architecture or some programming language. Also, if you have self-upgradeable blockchain, then you can force some unwanted update just by pushing some data into the chain. That gives too much power for miners and changes them into semi-developers by letting them auto-update other nodes, which can be dangerous. Even versions released by Core are not auto-upgradeable, you have to upgrade it yourself.

I skimmed the "paper" that describes this and it seems like the idea is to add a virtual machine, and the bytecode that handles the blockchain validation itself is embedded in the blocks. This leaves me with a major question.

Who decides what updates to the bytecode should be added?

Anyone with the power to push updates to the bytecode (and therefore changing how ALL blockchain nodes process data, instantly) has tremendous power over the network, making it basically a centralized network.

In contrast, in the current Bitcoin ecosystem, any node operator is free to run any code they want, and refuse updates they disagree with. This could result in forks, as with BCH, but I see this as a feature and not a flaw - the Bitcoin core devs do not have absolute power to decide what code runs the network.


Remember how the DAO code (equivalent to your "ABC" blockchain's bytecode) running on Ethereum was flawed, and it allowed hackers to take over everything? What stops a similar scenario from happening with an "ABC" blockchain?

post canceled due to lack of interest and support.

So we're talking about arbitrary blockchain software now, not Bitcoin Core.

The thing about those is that many of them have a weakness in that they are not properly audited as well as they should be for a digital currency consensus enforcer. This is usually due to a lack of manpower and resources (they'd rather audit bigger projects. These projects usually have small download sites making it easy for some random person with their own modifications to masquerade as the official download site.


That would be better for most of those one-release, never work on upgrading again kind of cryptocurrencies.

post canceled due to lack of interest and support.

It's basic software engineering.

This is similar to any other large-scale program using a versioned file format for storage. Search index "databases" (mostly just sqlite files or some proprietary "lite" database as a file) for example, usually have a version written at the top of the file and the indexing program is coded to understand versions up to a specific one.

But newer file versions running on older software are oftentimes incompatible because they often remove fields read by the older versions. You don't see this happening with Bitcoin Core though, because developers update the local block[chain] database format versions in such a way that they are backward-compatible with older client versions by never removing any fields.

So it all depends on the program whether the developers are careless and don't make backward-compatible changes to file formats. If this is true then the older programs will flat-out fail when they encounter a newer format (this includes third-party "new" formats that are unknown to the public for the purposes of this post).

A backward-compatible change will cause older programs to continue to work normally, including in the face of these private, unknown new versions.

post canceled due to lack of interest and support.

You seem to be speaking of "the blockchain"™... as if there is only a singular instance of it which a malicious actor can alter and thereby affect everyone.

In reality, any malicious actor will be able to do whatever they like to their copy of the blockchain data... with whatever code they want to use. However, as illustrated by pooya87 illustrated, any "non valid" data created by this malicious actor will be rejected by everyone else running "non modified" nodes.


Also, you keep talking about manipulating the blockchain... the data is not manipulated... it is "created" (ie. transactions are created, blocks are mined)... the entire concept of the blockchain rests on the fact that it is immutable... so the data cannot be "manipulated".

So, I am thinking I am not understanding what you actually mean when you say:

In what ways is "the blockchain" being manipulated?

post canceled due to lack of interest and support.

Not at all. The code doesn't expect at all the actions be "uniform and certified". That's why the code contains consensus rules.
Since the others have the proper code, their code will simply reject your block if it didn't follow the rules.

This means that whatever malicious you do, it will either remain local if you altered the consensus rules, either it will be dropped too when the correct blockchain will become longer than yours.
Keep in mind that you cannot really alter older blocks...