Transcript for #bitcoin-dev 2017/10/24

00:14 BGL why doesn't the bitcoin client even recognize the path to its previous installation, upgrading 14 to 15
00:15 BGL and this upgrading utxo database for 30 plus minus isn't expected eitehr
00:21 esotericnonsense dviola: right you can have ~infinite addresses (i imagine there's some very very large number that would break it)
01:07 dviola esotericnonsense: I see, thanks
01:17 wxss BGL, the utxo upgrade is expected, it is in the release notes
01:20 dviola so if I can create infinite amount of addresses, what is the 100 addresses that some people refer to?
01:24 esotericnonsense dviola: pre-HD wallets would create 100 keys on first load
01:24 esotericnonsense dviola: if you backed up your wallet, the backup was only useful for those first 100 keys, if you created more you'd eventually need another backup
01:24 esotericnonsense (which would have say, 200 or 300 keys in, e.g.)
01:25 esotericnonsense this is not the case any more, newly created wallets use a seed.
01:30 dviola esotericnonsense: I see, that makes sense, thanks
02:56 nixbox Hello everyone
02:56 nixbox What is the best way to start with bitcoin development. I understand the basics of Bitcoin and the blockchain. Do you think writing test cases would be a good place to start?
02:57 nixbox Can anyone give me some useful pointers?
02:57 nixbox fyi, I have the repository setup, i also compiled everything from source and played around with "regtest" a little bit.
10:15 dafuq hello. trying to get a node going here
10:16 dafuq it's going to take weeks(!). where is the bottleneck? my internet and hardware are decidely not the problem.
10:16 dafuq is this normal? maybe there are a lot of people trying to set up nodes right now?
10:16 dafuq just trying to understand where the bottleneck is
10:29 Tykling dafuq: sometimes you can speed it up by bootstrapping it with a blockchain from some point not too long ago
10:31 dafuq Tykling, so what i'm wondering is, is it a known problem? from your response, it sounds like it?
10:31 Tykling what is a known problem?
10:32 dafuq i can't parse and process that question.
10:32 Tykling you are asking if it is a known problem, can you elaborate which problem you mean
10:33 dafuq how long it takes to DL the blockchain to run a node.
10:34 Tykling yes that is known to take a long time
10:34 dafuq i can DL a +1G movie in the time it takes to make a coffee
10:34 dafuq so it's not my HW
10:34 dafuq or net
10:35 dafuq so where is the bottleneck? other nodes not uploading freely?
13:29 sdfgsdfg im not sure
15:34 LowKey Hi, I getting an issue when compile qt wallet , with this error on pastebin : https://pastebin.com/GxYHYVup
16:58 Anon_Help is there anyone i can pm to report a critical vulnerability
17:04 arubi Anon_Help, I'd send to the 'security
17:04 arubi email here: https://bitcoincore.org/en/contact/ with pgp for wumpus
17:04 Anon_Help ok thx
17:29 jb55 yo does something like this already exist before I continue working on it? https://github.com/jb55/btcs
17:29 jb55 I've seen basic parsers/compilers/decompilers but no evaluators
17:29 jb55 except in Haskoin but I wanted something a bit more lightweight
17:33 arubi the evaluator is the most interesting part :) I would use it if you build it
17:35 arubi it can be done with core, but not completely like checking if a transaction is actually valid now, eg a script could complete successfully but when you end up relaying the locktime could be preventing validity of the tx
17:35 jb55 yeah I'm still thinking about how to handle that properly
17:36 arubi parameters!
17:36 arubi lots and lots of em
17:36 jb55 ideally it would be some pure state input
17:36 arubi that's not too difficult with core already
17:37 arubi I say not too difficult, it is difficult really
17:37 arubi but not something you can't get used to hehe
17:38 arubi something like what you're building is very useful even if you don't add script validation with context. don't let me discourage you. I'll probably use it
17:39 jb55 I'm not discouraged, I would find it useful even without context but I want that as well :)
17:44 arubi jb55, awesome. for my serializer, I also defined a few "make your life easy" templates, like plain numbers are treated as scriptnum (need to be valid), the character @ means minimal push, so something like @<hex pubkey> is converted to 0x21 0x<pubkey> (and longer pushes if needed), a 0x<hex> is just treated like literal serialized part of the script.. you're probably already on it, but just my pov :)
17:46 jb55 arubi: oh yes this is all planned :)
17:47 jb55 although I never thought of that minimal push thing... thanks
17:52 jb55 arubi: if you have any other ideas for high level constructs let me know. I'm using this as a vehicle to learn bitcoin script so I'm not sure of all the patterns yet.
17:57 arubi jb55, not anything you wouldn't be able to pick up on quickly enough. script is very simple if you just accept reverse polish notation :)
17:58 arubi will definitely try to help if you have questions, feel free to ask
17:58 jb55 will do, thanks
18:00 jb55 tokenizing <pubkey> is a fun test for now because I can basically run BIP examples as is
18:02 jb55 maybe there would be a mode that prompts for input at those points lol, variables eventually?? not a high prio right now though
18:02 arubi that would be very cool
18:02 arubi like an active shell
18:02 jb55 just want to make it really easy to test new ideas quickly
18:03 jb55 or for learning, since many scripts right now are pretty simple if your brain is wired for RPN
18:03 arubi yea, and if you're not checking signatures, it's really just "run this from start to finish"
18:05 jb55 yeah I'm less interested in checking signatures, more interested in testing control flow for different inputs
18:05 jb55 although that will ultimately sometimes depend on sigs so that will be in there of course :P
18:06 jb55 but more so along the lines of "if this sigcheck succeeds or fails what happens"
18:06 arubi yes, and then you might want to look at op_codeseparator which will make your life interesting :)
18:06 jb55 as apposed to explicit sig checking
18:06 jb55 arubi: I've looked at that but I still don't know what it does
18:07 arubi it's a marker for a checksig operation to mark "where from" to serialize a script for sighash
18:07 jb55 whoa
18:07 arubi if there aren't any, it's at the start. as the script executes, if a codesep is met, the marker is now where it was
18:08 jb55 interesting...
18:08 arubi it only makes a difference for checksig stuff, but yes it is interesting, and legacy checksigs vs. segwit checksigs serialize it differently :), segwit is much easier
18:09 arubi really you could just be "segwit compatible only" and save a lot of headache
18:11 jb55 sounds reasonable
18:16 arubi the behavior is pretty similar really, segwit serializes the codesep while legacy doesn't. segwit makes checksig ops a lot easier because of the better sighash scheme in bip143. there are so many interesting sighash types, and there are probably going to be more eventually, that implementing legacy just seems like a waste of time now
18:20 jb55 cool I'll check out that bip