| 03:11 |
punkman |
http://logs.nosuchlabs.com/log/asciilifeform/2021-07-23#1048432 << very cool |
| 03:11 |
dulapbot |
Logged on 2021-07-23 14:29:36 asciilifeform: in largely unrelated lulz of possible interest to mats . |
| 03:11 |
punkman |
https://pbs.twimg.com/media/E5P2MfoVcAUlTWD?format=jpg&name=large |
| 03:13 |
* |
punkman woke up to earthquake |
| |
~ 14 hours 23 minutes ~ |
| 17:36 |
asciilifeform |
!w poll |
| 17:36 |
watchglass |
Polling 17 nodes... |
| 17:36 |
watchglass |
185.85.38.54:8333 : Could not connect! |
| 17:36 |
watchglass |
84.16.46.130:8333 : Could not connect! |
| 17:36 |
watchglass |
185.163.46.29:8333 : Could not connect! |
| 17:36 |
watchglass |
205.134.172.27:8333 : Alive: (0.084s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 (Operator: asciilifeform) |
| 17:36 |
watchglass |
205.134.172.28:8333 : Alive: (0.023s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=692475 (Operator: whaack) |
| 17:36 |
watchglass |
205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.081s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=692465 |
| 17:36 |
watchglass |
54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.174s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 |
| 17:36 |
watchglass |
208.94.240.42:8333 : Alive: (0.160s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 |
| 17:36 |
watchglass |
143.202.160.10:8333 : Alive: (0.234s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 |
| 17:37 |
watchglass |
176.9.59.199:8333 : (static.199.59.9.176.clients.your-server.de) Alive: (0.340s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=412068 (Operator: jurov) |
| 17:37 |
watchglass |
54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.316s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 |
| 17:37 |
watchglass |
213.109.238.156:8333 : Alive: (0.398s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 |
| 17:37 |
watchglass |
205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.391s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=692475 |
| 17:37 |
watchglass |
103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.396s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=692473 |
| 17:37 |
watchglass |
71.191.220.241:8333 : Violated BTC Protocol: Bad header length! (Operator: asciilifeform) |
| 17:38 |
watchglass |
205.134.172.26:8333 : Busy? (No answer in 100 sec.) |
| 17:38 |
watchglass |
192.151.158.26:8333 : Busy? (No answer in 100 sec.) |
| |
~ 32 minutes ~ |
| 18:10 |
whaack |
!e height |
| 18:10 |
trbexplorer |
692475 |
| 18:15 |
whaack |
!e view-raw-txn 50 0 |
| 18:15 |
trbexplorer |
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d013fffffffff0100f2052a010000004341041ada81ea00c11098d2f52c20d5aa9f5ba13f9b583fda66f2a478dd7d95a7ab615159d98b63df2e6f3ecb3ef9eda138e4587e7afd31e7f434cbb6837e17feb0c5ac00000000 |
| 18:16 |
whaack |
!e view-raw-txn 51 0 |
| 18:16 |
trbexplorer |
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d0144ffffffff0100f2052a010000004341043cba05459e89a46f9f3ef8e01d07ccd4ce9fc2bb35a6508419c98883230374ce1c5e177efb612f30842cd699d1aeaeda61e720592d0518db0f9c2b9de9a2cea1ac00000000 |
| 18:26 |
asciilifeform |
whaack: wassat ? |
| 18:31 |
whaack |
asciilifeform: the parameters for view-raw-txn and view-txn be either (a) 1 parameter, the txid (hash) or (b) 2 parameters, block number and txn index |
| 18:31 |
whaack |
so i am looking at the raw bytes of the coinbase transactions for block 50 and block 51 |
| 18:31 |
asciilifeform |
watchglass: right, i recall. but what's this tx ? |
| 18:31 |
asciilifeform |
ah |
| 18:32 |
whaack |
i'm curious to see how the very old fashion "pay to pub key" transactions are structured |
| 18:32 |
whaack |
this was used for a bit before pay to public key hash became in fashion |
| 18:32 |
* |
asciilifeform recalls. the ones w/ the exposed pubs. |
| 18:33 |
whaack |
!e view-txn -paste 50 0 |
| 18:33 |
trbexplorer |
http://paste.deedbot.org/?id=2BOJ 1 of 1 |
| 18:34 |
whaack |
I should note that this prototype for my block explorer has a misnomer, I have the concept of "address" and scriptPubKey confused. |
| 18:35 |
whaack |
Whenever the scriptPubKey refers to a p2pkh, I parse the p2pkh, dump some of the opcodes, and return the base58check *address* |
| 18:35 |
whaack |
however whenever the scriptPubKey field has anything other than p2pkh, I just return the hex representation of the scriptPubKey |
| 18:36 |
whaack |
so the field "address" is returning two different concepts depending on the value in scriptPubKey |
| 18:38 |
whaack |
asciilifeform: do you have an opinion as to whether there's any benefit to storing the hash of the pub key vs the pub key? as far as i can tell it's mostly for bullshit reasons such as "extra security in case of quantum attack" (except not really since in that false reality miners can mutate the txn as they receive the value x for h(x) = y) |
| 18:38 |
asciilifeform |
whaack: it's a 'belt & suspenders' in case of algo break, nominally. and saves a little space. |
| |
↖ |
| 18:39 |
whaack |
what does belt and suspenders mean in this case? |
| 18:40 |
whaack |
does the "saving space" outweigh the extra strain it puts on nodes to compute the hash? |
| 18:40 |
asciilifeform |
whaack: the hash only gets computed when verifying the tx. i.e. 1-time expense (per noad). |
| 18:41 |
asciilifeform |
as i understand, the primary motivation wasn't to conserve disk, however. but for hypothetical 'dr. evil invents pill for ecdsa' scenario. |
| 18:42 |
asciilifeform |
and whaack is correct, if dr. evil is also miner (or in collusion w/ same), he can steal outputs as they get spent |
| 18:43 |
asciilifeform |
but this is not necessarily the only scenario -- say, phuctor-style weak-key discoveries (punkman linked to a coupla minor ones yest.) are only relevant when pubkey is exposed. |
| |
↖ |
| 18:44 |
asciilifeform |
asciilifeform however would like to remind readers that hashes are voodoo, and there is no 'proof of hardness' for collision search for any such algo, nor is likely to be. |
| |
↖ |
| 18:45 |
asciilifeform |
it is entirely possible that the cheapest means of breaking 'cold' addrs is to find such collision. |
| 18:45 |
asciilifeform |
this, rather than whatever 1-time-per-noad-life cpu cost, is imho the main down-side of p2pkh. |
| 18:47 |
asciilifeform |
in the place of shitosi, asciilifeform would've demanded that the hash must be ~longer~ than the original pubkey. to the point that the prob. of a collision existing, oughta be ~0. |
| 18:47 |
asciilifeform |
that way -- save no disk; but 'pure win'. |
| 18:47 |
asciilifeform |
but it aint as if anyone asked asciilifeform when designing this thing. |
| 18:49 |
asciilifeform |
whaack: makes sense ? |
| 18:51 |
whaack |
asciilifeform: yes, your suggestion would prevent or greatly reduce the posibility of the hypothetical scenario where an attacker is able to find another public key that whoes hash collides with the hash of the public key of the true owner |
| 18:53 |
asciilifeform |
the current scheme impeded phuctorism, but opens up for collision search. |
| 18:54 |
asciilifeform |
possibly hypothesis was that chance of a valid pubkey (i.e. one for which a priv exists) being also a collision, is 0. but there is no proof of this. |
| 18:55 |
whaack |
doesn't even need a valid private key if attacker just wants to burn someone's coins |
| 18:56 |
whaack |
ah wait nvm yes it does cuz he still needs a signature |
| |
~ 1 hours 4 minutes ~ |
| 20:00 |
punkman |
http://logs.nosuchlabs.com/log/asciilifeform/2021-07-24#1048516 << only true for attacks that benefit from knowing pub key. if you are generating random privkeys, you just hash the pubkey and then see if it matches any of the known pubkeyhashes |
| |
↖ |
| 20:00 |
dulapbot |
Logged on 2021-07-24 14:43:10 asciilifeform: but this is not necessarily the only scenario -- say, phuctor-style weak-key discoveries (punkman linked to a coupla minor ones yest.) are only relevant when pubkey is exposed. |
| 20:04 |
punkman |
also gotta reveal pubkey when spending, so hash only helps addresses that have never spent |
| 20:04 |
verisimilitude |
http://logs.nosuchlabs.com/log/asciilifeform/2021-07-24#1048517 This reminds me of something I've written: Through the rotations, this message goes; where will the bits flip, nobody knows! |
| 20:04 |
dulapbot |
Logged on 2021-07-24 14:44:51 asciilifeform: asciilifeform however would like to remind readers that hashes are voodoo, and there is no 'proof of hardness' for collision search for any such algo, nor is likely to be. |
| 20:06 |
verisimilitude |
To bingoboingo, I'd issues commenting, and made a mistake when editing my comment, thinking perhaps mentioning TMSR was the issue. If it be little trouble, I'd like ``the TSMR'' in the second paragraph replaced by ``TMSR''. |
| 20:10 |
punkman |
if I recall correctly, pubkey was used primarily to save space, nothing else |
| 20:10 |
punkman |
*pubkey hash |
| 20:12 |
punkman |
revealed pubkey was also reason for the "only use addresses once" meme, that and nonce attacks when you sign more than 1 tx |
| |
↖ |
| 20:16 |
punkman |
the wildest feature was the "pay to IP address" mechanism. I think it's still in TRB. |
| 20:17 |
punkman |
or did asciilifeform chop that thing off? |
| |
↖ |
| 20:19 |
punkman |
apparently removed in prb v0.8 https://en.bitcoin.it/wiki/IP_transaction |
| 20:27 |
punkman |
https://www.coindesk.com/thorchain-8-million-exploit-bifrost |
| 20:28 |
punkman |
https://twitter.com/THORChain/status/1418360743523618825 "The hacker deliberately limited their impact, seemingly a whitehat." << lol why |
| 20:29 |
punkman |
"THORChain is too important not to deliver on. |
| 20:29 |
punkman |
The complexity of the state machine is currently its archille's heel, but this can be solved with more eyes on, as well as a re-think in developer procedures and peer-review. Thanks all for support, there's only one way forward." |
| |
↖ |