Topic: Looking for feedback on a new scaling solution - Project Boreas (Read 300 times)

exact same reason no dev and no user should move satoshi nakamoto 2009 stash..
his key his property his discision or loss..

...
the 15 address 'treasury block' is actual bitcoin signed to the group of actual bitcoin held 15 addresses
a level below that is offchain transactions where the manager and user combine and make smart contracts away from bitcoin network
i presume that because the user address is not an actual bitcoin network broadcasted tx but just visible only in the borreas network. they can just trash the altcoin blocks and just use their 10 of 15 treasurer sigs to combine efforts in a full treasurer settlement

EG
imagine bc1qsMan1...      is the treasury address for manager1 where real bitcoins on bitcoins blockchain puts real coins

on borreas. the user+manager1 and other treasurers make a 'borreas address' for user transactions OFFCHAIN:
bc1qsMan1 (9)->  3Borr345U5r123 (3)
                           3Borr345u5R246 (3)
                           3Borr345U5r369 (3)
^these 3borr transactions are NOT on the bitcoin blockchain but what IS in the borreas protocol/network which the borreas network accepted as active./valued 'as real' and locked where all users and services can see within borreas

as long as borreas is active and running it has to abide by the rules of user request needed to move funds within borreas. but obviously if borreas fails. then the only real funds exist in the bc1qsMan1 address
the treasurers just move funds from the bc1sdMan1 address

the borreas network should ofcourse while active and running be checking that no funds move from the bc1qsman address without a 3Borr address request.
if it does happen. then yea borreas network is broke and trust is lost

so.. in essense the treasures can claim back the lost coins of users offline.. but only if/when they break borreas network

There are a lot of good books about the Bitcoin Technology and even the Ethereum Network and its general functions. I dont know how deep you want to dive into that topic, but to get clear with its technical functions i can recommend the book Mastering Ethereum. The principles behind the crypto nodes and the closed p2p network are the same.

https://github.com/ethereumbook/ethereumbook/blob/develop/book.asciidoc

I've modified the living whitepaper and redid the math. Also, the whitepaper is now just a Notion page.

Okay, I've completely overhauled the whitepaper. Instead of being on the wiki, I'm uploading it as a pdf for now. It is easier to maintain since Github Markdown doesn't seem to support LaTeX. If anyone knows how to create equations in Github Markdown, let me know!

Living Whitepaper: https://www.notion.so/davidnettey/Scaling-Bitcoin-Through-Off-chain-Verification-and-On-chain-Settlement-d1b59017badd4707b6fadf7db620d7f2

The gist of the pivot is this:

• No longer using ORV as the consensus mechanism
• Using Avalanche as consensus mechanism
• The second layer network now acts like a decentralized payment processor
• Users control their own funds

Abstract:

Bitcoin was created as a new type of currency that could improve on the short falls of fiat currencies. It is decentralized, permission-less, immune to hyperinflation, and open source. Despite all these advantages, it does have flaws and limitations. One of the most pressing limitations in Bitcoin is scaling. Bitcoin has a low transaction throughput, about 3 to 7 transactions per second [5]. When the network is congested, transaction fees can skyrocket. In order for Bitcoin to be used widely as a peer to peer cash system, it must solve its scaling issues.

To increase transaction speeds, we can make use of a second layer network. This network will act as a verification layer, allowing transactions to be viewed and spent much faster. The Avalanche consensus mechanism will be used to track and verify transactions off-chain. The Bitcoin network will act as the settlement layer. A user's wallet will periodically post a clearing transaction to the Bitcoin network containing verified but unsettled transactions. In order to save on fees, the clearing transaction will be comprised of multiple off-chain transactions. The second layer network essentially acts as a decentralized, trustless bank card issuer and payment processor for the Bitcoin network.

Let me know if there are any improvements I can make!

Thanks for your patience, I really appreciate it!
So the essential key would always be in the custody of the user (i.e. never backed up via secret sharing)? If so, how would we recover funds in the address if the user were to ever go offline, like if their phone were destroyed?
I ask this because that address would be part of the treasury. If someone wanted to move bitcoin out of the network, to cold storage for example, the network would need to be able to perform the transaction using the address if necessary. If there was ever a run on the network, I'd like for everyone to be able to get their sats back.

Ah okay, you were just using 15 nodes in the network as a whole for an example.

Good point. I didn't take the remaining third into consideration. How about this:
     a. Each node creates a random shared secret
     b. The nodes elect a random node
     c. The elected node puts together 2/3 of the shared secrets to generate a new secret. This will be the network's private key.
     d. The elected node creates new shared secrets and distributes them to each node on the network
This way any 2/3 of the network can reproduce the key, including the third left out when the key was originally created. I chose 2/3 since it seems to be the standard assumption for BFT systems, that at least 2/3 of the nodes are honest.

Can you elaborate more on this?


I really like this idea. It stops any one party from accessing the funds without the permission of the other. Maybe this could be combined with the secret shares algorithms to make sure the funds are always accessible.

I really like the idea of having the users work together with nodes on the network in order to deposit into or withdraw from the treasury. I might be misreading your post but it sounds like the treasury is rather dependent on these 15 manager nodes. How about each deposit into the network has its own multi-sig address? The address can formed like this:
 
1. The user generates a private key using a shared secret algorithm.
2. The nodes on the network generate a private key:
     a. Each node creates a random shared secret
     b. The nodes elect a random node
     c. The elected node puts together 2/3 of the shared secrets to generate a new secret. This will be the network's private key.
3. The elected node and the user both create a public key from their respective private keys
4. The multi-sig address is formed from the public keys and propagated through the network
5. The user sends a shared secret to each node online at the time. It would take 2/3 of the nodes online at the time to reconstruct the private key.

At the end of this process each node should have the address, their own shared secret, and a shared secret from the user. All the multi-sig addresses generated this way are the "treasury". If someone needs to transfer funds outside the network, the nodes can coordinate to recover bitcoin in these addresses. The private keys are backed up on the network without any one node knowing all two keys required to unlock the address. Since the treasury is spread out across different addresses, there isn't a single point of failure. If one address in compromised, the other addresses are likely to be safe.

A malicious actor could take funds out of an address in two ways:

1. Control 2/3 of the network at the time the address was made
2. Control the user and the randomly elected node at the time the address was made

First one could be deterred through normal anti-Sybil attack countermeasures like staking or PoW. The second one is tougher. Sybil attack countermeasures can help keep the bad actor from spamming nodes. The randomness makes it less likely the bad nodes get picked the larger the network becomes. I'm having trouble thinking of other ways around this. Another thing is that I would be worried about how much bandwidth a protocol like this could take up.

I've been doing research on alternative consensus mechanisms and I came across Avalanche consensus. It seems to fit what I'm looking for! It seems very scalable and fast. The only issues I have with it is that it doesn't seem to have a baked in way to prevent spam and Sybil attacks. These can be deterred by using existing methods such as staking for Sybil attacks and small amounts of proof of work for spam, among other methods.

Any thoughts on it?

a side note... be carefull about QV, especially about bounded-nature of probability in less-than-ideal contexts. Inspired by a Vitalik Buterin blog post, I wrote something about it here, if it can help you:

https://medium.com/@baro77/quadratic-payments-with-constrained-probabilities-b40facba716?sk=60199e8bea21a8c0e6820791435aa6f0

Gotcha, I was trying to keep to the language that Nano uses when describing their tech. I just went through the Nano description in the living whitepaper and made some changes for clarity.
Let me know what you think!

Could you give me a couple examples? I'd like to list them as issues to discuss on Github as well.

To separate the wallets (mobile users) from the nodes, I think I'll change it so that the treasury is one multi-sig address. Each private key is protected and backed up by a shared secret algorithm. I explain in detail here: https://github.com/netteydavid/ProjectBoreas/issues/3
As for the hub problem, I've been thinking of ways to improve or completely replace ORV. I'm cataloging ideas here: https://github.com/netteydavid/ProjectBoreas/issues/2. An improvement idea, as mentioned by dkbit98, is to implement some sort of quadratic voting system.

Thanks for the feedback!

I'll go through the living whitepaper and clear that up, thanks!

I was unsure what else to put in the README since the project is brand new. I'll add stuff like the goal of the project and info on contributing.


Thanks for the feedback!

Thanks for the feedback! Good point on the bitcoin whales. I didn't take that into consideration. I'll do more research on quadratic voting.
I opened an issue about alternatives or improvements for ORV. Any thoughts on the comment I posted there?
Link: https://github.com/netteydavid/ProjectBoreas/issues/2#issuecomment-796400209

Sybil Attack is not so easy to solve and I don't like solution you have for each vote to be weighted by account's balance, that would give huge voting power to whales without some quadratic voting solution.
Also you say that accounts with zero balance would not count, but what if I create many accounts with some minimal balance just enough to get multiple votes, or imagine scenario if bitcoin whale splitting his bitcoin in multiple addresses to gain more power.
Not so hard to imagine attacks on network or making it totally centralized.

My curiosity about Bitcoin has been on and off for the past couple years. Predictably, my curiosity about the technology and its implications usually peaked with the market. This year, I decided to just dive fully into the ocean that's Bitcoin and cryptocurrency. I've been absorbing as much information as I could for the past couple months. Reviewing myself on how Bitcoin works and learning about how other cryptocurrencies work. I've also committed financially. Glad to say that I'm on my way to owning at least one Bitcoin!

I'm a developer, so what excites me at heart is the technology behind Bitcoin. I have no idea how Nakamoto thought of this, but the dude's a genius. But like most of you know there are tradeoffs with proof-of-work and the blockchain. What I'm concerned the most about is the speed of transactions and the fees. So I learned about the Lightning Network. I have high hopes for the project, but I really wanted to take a shot at creating a scaling solution. I also wanted to contribute to the community, both Bitcoin and the open source community. So I've created something I call Project Boreas.

I was inspired by the fee-less and fast transaction speeds in the Nano network. I thought maybe something similar to their technology could be applied to a second layer network. I wrote up my first whitepaper and published it on a Github repository. I also created a living whitepaper so that any changes can be put there while keeping the original. Also, I plan on making the project open source so anyone can use the idea.

Right now, the original and living whitepaper is all I have on the repository. I'd really appreciate it if anyone could critique the paper. Any helpful criticism is welcome. It can be spelling, grammar and structure. Critiques on the soundness of the idea itself are especially welcome. Thanks!

Github: https://github.com/netteydavid/ProjectBoreas

Original whitepaper: https://github.com/netteydavid/ProjectBoreas/blob/main/Directed_Acyclic_Graphs_as_a_Second_Layer_Scaling_Solution_for_Bitcoin.pdf

Living Whitepaper: https://www.notion.so/davidnettey/Scaling-Bitcoin-Through-Off-chain-Verification-and-On-chain-Settlement-d1b59017badd4707b6fadf7db620d7f2

Issues: https://github.com/netteydavid/ProjectBoreas/issues