12000+ entries in 0.02s
mod6: lol, that's probably gonna be way low, but i'll stick with it.
mod6: I'll say 1431 b0rk3d moduli.
mod6: as far as broken moduli? or dups?
mod6: I support no such futher complixity in V/vdiff to deal with these blobs. No one-offisms, etc.
mod6: That said, I'm not positive what is a favorable solution to this. For me, I guess I would have considered a disjointed genesis. All code in a genesis.vpatch, plus a comment in the code or README.txt file that points to a clearsigned, base64 encoded deed of the (repeatably extractabale) binary (image in this case).
mod6: All in all, I agree that blobs do not belong in a vpatch. As stated, they are for readable, grokable, text only.
mod6 catches up on megal0g
mod6: ok yah got 442`826 nao
mod6: (ive been truncating mine on the regular because testing & such)
mod6: 86M /mnt/btc-dev/.bitcoin/debug.log
mod6: 114G /mnt/btc-dev/.bitcoin
mod6: <+ben_vulpes> in gb, silly
mod6: mircea_popescu: currently, "blocks" : 442825
mod6: so, if we wanna go backwards, we'd have to create another similar method to go backwards with something like pindex = pindex->pprev. and this doesn't seem wholly better than what exists. i guess i did think about this about last week, but just figured putting in less code is better.
mod6: The function 'importprivkey' uses an existing wallet.cpp function called CWallet::ScanForWalletTransactions, where you pass this a pointer to the CBlockIndex you want to ~start~ from, then this just iterates forward. by pindex - pindex->pnext;
mod6: asciilifeform: also, there is a techincal reason for going front -> back, as opposed to back -> front.
mod6: Alas, a window into what has been happening for the last 9 days. :]
mod6: There are maybe a few others that will help as well; maybe a rawtx signing function, and maybe something that decodes rawtxs, maybe also some script decoding?
mod6: Not the end all be all, but a starting point.
☟︎ mod6: So I've created a patch that so far puts in the ability to view 'listunspent' UXTOs in the wallet.
mod6: While doing such work, I decided it'd also be nice (if not for trb integration, for myself) to have some tools to help me construct a rawtx.
mod6: Not being an expert myself on rawtx's, I've decided to try to get familiar with them, and become more of something closer to an expert -- so some mental strengthining has been going on there.
mod6: And I've created a reground patch for that.
mod6: I've reviewed the rawtx submission that polarbeard sent.
mod6: Anyway, this is all well and good. Just something we're working on, and considering with the utmost care.
mod6: <+asciilifeform> but you can blow yourself up like this by mis-specifying start-from-and-go-forward blocknumn also. << i've tested this a bunch, with a rescan too, and seems ok. what do you think will be the issue here?
mod6: However, this case probably exists, however, we havent replicated it yet -- and not for failing to do so, but it just needs to be setup and tested by shinohai and myself.
mod6: This might resolve itself by doing a full -rescan, separately.
mod6: This edge case being: If pub/priv keypair A, have been sent 1.0 bitcoins on say, tx 123456789, on block 200`000. Then sent 0.5 bitcoins from pub/priv keypair A to pubkey address B on block 250`000. If the uesr only scans back from 300`000, the balance in the wallet may not reflect the 0.5 output still there for that pubkey (from keypair A).
☟︎ mod6: however, this leaves one edge case, I think. And would need to be tested much before I send this one out.
mod6: asciilifeform: this could be made to happen indeed. it seemed more straight-forward to scan from low to high. but again, this could be altered.
mod6: Depending on how fast your machine might be, this might take a while.
mod6: We've seen that when you import a private key with the original I sent to the ML, it works great, but it does take the time to scan through the index from genesis to HEAD for transactions.
mod6: This feature will allow a user to import a private key, but choose which block height he starts scanning (for related transactions to the address) upon import.
mod6: lemme try this again.
mod6: There was a minor feature request to importprivkey, which was submitted late last month to the ML. This feature will allow a user to import a private key, but choose which block ight he starts scanning upon import.
☟︎ mod6: This month has been pretty productive for the Foundation already.
mod6: hahaha, the bottom is so gd funny.
mod6: i love these FUCKGOATS pics.
mod6: <+goldfinger> and i noticed i connected with some nodes that reported (protocol)verison 99999 << someone saw us on the tubes. hai!
mod6: yeah, srsly. "here's my tax returns." wat?!
mod6: trinque: that does fix that ya.
mod6: lemme try that trinque
mod6: so, thanks for all your efforts. i appreciate it.
mod6: you are backing us away from "number of seconds from 'midnight' of rsacalypse" one step at a time. first lamport, then FUCKGOATS, each step helps.
☟︎ mod6: then it does verify.
mod6: asciilifeform: your sig verifies, mine does not, unless you remove the '- ' infront of the '------' lines
mod6: aight, will remember for next time though.
mod6: fair enough, i can just throw in another i suppose.
mod6: ah, shit. i guess i agree. maybe I should have put a line in the top of that thing.
mod6: and we've seen how close the rsacalypse. i feel like we were right there a few months back.
mod6: It's weight of responsibility of protecting yet another key, or the possibility of being locked out of heaven.
mod6: yeah, all those considerations are valid too asciilifeform
mod6: I like what it does, and it seems to make sense in the case where I might need this one single time. To prevent against cryptographic death, I can generate this key pair, sign it with my PGP key, and then send a one time message of my new PGP key fp to save me from hitting the ground.
mod6: since it's confession time: I read asciilifeform's post probably 5 times total. Following through all of the steps at least 2x to get the hang of what was going on there, and reviewing the code.
mod6: i beleive that mentally, when you read a rating, you grok this text on some level, which invokes some type of response. i can be ignored, sure, but it happened never the less.
mod6: i agree, but it tends to happen. that still doesn't take away that my rating is ~not~ a guarantee of anything.
mod6: Yah, and then should I need it, I can use the lamport priv key to send a message "hey, it's mod6. my new pgpkey fp is: ABCDEF1234567890..."
mod6: I should clearsign the pubkey with my pgp-pubkey and deedbot this, aha?
mod6: So, changing subjects for a minute... I have these lamport battle-ready pub/priv keys made.
mod6: i thought also that i remembered some guy who tried to hijack your nick or something.
mod6: I agree there too. When you sign a vpatch, you're saying, "I, have read (or wrote) this, and I place my seal upon it as it is correct and right." Not, "mod6 wrote this thing, I rate him a '+1 Cool Guy' for effort."
mod6: btw, lol @ washitistan
mod6: especially when my transcation happened before his other "scammy" dealings
☟︎ mod6: should I be hung up by my heels for that?
mod6: it's even happened to me. i rated a guy with positive rating, he didn't scam me at all. but he apparently scammed some other people.
mod6: i get trinque's worry; that he'll wake up and find his wallet emptied out; and he wants a pill against that. the preposed solution is fine for that. but signed ratings is not the answer imho.
mod6: this reminds me of this line in your unicode paper.
mod6: <+mircea_popescu> and herein included - all my ratings. you can not at some point come and say "X scammed me of a btc and you had him rated +1 therefore you owe me some cents" << while reading, this is what I was thinking too. We've seen many times where someone reputable has a positive rating for X, and then later X scams out. These ratings can't act as a guarantee; which would place the rater in some leg