1 2017-12-23 01:22:34 <eck> it's probably easiest to just run a full node in that case
 2 2017-12-23 01:23:29 <eck> you can enumerate the transactions in each block from the json rpc api
 3 2017-12-23 01:23:55 <eck> and using that you can the transaction fees for all the transactions in a block
 4 2017-12-23 02:41:02 <tomatopeel> 2 confirmations in 45 min on testnet, bleh >.>
 5 2017-12-23 02:41:17 <echeveria> tomatopeel: I'll move some more hashrate to it.
 6 2017-12-23 02:43:08 <mlz> can't wait to see the testnet bugbunny come back and gives us a block every minute :D
 7 2017-12-23 03:03:36 <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
 8 2017-12-23 03:04:16 <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?
 9 2017-12-23 03:04:51 <tomatopeel> maybe older obsolete asic's I guess
10 2017-12-23 04:29:36 <echeveria> tomatopeel: mining on test net is abusable as well.
11 2017-12-23 04:30:10 <echeveria> you can reset the difficulty to zero using a bug.
12 2017-12-23 04:33:38 <luke-jr> echeveria: not a bug; it's intentional..
13 2017-12-23 04:56:29 <mlz> luke-jr, why is it intentional? for what reason?
14 2017-12-23 04:56:49 <mlz> i don't mind fast blocks though :D
15 2017-12-23 04:57:18 <mlz> what we also need is a reset testnet, too many blocks to download now
16 2017-12-23 05:03:34 <cncr04s> nooooo
17 2017-12-23 05:03:40 <cncr04s> my testnet fortune
18 2017-12-23 05:13:20 <luke-jr> mlz: so difficulty won't get high
19 2017-12-23 05:15:09 <mlz> oh i see
20 2017-12-23 06:37:53 <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
21 2017-12-23 06:43:13 <arubi> dograt, this was recently posted : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
22 2017-12-23 06:47:09 <phantomcircuit> dograt, that's for a sort of intermediate security setup, full nodes would still need to build the utxo from the full blockchain
23 2017-12-23 06:49:06 <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?
24 2017-12-23 06:49:55 <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 :))
25 2017-12-23 06:50:37 <phantomcircuit> dograt, no
26 2017-12-23 06:50:45 <phantomcircuit> it completely changes the security model to do that
27 2017-12-23 06:51:11 <phantomcircuit> currently the worst you can do by hashpower attack is to reverse transactions in those blocks
28 2017-12-23 06:51:24 <phantomcircuit> with utxo commitments you could completely fabricate history
29 2017-12-23 06:51:35 <phantomcircuit> the reward is vastly larger for attackers
30 2017-12-23 06:55:12 <dograt> phantomcircuit: hm. I'm afraid I don't understand
31 2017-12-23 06:56:00 <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
32 2017-12-23 07:04:07 <dograt> arubi: heh, following that email chain: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014339.html someone proposes my exact idea
33 2017-12-23 07:10:16 <dograt> phantomcircuit: ok I think I understand now
34 2017-12-23 07:10:30 <dograt> Do you mean if an attacker starts with a faulty commitment and builds a chain off of that?
35 2017-12-23 07:10:40 <dograt> Because it takes fewer blocks than the canonical chain
36 2017-12-23 07:30:04 <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
37 2017-12-23 07:30:34 <phantomcircuit> dograt, yes, it means to rewrite all of history takes only maybe a few hundred or thousand blocks instead of 500k blocks
38 2017-12-23 07:30:43 <phantomcircuit> dograt, which is a significantly different thing
39 2017-12-23 07:30:58 <phantomcircuit> i suggested exactly this in the past
40 2017-12-23 07:31:00 <phantomcircuit> i was wrong
41 2017-12-23 07:32:10 <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
42 2017-12-23 07:32:40 <dograt> However it's good to know people are on the case
43 2017-12-23 07:33:06 <arubi> you don't have to keep storing the whole chain
44 2017-12-23 07:33:40 <dograt> Right, but you need to acquire it
45 2017-12-23 07:33:51 <arubi> yes
46 2017-12-23 07:33:58 <dograt> So I suppose the requirement would be bandwidth/max storage
47 2017-12-23 07:34:49 <arubi> it's still a lot more difficult to validate the data than to fetch it, I think
48 2017-12-23 07:35:08 <dograt> Ah.
49 2017-12-23 07:41:11 <phantomcircuit> arubi, it is
50 2017-12-23 08:12:49 <dograt> And once you look it's everywhere :)
51 2017-12-23 08:12:54 <dograt> From last month: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015296.html
52 2017-12-23 08:13:07 <dograt> it"
53 2017-12-23 08:13:07 <dograt> publish a hash of it in the block header so that the blockchain commits to
54 2017-12-23 08:13:07 <dograt> "The idea behind PLP is to serialize the UTXO set in a standardized way, and
55 2017-12-23 08:13:14 <dograt> (oops sorry for the flood)
56 2017-12-23 08:15:50 <echeveria> dograt: the gettxoutsetinfo RPC call reads out the UTXO and hashes it.
57 2017-12-23 08:18:46 <echeveria> # time bitcoin-cli gettxoutsetinfo
58 2017-12-23 08:18:49 <echeveria> real    3m4.464s
59 2017-12-23 08:20:04 <echeveria> validating a block on this machine is usually under 100ms, so we've clearly got to do something different.
60 2017-12-23 11:12:31 <largep> is there a limit to listreceivedbyaddress lets say you have millions of addresses
61 2017-12-23 11:12:44 <echeveria> no, but things get very, very slow.
62 2017-12-23 11:14:29 <largep> how slow?  will it block other commands?
63 2017-12-23 11:17:38 <echeveria> my bitcoind takes something like 10 minutes to load the wallet.
64 2017-12-23 11:18:18 <echeveria> few seconds for things like getwalletinfo. think sending a transaction takes a while.
65 2017-12-23 11:18:29 <echeveria> this is with ~1M transactions.
66 2017-12-23 11:19:01 <echeveria> 9 seconds to sign a transaction.
67 2017-12-23 11:28:48 <jouke> echeveria: how many keys?
68 2017-12-23 11:29:59 <echeveria> I don't think that's visible from RPC
69 2017-12-23 11:30:37 <jouke> No, debug log wil often show you how many keys it has reserved after you create a new one
70 2017-12-23 11:31:45 <echeveria> that shows the keypool info only doesn't it?
71 2017-12-23 12:00:47 <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
72 2017-12-23 18:17:56 <tomatopeel> using raw transactions, the best practice which will mimic the default behaviour of bitcoin-qt is to send change to "$(bitcoin-cli getrawchangeaddress)" ?
73 2017-12-23 18:21:09 <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?
74 2017-12-23 19:07:09 <Randolf> tomatopeel:  Backup all of your Private Keys before you delete your wallet.dat file.
75 2017-12-23 19:07:19 <Randolf> In fact, backup your wallet.dat file before deleting it too.
76 2017-12-23 19:07:43 <Randolf> Whoops, sorry, I thought this was the #bitcoin channel.  :)
77 2017-12-23 19:43:50 <tomatopeel> Randolf: this is all on testnet but thanks haha and it's okay I'm still 88% noobish in any channel ;)
78 2017-12-23 21:33:13 <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?
79 2017-12-23 21:33:49 <Eliel> I should add that reliability requirements are pretty high. Can't really compromise on that.
80 2017-12-23 21:39:50 <eck> you make an rpc call to addwitnessaddress and provide it with an address returned by getnewaddress
81 2017-12-23 21:39:58 <eck> it gives you make a segwit address
82 2017-12-23 21:41:17 <eck> that's pretty much it, you can test using testnet/regtest as usual
83 2017-12-23 21:46:51 <Eliel> the most important thing would be to get change addresses to be segwit
84 2017-12-23 21:50:14 <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
85 2017-12-23 21:50:49 <RainMan28> hey eck did you mean to send that to me?
86 2017-12-23 21:52:40 <eck> no
87 2017-12-23 22:59:08 <DSidH> arubi: my first segwit tx :) https://www.blocktrail.com/tBTC/tx/b49f3d6d15f2bdd9217ba3caaf1bb1f2d9875c9657e6b0ac7a0ef841d486ad1d
88 2017-12-23 23:01:12 <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)