Topic: MultiSig Broadcast Network (Read 755 times)
Thanks alot for the insightful reply.
I don't think it ever got beyond a concept. The preferable solution is to use the existing decentralize message relaying network called Bitcoin. 
There is a risk that an attacker would use partially signed transactions to flood the network at no or minimal cost. Some DOS prevention mechanism is needed to ensure the network is hardened against that type of an attack. The reason bitcoin nodes enforce a minimum fee to relay some transactions, is to protect the network from this type of attack. The min fee to relay has nothing to do with compensating miners (a common misconception), miners can already include whatever transactions they like in the next block regardless of what rules nodes follow for relaying transactions.
At its core Bitcoin IS a message relay system. Nodes share information by propagating messages to peers . Blocks, transactions, alerts, peer data are all passed as messages. All the low level plumbing (peer discovery, bootstrapping, versioning, node banning, message encoding, etc) has already been written. The network is robust in terms of reach and uptime. Creating a new "partially signed tx" message is trivial, figuring out how keep an attacker from abusing that new feature isn't as trivial but is solvable. A couple of ideas come to mind. The first would be to for nodes to require and verify a "proof of work" attached to partially signed message before relaying. It couldn't be SHA-256 based because ASICs are just too efficient but other proofs of work may be effective. A second option would be a proof of burn where the message creator references a transaction where they previously destroyed a minimum number of coins as a provable cost. Lastly it is possible that it could be accomplished with some good old fashion relay volume limits and node banning but that would need to be carefully tested.
If someone wanted to build a third party relaying network, they are still going to need to ensure the network is hardened against DOS attacks. Once built, deployed, and tested, it would make sense for it to be incorporated into Bitcoin clients. So a good place to start for any proof of concept would be to fork the existing codebase. That would make it easy to integrate that functionality back into Bitcoin and it would save the developer a lot of time reinventing the wheel (peer discovery, bootstrapping, message parsing, etc).
There is a risk that an attacker would use partially signed transactions to flood the network at no or minimal cost. Some DOS prevention mechanism is needed to ensure the network is hardened against that type of an attack. The reason bitcoin nodes enforce a minimum fee to relay some transactions, is to protect the network from this type of attack. The min fee to relay has nothing to do with compensating miners (a common misconception), miners can already include whatever transactions they like in the next block regardless of what rules nodes follow for relaying transactions.At its core Bitcoin IS a message relay system. Nodes share information by propagating messages to peers . Blocks, transactions, alerts, peer data are all passed as messages. All the low level plumbing (peer discovery, bootstrapping, versioning, node banning, message encoding, etc) has already been written. The network is robust in terms of reach and uptime. Creating a new "partially signed tx" message is trivial, figuring out how keep an attacker from abusing that new feature isn't as trivial but is solvable. A couple of ideas come to mind. The first would be to for nodes to require and verify a "proof of work" attached to partially signed message before relaying. It couldn't be SHA-256 based because ASICs are just too efficient but other proofs of work may be effective. A second option would be a proof of burn where the message creator references a transaction where they previously destroyed a minimum number of coins as a provable cost. Lastly it is possible that it could be accomplished with some good old fashion relay volume limits and node banning but that would need to be carefully tested.
If someone wanted to build a third party relaying network, they are still going to need to ensure the network is hardened against DOS attacks. Once built, deployed, and tested, it would make sense for it to be incorporated into Bitcoin clients. So a good place to start for any proof of concept would be to fork the existing codebase. That would make it easy to integrate that functionality back into Bitcoin and it would save the developer a lot of time reinventing the wheel (peer discovery, bootstrapping, message parsing, etc).
I can remember there was a talk over here or on reddit talking about a practical implementation of MultiSig when it comes to signing keys located all around the world.
Instead of passing the partially signed TX around and let others sign it some guy proposed to have a P2P network for that.
Unfortunately I cannot remember the source?
Anyone? Any updates?
Instead of passing the partially signed TX around and let others sign it some guy proposed to have a P2P network for that.
Unfortunately I cannot remember the source?
Anyone? Any updates?
Jump to: