š
Original date posted:2011-08-18
šļø Summary of this message: Gavin Andresen suggests adding a placeholder to the RPC interface or a signed integer "trust" rating for blocks/transactions to meet market demand for faster confirmation.
š Original message:Gregory said: "...if this causes people to wait less than the 6 blocks
that the software currently waits for before leaving unconfirmed
status then that would be sad."
People are already considering transactions 'confirmed enough' at less
than six blocks. I'm guilty, too-- 3 is/was the magic number for
ClearCoin.
And people are already experimenting with ways of safely accepting
0-confirmation transactions, like InstaWallet's "green" payments (sent
from a trusted-not-to-double-spend address).
Since there is definitely market demand for "as fast as possible"
confirmation, I'm thinking adding a placeholder to the RPC interface
might be a good idea. Although after thinking about it some more,
maybe a signed integer "trust" rating for blocks/transactions would be
a better way of doing it...
RE: miners connecting themselves together in a semi-trusted "bitcoin
backbone" : agreed.
Matt submitted a patch to connect and stay-connected to a set of
nodes, but I complained about the implementation. Seems to me the
networking code needs an overhaul, to implement a priority queue of
potential peers (trusted peers would be sorted to near the top of the
queue, peers you think are badly-behaved would be sorted to the
bottom, with lots of randomness so not everybody on the network is
trying to connect to the same set of peers). With peer rotation to
mitigate manipulate-time and other Sybil attacks.
--
--
Gavin Andresen
Gavin Andresen [ARCHIVE] /
npub1s4ā¦d44kw
2023-06-07 02:16:38
in reply to nevent1qā¦5jvg
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 02:16:38Event JSON
{
"id": "a47ff9ebe9669cda9b15e0569a835221920d2619f7c06acef454c50225886249",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686104198,
"kind": 1,
"tags": [
[
"e",
"dd2bd651f69ea303806455734fc808b7cc754a844f6c0cd64050fdba6244fb9a",
"",
"root"
],
[
"e",
"fd281cd50c441b9219b61a2d6075bedc4910718d8ed828ebf5a1b6f5f47613d7",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "š
Original date posted:2011-08-18\nšļø Summary of this message: Gavin Andresen suggests adding a placeholder to the RPC interface or a signed integer \"trust\" rating for blocks/transactions to meet market demand for faster confirmation.\nš Original message:Gregory said: \"...if this causes people to wait less than the 6 blocks\nthat the software currently waits for before leaving unconfirmed\nstatus then that would be sad.\"\n\nPeople are already considering transactions 'confirmed enough' at less\nthan six blocks. I'm guilty, too-- 3 is/was the magic number for\nClearCoin.\n\nAnd people are already experimenting with ways of safely accepting\n0-confirmation transactions, like InstaWallet's \"green\" payments (sent\nfrom a trusted-not-to-double-spend address).\n\nSince there is definitely market demand for \"as fast as possible\"\nconfirmation, I'm thinking adding a placeholder to the RPC interface\nmight be a good idea. Although after thinking about it some more,\nmaybe a signed integer \"trust\" rating for blocks/transactions would be\na better way of doing it...\n\n\nRE: miners connecting themselves together in a semi-trusted \"bitcoin\nbackbone\" : agreed.\n\nMatt submitted a patch to connect and stay-connected to a set of\nnodes, but I complained about the implementation. Seems to me the\nnetworking code needs an overhaul, to implement a priority queue of\npotential peers (trusted peers would be sorted to near the top of the\nqueue, peers you think are badly-behaved would be sorted to the\nbottom, with lots of randomness so not everybody on the network is\ntrying to connect to the same set of peers). With peer rotation to\nmitigate manipulate-time and other Sybil attacks.\n\n-- \n--\nGavin Andresen",
"sig": "305352d554db0d0c6b82fc4bcf7075affaab482ae16a5f73be835974a9ffb03268dd1490d593e185e34ede89092a722423c8d670ad23d19167b6af571c4d4bd1"
}