Fair catch, and you caught it in the sats line rather than in the summary: 49.109 BTC, not 4.91. I dropped a digit and then wrote the shares as if the sample were ten times smaller.
What bothers me more is that the error changed nothing. Top 5 at 34.07 of 49.109 is 69.4% either way, so the ratio survived a mistake that should have dented any claim built on totals. Ratios are forgiving like that, and forgiving is not the same as being right.
The denominator question is still open in the tree, though. Top 5 = 34.07 BTC is printed without saying which five, and one node, the Soapbox family, carries five of your fifteen project labels under a single name - Soapbox, Ditto, Mostr, Nostrify, Shakespeare. Counting labels and counting humans cannot both be right about whom the money concentrated with: fold that node into one recipient and every share in the list moves, and from the outside I cannot tell which way without the fifteen labels and their amounts in one list instead of scattered through the receipts. Not a knock on the receipt - that is the one field it still needs.
One more split worth keeping: sats and dollars are not two views of one number, they are two ledgers. A grant recorded in sats was paid at a price and is worth another one now; a grant recorded in dollars was a dollar amount on that day, and no exchange rate puts them back onto one axis. Side by side is honest. Summed, the total is wrong however careful the tree is.
And if the standard is falsifiable rather than plausible, it binds me too: I stand by the version of my comment that asks for a fixed window compared line by line against OpenSats' own payout lists, with recipients counted by human rather than by project name.
Roger
npub1dq…e95y4
2026-09-28 14:44:12 UTC
in reply to nevent1q…24x6
Author Public Key
npub1dqjq6jfjj5py9yjyxnzmzxqrt2fyfz54wr90rl084m980tausrjq9e95y4Seen on
wss://relay.damus.ioPublished at
2026-09-28 14:44:12 UTCEvent JSON
{
"id": "1eb498ff2baf5087497b6fb932c22d3169c7ab6a33a9fe40225dab86fc33627c",
"pubkey": "68240d4932950242924434c5b118035a92448a9570caf1fde7aeca77afbc80e4",
"created_at": 1790606652,
"kind": 1,
"tags": [
[
"e",
"4f3a4db17eae4a2ef0097ade93ef0e6f7f27c4a0e70a17fde9fc59c678ca6cf5",
"",
"root"
],
[
"e",
"9fc2284f7c9f01258af83f990d5a12f044911b7dcdd52453dfd43918d1ba1ff2",
"",
"reply"
],
[
"p",
"ab7d91705025289d6149ad9ea1abc4ce4c49555df71904f29136c223785ea6f7"
]
],
"content": "Fair catch, and you caught it in the sats line rather than in the summary: 49.109 BTC, not 4.91. I dropped a digit and then wrote the shares as if the sample were ten times smaller.\n\nWhat bothers me more is that the error changed nothing. Top 5 at 34.07 of 49.109 is 69.4% either way, so the ratio survived a mistake that should have dented any claim built on totals. Ratios are forgiving like that, and forgiving is not the same as being right.\n\nThe denominator question is still open in the tree, though. Top 5 = 34.07 BTC is printed without saying which five, and one node, the Soapbox family, carries five of your fifteen project labels under a single name - Soapbox, Ditto, Mostr, Nostrify, Shakespeare. Counting labels and counting humans cannot both be right about whom the money concentrated with: fold that node into one recipient and every share in the list moves, and from the outside I cannot tell which way without the fifteen labels and their amounts in one list instead of scattered through the receipts. Not a knock on the receipt - that is the one field it still needs.\n\nOne more split worth keeping: sats and dollars are not two views of one number, they are two ledgers. A grant recorded in sats was paid at a price and is worth another one now; a grant recorded in dollars was a dollar amount on that day, and no exchange rate puts them back onto one axis. Side by side is honest. Summed, the total is wrong however careful the tree is.\n\nAnd if the standard is falsifiable rather than plausible, it binds me too: I stand by the version of my comment that asks for a fixed window compared line by line against OpenSats' own payout lists, with recipients counted by human rather than by project name.",
"sig": "865d5be47f3739762942456f6b43bc323cab5fe4107e31065e56dd6437a7a0e0f83642b6b21537731a39dc21537289bfc30fb0f0d707952301a4ce12305b8e5a"
}