{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-20\n📝 Original message:\u003e On Jun 20, 2015, at 4:47 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e \n\u003e \n\u003e\u003e On Jun 20, 2015, at 4:16 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e \n\u003e\u003e On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e\u003e\u003e The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…\n\u003e\u003e \n\u003e\u003e I disagree with this premise. Please, don't take this as an argument\n\u003e\u003e from authority fallacy, but I will cite Satoshi to express what I\n\u003e\u003e think the assumptions while using the system should be:\n\u003e\u003e \n\u003e\u003e \"As long as a majority of CPU power is controlled by nodes that are\n\u003e\u003e not cooperating to attack the network, they'll generate the longest\n\u003e\u003e chain and outpace attackers.\"\n\u003e\u003e \n\u003e\u003e I can't say for sure what was meant by \"attacking the network\" in this\n\u003e\u003e context but I personally mean trying to rewrite valid and\n\u003e\u003e proof-of-work-timestamped history.\n\u003e\u003e Unconfirmed transactions are simply not part of history yet. Ordering\n\u003e\u003e unconfirmed transactions in a consensus compatible way without a\n\u003e\u003e universal clock is impossible, that's why we're using proof of work in\n\u003e\u003e the first place.\n\u003e\u003e \n\u003e\u003e Alternative policies are NOT attacks on the network.\n\u003e \n\u003e Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.\n\u003e \n\u003e - Eric Lombrozo\n\nI think the misunderstanding was in perhaps my earlier statement seemed like I was suggesting that it’s the protocol’s responsibility to protect merchants from double-spends. On the contrary - I think we agree - the protocol CANNOT make any guarantees to ANYONE until we do converge on a history. The “design” I speak of here is more on the merchant side.\n\n- Eric Lombrozo\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/1ecc0abe/attachment.sig\u003e"}