Transcript for #bitcoin-dev 2017/08/22

10:12 nazarewk what is the way to go to retrieve all txids from wallet?
10:12 nazarewk (so i can separately gettransaction on them)
11:43 ossifrage nazarewk, more then what you get from listtransactions?
11:45 ossifrage I guess listtransactions doesn't include old transactions, only the UTXO components
11:57 wumpus listtransactions (at least in bitcoin core) gives you all transactions, new and historical
11:57 wumpus if you just want the utxo components, use listunspent
12:01 nazarewk well... listtransactions is extremely slow on large volume
12:11 ossifrage listtransactions does not seem to give you historical txns on 0.14.2 just 'active' txns
12:13 ossifrage I moved all my coins to a new address and all my old mining transactions are not shown on listtransactions
13:01 wumpus possibly there's a bug then, I don't know
13:02 wumpus depends on what steps exactly you followed, did you import any keys into the wallet?
14:24 ossifrage What was the reasoning behind limiting the difficulty increase to 4x?
14:27 cdecker ossifrage, foot-gunning?
14:28 ossifrage cdecker, yes I would rather not shot myself in the foot. I would imagine people thinking, "a 4x increase that will never happen..."
14:32 esotericnonsense in the pre-asic days it could avoid an attack whereby someone turns a shitton of machines on for one diff adjustment period and ramps difficulty by a factor of 100 or something silly
14:33 esotericnonsense (it would be far more costly for them to achieve a similar ramp with the 4x rule as they'd have to mine for multiple periods with diff increasing each time)
14:35 ossifrage esotericnonsense, ah yes, I remember that happening with some of the early bitcoin-clone-alts
18:41 cluelessperson Hey guys, I'm reading the documentation for bitcoin private keys, and it describes that most keys are 256, and valid between 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140
18:41 arubi yep
18:42 arubi well, what do you mean by most are 256?
18:42 cluelessperson bits, but then it says
18:42 cluelessperson Newer wallets may use BIP 32 seeds for their private keys, which can be as long as 512 bits.
18:43 arubi right, you usually use bip39 to derive a bip32 seed
18:43 cluelessperson is that meaing you can use 512 bit bitcoin private keys? or simply that bip32 may generate bitcoin keys (256 bit) FROM those BIP32 massive keys?
18:43 arubi so that output is 64 bytes for the seed
18:43 arubi core uses 32 bytes as the bip32 seed. (actually it uses a valid private key)
18:44 arubi ah no, those 64 bytes are hashed then you get 32 bytes private key and 32 bytes chain code
18:44 cluelessperson arubi: That doesn't tell me what this documentation means.
18:44 arubi private keys are always in that range
18:44 cluelessperson Ah.
18:44 arubi bip32 keys are extended private or public keys
18:45 cluelessperson So, I think it means, "Master Keys" may be larger, as they wind up generating/deriving/hashing to validly ranged bitcoin private keys.
18:45 arubi so both the private \ public bytes /and/ a 32 byte chain code
18:45 cluelessperson arubi: What do you mean by chain code?
18:45 arubi it's just another value used to derive the next level and index
18:46 arubi (in the bip32 path)
18:46 arubi cluelessperson, disregard bip32 and secp256k1 with its private key range
18:46 arubi they're unrelated
18:47 arubi these 512 bits seeds aren't private keys, just some output usually from kdf function of bip39
18:47 arubi s/function//
18:47 cluelessperson arubi: got it, the technical writing on the bitcoin wiki is just confusing to bring it up
18:48 arubi yea seems so
18:54 meshcollider arubi: the 512 bit output from the seed in BIP32 is split into two 256 bit halves, one of which is the private key and the other is the chain code
18:55 arubi right, hmac-sha512'ed and split left and right
18:55 meshcollider Yep
18:56 arubi :)
19:01 cluelessperson what is chain code
19:03 meshcollider It's just a 256 bit value used to generate children
19:03 meshcollider It's all in BIP 32
19:08 arubi yep that's pretty much it. chain code is one input to a hash function used to generate the next level's chain code
19:09 arubi well and key, but bip32 is better at explaining that part
21:24 kanzure hmm i don't like this, i would prefer it to have: Allow: /pipermail/* instead of: Allow: /pipermail/
21:58 cluelessperson Could someone help me understand what this means?
21:58 cluelessperson
21:58 cluelessperson
21:59 cluelessperson Specifically, when I decode the base58 WIF, I get bytes
21:59 cluelessperson Is there a trick to determining, compressed(true/false),net from the WIF ? or should I be trying to work out some logic table myself?
22:00 cluelessperson " Drop the first byte (it should be 0x80)" yeah, 0x80 is mainnet
22:00 cluelessperson "If the private key corresponded to a compressed public key, also drop the last byte (it should be 0x01). If it corresponded to a compressed public key, the WIF string will have started with K or L instead of 5 (or c instead of 9 on testnet)"
22:00 cluelessperson Jesus
22:00 cluelessperson so, the last byte will only be 0x01 if it's compressed?
22:01 cluelessperson or should I rely on the leading symbol to determine compression?
23:14 ginseng HD wallets were introduced in core v.0.13.0. Were pre-0.13.0 wallets deterministic in any way or were they just 100 randomly generated keys?
23:24 esotericnonsense ginseng: latter
23:24 esotericnonsense i think there was a flag to set the size, you could pregenerate more if you wanted
23:25 Emcy is it interesting that my .15rc node is uploading a lot less data than 14.2 did
23:25 Emcy like less than half
23:26 Emcy it was 37gb per day with 14.2, now its 16gb yesterday and 17gb today
23:26 Emcy banning btc1 wouldnt have that much effect
23:27 Emcy would it? Unless btc1 was attacking satoshi nodes to waste bandwidth? idk
23:33 ginseng esotericnonsense: ty