Transcript for #bitcoin-dev 2017/11/19

01:22 satwo Is every tx in the mempool a descendant and ancestor of itself? I'm trying to get a handle on the data returned from GetRawMempool (Verbose) when using JSON RCP
06:49 melik hmmm, looks like ifconfig and /etc/rc.local were deprecated in Debian 9 -- re: https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-deb...
07:01 melik hmmm something weird with lxc: init.lxc: failed to mount /dev/shm : No such file or directory
07:06 melik https://github.com/devrandom/gitian-builder/pull/150
07:07 melik ill push commits to replace any instances of ifconfig with brctl/ip
12:39 txter The transaction hash, is that a hash of the whole raw transaction?
12:52 txter That is, is this correct?
12:52 txter 1. The transaction is sent raw to other peers (serialized in hex format).
12:52 txter 2. In that raw transaction there is a hashed 'txid' of the previous output raw transaction proving the ownership of the coins.
14:19 luke-jr melik: Debian went off the systemd deep end; suggest switching to Devuan
14:19 luke-jr txter: this is not a channel for altcoin dev supportp
14:30 jaromil luke-jr: <3 we have also the right version of berkleydb in the pipeline for Devuan ASCII
14:31 jaromil melik: if you need help with porting the gitian build to Devuan, there are developers here who can help, me included.
14:33 txter luke-jr: I'm asking in regards to Bitcoin core
14:49 luke-jr txter: you're sneakily not disclosing you're trying to make an altcoin
15:09 txter luke-jr: I'm on other alt-coin channels, but I am reading through Mastering Bitcoin right now. I've just finished reading chapter 6 on transactions. One thing that is not covered is how transactions are persisted.
15:09 txter My question has nothing to do with alt coins, it's about how Bitcoin persists transactions in leveldb
15:09 txter :)
16:27 Michail1 If you setup a new full node, will setting it to prune (550) mean it will prune as the data comes in, or does it have to download entire chain and then finally prune?
16:41 txter This is said about prune in Mastering Bitcoin: 'Prune: Reduce the disk space requirements to this many megabytes, by deleting old blocks. Use this on a resource-constrained node that can't fit the full blockchain'
16:41 txter So I'm guessing you will not have to get all the blockchain first, as it is for nodes that can not fit the whole thing
16:45 Michail1 That doesn't answer the question.
16:46 arubi it prunes as it goes
16:46 Michail1 I understand what it does, but is it afterthefact (Meaning, must download the 150GB first then prune, or it will prune as the data is coming in).
16:46 Michail1 arubi - thankis.
16:46 arubi yw
16:48 txter Why does prune need you to first download 150gb of data when it's there so nodes that specifically can't store 150gb can continue working?
16:49 Michail1 txter - Just a note though.... Yes, you will have to download the entire chain. There isn't the ability yet (that I know of) in which you can start at a certain point. Probably an update in the future though when someone can simply start from Jan 1st, 2015 as a start point from a download of a verified chainstate/uxto, etc. It will happen.
16:49 arubi you download so you can verify it
16:51 spinza you download, verify and delete keeping only the last X GB as specified in pruning options
16:51 txter what if you set prune to 150mb, and as soon as you hit 150mb of chain data it stars discarding earlier data. So when you finally get to this point in time you have 150mb of chain data and you know it's valid since you technically downloaded the whole chain but only keypt around 150mb
16:51 txter yeah, basically what spinza said
16:52 arubi that's how it works, only the minimum is 550mb
16:52 spinza i thouhght the minimum was like 5GB
16:53 txter Makes sense to have a minimum
16:53 arubi for pruning it's 550mb, but aside from the chain there are other databases that you can't prune so it ends up taking a few gbs
16:55 txter Which databases are that?
16:56 arubi utxo database, wallet..
16:57 txter I'm reading through Mastering Bitcoin and there is one thing I'm trying to figure out that's not in the book, and that is how data is persisted. In my mind after reading the chapter on transactions I thought the key store db stored: key: txid -> value: raw transactoin in HEX
16:57 txter but then where would blocks fit in
16:58 arubi well we just talked about how blocks can be pruned :)
16:58 spinza what data?
17:01 txter Well. If I send a transaction to another node, it's going to be put into the mempool (if I remember correctly). There I'm guessing the key value store is (key: txid, value: raw transaction). Is that the leveldb database?
17:01 txter then there must be another database for the actual chain. Is that a relational one?
17:02 txter I'm just asking these questions cause I havent finished reading the book (currently on chapter 6), but I'm going to look at the bitcoin code after I finish the book
17:03 arubi I think it's better to look at code now
17:04 txter Yeah I might take a look after this chapter. Will probably fill in the blanks
19:17 firelegend Hi all, I created a new bitcoin wallet, unencrypted, I generated an address and immediately tried dump the private key, however I am met with error code - 5
19:17 firelegend Any reason for this?
19:20 arubi is that reproducible?
19:21 firelegend Reproducible how?
19:21 firelegend I tried many times, generated a new address, same thing
19:21 firelegend I use the request payment box to get a new address
19:22 firelegend And then the console for dumpprivkey
19:22 arubi what's the exact error say?
19:22 firelegend Invalid bitcoin address error code - 5
19:23 firelegend Perhaps these addresses are from compressed Public keys?
19:23 arubi of course they are
19:23 firelegend Ah
19:23 firelegend So then dumpprivkey requires uncompressed?
19:23 arubi no?
19:23 firelegend Then not sure why it doesn't work
19:24 arubi do 'validateaddress <address>'
19:24 arubi see if errors on invalid address
19:24 firelegend Says false
19:24 firelegend As in isvalid is false
19:25 arubi I'm not sure what you're pasting in there, but it's not addresses
19:25 firelegend No way, it ia
19:25 firelegend Is
19:25 arubi maybe you have 'bitcoin-cli' in your path and it's a symlink to testnet or an altcoin
19:25 firelegend Hmm
19:25 firelegend That's plausible wait
19:28 firelegend Does not seem to be in my path
19:28 arubi alias?
19:28 firelegend Perhaps it's because I am using a different datadir?
19:28 arubi well what's in ~/.bitcoin.conf ?
19:28 arubi if it's not an alias, not a wrapper, not a symlink, then it's reading that ^
19:29 arubi er, ~/.bitcoin/bitcoin.conf
19:29 firelegend But I've set a datadir on the command line parameters
19:29 firelegend Also I'm on Windows
19:30 arubi oh, try `bitcoin-cli getblockchaininfo`, what does it say for bestblockhash ?
19:32 firelegend Alright just a sec
19:35 firelegend https://pastebin.com/uw4Q4wxD
19:36 arubi can you post a throwaway example of an address that you passed to validateaddress and returned isvalid : false ?
19:38 arubi very weird. I really don't understand where armory's p2sh-p2pk, or whatever it might be relates to all of this
19:41 firelegend I run bitcoin core qt
19:41 firelegend Version 0.14.2
19:41 arubi oh disregard the armory comment, I got confused with the guy in #bitcoin
19:42 arubi yea
19:43 arubi firelegend, an example of what goes into validateaddress and fails will be helpful. are you running other daemons at all?
19:43 arubi if they're on the same rpc port, it might interfere
19:45 firelegend Not that I'm aware of, no
19:50 firelegend Is it possible bitcoin core at doesn't pass the datadir parameter to cli?
19:55 firelegend Hmm weird
19:55 firelegend .it seems to work now after restarting it twice
20:01 firelegend Seems like after generating a new address it takes a while for it to appear with dumpprivkey
20:04 arubi I haven't tried generate && dump one after another, but it makes sense that accessing these things can take more than a microsecond
20:06 firelegend A few minutes
20:08 firelegend I'm doing this by hand
20:08 firelegend So Def a few seconds in between
20:10 arubi well good to know. I mostly stress testing core using regtest, and the datadir is in /dev/shm, so I don't experience a lot of these quirks
20:10 arubi I'm*
20:11 firelegend Uhm it's not a test
20:11 arubi yea I figure
20:11 arubi that's why I'm assuming I never encountered it
20:11 firelegend I am simply trying to generate an address, make sure I have the key and send some BTC there
20:11 arubi well, if you generated it, you do have the key
20:11 arubi it's enough to run validateaddress
20:11 arubi it'll say "ismine : true"
20:12 firelegend Paranoia, plan to use cash and sell it, while making sure my BTC stay safe
20:12 arubi even better, "solvable : true"
20:12 arubi paranoia should divert you from dumping private keys
20:13 firelegend I'm afraid that while this bug occurs, or quirk, neither dumpprivkey work nor validateaddress
20:14 arubi hm I guess it doesn't say about solvable, where did I see it..
20:14 firelegend Because they return isvalid:false
20:14 arubi well, you still haven't posted an example of what you're passing to it
20:14 firelegend Just the bit on address
20:15 arubi can you generate a throwaway address and paste it?
20:15 firelegend 12fG2krj6iEr1GEzGdScERM5Ec9PYXtvX2
20:16 arubi whaddaya know, it's invalid
20:16 arubi maybe you have malware :)
20:17 arubi the first bytes are "1234", comon
20:18 firelegend Sorry?
20:20 arubi firelegend, if you don't know what I'm talking about, I suggest you completely reinstall your operating system
20:21 firelegend Pretty sure I am clean
20:22 arubi wait
20:22 arubi yea, my fault. I was bit by my own symlinks..
20:23 arubi man that's some coincidence.. I thought you were trolling, the first two bytes of the hash160 is 12, 34.. it seemed so artificial
20:24 arubi firelegend, the address is valid. I'm not sure what's been passed through to bitcoin-cli. can you pase the full command?
20:24 firelegend Well I am not
20:24 arubi yea, there's 1 to 2^16 chance of it being an hones 12, 34 address, and it is. please don't blame me :)
20:25 arubi s/hones/honest/
20:26 firelegend Seems to work once more
20:27 arubi you said you're running 0.14.2, latest is 0.15.1 . maybe try it out and open an issue on github if it doesn't solve the problem
20:27 firelegend Figured it out
20:27 firelegend Quotes
20:28 firelegend Must use quotes
20:30 arubi oh, that's unexpected..
20:32 firelegend Still paying 16 dollars as fees is a bit much
20:32 arubi pay less if you want
20:32 firelegend I did
20:33 firelegend 150k Satoshi per kb
20:33 firelegend Instead of 0.004
20:33 arubi I usually go with 10-20 sat/byte
20:34 firelegend And it works?
20:34 arubi I aim for weekends
20:34 firelegend Well, I'm about to sell bch all of it so
20:35 firelegend Maybe I will make it all back
20:35 dviola arubi: how do you know the size of your tx before sending?
20:35 arubi you put dummy signatures in it
20:36 dviola not sure how
20:39 arubi oh sorry, you mean with the client?
20:40 arubi I'm not sure if there's a way to tell easily
20:40 arubi /dinner time
20:41 jb55 put together a script that pulls fee estimtes from your full node: https://github.com/jb55/bitcoin-fees
20:43 dviola yes, with core
20:43 dviola I just want to be able to calculate the right fee for my tx
20:44 dviola I'd like to know how most people do it
20:44 dviola I've been using the fee estimator in core
20:44 dviola which is ok, but I wonder if there is a better way
20:45 eck the median txn is 121 bytes
20:45 eck err
20:45 eck 226 bytes
20:45 jb55 ^
20:45 eck i would start with that unless you have a reason to suspect it would be different
20:45 jb55 that's the default I use for my fee estimation script
20:45 eck i believe 226 bytes is for 1 input, 2 outputs p2pkh
20:46 firelegend Mean or median?
20:47 eck median
20:48 eck the mean would be larger, i don't know if you can create a transaction smaller than that
20:49 dviola ok so the more inputs the higher the bytes
20:49 dviola ?
20:49 jb55 hmm to send 100kb tx in 1-2 blocks would cost $1322 right now :O
20:51 eck that would be a big tx
20:51 eck dviola: yes
20:51 dviola eck: I see, thanks
20:52 dviola can't believe I overpaid like $20 before
20:54 dviola well, that tx had 10+ inputs so it's not too bad I guess
21:34 melik luke-jr, jaromil Ah, I see!
21:35 melik thanks guys; first time hearing about devuan, i see that it still use sysvinit
21:36 melik i'll set up a new VM then, thank you :)