| 02:03 |
* |
asciilifeform thinking further re the algo -- can be simplified as follows : |
| |
↖ |
| 02:03 |
dulapbot |
Logged on 2021-09-13 16:25:46 asciilifeform: sooo punkman , cgra , et al: let's try this 'solution' on for size : |
| 02:04 |
asciilifeform |
1) any message where bounces==0 and Speaker is not in H is rejected. |
| 02:04 |
dulapbot |
Logged on 2021-09-13 16:43:42 asciilifeform: i.e. an attempted impersonation by someone in the victim's l1. |
| 02:05 |
asciilifeform |
2) ~every~ hearsay message (rather than strictly in-wot hearsay) is embargoed for a configurable interval. |
| 02:05 |
dulapbot |
Logged on 2021-09-13 16:36:56 asciilifeform: proposes a value of 1s for 'Td' . |
| 02:06 |
asciilifeform |
3) within this interval, the number of distinct peers who sent a bounces==1 duplicate of the message is counted. |
| 02:06 |
dulapbot |
Logged on 2021-09-13 16:38:33 asciilifeform: in fact already specified this in 4.1.2.2.2. In-WOT Hearsay. simply, now also count the # of peers from whom got bounce<=1 dupes of a given msg. |
| 02:07 |
asciilifeform |
4) if this number is 3 or less, the message is displayed in the format e.g. ' asciilifeform(cgra,signpost,punkman): .... ' where the handles in the parens are the peers who sent in the bounces==1 hearsay copies of the msg |
| 02:07 |
asciilifeform |
... if the number is 4 or more, then the format ' asciilifeform(4): .... ' is used. |
| 02:09 |
asciilifeform |
^ oughta be configurable on station, the exact value is an aesthetic preference. |
| 02:10 |
asciilifeform |
the count represents simply the number of distinguishable 'simultaneous' (w/in ~1s) paths which the message took to reach your console. |
| 02:12 |
asciilifeform |
nao a forgery would need to be injected via the peripheral (i.e. non-common) peers of N of your peers ~simultaneously~, to have a shot of fooling you. |
| 02:12 |
asciilifeform |
on top of this, we retain the selfchain mechanism, which continues to work a++ for folx who have decent net connections. |
| 02:13 |
* |
asciilifeform sees this as adequate solution ; invites comment. and will bbl. |
| |
~ 5 hours 57 minutes ~ |
| 08:10 |
punkman |
https://www.theartnewspaper.com/news/hermitage-goes-virtual-with-nft-exhibition |
| |
~ 1 hours 4 minutes ~ |
| 09:14 |
punkman |
Here's idea following from: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-13#1057933 |
| 09:14 |
dulapbot |
Logged on 2021-09-13 14:36:02 punkman: if we forget about packet size limitation, I suppose message could contain N encrypted copies, one for each peer, and hearsay broadcast now has meaningful sig for recipient, even if not received directly |
| 09:20 |
punkman |
suppose we put an HMAC(Message) next to Message in Red Packet. Maybe Peer1 can somehow aggregate one HMAC for each of his peers, into a single HMAC(Message) that doesn't take up N*64 bytes |
| |
↖ |
| 09:22 |
punkman |
now Peer2 can forward Peer1's message to Peer3, and Peer3 checks for "is HMAC(K_1, Message) in AGGREGATE-HMAC(Message)", and can thus verify that the forwarded message was indeed signed by Peer1 |
| 09:24 |
punkman |
maybe Peer1 can make a Bloom filter that can hold (number of peers)*2 64byte strings, he calculates HMAC(K_N, Message) for each peer, puts it in Bloom filter, and uses that as the AGGREGATE-HMAC |
| 09:28 |
punkman |
now if you peer with a new person and he tries to getdata, neither you or other peers can send him the old packets, they must be reground by original speaker so AGGREGATE-HMAC includes HMAC for the new peer. |
| 09:29 |
punkman |
so new peer can only getdata directly from you, and doesn't even need the inner AGGREGATE-HMAC to verify it's coming from you |
| 09:31 |
punkman |
question is how small can we make this Bloom Filter, while keeping the "is HMAC(K_1, Message) in AGGREGATE-HMAC(Message)" operation reliable/secure |
| |
~ 31 minutes ~ |
| 10:03 |
punkman |
found a couple related papers: https://cacr.uwaterloo.ca/techreports/2012/cacr2012-32.pdf https://www.cs.umd.edu/~jkatz/papers/aggregateMAC.pdf |
| |
~ 2 hours 10 minutes ~ |
| 12:13 |
PeterL |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-13#1057913 << RE. handle collisions: you can ask politely that one of the two change their name, but iiuc that would require setting up new connections with each of their peers? |
| 12:13 |
dulapbot |
Logged on 2021-09-13 14:25:56 asciilifeform: punkman: say asciilifeform has peers a,b,c. punkman has peers x,y,z. asciilifeform and punkman became peers. |
| 12:16 |
punkman |
if Peer2 wants to send "Peer1 says he luvs cock" to Peer3, he could generate a filled up bloom filter with a XX% false positive rate, and then HMAC(K3<->1, FakeMessage) will pass the test XX% of the time. |
| 12:16 |
punkman |
so Peer3 must be able to verify that the Bloom filter has a small enough false positive rate |
| |
↖ |
| 12:17 |
punkman |
which I think can be done like this: https://en.wikipedia.org/wiki/Bloom_filter#Approximating_the_number_of_items_in_a_Bloom_filter |
| 12:23 |
punkman |
PeterL: even if one of the Joes decides to be "Joe_2", now everyone that has logs/cache must go and change, if logs are to keep making sense |
| |
↖ |
| |
~ 42 minutes ~ |
| 13:06 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-14#1058098 << imho terrible idea. there's what, 320 message bytes avail. to cannibalize for such a pseudosig; even if you leave only a pittance for the msg text itself -- that's still a very small space, while a wot could be ANY # of entries |
| 13:06 |
dulapbot |
Logged on 2021-09-14 05:20:19 punkman: suppose we put an HMAC(Message) next to Message in Red Packet. Maybe Peer1 can somehow aggregate one HMAC for each of his peers, into a single HMAC(Message) that doesn't take up N*64 bytes |
| 13:06 |
asciilifeform |
if i have 500 peers, and the aggregate is only 4x larger than a standard hmac, what do you suppose will happen. |
| 13:07 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-14#1058108 << it trivially won't. and meanwhile adds mega-overhead to all processing. |
| 13:07 |
dulapbot |
Logged on 2021-09-14 08:16:50 punkman: so Peer3 must be able to verify that the Bloom filter has a small enough false positive rate |
| 13:07 |
asciilifeform |
it is difficult imho to think of a worse idea for pest. |
| 13:08 |
* |
asciilifeform doesn't even understand why to contemplate any such thing, when reasonable solution already posted. |
| 13:08 |
dulapbot |
Logged on 2021-09-13 16:25:46 asciilifeform: sooo punkman , cgra , et al: let's try this 'solution' on for size : |
| 13:08 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-14#1058110 << mno ? so, trinque turned into signpost , do 'logs must change, to make sense' ? why ? |
| 13:08 |
dulapbot |
Logged on 2021-09-14 08:23:28 punkman: PeterL: even if one of the Joes decides to be "Joe_2", now everyone that has logs/cache must go and change, if logs are to keep making sense |
| |
~ 48 minutes ~ |
| 13:57 |
punkman |
asciilifeform: yes never mind about the logs |
| 13:59 |
punkman |
per simple calculator: 120bytes gives you 100 item bloom filter with 1% false positive, 180 bytes for 100 items 0.1% false positive |
| 14:00 |
punkman |
not great for 500 peers |
| 14:00 |
punkman |
and you'd have to process 500 MACs |
| 14:01 |
asciilifeform |
500macs per se aint fatal, they parallelize (speaking here of the ordinary kind, rather than lossy) |
| 14:06 |
asciilifeform |
punkman: the problem is elementarily that the bottle is finite but the water, if you will, is unbounded |
| 14:08 |
punkman |
do you suppose you will ever have 500 peers, meaning 500 people with GPG keys, and exchange secrets with all of them? |
| 14:09 |
asciilifeform |
punkman: likely not. but not prepared to say 'well you oughtn't have moar than x.. and btw probability of forgery will go up geometrically with # of peers' |
| 14:09 |
asciilifeform |
right now the only limit for peer count is how many cpu cores you can spare |
| 14:12 |
punkman |
suppose you had 500 people in WOT, 2-3 times Dunbar number, is it so wrong to say that "I can only fit 100 in my living room" |
| 14:12 |
asciilifeform |
punkman: i find the very principle of climbing forgery %rate unacceptable. |
| 14:12 |
asciilifeform |
bloom filter exemplifies errything asciilifeform despises about heathen crypto. |
| 14:13 |
asciilifeform |
the crypto is to function identically regardless of # of peers. or it's hokum. |
| 14:14 |
punkman |
1 in 100 false positive with 100 people, means if I generate message+random bloom filter, I need to send to ~100 peers for 1 to believe in forgery, then you can also add in that "bogosity" measure |
| 14:15 |
asciilifeform |
mno. simply means you need to generate 100 forgeries. |
| 14:15 |
asciilifeform |
(in practice, ~50) |
| 14:15 |
punkman |
if I send more than 1 forgery, you can already sound alarm |
| 14:16 |
punkman |
we have selfchain |
| 14:16 |
asciilifeform |
punkman: i aint using lossy crypto. i aint participating in a network that uses lossy usg.crypto. this is asciilifeform's final word on bloom filters. |
| 14:17 |
punkman |
and if we also think about the commitment scheme, then I need to send message and reveal random for you to have correct random in forgery |
| 14:17 |
asciilifeform |
punkman: lol how many bytes wouldja then leave for text ? |
| 14:17 |
asciilifeform |
if yer eating 100 for blomism, anuther 64 (32 : H(R), 32 : R') for committment ? |
| 14:19 |
asciilifeform |
156 for msg is kinda laffable imho |
| 14:20 |
asciilifeform |
anyways i utterly , thoroughly fail to grasp the point of this horror show, when one can simply print the # of peers who duped-with-bounces==1 a given hearsay. as detailed yest. |
| 14:20 |
asciilifeform |
each such peer counted is effectively equivalent to that msg carrying that peer's sig. |
| 14:22 |
punkman |
no particular point, just derping out loud. might be useful for different application |
| 14:24 |
punkman |
was also thinking about commitments and ended up with horror show of a hash-based signature scheme |
| 14:24 |
punkman |
what does asciilifeform think of hash-based sigs as replacement for GPG signing? |
| 14:26 |
asciilifeform |
punkman: i've a canonical piece re subj |
| 14:26 |
asciilifeform |
(only practical imho for emergency use) |
| |
~ 1 hours 9 minutes ~ |
| 15:35 |
asciilifeform |
!w poll |
| 15:35 |
watchglass |
Polling 17 nodes... |
| 15:35 |
watchglass |
185.85.38.54:8333 : Could not connect! |
| 15:35 |
watchglass |
84.16.46.130:8333 : Could not connect! |
| 15:35 |
watchglass |
185.163.46.29:8333 : Could not connect! |
| 15:35 |
watchglass |
71.191.220.241:8333 : (pool-71-191-220-241.washdc.fios.verizon.net) Alive: (0.035s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 (Operator: asciilifeform) |
| 15:35 |
watchglass |
205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.082s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 |
| 15:35 |
watchglass |
54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.111s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 |
| 15:35 |
watchglass |
205.134.172.26:8333 : Alive: (0.146s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=700531 |
| 15:35 |
watchglass |
208.94.240.42:8333 : Alive: (0.159s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 |
| 15:35 |
watchglass |
205.134.172.28:8333 : Alive: (0.144s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=700531 (Operator: whaack) |
| 15:35 |
watchglass |
205.134.172.27:8333 : Alive: (0.293s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700419 (Operator: asciilifeform) |
| 15:35 |
watchglass |
143.202.160.10:8333 : Alive: (0.294s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 |
| 15:35 |
watchglass |
54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.262s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=700402 |
| 15:35 |
watchglass |
213.109.238.156:8333 : Alive: (0.416s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 |
| 15:35 |
watchglass |
103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.643s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700419 |
| 15:36 |
watchglass |
176.9.59.199:8333 : Violated BTC Protocol: Bad header length! (Operator: jurov) |
| 15:36 |
watchglass |
192.151.158.26:8333 : Busy? (No answer in 100 sec.) |
| 15:36 |
watchglass |
205.134.172.6:8333 : Busy? (No answer in 100 sec.) |
| |
~ 1 hours 8 minutes ~ |
| 16:45 |
PeterL |
Does pest need 64 bytes for the signature? Could a smaller signature be used, and allow a correspondingly larger message size? |
| 16:49 |
asciilifeform |
PeterL: how much of a diff would 32 extra byte of text payload make ? you still need 2 to cover a max len irc msg |
| 16:50 |
b |
hi asciilifeform. what is the reserved field in pest packets for? |
| 16:50 |
asciilifeform |
hi b. ( who might you be ? ) -- answered in earlier thrd. |
| 16:50 |
dulapbot |
Logged on 2021-09-10 16:30:04 asciilifeform: PeterL: so that all other fields 32bit-word-align. |
| 16:51 |
bomolochus |
ah, only grepped spec. |
| 16:51 |
asciilifeform |
b: do we know one another ? how didja come across dulapnet ? |
| 16:51 |
asciilifeform |
err, bomolochus ^ |
| 16:51 |
bomolochus |
historically ben_vulpes |
| |
↖ |
| 16:52 |
asciilifeform |
a. |
| 16:52 |
asciilifeform |
bomolochus: i.e. he introduced you? or yer ben under new nick |
| 16:52 |
asciilifeform |
( if the latter, plox to ping signpost (aka trinque) to update yer deedbot reg ) |
| 16:53 |
bomolochus |
fancy, glad to see the continuity |
| 16:53 |
bomolochus |
will do |
| 16:54 |
asciilifeform |
bomolochus: wb! then |
| 16:54 |
asciilifeform |
errything's continuous, http://logs.nosuchlabs.com/log/ goes back to 'dawn of time', searchable/linkable |
| 16:55 |
* |
bomolochus blows dust off finger-macros |
| 16:55 |
asciilifeform |
quite a few of the old playing characters are here |
| |
~ 1 hours 12 minutes ~ |
| 18:07 |
asciilifeform |
bomolochus: don't hesitate to ask about the pest spec (didja get a chance to read whole thing? and threads?) -- or anyffin else |
| |
~ 1 hours 10 minutes ~ |
| 19:17 |
bomolochus |
i've read the spec, but it deserves a second pass. haven't read all of the logs threads yet, but some. |
| 19:24 |
asciilifeform |
bomolochus: very much a work in progress; rekey section not written yet; the hearsay mechanism from yest. -- ditto |