📅 Original date posted:2015-02-12
📝 Original message:On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> Why don't you use getrawmempool RPC call to synchronize mempool contents?
Since RPC interface does not scale to serve a multi user service.
In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.
POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only.
These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.
On Feb 12, 2015, at 8:45 AM, Peter Todd <pete at petertodd.org> wrote:
> IOW, assume every transaction your "border router" gives you is now the
> one and only true transaction, and everything conflicting with it must
> go.
You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting
double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .
Tamas Blummer
Bits of Proof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/69bb8178/attachment.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 15:30:07
in reply to nevent1q…4xfr
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 15:30:07Event JSON
{
"id": "0e9d1dac32912b7590151899e272f5ccf9e60eefbd99e658dcff0f767c631c1c",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686151807,
"kind": 1,
"tags": [
[
"e",
"ba772dbf5c965827fc712af37e2abb78447348cb2e1023b6358796cc65e7b8fb",
"",
"root"
],
[
"e",
"d2a1fbe6c19f191805e3f742f69c1556f986cb94437e7659f8e7c2a419bf29bc",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 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",
"sig": "330d176403fa69dc7b59c852b9ac075c99146037419dff3131f3e20a1d18e18ceb9caec43e8a5f6f7c81aa792b97cc91b8ca67b82cf2313f0d76ab0ba6fa1117"
}