Support NatureHacker with
TEEF Cleaning Alt-ToothpasteBitcoin has a 10 minute block time and a 1 mb maximum blocksize. This was arbitrarily set before research was done to find out exactly how long block transmission time would be across the entire network. It was discovered that this transmission time is not negligible; roughly 40 seconds for 95% of nodes to receive the block.
https://bitcoin.stackexchange.com/questions/10821/how-long-does-it-take-to-propagate-a-newly-created-block-to-the-entire-bitcoin-n
This means that the last person or group to mine a block has up to a 40 second head start before various other miners have a chance to start. What this does is make the blocktime very important, the longer the blocktime the less percentage of head-start some miners would have over others. Effectively what this head start accomplishes is a smaller that 50% majority is needed to be able to attack the network and also that larger miners and perhaps pools would mine a disproportionatly greater amount of blocks per hashrate.
So the thought would be that we can get around this by increasing the size of blocks to be bigger than 1 mb so we can get more transactions verified while still keeping the blocktime long so that their isn't much unfair advantage to larger miners. The problem is that one of the factors that increases the time a block takes to propagate across the network is the blocksize. According to the same paper linked above; for blocks larger than 20kb it is about 1/4 second longer to propagate the network per extra kilobyte of blocksize. So it is not a good solution to speed up transactions and keep Bitcoin decentralized by simply increasing the blocksize like what was done in Bitcoin Cash.
Segwit was an idea to reduce the size of transaction data so that more transactions can be transmitted at once without changing the blocksize (much) and also not changing the blocktime. This would be an ideal solution in theory and provide faster transactions without changing the decentalization aspects of having a long blocktime and small blocks.
The way segwit accomplishes this is by separating the signatures from the transaction data. According to the whitepaper; miners can verify transactions without thier appropriate signature data existing. The transactions can even post to the blockchain with a valid hash and not have the signatures transmitted until a later date.
https://www.reddit.com/r/Bitcoin/comments/6xfh86/is_there_a_segwit_white_paper/
This introduces the possibility of the "anyone can spend" bug since signatures are not a universally verified part of the main blockchain. The counter argument is that non-mining nodes wouldn't let the bug happen. However the original bitcoin whitepaper clearly shows that the longest chain wins -- and non-mining nodes do not add to the blockchain thus their fork will likely loose. Also as I have discussed on the forums lately (my avatar is ir.hn), it also means that if it becomes more profitable for miners to skip verifying the signatures to save time to get started mining a block faster, they may do so. This is because the signatures are not included in the hash, so transaction hashes can be verified without the signature data. If miners ever decided en-masse to skip the signature verification step it would seriously compromise the security of the network and inevitably lead to the collapse of Bitcoin.
For a while I thought the only way to properly scale Bitcoin is to keep a small blocksize and long blocktime and to have bitcoin clone forks that trust each-others transactions. This method would probably work but create possible fungibility issues between the clones.
However I decided to believe that it would be possible to achieve scaling within bitcoin so I set out to develop a better way than the risky Segwit.
What I came up with I will call Transept; short for "transaction separation". The point of this method is the fact that people making transactions have already broadcast their transactions to the whole network and the miners need not do this all over again everytime. The idea of transept is simple; only the transactions' final hash is recorded in the main blockchain. This means not only is the signature data missing from the blockchain like with segwit, but also all the transaction data is missing from the blockchain. So this method would allow more transactions per block than segwit but how could this possibly be safer than segwit since there is more data missing? The reason it is safer is because to verify the hash, ALL of the transaction data including the signatures MUST be verified. This means the miner who receives the block must have all of the full transactions on file to verify that the final transaction hashes by the previous block winner is valid. So in other words, all miners need to save all the recent transaction data locally but need not broadcast this information again across the network. So the benefits are: more transactions per block without increasing the blocksize, and thus faster payments and lower fees. The downside is that the blockchain will be a little harder to search. The good part is that the full transaction information will be saved somewhere outside the blockchain and the data they have recorded can be fully verified by the hash recorded in the broadcast blockchain. So if you have the transaction hash of when you sent sally 1 BTC; you can search for the transaction from whoever has it saved and get all the details, and verify yourself that the details are correct; that the hash of all that data is equivalent to the hash recorded in the blockchain. So you know their record was true.
So how this would work would be as follows. Bob wants to send 1 bitcoin to sally. He knows sally's public address. Bob broadcasts his proposed transaction; sending 1 btc to sally's public address and then signs the transaction with his private key. All of this data will be broadcast over the entire network to everyone. Now a miner hears this and saves this and puts this transaction into his next block, however he doesn't put all of that info into the next block, he just hashes all of that transaction's data using sha-256 or whichever algorithm. So his input into the hash is bob's signature, sallys public key, the transaction amount, and the previous transaction's hash. He hashes all of this together and it gives a single number (hash). This number is then added to the blockchain and is broadcast when the miner wins the next block, but all the transaction details are not broadcast. Each transaction itself will not have its very own timestamp, it will simply carry the timestamp of the whole block. This shouldn't be a problem as it will be within 10 minutes of the actual time and the miner would make sure that they don't include "double spends"; for example if bob has .08 bitcoin and tries to send .08 to sally and also .08 to billy, the miner sees both these transactions and only recognizes the first send he sees and not the second, or recognizes none of them or recognizes the second spend. I suppose that call is up to the miner. If a timestamp is desired for each transaction that would have to be broadcast with each individual transaction hash in the broadcast blockchain and would add size to the broadcast transaction since this timestamp can't be included in the hash since other miners wouldn't easily be able to figure out the timestamp you gave the transaction. I personally believe that transaction hashes don't need to be broadcast with timestamps so long as the miner doesn't allow double spending attempts (which other miners would be able to verify that no double spending was allowed). The transaction hash would be associated with the timestamp of the block it was included in.
Miners would see the broadcast hashes in a broadcast block and be able to verify these hashes are correct and line up with the transactions they themselves heard over the network since the last block. The way they save all the detailed transaction information they hear over the network would likely be on a local (on their own computer) database. This database would be small and temporary and only include transactions that they have heard that have not yet been included in a broadcast block. Once the transactions have been included in a broadcast block, they would be removed from this database.
Another type of database would also need to be maintained locally on miners computers. This is a database of all the current public keys of all wallets with an unspent bitcoin balance and what that balance is. This "current balance" database would only be updated when a broadcast block is recieved and verified, then they would update this database accordingly so that each wallet's balance is current.
A third database would be optional to maintain, but would be very important nonetheless. A historical database that records a detailed account of every transaction that ever occured and was confirmed. This database would contain, for example in the bob-to-sally transaction, sally's public key, the amount bieng sent, and bob's signature, and possibly the previous transaction's hash. As discussed previously, this account can be verified by matching the hash of these transaction details with the corresponding hash recorded in the blockchain. Thus a supposed historical database can be verified by matching it to the broadcast blockchain.
Since this third database isn't needed to mine, all that a miner would need to download to get started would be the database containing the balances of every wallet, and the broadcast blockchain which would only contain a single number (hash) representing every transaction. This broadcast blockchain would be much smaller than an equivalent length blockchain in it's current form. Thus a miner could get started mining very quickly.
So only the single hash representing the transaction is added to the blockchain. Now in order for a miner to validate the transaction they must have also heard that bob-to-sally transaction be broadcast originally and have saved that transaction. When they see the hash of that transaction in the next block they can verify that it is correct with the transaction data they have saved for the bob-to-sally transaction. All mining and non-mining nodes would be able to do this and would have to do this to verify it. This full verification would be near instant just like verification is now without segwit.
In this system wallets would not have to be full nodes. Wallets wouldn't need to see the
In conclusion, the main blockchain does not to have the full version of all the transaction data, public key, and signature. Having just the hash of all of this data together would be enough. It will become a lucrative buisness to run a "transaction search engine" that saves all the intricate transaction details
