Regardless of re-org rules. All nodes should reach consensus. This is the main point.

Hey there. I did thought about the same thing. It should not be like that. look at my tweet to @TruthCoin

https://twitter.com/hosseamin/status/1090459542364848133

Edit: I'm wrong here,

Take a look at page to for the explanation

That's mining chip. ASIC (Application Specific Integrated Circuit). It's only for mining. Doing it for validation needs alot more capital. Some estimated about 100mUSD.

Baking ASICs for validating bitcoin would give the highest efficiency. There are two reason for not doing it.

1. ASIC cannot be changed once it's out there.
2. Cost of manufacturing an ASIC is not realistic at the moment. Also it may raise a security issue.

Instead using small compute units is the perfect solution to scale. It improves efficiency against a CPU core. And it's general purpose computing unit.
Look at the thread i did open. https://bitcointalk.org/index.php?topic=5103538.0

bitcoin scripting language should get ported to opencl. For it to be able to run on GPU. I'm sure we can find shortcuts to automate most of the process of porting.

I agree implementing GPU validation is the cheapest and simplest way to increase validation speed. I have limited experience on writing code for GPU. But I'm interested.

For anyone interested in manycores. Take a look at this site. http://bjump.org/manycore/

Merge process will take care of that. I have somewhat good understanding of how validation process is taking place. Same goes for child pays for parent.

That's not a requirement to reach consensus. One can do so after evaluating asynchronously. And merging the result to take final decision.
This is certainly possible. The question is, Is it needed. As domob did point out. It will probably have no effect with current CPUs available. I reckon many cores can change the game. In which verification time of input coins are done faster than validating a block and fetching UTXOs.

I see. That can kill this idea. Anyway at least i tried to talk about it.

There are couple of reasons i see the validation process is done linearly. First of all leveldb (database of UTXO set) does not support multi-threading. And there are static variables defined inside `validation.h` keeping track of state of blockchain. Maybe I'm wrong.

Well. I'm new to bitcoin. I don't have much skin in the game. I'm just interested in the project. Want to figure out how the economy of development works out.
I can start my work to reach a proof-of-concept. I want to see if anybody interested in spending money on it.

Initial goal, speeding up bitcoin initial validation time based on number of available cores

Assuming bandwidth is not an issue for initial validation, I have a project in my mind to do this initially. And in future it lowers one aspect of scaling hurdles which is processing time for validation.

To achieve higher performance we need to expand the number of cores.
GPUs provide more cores, I think at the moment Nvidia has about 50 compute unit. Also it's cheap at the moment because of all these mining rigs.
And one can achieve even more performance by designing an SoC designed for search and cryptography operation. https://www.sifive.com/

At the moment bitcoin-core validation is taking place in a linear fashion. within a single core.

Here's what I'm thinking.

1. Implementing a new bitcoin specific con-current functional search engine

For validation, UTXO database is required. Which is a list of unspent coins. The search engine only requires to have integer for indexing and storing binary data for txid, public script and vout.
Simple sketch of it would be.
It should divide indexed data in multiple files within a range of integer associated with them. Which allows for each piece to work independently.
And fetch process can be done in bulk.
Write procedures are done periodically as re-write of indexed data.

2. Queue/Merge based managing core

I believe the best way to manage validation is to do each task in functional manner and manage it with putting tasks in queue and merging the result.
So for example when manage core receives a block, It holds state of each transaction and digest the block into input coins. And sends tasks to search and then validates coins with spending script then merges the result.

3. Passive block validation

Meaning validation will get into queue without the need for the previous block finish its job. By validating pow before doing this task, DoS attack won't be an issue.
In this form validation process are done asynchronously. Then final decision is taken by merging the result.


Let me know if you have any questions.
I'm looking for a method to fund this project. As i don't have enough capital to do it myself.

If a blockchain has no currency attached to it. There's no need for the blockchain itself. You will get an empty ledger.

The right question would be. Can we attach an exiting national currency to a blockchain? Very unlikely.

First of all there's need for massive cooperation from current system.
What i would ask. Why we need one? Most of national currencies are already working digitally. IMO they're working just fine.


Bitcoin's birth was because of lack of trust on existing national currencies. It also helped removing restrictions existed/imposed to transact inter-nationally.

Bitcoin's uses blockchain to keep track of bitcoin ledger in real-time. I don't think there's any other method for doing it, While keeping the system with no need for a central authority to determine what time is it and what has written on the ledger until now.

So what does it mean.

Imagine your bitcoin node stops working at some time for one day. And the next time it starts. It knows the ledger until yesterday. There's a network of nodes running on the internet. It tries to connect to one or more. And ask what happened. You can't trust strangers. So bitcoin's blockchain is here to help.
 
The function time is proof-of-work. It's designed to find a block every 10minutes. Which has a special feature, It can rollback in time (It's very UN-efficient, 51% attack can be done with this feature).
Each block contains a set of valid transactions. By attaching the previous block (-10min) to new block with proof-of-work function. blockchain is formed.

HeRetiK, Thanks for replying.

Yes. I'm trying to mix them together. I didn't write a good initial-post. I'm not looking for re-creating the same rules or accounting system as bitcoin.
I understand more/less how bitcoin works. So i agree with what you say.


I did check bitcoin's code regarding to add some data to p2sh UTXO's, The network is rejecting it. It might be accepted by protocol.
Only way to add data is by. OP_RETURN, Which makes that UXTXO UN-spendable.
The thing I'm trying to achieve is let users have ability to UPDATE/DELETE or verify ownership by providing a signature for that p2sh which is bundled to it.

There's a way to force miners accepting all txs by determining best chain, as longest and with most lost coins relative to subsidy at that point.

I mean there's no need to put a fixed amount of block-size limit since blockchain is inherently limited. Then at the time of peak usage network should handle more txs. Amount for increasing subsidy can estimate how much network can handle in future....


You are right there's a need for another network providing public cloud. But the issue it solves is agreeing on what exists at present. So it will trigger CREATE/UPDATE/DELETE commands. (Bitcoin has a secure network to solve a piece this puzzle)

Hi everybody, Thanks for responding.

First of all i figured I'm terrible at explaining things

1. I'm not trying to change the bitcoin rules. (fork was the original idea, Not like bcash)
2. Regarding "Intrinsic value" i wasn't trying to oppose to bitcoin. I agree with you. I'll explain why i said that.



1. First reason i would say It's good thing. We can make sure how much storage is needed for blockchain. Thus there's no need to put limit in blocksize.
2. subsidy will be fixed but inflationary instead of halving so more data can be written in blockchain over time.
3. Though it may not be a good idea for being currency.


I meant if the coin's value becomes zero in respect to others. You can put some data to the blockchain. It might be a silly discussion. So i take it back.


So i figured if there's specific format for pubkey-script. For example, p2sh + original host + checksum-of-file

1. Then user can edit/remove the file by spending the p2sh.
2. end-user can verify the file, So receiving it from any host will be fine.
3. Hmm, with HTTPS, caching files for ISP is no longer an option.
4. Each cloud user should have a server for doing fancy stuff. and making sure the integrity of files. It will reduce load on that server.

I didn't look at those in depth. I guess they didn't do it this way. (Filecoin, Storj for sure)


I may be wrong. Please tell me what you think. So i won't spend my time for nothing....

I'm not just talking about bitcoin as currency.

Here are two problems.

- Lack of Intrinsic value
- High fees due to block-size limit

Okay here's how i think it can achieve that.
 
1. All tx should burn some coin depending on tx size, (One(satoshi) coin will be equal to one byte) to put the tx in blockchain (cost of usage).
2. Subsidy should be inflationary due to burn of coins at usage. also it will define limit of blockchain size

Also this kind of bitcoin can also be used as public and open data store (what cool boys call it public cloud).

Then delivery of data can be a tool for earning revenue from consumer (ISP are doing it, but it will be cheaper for them) or the other way around.

What do you think?