rich1.0npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjthttps://nostr.ae/npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtnjumphttps://nostr.ae📅 Original date posted:2015-02-12 📝 Original message:Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike at plan99.net>: >> >> Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. > > It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having the disadvantages of centralised trust. That trust you put in them is extremely limited, and temporary. First of all, the standard multisignature notary model applies like how I originally described it in my blog post over a year ago. You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. After confirmation in the blockchain, you have standard Bitcoin transaction security. To profit, the notary would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. To provide security for high value transactions, NRW adds a collateral transaction that the notary stands for and signs in advance, and gives to the seller. The key here is that it is constructed such that if the original payment gets doublespent, then this collateral transaction to the seller becomes spendable. So there is two outcomes - either the customer or the notary pays the seller. The customer can't force a doublespend. The notary can't steal or freeze funds (due to nlocktime fund recovery option). The seller knows he'll get the funds for sure before delivering the goods. Nobody is at risk. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/be689276/attachment.html>