Transep: A method for infinite "on-chain" scaling for cryptocurrencies like Bitcoin or Dogecoin that is a safer alternative to Segwit
Published: 2/13/2021
Author: NatureHacker
Maintainer: NatureHacker
License: Site License
Categories: See Footer
See Also: Meta ledger, monaton
Page: (upload / browse / edit / print)
Discussion: Transep-Talk
Archive:, , Original article, original article backup, orig article backup 2
Download: URL,PDF from URL

Transep is an alternative to Segwit for "on-chain" scaling of cryptocurrency transaction rate that can infinitely scale. I use quotes because it is not really on-chain in the sense that it actually uses a sidechain to achieve it. However it is on-chain compared to other 2nd layer things we are seeing like paypal or cashapp being intermediaries for using crypto as payments or robinhood being an intermediary for bitcoin investments without actually making individual transactions on the bitcoin network when ownership changes hands. This commercialized 2nd layer was predicted by Hal Finney in reference to Bitcoin Banks and he has been proven totally right.

Segwit creates a sidechain that is not maintained by anyone where all the signature data from a block is stored. The hash (merkle root) of all this sidechain signature data is included in the block header of a block. So even though the signatures are not part of main block persay, the hash of the signatures are and thus can be checked with the signatures when they see them. The transactions are all kept in the main block, which makes sense because miners want to get transaction fees for each transaction and is necessary for miners to get these fees because eventually bitcoin will not generate any new coins for miners.

Transep on the other hand separates the entire block from the blockchain and only the final hash of the block makes it into the main blockchain. However both miners and nodes are incentivized to keep the full block info because without it nothing could be verified. In fact with transep miners could pre-verify blocks before a proof of work is completed by the network. With segwit; miners may gloss over not being able to verify the signature hash, because it isn't a core issue of the block validity and they don't want to waste the time when they could be mining.

Transep may or may not work for deflationary coins like bitcoin and would be best suited to non-deflationary or inflationary coins like Dogecoin. This is because miners will split the fees with masternodes.

Problem with Segwit

The problem with Segwit is firstly it is not very effective. It doesn't free up too much space in the blocks since all the transactions are still recorded. Also the sidechain is limited to signature data, so bigger sidechain blocks aren't possible. Secondly, there is no one incentivized to maintain the signature data once a block has been "accepted" by the network. Since the signature data could be ignored or misplaced, the signature hash cannot be verified in that case.

What is Transep

Think of transep as the breaking up of paypal and ebay. Both of them are needed in an online marketplace, but it is best to keep them separated for more wide and fair adoption.

Transep which stands for "transaction separation" meaning basically everything is removed from the blockchain except a final hash of the block. The block thus is not maintained nor created by miners at all. Other nodes (hereby called "masternodes") create blocks and collect transaction fees from people submitting transactions. These blocks made by masternodes can be any size. Market forces will determine how big these blocks will be. Masternodes wouldn't want them to be too big as to not propagate the entire network in well under a blocktime, because then miners might not get the block in time to mine a proof of work on top of the block. However since miners do not need to broadcast these blocks themselves, just confirm that they saw them via including the hash of the block in the blockchain, there can't be DDOS spam of huge blocks that take forever to verify and bloat the blockchain. Market forces determine which masternode block makes it into the blockchain. Thus the miners, by using proof of work, are merely voting on which masternode block is accepted this round by the network. In order to be accepted, masternode blocks should be small enough to quickly propagate the network and get in front of every potential miner in time to be mined on, and large enough to generate a lot of transaction fees. Masternodes could also submit a "bid" to miners that since they took in 1 bitcoin in fees they can give the miner 0.5 bitcoin if the miner uses their block. So this aspect would incentivize masternodes to have big blocks but also minimize how much profit they take for themselves. Of course a miner could run their own masternode and only use their own blocks in order to minimize a 3rd party masternode taking a cut, but again they may as well submit their masternode blocks to all the network; in case someone else wins the block they could use their masternode block. So market forces would incentivize many parties running masternodes. Also if other miners didn't see that masternode block ahead of time, that the winning miner used, they would simply reject the miners winning block. So again, masternode blocks would need to be widely distributed so that they will be accepted by the network. If a node is consistently holding back sharing their masternode block until they find the proof of work, the other nodes should blacklist this miner and masternode.

A rule should be set that in order for a masternode block to be valid, the majority of nodes needed to have seen it before the previous proof of work was broadcast. So if miners are working on finding a proof of work for block 19, masternodes need to send their proposed block 20 to the network before miners finish block 19. Of course people could submit a bunch of bad block 20's to throw miners off but there is no real reason to do this. Market forces would mean that you want to propose good blocks so if miners use your block you will earn the transaction fees in the block. Miners are the voters and they need to be well informed of and check the validity of masternode blocks before voting on which one is hashed into the blockchain. Miners would likey start with the blocks that bid the highest fee and check the validity. Again since the blocks all need to be recieved by the majority of nodes before the last block was finished, there would be little incentive to send bad spam blocks because nodes would have time to pre-verify the blocks before it is time to start mining on top of one of them.

Even if every sucessful masternode block is created by the mining pool that wins the challenge, still the fact that the block is separated from the blockchain will remedy the reason the blocksize limit was created in the first place. This bieng that super large blocks are DDOSing the network. Mined blocks are super small, just a hash, even though they represent lots of transactions. Also the large masternode block needs to be sent well ahead of time so they can be pre-verified by the network thus preventing the large block spam that Hal Finney was afraid could DDOS the network.

So lets say there are 10 masternode blocks that have propagated the network. A miner then chooses one to mine on top of. He simply takes the hash of the masternode block hashed with the previous block hash, then cycles through nonces until the hash of the block and the previous hash and the nonce meets the requirement for proof of work. Now he sends the total hash and his nonce widely across the network. When another miner gets it they verify firstly that they have also seen that masternode block in the alloted time, and that the nonce when hashed with that block hashes, gives the required proof of work. Now lets say this miner is destined to win the next block. He takes the hash of the last block, hashes it with a new masternode block that isn't double spending what the previous blocks have already spent, and looks for the nonce. When he finds it, he broadcasts his nonce and hash and thus the cycle repeats.

Why are big masternode blocks not problematic whereas big miner blocks are?

The reason is because if a miner sends out a large block with proof of work concurrently, another miner has to verify the entire block and proof of work before starting to mine the next block. If many miners are sending out large and different blocks with corresponding proof of work, every miner has to verify them before starting mining on top of it. If blocks are very big then this can set back miners a lot of time and could basically turn into a DDOS. If we separate the big block from the blockchain, miners would only send the block hash and their proof of work. So other miners can determine which miner won the last challenge without verifying the entire block. Now the loosing miner can look into their own memory and see the masternode block that the winning miner used, and the loosing miner already had that masternode block verified so he can immediately work on mining the next block. So the issues of having big blocks broadcast at the same time as the proof of work, is solved since everyone already saw the blocks ahead of time before the proof of work was found. Or, even if they didn't verify that block ahead of time, they did have it in their memory, so the winning miner just needs to send the winning hash and nonce and the others can verify that with the block they already have in their memory. This means the proof of work can go out and be transmitted fast even though the block that was mined was large.

If a miner was colluding with a masternode to not release the masternode block until after the miner already completed the challenge, the network should reject such a block. Any miner should reject a winning miner if that miner used a masternode block that the rest of the network didn't already recieve before they started mining the current block.

Would lots of big masternode blocks congest the network?

In short no, miners can basically just choose the block that has the highest bid, then verify it and use it to start mining on. They could also pre-verify a few more of these in case another miner proposes a proof of work with one of those other blocks.

What happens with the block data and transactions?

Miners will need to have access to all of the accepted blocks whose hash is recorded in the blockchain. This is so they can verify that new masternode blocks have not double spent something that another accepted block has spent. Miners are the ultimate deciders what is valid on the blockchain. Also masternodes themselves are incentivized to keep the full blockchain including all the transaction data so the blocks they build, miners will find valid. If they are not valid, miners will simply not choose their blocks and then the masternode will not get rewarded the transaction fees for their proposed transactions. People simply wanting to submit transactions to the network really don't need to have the full dual layer blockchain, they just need the list of valid block hashes by the miners since they know what their transactions that have been accepted by the network are. So in practice both the masternodes and miners would need to keep on hand both layers of the blockchain. They can prune this however they see fit to keep the data on hand to make good decisions about how to vote (in the case of miners) or how to build blocks (in the case of masternodes). "Full nodes" could also be non-voting witnesses with all the data and alert the network if they find a discrepancy for the miners to investigate.

Pro's and Con's


  1. Blockchian will be less searchable because transactions will not be forced to be published immutable forever in the main blockchain.
  2. Miners cannot change transactions. So if a miner sees overlap in transactions from a previous block and the block he wants to mine, he can't mine that block he wanted to. He must find a masternode block that has no transactions in common with previous mined blocks. This might incentivize masternodes to narrow their scope; to focus only on one region of the world, or one type of transaction, so as to not overlap other masternodes transactions.


More people will be able to profit instead of just miners. Much shorter blocktime is needed for small miner blocks to propogate network [1]. We could have blocktimes as low as 20 seconds which would include time for the tiny miner block to propogate in a second or two and have miners compete for proof of work.

Other pages that link to Transep:

Attachments to Transep:

Password to edit: nature