Gavin Andresen [ARCHIVE] on Nostr: š
Original date posted:2011-08-18 šļø Summary of this message: Gavin Andresen ...
š
Original date posted:2011-08-18
šļø Summary of this message: Gavin Andresen suggests reporting the number of confirmations differently during a chain split and proposes a confidence measure to gauge transaction reliability.
š Original message:> For vectors variant, I wonder if it'd be safe to report the number of
> confirmations differently for the duration of a chain split. If you
> have a block but a majority of peers relayed a block that split the
> chain, subtract 1 from each confirmation reported via RPC.
Or maybe report them as 'suspicious.' Changing the meaning of
'confirmations' is likely to break code (e.g. code like block =
current_blockchain[blockcount-tx.confirmations] ... would give the
wrong block).
A floating-point 0.0-1.0 'confidence' measure might be a good idea to
go along with the integer confirmations. I can think of all sorts of
ways of gauging the reliability of transactions or blocks (did it come
from a trusted peer-- assuming we eventually have trusted peers. Does
it have a lot of confirmations? Are there no active block chain
forks? Have we been getting new blocks at the rate we expect? etc
etc etc)
We could start with an as simple-as-possible "confidence == 0 if
confirmations < 2, otherwise confidence = function(#confirmations)"
and improve it from there.
--
--
Gavin Andresen
Published at
2023-06-07 02:16:31Event JSON
{
"id": "60204daf6e2287b3cc987fef8613079a4ec196aa2ad0679a337e5f577f417271",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686104191,
"kind": 1,
"tags": [
[
"e",
"dd2bd651f69ea303806455734fc808b7cc754a844f6c0cd64050fdba6244fb9a",
"",
"root"
],
[
"e",
"2029a83375756707ecaeed6424f4e8e1367c684f188f70c0aeb66285bd972922",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "š
Original date posted:2011-08-18\nšļø Summary of this message: Gavin Andresen suggests reporting the number of confirmations differently during a chain split and proposes a confidence measure to gauge transaction reliability.\nš Original message:\u003e For vectors variant, I wonder if it'd be safe to report the number of\n\u003e confirmations differently for the duration of a chain split. If you\n\u003e have a block but a majority of peers relayed a block that split the\n\u003e chain, subtract 1 from each confirmation reported via RPC.\n\nOr maybe report them as 'suspicious.' Changing the meaning of\n'confirmations' is likely to break code (e.g. code like block =\ncurrent_blockchain[blockcount-tx.confirmations] ... would give the\nwrong block).\n\nA floating-point 0.0-1.0 'confidence' measure might be a good idea to\ngo along with the integer confirmations. I can think of all sorts of\nways of gauging the reliability of transactions or blocks (did it come\nfrom a trusted peer-- assuming we eventually have trusted peers. Does\nit have a lot of confirmations? Are there no active block chain\nforks? Have we been getting new blocks at the rate we expect? etc\netc etc)\n\nWe could start with an as simple-as-possible \"confidence == 0 if\nconfirmations \u003c 2, otherwise confidence = function(#confirmations)\"\nand improve it from there.\n\n-- \n--\nGavin Andresen",
"sig": "4842134c8e1b2057ddf3f876faff6fc51f891dba04303826e97aeae6b334fb4e7d0d470aeca49aabe789431cda87a823558745368374ea316dbccfd9964fe84a"
}