Pages:
Author

Topic: A PIN and PoS powered second layer proposal - page 2. (Read 306 times)

copper member
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
September 23, 2019, 11:55:36 AM
#2
The PoS system seems like the one Ripple uses (with a few trusted nodes controlling the network) ?

You can't use sms for verification but you could potentially use auth codes (phone numbers are fairly easy to hijack) - you could also get them to sign something on their phone too.

This solution would also be bit slower than the current lightning network as the current network doesn't have to ping as many nodes to create a transaction.
member
Activity: 87
Merit: 40
September 23, 2019, 08:38:52 AM
#1
I have been working on a project for two years, and would like to request technical comments for the security of this implementation. I'm not saying this proposal is as secure as Bitcoin network, there is some trade off between the user convenience and security.

There are two layers of security to discuss.

1. PoS secured BTC

We have N nodes, secured by stake. N is a relatively small number, typically 35. We suppose the PoS network is secure enough and won't discuss the PoS implementation. We also suppose the PoS nodes will never change, there are always N nodes running.

The PoS network transactions are similar to those in Bitcoin, public keys, UTXOs. The only difference is that the transactions are faster and free, because the PoS and only a few nodes.

These N nodes manage a multi-sign Bitcoin address, whenever a transaction sent to this address, there should be some extra data in the OP_RETURN script to announce that the destination A of this output. Pretty much similar to deposit to a central crypto exchange and use the memo as the hint for the user.

After public key A received some BTC, they can transfer it fast in the PoS network to another public key B. Say we deposit 10 BTC to A, and A can transfer 3 to B and change 7 to themself. This transaction doesn't appear in the Bitcoin blockchain, only in the PoS network, so it's very fast and free. Very similar to the famous Lightning Network transaction.

Whenever A or B want to transfer BTC to another Bitcoin address outside of the PoS network, they initialize a transaction to tell the PoS nodes that they want to transfer. Because we have the assumption that the PoS network is secure enough, they will approve that A can only transfer out no more than 7 BTC, and B no more than 3 BTC. This process is very similar to the famous Lightning Network solution when close a channel, but much faster and easier for users.


2. PIN secured public key

Every public key in the PoS network is an EC point, so it's very easy to build m-of-n multi-sig address. Then we have a central service, which acts as an API endpoint to communicate with all the PoS nodes. For simplicity, this discussion only discuss the n-of-n multi signature.

1. The central service named Server will allow User to claim an account with phone number and SMS verification code. Server will generate N permanent secret seeds for the User and send them back to the User, the User may choose to save them. Each secret has a prefix to connect them with each node respectively.
2. User chooses a 6 digit PIN on their device, then hash the PIN with each seed to get N EC private keys. Due to the secret prefix, those private keys are connected to each node.
3. For each private key, the User sign current unix timestamp as a message and send the signature with corresponding public key to the connected node.
4. The node will check the signature matches with the public key, then produce a new EC private key by hashing the public key and its own node private key. Then respond the public key to the User.
5. User aggregates all N public key responses to a multi-sig address M, then this address is their address to receive transfers of other Users.
6. Whenever the User wants to transfer, they just repeat the step 3, but with the transaction as message payload. The node will check request signature and sign the transaction, send back the transaction signature.
7. User aggregates all N signature responses to get the final transaction signature.

Why is this secure?

1. Each node have built in rate limit to prevent brute force attacks.
2. The each node can't guess the signature to request other nodes.

The only flaw I have thought about is that the Server may lock the rate limiter for users by computing 10 million public keys to attach each nodes.

I'm sincerely welcome some comments on the security of this procedure.
Pages:
Jump to: