{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-05-15\n📝 Original message:On Wed, May 15, 2013 at 12:25:09PM +0200, Adam Back wrote:\n\nProtocols aren't set in stone - any attacker that controls enough\nhashing power to pose a 51% attack can simply demand that you use a\nBitcoin client modified to provide the attack with the full transactions\nfrom the beginning. Any blocks containing transactions with unknown\ncontents will be attacked into oblivion.\n\nOn the other hand if the \"attacker\" has less than 50% of the hashing\npower, they have no choice but to let other blocks through, and provided\nminers are free from regulation imposed on them you can bid to get your\ntransactions mined with fees. Anyone using a blockchain-based\ncrypto-currency simply has to accept that mining is a random process and\ngetting a transaction confirmed is inherently unreliable.\n\n\u003e So in a previous mail I described a simple, extremely efficient and easy to\n\u003e implement symmetric key commitment that is unlinkable until reveal time (at\n\u003e bottom).  I think this can help improve the byzantine generals problem, that\n\u003e bitcoin only defends to simple majority (with one vote per CPU power), and\n\u003e so assumes most nodes by cpu power are honest.  With this simple protocol\n\u003e change you dont need any honest nodes, just some honest clients to spend to,\n\u003e to have your transaction accepted.  \n\n-- \n'peter'[:-1]@petertodd.org\n00000000000001754b62829d854463fa72fe7d972a7b7d13d0c30fc86423773c\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130515/4fd75dd9/attachment.sig\u003e"}