1 2015-04-26 03:26:53 <leakypat> Am I correct in thinking newer version s of Bitcoin core have an "insane miners fee" error check built in?
2 2015-04-26 03:27:11 <leakypat> I could have sworn I have seen this in debug.log before
3 2015-04-26 09:27:22 <sipa> robbak: sure it is not out of memory?
4 2015-04-26 10:06:29 <robbak> fairly sure - but it is something to check.
5 2015-04-26 10:07:14 <sipa> it is surprising that both gcc and clang fail
6 2015-04-26 10:07:49 <robbak> Yes, it is.
7 2015-04-26 10:09:00 <robbak> two entirely different versions of FreeBSD.
8 2015-04-26 12:20:01 <wumpus> * [new tag] v0.10.1 -> v0.10.1
9 2015-04-26 12:22:00 <sipa> woohoo
10 2015-04-26 12:49:20 <xabbix> Is there a full node with RPC server running (rpcallowip=*) that is free for use and open for all for either testnet/livenet? If not, is it a stupid idea to set one up? Obviously without any funds.
11 2015-04-26 12:53:00 <cfields_> :)
12 2015-04-26 12:53:15 <cfields_> building
13 2015-04-26 12:53:41 <PRab> xabbix: Even if you did that, you would probably want to disable a couple of commands (stop, setgenerate).
14 2015-04-26 12:54:15 <xabbix> PRab, How can I disable some of the RPC commands?
15 2015-04-26 12:54:30 <PRab> xabbix: Even with those commands disable, I'm not sure if its a good idea.
16 2015-04-26 12:54:48 <PRab> xabbix: The only way that I know of is to modify the source and recompile
17 2015-04-26 12:56:02 <xabbix> PRab, I'm thinking about setting up a dedicated machine for it, so if someone finds a vulnerability that will lead to remote code execution or something similar, I wouldn't really mind. I'm surprised there isn't one available and open for all for testnet.
18 2015-04-26 13:03:40 <wumpus> at least disable the wallet (this also disables *generate)
19 2015-04-26 13:04:36 <wumpus> but to remove `stop` and potentially other harmful commands you need to change the source, I'd still discourage it, the RPC interface is not meant to be hardened against public use
20 2015-04-26 13:05:11 <xabbix> wumpus, ok, thanks for the input. I'll try something else.
21 2015-04-26 14:00:49 <jtimon> but I've just pushed 9ddf5e5f to jtimon/policy (#5595) and it's not wroking, do I really need to open a new PR ?
22 2015-04-26 14:00:49 <jtimon> I have had this problem before and I solved it, but I can't remember how...https://github.com/isaacs/github/issues/361
23 2015-04-26 14:00:49 <jtimon> you can't force push when a PR is closed, it won't let you reopen until you put there exactly the same commit that was there when you closed it
24 2015-04-26 14:05:22 <sipa> jtimon: i can reopen it, i think
25 2015-04-26 14:07:09 <sipa> give me a minute
26 2015-04-26 14:09:12 <jtimon> thanks, I have both versions locally, now the old one is supposed to be up, but I still can't reopen
27 2015-04-26 14:09:58 <jtimon> REM: first reopen, then force push (I knew this!)
28 2015-04-26 14:10:24 <jtimon> but in fact I think it is a stupid rule in github
29 2015-04-26 14:13:16 <wumpus> I think the reason is that when you pull to the branch of a closed pull request, it assumes that you pushed something new and disassociates the branch from the pull, thus after that you can't reopen it (as that would make no sense without an associated branch)
30 2015-04-26 14:14:32 <jtimon> yep, but they don't impose that restriction with open PRs
31 2015-04-26 14:15:36 <jtimon> anyway, I just pushed the old commit 9ddf5e5, or at least git push jtimon policy says Everything up-to-date
32 2015-04-26 14:16:04 <wumpus> sure, because the open pull means that you still want the association; e.g. a lot of people always make pulls from their master branch
33 2015-04-26 14:17:22 <jtimon> I don't know I think last time I solved it by simply force pushing the old branch again
34 2015-04-26 14:19:41 <jtimon> I guess a new PR is not the end of the world but if sipa can solve it, that would be better
35 2015-04-26 14:19:58 <wumpus> I doubt he can restore the association
36 2015-04-26 14:20:46 <sipa> wumpus: can't you reopen the PR?
37 2015-04-26 14:20:54 <sipa> not at my computer now
38 2015-04-26 14:22:06 <wumpus> nope, it's greyed out
39 2015-04-26 14:22:56 <jtimon> I feel specially bad about 5595 because it is a slower but cleaner approach to what luke wanted to do
40 2015-04-26 14:22:59 <wumpus> one would have to restore the association between the branch and the pull, but at least through the web interface that's not possible, maybe something that can be done through the API but I'm not sure
41 2015-04-26 14:23:39 <jtimon> never mind, I'll just reopen a new one and link them to each other
42 2015-04-26 14:23:51 <sipa> oh ok
43 2015-04-26 14:45:54 <cfields_> https://bitcoincore.org/cfields/bitcoin-0.10.1/signature.tar.gz up for gitian signers
44 2015-04-26 16:13:29 <RainMan28> is there a safe way to have bitcoind running on one server as a host and other machines acting as clients? The wiki was recently updated and says using RPC is not safe even over SSL
45 2015-04-26 16:37:55 <sipa> RainMan28: if you can trust the clients and the network
46 2015-04-26 16:39:37 <RainMan28> sipa: if i have a bitcoind wallet already on a cloud server with a small amount of coins on it, is there any added security issues with having another machine on that same cloud acting as the client and they communicating over SSL?
47 2015-04-26 16:40:07 <s7r> will CHECKLOCKTIMEVERIFY when/if implemented have any effect on previous signed (and not broadcasted) txes locked with nLockTime?
48 2015-04-26 16:40:34 <s7r> it will not obsolete or affect nLockTime in any way, it's just an additional feature, better from some points of view
49 2015-04-26 16:40:38 <s7r> is this correct?
50 2015-04-26 16:45:32 <sipa> s7r: cltv is an opcode; it has no effect if you don't use the opcode
51 2015-04-26 16:49:18 <sipa> RainMan28: what are you trying to protect against?
52 2015-04-26 16:50:19 <RainMan28> sipa: someone stealing the bitcoins from some other machine or seeing the password that the client machine uses to communicate with the host machine
53 2015-04-26 16:51:18 <sipa> the only one who could do that is the cloud provider, and they can already just take the coims
54 2015-04-26 17:12:37 <RainMan28> sipa: I see. Do you know what prompted the change on the wiki from a guide to how to use it to it now being strongly discouraged?
55 2015-04-26 17:14:17 <sipa> RainMan28: you should not expose rpc to the internet, even with ssl
56 2015-04-26 17:14:31 <sipa> there are too many things that can go wrong
57 2015-04-26 17:14:52 <jonasschnelli> RainMan28: if you are planing to do only a fee transations, you might consider using multisig transactions which co-signing over your local pc/mac/smartphone.
58 2015-04-26 17:15:00 <jonasschnelli> s/fee/few
59 2015-04-26 17:15:09 <RainMan28> sipa: ok, but is there some known vulnerability or do I just have to trust my cloud provider if I limit the RPC connect IP to just the client machine's IP
60 2015-04-26 17:16:16 <sipa> RainMan28: no known vulnerability
61 2015-04-26 17:16:34 <sipa> RainMan28: but if you run it on a cloud server, you are already trusting them
62 2015-04-26 17:16:48 <RainMan28> sipa: right
63 2015-04-26 17:18:08 <RainMan28> jonasschnelli: thanks for the suggestion, this would be more than just a few transactions
64 2015-04-26 17:54:08 <s7r> sipa sorry was afk. So simpler, I am fine with basic old nLockTime even after CLTV is soft-forked ?
65 2015-04-26 17:55:06 <sipa> s7r: cltv has no effect if you don't use it
66 2015-04-26 17:55:22 <s7r> I thought it's a _replacement_ for nLockTime
67 2015-04-26 17:55:38 <s7r> and after it's soft-forked I won't be able to use previously signed but not broadcasted txes locked with nLockTime
68 2015-04-26 17:55:46 <s7r> but guess that's just impossible for a wide consensus network
69 2015-04-26 18:01:58 <sipa> no
70 2015-04-26 18:02:17 <sipa> it's an opcode that places a _constraint_ on the spending transaction's locktime
71 2015-04-26 18:02:28 <sipa> it is definitely not a replacement for it
72 2015-04-26 18:03:24 <s7r> so i will not be able to sign an output with nLockTime 30 days from now and give it to you, and tomorrow I sign an outpout spending everything to myself with nLockTime 0
73 2015-04-26 18:03:24 <sipa> in fact, it relies on locktime functioning as it always did
74 2015-04-26 18:04:23 <sipa> s7r: if the coin you are spending has a ctlv in its output which restricts your locktime, no
75 2015-04-26 18:04:48 <s7r> well, currently it cannot have ctlv, right ?
76 2015-04-26 18:06:16 <sipa> eh, cltv
77 2015-04-26 18:06:23 <sipa> no, because it does not exist
78 2015-04-26 18:07:02 <sipa> you will know when you're spending a cltv output, because you will have chosen it yourself
79 2015-04-26 18:07:58 <s7r> the way i understand it currently bitcoin core does not understand / know about cltv
80 2015-04-26 18:08:06 <s7r> have i read an outdated document?
81 2015-04-26 18:09:43 <roasbeef> have you read the BIP?
82 2015-04-26 18:12:25 <s7r> yes
83 2015-04-26 18:18:45 <s7r> roasbeef so?
84 2015-04-26 18:32:14 <sipa> s7r: no, it is just a proposal
85 2015-04-26 18:32:41 <sipa> s
86 2015-04-26 18:32:57 <sipa> s7r: as it is a softfork, initially it can just be miners
87 2015-04-26 18:33:16 <sipa> but before it is enforced globally as a network rule, you can't use it
88 2015-04-26 18:33:47 <sipa> s7r: in short, don't worry
89 2015-04-26 18:34:00 <sipa> s7r: if you are not aware of cltv, it does not apply to you
90 2015-04-26 18:34:44 <sipa> there is not even a plan for deploying it
91 2015-04-26 18:34:47 <sipa> yet
92 2015-04-26 19:35:49 <ejigger> http://www.ideamap.net/R3D6B9/R3D6B911115Front.asp
93 2015-04-26 19:35:49 <ejigger> Need your indispensable input on an important digital currency study
94 2015-04-26 19:35:49 <ejigger> Patented IdeaMap methodology study on digital currency
95 2015-04-26 20:38:38 <s7r> sipa ack!
96 2015-04-26 20:38:46 <s7r> thanks for the info.
97 2015-04-26 20:38:59 <s7r> maybe I can use it in my system, after everyone supports it and we have it enforced as a network rule.
98 2015-04-26 20:39:12 <s7r> but at this moment I don't really need it, nLockTime does just fine for my taks
99 2015-04-26 20:39:14 <s7r> task*
100 2015-04-26 20:48:55 <andytoshi> sipa: im not gonna finish reviewing libsecp256k1 #210 today, i've made good progress yesterday and tomorrow (i'm comfortable that the math is solid at least) but i'm feeling sick and it's hard to think
101 2015-04-26 20:49:08 <sipa> andytoshi: take your time
102 2015-04-26 20:49:20 <andytoshi> this is a really really cool trick
103 2015-04-26 20:49:48 <sipa> yes!
104 2015-04-26 20:50:54 <sipa> andytoshi: we had come to a point in libsecp256k1 where i'd already be willing to spend quite some review cycles on a 1% verification speedup
105 2015-04-26 20:51:12 <sipa> andytoshi: then this guy shows up with *original research* that gives like 8% :p
106 2015-04-26 20:51:15 <andytoshi> :P
107 2015-04-26 20:53:24 <phantomcircuit> neat
108 2015-04-26 21:25:24 <jonasschnelli> sipa: https://github.com/jonasschnelli/bitcoin/commit/b2d9336ddf815414c8867bcc80b0a2c9ddfddeac#commitcomment-10907343
109 2015-04-26 21:25:48 <sipa> yes?
110 2015-04-26 21:26:05 <jonasschnelli> isn't the while structure looping backward until we reach the first pruned block or we reach the rescan index (pindexRescan)?
111 2015-04-26 21:26:29 <sipa> ugh
112 2015-04-26 21:26:31 <sipa> i missed that
113 2015-04-26 21:26:39 <jonasschnelli> the if at L1298 only checks if the loop stopped because of BLOCK_HAVE_DATA or the reach of pindexRescan
114 2015-04-26 21:26:44 <jonasschnelli> IMO it looks good.
115 2015-04-26 21:27:06 <sipa> sorry, commented
116 2015-04-26 21:27:27 <jonasschnelli> Cool. Thanks.
117 2015-04-26 21:27:36 <jonasschnelli> And thanks for the review
118 2015-04-26 21:45:49 <sipa> my gitian build fails
119 2015-04-26 21:46:15 <sipa> ./bin/gbuild:21:in `system!': failed to run on-target -u root bash < target-bin/upgrade-system.sh > var/install.log 2>&1 (RuntimeError)
120 2015-04-26 21:46:15 <sipa> Installing additional packages (log in var/install.log)
121 2015-04-26 21:46:15 <sipa> Upgrading system, may take a while
122 2015-04-26 21:50:56 <Krellan> sipa: Thanks for looking at my PR https://github.com/bitcoin/bitcoin/pull/5288 - should be in good shape now
123 2015-04-26 21:51:36 <sipa> Krellan: sorry, i thought i'd have a quick look at what was keeping it up, but i should review more thoroughly (won't happen today, though)
124 2015-04-26 21:53:22 <Krellan> OK cool, no problem
125 2015-04-26 21:59:29 <Krellan> If that PR makes it in, then I would love to stack upon it and add a maxconnections parameter, which should be nicely integrated
126 2015-04-26 21:59:54 <Krellan> Given PR 4687 and PR 6014, I'd be going for "third time's a charm"
127 2015-04-26 22:12:47 <jonasschnelli> sipa: gitian: did you check if a qemu process is (still) running? Had the same issue recently.
128 2015-04-26 22:14:43 <sipa> jonasschnelli: downgraded gitian, now it works
129 2015-04-26 22:14:45 <sipa> and matches
130 2015-04-26 22:15:16 <jonasschnelli> Ok. Nice
131 2015-04-26 23:41:20 <jonasschnelli> Needs GUI and "low priority" tag: https://github.com/bitcoin/bitcoin/issues/5908
132 2015-04-26 23:51:11 <kanzure> does headers-first prevent blocks from downloading? i am stuck at 26859 on testnet3.
133 2015-04-26 23:58:59 <phantomcircuit> kanzure, no but you can get stuck if you have shitty peers
134 2015-04-26 23:59:02 <phantomcircuit> which most of testnet is
135 2015-04-26 23:59:07 <phantomcircuit> since there's lots of shenanigans
136 2015-04-26 23:59:21 <kanzure> perfect
137 2015-04-26 23:59:22 <kanzure> thank you
138 2015-04-26 23:59:25 <phantomcircuit> check pm
139 2015-04-26 23:59:47 <phantomcircuit> BWAHAH NOW I HAVE YOUR IP!
140 2015-04-26 23:59:57 <phantomcircuit> ACTION isn't sure what to do with it