Transcript for #bitcoin-dev 2017/12/23

01:22 eck it's probably easiest to just run a full node in that case
01:23 eck you can enumerate the transactions in each block from the json rpc api
01:23 eck and using that you can the transaction fees for all the transactions in a block
02:41 tomatopeel 2 confirmations in 45 min on testnet, bleh >.>
02:41 echeveria tomatopeel: I'll move some more hashrate to it.
02:43 mlz can't wait to see the testnet bugbunny come back and gives us a block every minute :D
03:03 tomatopeel mainnet is 1.44e+19 h/s, testnet is 3.36e+12 h/s unless my scientific notation conversions are off... so mainnet has about a factor of half a million more hash power, makes sense I guess? no idea really
03:04 tomatopeel makes me wonder about mining on testnet though (sorry I'm pretty new) - I guess some people are kind enough to devote decent amounts of hash power to testnet? surely nobody is running asic's on it?
03:04 tomatopeel maybe older obsolete asic's I guess
04:29 echeveria tomatopeel: mining on test net is abusable as well.
04:30 echeveria you can reset the difficulty to zero using a bug.
04:33 luke-jr echeveria: not a bug; it's intentional..
04:56 mlz luke-jr, why is it intentional? for what reason?
04:56 mlz i don't mind fast blocks though :D
04:57 mlz what we also need is a reset testnet, too many blocks to download now
05:03 cncr04s nooooo
05:03 cncr04s my testnet fortune
05:13 luke-jr mlz: so difficulty won't get high
05:15 mlz oh i see
06:37 dograt Hi. Could anyone point me towards known schemes to reduce blockchain storage requirements of full nodes by including checkpointing info in blocks? For example, if miners were to maintain merkle patricia tries that maps the current balances of all utxos and update it after every block received (using a persistent/functional trie to support temp forks) and the root hash
06:43 arubi dograt, this was recently posted :
06:47 phantomcircuit dograt, that's for a sort of intermediate security setup, full nodes would still need to build the utxo from the full blockchain
06:49 dograt phantomcircuit: really? If a new node grabs some utxo set and sees it has a hundred or more confirmations, couldn't it be quite sure?
06:49 dograt (I'm still talking about my naive solution of putting the root hash in the block, I had lacked the terminology/background to describe the problem before, now I'm getting it from reading the resources pointed out by arubi :))
06:50 phantomcircuit dograt, no
06:50 phantomcircuit it completely changes the security model to do that
06:51 phantomcircuit currently the worst you can do by hashpower attack is to reverse transactions in those blocks
06:51 phantomcircuit with utxo commitments you could completely fabricate history
06:51 phantomcircuit the reward is vastly larger for attackers
06:55 dograt phantomcircuit: hm. I'm afraid I don't understand
06:56 dograt Actually I'm reading one of the linked mailing lists emails that is talking about "txo commitment"; I had not heard of this term before
07:04 dograt arubi: heh, following that email chain: someone proposes my exact idea
07:10 dograt phantomcircuit: ok I think I understand now
07:10 dograt Do you mean if an attacker starts with a faulty commitment and builds a chain off of that?
07:10 dograt Because it takes fewer blocks than the canonical chain
07:30 arubi dograt, right, I think I've heard some form of utxo state commitments in blocks but really I don't think there's a way to do it while keeping the same security that we have from full validation
07:30 phantomcircuit dograt, yes, it means to rewrite all of history takes only maybe a few hundred or thousand blocks instead of 500k blocks
07:30 phantomcircuit dograt, which is a significantly different thing
07:30 phantomcircuit i suggested exactly this in the past
07:31 phantomcircuit i was wrong
07:32 dograt Yeah.. but. I'm not optimistic in bitcoin being able to remain decentralized if the storage required to run it continnues to increase without limit
07:32 dograt However it's good to know people are on the case
07:33 arubi you don't have to keep storing the whole chain
07:33 dograt Right, but you need to acquire it
07:33 arubi yes
07:33 dograt So I suppose the requirement would be bandwidth/max storage
07:34 arubi it's still a lot more difficult to validate the data than to fetch it, I think
07:35 dograt Ah.
07:41 phantomcircuit arubi, it is
08:12 dograt And once you look it's everywhere :)
08:12 dograt From last month:
08:13 dograt "The idea behind PLP is to serialize the UTXO set in a standardized way, and
08:13 dograt publish a hash of it in the block header so that the blockchain commits to
08:13 dograt it"
08:13 dograt (oops sorry for the flood)
08:15 echeveria dograt: the gettxoutsetinfo RPC call reads out the UTXO and hashes it.
08:18 echeveria # time bitcoin-cli gettxoutsetinfo
08:18 echeveria real 3m4.464s
08:20 echeveria validating a block on this machine is usually under 100ms, so we've clearly got to do something different.
11:12 largep is there a limit to listreceivedbyaddress lets say you have millions of addresses
11:12 echeveria no, but things get very, very slow.
11:14 largep how slow? will it block other commands?
11:17 echeveria my bitcoind takes something like 10 minutes to load the wallet.
11:18 echeveria few seconds for things like getwalletinfo. think sending a transaction takes a while.
11:18 echeveria this is with ~1M transactions.
11:19 echeveria 9 seconds to sign a transaction.
11:28 jouke echeveria: how many keys?
11:29 echeveria I don't think that's visible from RPC
11:30 jouke No, debug log wil often show you how many keys it has reserved after you create a new one
11:31 echeveria that shows the keypool info only doesn't it?
12:00 jouke Maybe it depends on the debug options, but afaik it shows both the total number of keys and the number of keys in keypool
18:17 tomatopeel using raw transactions, the best practice which will mimic the default behaviour of bitcoin-qt is to send change to "$(bitcoin-cli getrawchangeaddress)" ?
18:21 tomatopeel also, I'm currently fooling around with bitcoin-cli/bitcoind between two datadirs. If I want a third node, to avoid re-downloading everything again, can I just rsync one of my already-downloaded datadir's and just delete the wallet.dat?
19:07 Randolf tomatopeel: Backup all of your Private Keys before you delete your wallet.dat file.
19:07 Randolf In fact, backup your wallet.dat file before deleting it too.
19:07 Randolf Whoops, sorry, I thought this was the #bitcoin channel. :)
19:43 tomatopeel Randolf: this is all on testnet but thanks haha and it's okay I'm still 88% noobish in any channel ;)
21:33 Eliel Suppose I have a service that's running and is using bitcoind wallet with the RPC interface as the wallet. We'd like to upgrade to using Segwit transactions. What are reasonable options for doing that if we'd like to make the upgrade on the timescale of a few weeks?
21:33 Eliel I should add that reliability requirements are pretty high. Can't really compromise on that.
21:39 eck you make an rpc call to addwitnessaddress and provide it with an address returned by getnewaddress
21:39 eck it gives you make a segwit address
21:41 eck that's pretty much it, you can test using testnet/regtest as usual
21:46 Eliel the most important thing would be to get change addresses to be segwit
21:50 eck then your options are: (1) use 0.15 and create the transactions manually using bitcoin-tx, (2) run a 0.16 pre-release, or (3) wait until there's a stable bitcoind release that does SW change addresses
21:50 RainMan28 hey eck did you mean to send that to me?
21:52 eck no
22:59 DSidH arubi: my first segwit tx :)
23:01 DSidH From segwit developers guide: ".... the wallet must be able to recognize payment to such (P2WPKH) addresses...." ..What exactly does this imply? (to recognize payments)