{"type":"rich","version":"1.0","author_name":"npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8","author_url":"https://nostr.ae/npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-12\n📝 Original message:On Feb 12, 2015, at 9:16 AM, Alex Mizrahi \u003calex.mizrahi at gmail.com\u003e wrote:\n\u003e Why don't you use getrawmempool RPC call to synchronize mempool contents?\n\n\n\nSince RPC interface does not scale to serve a multi user service.\nIn absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.\n\nPOW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. \nThese simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.\n\n\nOn Feb 12, 2015, at 8:45 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e IOW, assume every transaction your \"border router\" gives you is now the\n\u003e one and only true transaction, and everything conflicting with it must\n\u003e go.\n\n\nYou are right that the assumption about the one and only transaction have to be relaxed. Broadcasting \ndouble spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .\n\nTamas Blummer\nBits of Proof\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.sig\u003e"}