Concept of a layer 2 to overcome Bitcoin Blockchain scalability issues

[GldLnRjng]

This is a layer 2 concept on the Bitcoin Blockchain that I elaborated from the functioning assumptions of Lighning Network, and would be an improvement of it. I would like to hear your considerations on that, mainly on feasibility and preservation of security granted by on-chain validation system.

I'm an economist and web developer, not a cryptographer.

This concept aims at solving the well-known scalability issues affecting Bitcoin Blockchain, that is the main brake to BTC Blockchain mass adoption.
Every constructive consideration or rebuttal are well accepted. I just want to humbly share with you the idea and see if it's possible to obtain some interesting hint for the qualitative development of the Proof-of-Work Blockchain technology in a mass adoption-oriented perspective.

So here's the idea:

The main goal is to overcome at the capacity of the approx. average of 7 transactions per second that the current Bitcoin Blockchain is able to perform. I focused on the output quality of these 7 transactions per second, rather than a way to improve the number with "brute-force" or algorithm optimization (honestly, I wouldn't even be able to do that).

The L2 should work like this:

Users willing to make a transaction in Bitcoin, acting on layer 2, would eventually open a transaction instance. This instance would comprehend the address sending currency, the address reciving currency, and the import of the transaction.

This instance would be send to a "Box". Boxes should have various setted maximum dimensions basing on the order of magnitude of the import. We are still on layer 2 and no real transaction still happened.
When the sum of the instances imports reach the capacity level of the so called box, this box will be used to create a block on the blockchain. Basically, one box is equal to a single transaction in the Layer 1 blockchain's block. Thus, a single transaction on the block will contain a lot of smaller transactions, collected by the L2 system.

We are now in layer 1.
When the sums of the boxes dimensions in the block will match the maximum dimension allowed for a block, (1MB, or 4MB, after SegWit), the block is created and ready for validation.
For security reasons, a log, containing all the sending addresses, paired with relative recivers, could be attached to the block (maybe in the head of the block as metadata?), so that there would be specific tracking of all the transactions composing boxes even on-chain.

So transaction instances go to boxes. Boxes go to Blocks. Blocks are validated on the blockchain.

At this point, the amount of Bitcoin reported in boxes inside the block is sent to the reciving addresses by the layer 2 system, off-chain, basing on the log that tracks send/receive addresses.
For this step, the L2 should maybe provide two addresses, one sending the amount in the boxes (transactions) stored in the block (after collecting all the instances to fill the box), and one reciving it (before the L2 split the import between the receiver addresses -users-, off-chain).

- Why boxes of different dimensions?

In order to aggregate efficiently transaction instances, these are stored in boxes that takes some time to be filled. The more transactions instances takes places in the L2 system, the fastest boxes are filled and the sooner the block recives transactions (boxes) for validation (scalability).
More boxes can be filled simultaneusly in the shortest amount of time possible, since every transaction instance will immediately find a "free" box, regardless the dimension of the traded import.

- Blocks still takes approx. 10 minutes on average to be added to the blockchain.

In this time window, the L2 could provide the possibility of delete the transaction instance, something we can consider user-friendly. This would be possible only until the block enter validation process.
Also in this time window, L2 could show imports of transaction with the "account balance - available balance" logic.
This means that until the block isn't validated and added to the blockchain the sending address will still have property on the amount of currency committed in the transaction instance, displayed as account balance but not as available balance. Same for the reciving address, unless the fact that the latter won't have property of that amount, not yet. This is maybe the weakest part of the concept from a security perspective. Waiting to ear your considerations on that.

Assuming the number of transaction instances very (sufficiently) high, which is something desirable, filling boxes would take a few seconds and the transfer would be, at least nominally, immediate on the L2 environment.

Bitcoin Blockchain would still create a block every 10 mins on average, but the blocks would be representative of a much higher number of actual transactions, working smarter rather than stronger.

I would really like to hear your considerations on that. What is wrong, what is good (if there's something good actually), what could eventually be improved? Is this valuable for further considerations and maybe prototyping?

Thanks for your time and attention, This is my first post. Hope I did everything the right way and post on the right section.

I originally posted this on the Bitcoin discussion section: https://bitcointalk.org/index.php?topic=5413582.0

[jackg]

This looks like something similar to coinjoin but without the privacy/mixing element is essentially replaced with a pool of transactions/signed receipts/ious?

As far as I can work out from what you've said you want to store signed transactions online in a way that no transaction has to be sent until it needs to be or is wanted - a bit like the ligjtninent network but the ln requires a multisig address to be funded.

[GldLnRjng]

Yeah, it has the analogies and differences that you mentioned with CoinJoin, which I didn't know before so thank you. The purpose is not mixing, nor specifically raise the privacy level, even if it could be quite easy to implement such a functionality I guess even if I'm not a fan of absolute secrecy in Bitcoin and think that the "default" system gives users the most reasonable level of privacy.

As for the rest yeah, you got it right. The transaction instances should be delivered to blockchain for validation only when the boxes are full.
The current problem of PoW protocol is that a lot of transactions can't find a block to be inscribed in and has to wait a very variable amount of time to find one.
This L2 network could do this work instead of the blockchain. Boxes are quite like blocks in their functioning, but boxes has different dimensions so that it's easier for the system to allocate transaction instances. Merging transactions in one, so that the the blockchain will see just one big one, is the part inspired by Lightning Network, but yeah, it overcomes the need to find a multisig address.

Also, if you want to make just one single transaction with someone, you don't need to open a channel, with all that implies, nor "hope" that the receiver address is in the channel network of someone that is in your network.
LN still remain the best scaling solution available right now imho, but user-side, I there could be some improvements.

[jackg]

Also, if you want to make just one single transaction with someone, you don't need to open a channel, with all that implies, nor "hope" that the receiver address is in the channel network of someone that is in your network.
LN still remain the best scaling solution available right now imho, but user-side, I there could be some improvements.

I think this might be something the lightning network could evolve into since they want to allow people to open channels with just the normal channel things (and no inputs) but I think that's waiting on a fork to allow transactions to be made on the blockchain without inputs (I guess so you join a channel of dome one with one that's funded and then be paid by someone else).

Systems like these and the lightning network don't become that good fro throughput and scalability until companies and exchanges start using them more though too in my opinion at least.


It'd probably have to be possible for offloading partial channels to be automatic so the empty channel maker gets their funds as soon as they need it but I this has already been implemented on a manual basis at least.

[GldLnRjng]

Yeah. I'm thinking more about a system that doesn't need channels at all together with something that can optimize mining output without sacrifice security.
This way transactions becomes more flexible and easy for users, that won't need to know nothing new about how to make an online payment.
Since scaling is led by adoption, I'm more for a product that already fits everyday people rather than something set as standard by companies and exchanges, so let's say "top-down".

Also, I think that a "box" system would be able to collect more transactions than a channel, since channels collect a series of transaction between the same two entities diluted in time, while a box collect a group of one-to-one instances of payment simultaneously.

Moreover, micro-transaction are usually one-shot events, so not reiterated in time. That makes overkilling to use channels for that for most of use cases.

[d5000]

I think concepts of this kind already exist and are being investigated, although no one has made it into the Bitcoin protocol (and I think there are currently also no concrete plans to include them):

• Extension Blocks (where also Joseph Poon, one of the authors of LN, was involved) is maybe the closest I know, this means that in each block a number of "extension" blocks could be defined which allows to include transactions but does not form part of the canonical chain (i.e. not all nodes must validate them, only those who want). It was meant as a possible solution to the "big blocker vs. small blocker" dispute in 2017 but has stalled, there seem to be incentive problems with it which would allow "de facto" an unlimited block size.
• Sidechains are also a bit similar: here most transactions are off chain, but users can transact from the BTC main chain to the sidechain and vice versa; the second step is the most complicated, because it involves that an UTXO has to be "unblocked" following rules of another chain, the "Drivechain" mechanism is the most interesting one, I believe it is currently in alpha testing on an altcoin testnet.
• your proposal also reminded me of that of Child chains which were included in an altcoin project (unfortunately there's no good explanation online I know of, but see a presentation of the platform here). Child chains consist of off-chain transactions which are bundled by a "bundler" (a new role) to a "childchain block", which is a special kind of transaction which gets included in the main blockchain; miners and full nodes validate all transactions but do not store child chains permanently. This feature is actually already live but not yet complete (child chain transactions are still stored by all nodes).

I'm one of those who like LN but do not think it will be enough to onboard billions of people, so I'm following these technologies too, which may complement LN in the future.

Maybe I misunderstood your proposal, but it would be interesting how you think it compares to these three concepts ...

[NotATether]

I'm one of those who like LN but do not think it will be enough to onboard billions of people, so I'm following these technologies too, which may complement LN in the future.

Maybe I misunderstood your proposal, but it would be interesting how you think it compares to these three concepts ...

It really depends on what those billions of people are going to use it for:

- If as a substitute for hard cash payments of small amounts, the current LN implementation will work just fine. Similar to how people don't carry large bundles of cash with them, so LN nodes don't carry too much BTC in their liquidity.
- If as a substitute for a bank account, something different is needed - LN can work really well with small amounts, but when you need to settle millions of dollars in transactions each day, it needs to be fast and modeled on L1-style blocks.

For the second one, I was thinking on the lines of an alternate layer 2 (i.e it does not know about the LN) where there is a mini-blockchain with fast generation times and possibly (gasp!) a larger block size, but this chain is ephermal, pinned to a particular L1 block, and is deleted when's new L1 block is mined.

That would give payment settlers the benefits of speed, and decentralization is guaranteed by the relatively small (few dozens of GB) size of the alt-L2 chain. As for security, well, there would be a separate mining difficulty for the ephermal chain that is low enough to allow CPU-mining by the alt-L2 nodes, in return, they get a very very tiny percentage of Bitcoin from the total settlement.

On L1 this would all be seen as some large transaction with many inputs/outputs. But given that Musig2 signatures are almost standardized, the tx fees spillover to L1 can be eliminated as a tax with just one input and output.

Sure, the idea still needs some work and will probably be subject to pitchforks and torches, but I want to reiterate that this is an extra layer intended only for the decentralized payment settlers (e.g stores). L1 is not going to be affected (I think).

When people say "scalability problem" they usually are talking about transaction settlers. Personally I think these should rest on top of Layer 1, as opposed to directly being the Layer 1 like Ethereum just did, as that will destroy decentralization.

[d5000]

It really depends on what those billions of people are going to use it for:

- If as a substitute for hard cash payments of small amounts, the current LN implementation will work just fine. Similar to how people don't carry large bundles of cash with them, so LN nodes don't carry too much BTC in their liquidity.

Yep, although it would take a long time to onboard 1 billion users to LN - around 10 years to be exact, in the best of the cases - if we assume 2000 channel openings could be included per block, which is very optimistic (and imo only will be possible with Channel Factories where more than 1 channel would be opened per transaction), then we'll have a maximum of ~100 million channel openings per year.

For the second one, I was thinking on the lines of an alternate layer 2 (i.e it does not know about the LN) where there is a mini-blockchain with fast generation times and possibly (gasp!) a larger block size, but this chain is ephermal, pinned to a particular L1 block, and is deleted when's new L1 block is mined.

I had thoughts of this kind too, although in the model I had in mind the sidechain would "cover" several thousands of blocks. As such concepts should be mentally a "low hanging fruit", and I'm not aware of any paper of such a concept, I assume that there must be some difficult-to-solve problem with this "transitory blockchain" model. Would however love to hear about it if you can move forward with your idea - it seems to cover a middle ground between "extension blocks" and "sidechains".

L1 is not going to be affected (I think).

If I understood it right, your model would work without a dedicated 2-way-peg (which is the problem of all the models I described above) but with a kind of Coinjoin-style mechanism where several dozens, hundreds or thousands of transactions are bundled into one or a few. If this is true, then it could work; the problem may however be that there must be "something to bundle", i.e. the transactions inside of the mini-blockchain must converge into a few inputs and outputs before the mini-chain is deleted. I guess this could be difficult to coordinate; it could work for specific cases (e.g. a city where many economic actors are densely interconnected, or even a IoT use case).

[GldLnRjng]

My apologizes for not responding in this month, I've been busy in rl and wanted to have the time to answer adequately.

So basing on what emerged by this topic, it seems like there are a several ideas with similarities to my proposal, but the thing that I think differ is the fact that this L2 should work as an aggregator of transactions with the capabilities of transmiting both send/receive addresses and amounts to the Bitcoin Blockchain.

What I actually propose is to create a protocol that aggregate groups (boxes) of transaction instances, made on the layer2, and finalize them by transmitting to the Bitcoin Blockchain. This would reasult in a "many to many" transaction in the main Blockchain, where the many senders and receiver are indicated by the informations stored in the boxes. Thus, the layer2 should be able to deploy transactions on the main blockchain, after gathering all the transaction instances initialized in the l2.
This would result in a much higher number of transaction per second that the network could handle and also a decrease in fees, since every transaction fee would be divided by the many senders aggregated in the boxes by the L2.

One of the main doubts that I have is that, even if there's the option of onetomany transactions and that a single l1 transaction can have multiple inputs, I'm not sure it would be possible to create a transacion with multiple inputs by different public(private) keys.

Hope you'll still be interested in discussing this proposal.

[NotATether]

My apologizes for not responding in this month, I've been busy in rl and wanted to have the time to answer adequately.

So basing on what emerged by this topic, it seems like there are a several ideas with similarities to my proposal, but the thing that I think differ is the fact that this L2 should work as an aggregator of transactions with the capabilities of transmiting both send/receive addresses and amounts to the Bitcoin Blockchain.

What I actually propose is to create a protocol that aggregate groups (boxes) of transaction instances, made on the layer2, and finalize them by transmitting to the Bitcoin Blockchain. This would reasult in a "many to many" transaction in the main Blockchain, where the many senders and receiver are indicated by the informations stored in the boxes. Thus, the layer2 should be able to deploy transactions on the main blockchain, after gathering all the transaction instances initialized in the l2.
This would result in a much higher number of transaction per second that the network could handle and also a decrease in fees, since every transaction fee would be divided by the many senders aggregated in the boxes by the L2.

One of the main doubts that I have is that, even if there's the option of onetomany transactions and that a single l1 transaction can have multiple inputs, I'm not sure it would be possible to create a transacion with multiple inputs by different public(private) keys.

Hope you'll still be interested in discussing this proposal.

You actually can make transactions with different inputs like that, but the transaction instances will quickly fill up blocks, leaving less room for other transactions - a direct consequence of jacking up the TPS (and increasing the blocksize does not change this).


For a Layer 2 system to be effective, it needs to be able to consider L2 transactions as immediately confirmed, without waiting for L1 to mine it in a block. In case it never makes it, then that is considered a "chargeback" and appropriate penalties can be taken by service providers, just like in a regular bank.

Otherwise, it is just a proxy for creating L1 transactions.

Also, to support many tps (I'm particularly gunning for 1 million transactions per second!), the L2 transaction data must either be ephemeral, as in, the invoice is reduced to a transaction ID once it is mined and the L2 transactions in it deleted, OR your wallet that uses whatever L2 implementation actually becomes its own bank and keeps only its own transaction records and no one else's.

I think the second option is more viable. In the case of multiple personal devices, you can sync your own transaction data across your local LAN or WiFi network.

[BlackHatCoiner]

NotATether and d5000, I think you should take a look on CoinPool if you haven't already. It aims to improve scalability similar to how lightning does, but in orders of magnitude more efficiently (with a few tradeoffs). I haven't read it all, and that's why I'm curiously skeptical, but if it does what it says, then on-boarding all population onto lightning may not be necessary.