1 2015-12-01 03:37:13 <Genitrus_> does anyone here know how to do bitcoin JSON RPC commands with python?
  2 2015-12-01 03:43:08 <moa> Genitrus_: https://github.com/vbuterin/pybitcointools might be helpful
  3 2015-12-01 03:43:12 <Genitrus_> when i do my GET request (for 'getblock' command) i get this: http://pastie.org/private/ghqvfamt789wmdr5y8vyw
  4 2015-12-01 03:44:13 <Genitrus_> moa thanks, but actually, i guess the language doesn't matter :) does anyone here use the JSON RPC commands? has anyone build requests to a remote JSON RPC bitcoin server?
  5 2015-12-01 03:44:28 <Genitrus_> moa i do appreciate that tho... i looked it over real quick... doesn't look like it'll help me with making RPC calls
  6 2015-12-01 03:44:43 <Genitrus_> <--- using a full node
  7 2015-12-01 03:48:09 <Genitrus_> where is sipa when you need to tip him ;(
  8 2015-12-01 03:51:46 <phantomcircuit> Genitrus_, https://github.com/jgarzik/python-bitcoinrpc
  9 2015-12-01 03:53:01 <Genitrus_> phantomcircuit: i tried :[
 10 2015-12-01 03:53:05 <Genitrus_> here's my output when using that........
 11 2015-12-01 03:55:59 <phantomcircuit> Genitrus_, bitcoind by default only listens for connections from localhost
 12 2015-12-01 03:56:18 <Genitrus_> http://pastie.org/private/eriq5z64pav4kloodgzeq
 13 2015-12-01 03:56:31 <Genitrus_> phantomcircuit: ah yes, let me post the bitcoin conf , too
 14 2015-12-01 03:59:10 <Genitrus_> phantomcircuit: this includes the conf:
 15 2015-12-01 03:59:10 <phantomcircuit> Genitrus_, just dont post the rpc password :)
 16 2015-12-01 03:59:12 <Genitrus_> http://pastie.org/private/rsqudwhue8qnvumjol6gg
 17 2015-12-01 03:59:39 <Genitrus_> thanks phantomcircuit :) i appreciate your input :D
 18 2015-12-01 04:00:30 <phantomcircuit> Genitrus_, you changed the rpcport
 19 2015-12-01 04:03:10 <Genitrus_> phantomcircuit: should i remove that line?
 20 2015-12-01 04:03:48 <Genitrus_> phantomcircuit: i am specifying the port in the connection URL, though
 21 2015-12-01 04:05:28 <afk11> Genitrus_: the error thrown in your first paste looks like it's trying 8333
 22 2015-12-01 04:06:51 <Genitrus_> yup, that's what i specified rpcport=8333 (in the bitcoin conf)
 23 2015-12-01 04:10:09 <tulip> 8333 is the p2p port, you can't bind the rpc port there as well.
 24 2015-12-01 04:11:51 <tulip> either way your configuration, binding the RPC interface to the world is pretty inadvisable, at a minimum all of the traffic is plaintext.
 25 2015-12-01 04:12:58 <Genitrus_> ok cool, it turned out to be a server error or something
 26 2015-12-01 04:13:05 <Genitrus_> port 8334 works
 27 2015-12-01 04:13:14 <Genitrus_> oooh i see tulip
 28 2015-12-01 04:13:45 <Genitrus_> tulip, does RPC password matter if like... there will never be any coins here? :D
 29 2015-12-01 04:15:58 <tulip> then you want `disablewallet=1` in your configuration as well. it probably doesn't matter beyond nuisance stuff like denial of service, but all the same making stuff world exposed which isn't designed to be is inadvisable.
 30 2015-12-01 04:18:32 <Genitrus_> thanks!
 31 2015-12-01 05:08:32 <Luke-Jr> ugh, why does bitcoin.org need to be jekyll/ruby mess that's impossible to build? :/
 32 2015-12-01 05:45:39 <Genitrus_> Luke-Jr: not sure why people even like ruby... if you love a language because it's an enjoyable syntax, do python ... don't put your fingers through hell typing a ton of pipes and extra typing "end" statements :(
 33 2015-12-01 05:46:06 <Luke-Jr> Genitrus_: I remember the days I could run my system without Ruby :/
 34 2015-12-01 05:46:53 <Genitrus_> me too. it was a beautiful time. now i need ruby when i want to be lazy and use "git up" :(
 35 2015-12-01 05:47:16 <Luke-Jr> O.o
 36 2015-12-01 05:47:29 <Luke-Jr> gitian and bitcoin.org are literally the only things I use Ruby for
 37 2015-12-01 07:28:29 <BW^-> ouch, bitcoind 0.11.2 crashed by segmentation fault.
 38 2015-12-01 07:29:18 <BW^-> is there any way to audit the local blockchain copy's correctness - maybe that should be adequately taken care of at startup with the "init message: Verifying blocks...\nVerifying last 288 blocks at level 3"  part ???
 39 2015-12-01 07:29:30 <BW^-> or could there be corruption more than 288 blocks back?
 40 2015-12-01 07:49:58 <gmaxwell> BW^-: you can tell it to check more by changing by setting the checkblocks argument.
 41 2015-12-01 07:50:16 <gmaxwell> Was there any more info with the segfault or a log entry right before it?
 42 2015-12-01 07:53:44 <BW^-> gmaxwell: see https://pastebin.mozilla.org/8853493
 43 2015-12-01 07:56:07 <BW^-> gmaxwell: what is leveldb's flushing policy, how many blocks back *could* be broken?
 44 2015-12-01 07:56:17 <BW^-> presuming the sigsegv was non-nasty
 45 2015-12-01 07:56:29 <BW^-> gmaxwell: if it happens ever again, i'll have a core dump that time. this time none sorry. :(
 46 2015-12-01 07:56:43 <BW^-> i wonder if it could just be like non-ECC RAM goofing, but don't hope so.
 47 2015-12-01 07:59:42 <gmaxwell> blocks aren't stored in leveldb.
 48 2015-12-01 08:00:12 <da2ce7> gmaxwell: great comment btw, I wish there was a place to catalouge such things: https://bitcointalk.org/index.php?topic=1162684.msg13115666#msg13115666
 49 2015-12-01 08:08:49 <BW^-> gmaxwell: sorry diss - did i miss anything you said?
 50 2015-12-01 08:10:10 <gmaxwell> BW^-: sadly no indication of the cause in that log, but if there was database corruption it almost certantly would have had clear log messages.
 51 2015-12-01 08:10:32 <gmaxwell> if it crashes again you could run under gdb so that if crashes a third time you get a backtrace.
 52 2015-12-01 08:11:44 <BW^-> right
 53 2015-12-01 08:11:54 <BW^-> gmaxwell: exactly, it's now set up to catch core
 54 2015-12-01 08:11:56 <BW^-> dump core
 55 2015-12-01 08:33:04 <BW^-> gmaxwell: if there's an error in the database in my BitcoinD, and then I make a full blockchain sync from that broken BitcoiND into *ANOTHER* fully syncing bitcoin node,
 56 2015-12-01 08:33:15 <BW^-> then during sync the first BitcoinD would indeed print errors and stuff, right?
 57 2015-12-01 08:33:26 <BW^-> or at least, the second node would realize it's getting a bad blockchain
 58 2015-12-01 08:33:27 <BW^-> and warn
 59 2015-12-01 08:33:58 <BW^-> gmaxwell: so a broken blockchain DB would always come to surface with all clarity, either in the broken node, or in the node that makes a full sync from the broken node,
 60 2015-12-01 08:33:59 <BW^-> right?
 61 2015-12-01 09:01:28 <gmaxwell> BW^-: maybe, if the utxo database is corrupt thats not read during a sync from another node.
 62 2015-12-01 09:15:52 <gmaxwell> da2ce7: thanks for your addition in that thread; it's thoughtful.
 63 2015-12-01 11:26:59 <BW^-> gmaxwell: aha wait.. so.. what is actually stored in leveldb then??
 64 2015-12-01 11:27:26 <BW^-> gmaxwell: anyhow, since the full syncing node that would download all of it, checks all data bottom up, then i mean at least if no new block comes in in like 3 hours on the syncing node,
 65 2015-12-01 11:27:29 <BW^-> gmaxwell: that shows that something is broken
 66 2015-12-01 11:27:46 <gmaxwell> an index to blocks (e.g. effectively headers and pointers to blocks) and a database of spendable transaction outputs which is the state needed to verify new blocks as they come in.
 67 2015-12-01 11:29:30 <BW^-> gmaxwell: wait, is there any command line option to perform a full DB rebuild?
 68 2015-12-01 11:29:47 <BW^-> gmaxwell: or I just install a new instance and ask it to use 127.0.0.1:8333 as only source?
 69 2015-12-01 11:29:57 <gmaxwell> BW^-: -reindex
 70 2015-12-01 11:29:57 <sipa> BW^-: yes, -reindex
 71 2015-12-01 11:30:19 <BW^-> aha.  what if -reindex actually finds an error, will it terminate with error and i need to sync from beginning?
 72 2015-12-01 11:30:58 <BW^-> (these Q:s i'm asking now are not So important for immediate practical purposes, but, they do give a very valuable contextual understanding for the best practice in how to manage the thing)
 73 2015-12-01 11:31:30 <erasmospunk> If the network needs 600s by average to find a block hash with 70 zeroed bits. How much time it would take to find a block hash with 7 zeroed bits? Is it a linear relationship?
 74 2015-12-01 11:31:47 <sipa> erasmospunk: logarithmic
 75 2015-12-01 11:32:23 <sipa> BW^-: it will start downloading from network wherever it stops being able to sync from disk
 76 2015-12-01 11:33:33 <sipa> erasmospunk: 63 bits less means around 9 quintillion times faster
 77 2015-12-01 11:34:03 <sipa> erasmospunk: so it would take the network 1/10000 of a nanosecond
 78 2015-12-01 11:34:04 <erasmospunk> sipa: that makes sense. Basically I would like to prove a formula
 79 2015-12-01 11:40:24 <gmaxwell> BW^-: if reindex finds an eror, it will stop using the local data at that point and fetch the rest from the network.
 80 2015-12-01 11:52:06 <erasmospunk> sipa: is this correct? "If the network needs 600 seconds to find a valid block, it will produce by average 64 blocks (about every 9s) that would have been valid if the difficulty was 64 times lower"
 81 2015-12-01 11:53:35 <kinlo> it would produce on average 64 blocks per 600 sec if the difficulty is 64 times too low yes
 82 2015-12-01 11:54:21 <BW^-> ahaa
 83 2015-12-01 11:54:26 <BW^-> gmaxwell: and all the remaining broken or suspected to be broken data locally will just be discarded?
 84 2015-12-01 11:54:26 <BW^-> gmaxwell: so it's like a SQL "pragma VACUUM();" + COMPLETE self healing routine?
 85 2015-12-01 11:54:29 <BW^-> gmaxwell: and it also delete as any old database files that will have become obsolete as of that moment?
 86 2015-12-01 11:54:31 <BW^-> so it's like a whole checkup for/includes all files in the data directory that it may have created before
 87 2015-12-01 11:55:04 <erasmospunk> kinlo: thanks for the ACK. Is there a way to mathematically prove it?
 88 2015-12-01 11:55:24 <sipa> BW^-: -reindex is literally "throw your databases away and start over with the blocks you still have"
 89 2015-12-01 11:55:33 <kinlo> isn't vacuum a full copy of the database?  looks to me a very expensive operation on the bitcoin database...
 90 2015-12-01 11:55:33 <sipa> BW^-: the databases are literally deleted
 91 2015-12-01 11:55:57 <kinlo> erasmospunk: its logical...  dunno what type of mathematical evidence you're looking for...
 92 2015-12-01 11:57:57 <BW^-> sipa: awesome - and by "database" here, that also includes *any* previous files that BitcoinD created in its data directory in the past,
 93 2015-12-01 11:58:01 <BW^-> *b.c. of an OS crash
 94 2015-12-01 11:58:01 <BW^-> whatever nasty the sigsegv was, as long as the filesystem is intact so filenames not were garbled during an OS crash
 95 2015-12-01 11:58:13 <wumpus> kinlo: leveldb has no 'vacuum'
 96 2015-12-01 11:58:17 <sipa> BW^-: everything consensus related
 97 2015-12-01 11:58:36 <kinlo> wumpus: weren't we talking about sqlite?
 98 2015-12-01 11:58:37 <erasmospunk> kinlo: a formal mathematical proof. It feels logical but having a mathematical proof has a more weight
 99 2015-12-01 11:58:39 <sipa> BW^-: it does not delete wallets, ip databases, fee estimation data, ...
100 2015-12-01 11:58:52 <wumpus> kinlo: not that I know of?
101 2015-12-01 11:58:58 <kinlo> ignore me then
102 2015-12-01 11:59:04 <wumpus> kinlo: but I just happen to fall into this conversation
103 2015-12-01 11:59:12 <kinlo> wumpus: so did I :)
104 2015-12-01 11:59:21 <sipa> BW^-: it also doesn't delete block files, obviously
105 2015-12-01 11:59:52 <wumpus> it removes all indices and running state based on the block files
106 2015-12-01 12:02:32 <BW^-> (sec, restart)
107 2015-12-01 12:03:18 <BW^-> sipa: what if block files are corrupt?
108 2015-12-01 12:03:20 <wumpus> and doesn't only do the minimum to rebuild them, it treats them as freshly received from the network, so re-does all checking and validation of the blocks
109 2015-12-01 12:03:37 <wumpus> <gmaxwell> BW^-: if reindex finds an eror, it will stop using the local data at that point and fetch the rest from the network.
110 2015-12-01 12:04:00 <wumpus> no need to repeat yourself
111 2015-12-01 12:04:22 <sipa> i answered that question earlier too :)
112 2015-12-01 12:04:27 <BW^-> ah sorry, just got brief impression that sipa meant that block data had a special status.
113 2015-12-01 12:04:34 <wumpus> sipa: looping!
114 2015-12-01 12:04:35 <BW^-> so -reindex is a real vacuum - awesome, thanks!
115 2015-12-01 12:04:51 <sipa> BW^-: not vacuum; it *wipes and starts over*
116 2015-12-01 12:04:58 <BW^-> right
117 2015-12-01 12:05:01 <sipa> it takes as long as downloading again from scratch
118 2015-12-01 12:05:10 <wumpus> no, it's not just that, it doesn't just rebuild indices, it *revalidates and  rechecks everything as if received from the network*
119 2015-12-01 12:05:11 <sipa> except no bandwidth
120 2015-12-01 12:05:14 <BW^-> sipa: ..minus the network latency, no?
121 2015-12-01 12:05:18 <BW^-> exactly got it
122 2015-12-01 12:05:19 <BW^-> right
123 2015-12-01 12:05:28 <BW^-> last Q on this topic: what happens if you press ctrl+C during reindex?
124 2015-12-01 12:05:37 <BW^-> also, reindex happens *before* it opens up for any network interaction right?
125 2015-12-01 12:05:44 <wumpus> it will continue next time
126 2015-12-01 12:05:49 <wumpus> yes
127 2015-12-01 12:05:54 <sipa> no
128 2015-12-01 12:06:03 <sipa> network connections are up during reindex
129 2015-12-01 12:06:11 <BW^-> sipa: but unresponsive?
130 2015-12-01 12:06:13 <sipa> but all block fetching/sync logic is disabled
131 2015-12-01 12:06:18 <BW^-> aha, so even if i start BitcoinD *without* -reindex next time, it will do the reindex then anyhow - got it
132 2015-12-01 12:06:18 <BW^-> mhm
133 2015-12-01 12:06:19 <wumpus> well it may do some network interaction, but nothing useful like serve or receive blocks IIRC
134 2015-12-01 12:06:28 <sipa> it can serve blocks
135 2015-12-01 12:06:40 <BW^-> sipa: reindexed blocks or all blocks?
136 2015-12-01 12:06:45 <wumpus> it could, but it doesn't
137 2015-12-01 12:06:47 <sipa> onky reindexed ones
138 2015-12-01 12:06:54 <sipa> wumpus: i expect it does?
139 2015-12-01 12:06:58 <sipa> no reason why not
140 2015-12-01 12:07:05 <wumpus> sipa: no, no block serving happens during initial sync
141 2015-12-01 12:07:12 <sipa> oh, of course!
142 2015-12-01 12:07:23 <wumpus> it could, but that's disabled...
143 2015-12-01 12:08:00 <BW^-> ok cool, thanks for letting me know :D
144 2015-12-01 12:08:00 <wumpus> sipa: https://github.com/bitcoin/bitcoin/issues/6971
145 2015-12-01 12:09:19 <wumpus> so yes for whitelisted peers it's enabled now
146 2015-12-01 12:13:34 <wumpus> well I guess if you ask it for specific blocks it will still serve them
147 2015-12-01 13:01:26 <btcdrak> da2ce7: time to ransomware gmaxwell into setting up a blog (instead of paying ransom in bitcoin).
148 2015-12-01 13:17:31 <BW^-> "LoadBlockIndexDB: transaction index disabled" - wait, does this have any performance impact on ordinary syncing?
149 2015-12-01 13:19:38 <jonasschnelli> BW^- : no
150 2015-12-01 13:22:16 <phantomcircuit> BW^-, actually it being disabled has a significant positive impact
151 2015-12-01 13:22:26 <phantomcircuit> ie if you enable it you'll do a bunch of work you otherwise wouldn't have to do
152 2015-12-01 13:23:11 <jonasschnelli> phantomcircuit: he's gone already... :/ Seems to be in hurry...
153 2015-12-01 13:23:30 <BW^-> "LoadBlockIndexDB: transaction index disabled" - wait, does this have any performance impact on ordinary syncing?
154 2015-12-01 13:24:07 <jonasschnelli> hah.. :) BW^- no...
155 2015-12-01 13:24:09 <BW^-> gmaxwell: supertiny feature req: something that would be nice in the "UpdateTip:" beyond the "progress=0.9.." report, is an ETA of when the full sync will be done
156 2015-12-01 13:24:32 <BW^-> jonasschnelli: right, so that's only to figure the "balances" for addresses, got it.
157 2015-12-01 13:25:15 <BW^-> gmaxwell: as in date and time approximation, just a very very simple rudimentary calculation
158 2015-12-01 13:25:18 <jonasschnelli> BW^- Yes. Somehow. But if you just want to "observer" a buch of addresses, you can also use "importaddress".
159 2015-12-01 13:25:35 <jonasschnelli> BW^- ETA is not easy
160 2015-12-01 13:25:57 <phantomcircuit> BW^-, that means txindex=0 which is faster to sync than txindex=1
161 2015-12-01 13:26:10 <phantomcircuit> with txindex=1 you build a transaction index as well as the utxo database
162 2015-12-01 13:26:22 <phantomcircuit> the default setting of txindex=0 is faster
163 2015-12-01 13:26:31 <phantomcircuit> (you do less work)
164 2015-12-01 13:26:43 <BW^-> jonasschnelli: just based on thes peed of the development of "progress=".
165 2015-12-01 13:26:48 <BW^-> i know it's gonna be badly imprecise
166 2015-12-01 13:27:00 <BW^-> just based on speed compared with last 1 or 2 UpdateTips, that's all
167 2015-12-01 13:27:15 <BW^-> got it.
168 2015-12-01 13:27:32 <jonasschnelli> BW^-: you could also do that on the client side. <time-used-since-bitcoind-start> / <progress>.
169 2015-12-01 13:28:16 <BW^-> jonasschnelli: sure.  but just like in console output watching the log. but yeah you're right
170 2015-12-01 13:28:32 <jonasschnelli> BW^- : UpdateTip is also a critical function. Adding more CPU work there might result in slower syncing (although slightly).
171 2015-12-01 13:30:20 <BW^-> aha got it. ok it's too integrated to be convenient so to speak, got it.
172 2015-12-01 13:30:38 <BW^-> (probably that ETA calculation would just be like 1000-5000 cpu cycles extra work per UpdateTip, but anyhow.)
173 2015-12-01 13:32:44 <jonasschnelli> right... might be okay. But time estimations are mostly imprecise. Maybe your system needs 90% of the resources elsewhere during the last 5% of initial block download...
174 2015-12-01 13:32:54 <jonasschnelli> a % value keeps the time dimension out. :)
175 2015-12-01 13:50:50 <BW^-> will "-whitelist 127.0.0.1/32"  for sure make the node that connects with "-connect=127.0.0.1:8333 " be whitelisted?
176 2015-12-01 13:51:19 <BW^-> if there'd be some way to make the whitelist interface-independent (as in, 127.0.0.1 is the loopback interface's ip), that could perhaps be a good thing
177 2015-12-01 13:51:20 <BW^-> like
178 2015-12-01 13:51:29 <BW^-> "-whitelist */32" , anyhow duno
179 2015-12-01 13:52:15 <wumpus> you could use -whitelist=127.0.0.1   .. but it's better to use a whitebind=XXX in that case
180 2015-12-01 13:52:55 <wumpus> (whitebind opens an extra port, everyone that connects to there is whitelisted)
181 2015-12-01 13:53:19 <BW^-> wumpus: aha you mean that's more reliable, mhm
182 2015-12-01 13:53:26 <wumpus> e.g. -whitebind=127.0.0.1:12345
183 2015-12-01 13:53:54 <wumpus> well in some cases it may be right to trust all connecting coming from localhost, but you have to be careful there, e.g. Tor hidden service connections also come from localhost
184 2015-12-01 13:54:25 <wumpus> easy to screw up there and accidentally whitelist much more than you intended
185 2015-12-01 14:00:14 <BW^-> wumpus: interesting, at least before the sync has been fully done, on 0.11.2,  "-whitebind=127.0.0.1:8334" does not cause any port to be opened
186 2015-12-01 14:02:35 <wumpus> BW^-: just tried it out, works fine for me - opens the port along with the default port
187 2015-12-01 14:03:39 <BW^-> wumpus: weird. i'm completely sure mine did not work
188 2015-12-01 14:03:57 <BW^-> wumpus: maybe it's because mine is not fully synced yet, and the syncing thing would be introduced in 0.12
189 2015-12-01 14:04:31 <wumpus> no, opening ports has nothing to do with being synced or not
190 2015-12-01 14:04:46 <BW^-> wumpus: then weird!
191 2015-12-01 14:05:18 <tulip> BW^-: your node will open the socket, but won't advertise itself until synched.
192 2015-12-01 14:05:38 <BW^-> wumpus: find my bitcoind arguments in PM
193 2015-12-01 14:06:18 <BW^-> tulip: wait, what does that mean?    netstat -a | grep 8334 shows nothing
194 2015-12-01 14:06:24 <BW^-> and telnet localhost 8334 gives connection refused
195 2015-12-01 14:06:47 <tulip> what's with the non standard port number? bitcoind uses 8333 for p2p.
196 2015-12-01 14:06:47 <wumpus> and 8333 is open?
197 2015-12-01 14:07:06 <BW^-> tulip: i did "-whitebind 127.0.0.1:8334"
198 2015-12-01 14:07:08 <BW^-> wumpus: yes 8333 is open!
199 2015-12-01 14:07:43 <BW^-> tulip: find my BitcoinD (0.11.2) args in PM also.
200 2015-12-01 14:08:16 <BW^-> weird. anyhow i'll see if it opens after sync is complete. i guess this should *NOT* be a firewall thing.
201 2015-12-01 14:08:23 <tulip> that's a strange configuration.
202 2015-12-01 14:08:46 <wumpus> it's not a firewall thing as then it would show up in netstat, just not be connectable
203 2015-12-01 14:09:09 <wumpus> it won't magically reopen after sync either, there is no code for that, it either opens together with 8333 or it never will
204 2015-12-01 14:10:07 <BW^-> i think it should be correct
205 2015-12-01 14:10:27 <BW^-> wumpus: interesting, i wonder what causes it not to open then - a Magic Bug? :))
206 2015-12-01 14:10:49 <tulip> why are you using two verification threads, but accepting up to 500 incoming connections? those at the bounds of what you would use for resource constrained, and unlimited resource configurations respectively.
207 2015-12-01 14:11:32 <BW^-> tulip: yes that is unbalanced,  that part is example
208 2015-12-01 14:11:48 <wumpus> I don't know, possibly, could be that the command line argument is ignored somehow. No one else is having problems with whitebind that I know of...
209 2015-12-01 14:12:31 <tulip> I am using whitebind in master, no problems.
210 2015-12-01 14:12:37 <BW^-> mhm.
211 2015-12-01 14:12:45 <BW^-> i guess to figure out more, i'd need to dig into the sourcecode
212 2015-12-01 14:12:49 <wumpus> you're sure that this is 0.11 and not 0.10?
213 2015-12-01 14:13:25 <tulip> the log prints are quite informative generally, looking for a "Bound to" line in them would be useful.
214 2015-12-01 14:14:45 <wumpus> yes, there should be a "Bound to 127.0.0.1:8334" message in the debug.log
215 2015-12-01 14:14:59 <wumpus> (or alternatively, errors)
216 2015-12-01 14:17:42 <BW^-> wumpus: 0.11.2 yes.
217 2015-12-01 14:17:51 <BW^-> wumpus: there's not. and no errors.
218 2015-12-01 14:20:29 <wumpus> can you try without any other arguments? just -whitebind=X, and, say, -testnet
219 2015-12-01 14:21:07 <BW^-> wumpus,tulip: startup log: http://pastebin.com/B9w8mmbY
220 2015-12-01 14:21:08 <wumpus> if there is nothing in the log it can virtually only be an argument parsing error somewhere
221 2015-12-01 14:21:24 <BW^-> wumpus: i'll try first with just -whitelist=myip/32 and connect
222 2015-12-01 14:22:01 <wumpus> the message would be after the part of the log you pasted
223 2015-12-01 14:22:54 <wumpus> I'm pretty sure that one will be ignored too, but you can try ofc
224 2015-12-01 14:23:51 <BW^-> wumpus: well at least also with -whitelist on A and -connect on B, before the full sync has happened, B does *not* get any blocks
225 2015-12-01 14:24:21 <wumpus> OK, yes, that change is only in master/0.12
226 2015-12-01 14:24:40 <BW^-> aha gotcha
227 2015-12-01 14:25:17 <BW^-> wumpus,tulip: here's the next part of the startup log http://pastebin.com/TiK4sUnX
228 2015-12-01 14:28:10 <BW^-> wumpus: so still no explanation for why the -whitebind doesn't work right?
229 2015-12-01 14:28:20 <BW^-> i'll see if anything changes after the full sync, and otherwise dig into firewall and sourcecode
230 2015-12-01 14:28:31 <wumpus> <wumpus> can you try without any other arguments? just -whitebind=X, and, say, -testnet
231 2015-12-01 14:31:51 <BW^-> wumpus: right, i'll do that too then.  be back to you in like 4 days :)
232 2015-12-01 14:45:47 <wumpus> doesn't have to take that long?
233 2015-12-01 14:46:30 <wumpus> if it has to create a new datadir it will have a listening port in a few seconds
234 2015-12-01 14:49:33 <BW^-> wumpus: aha.. could you PM me your suggested bitcoind arguments, based on my current ones, using which we can see quickly if it worked?
235 2015-12-01 14:49:42 <BW^-> maybe use /tmp as bitcoin data dir
236 2015-12-01 14:50:36 <wumpus> just pass as little arguments as possible
237 2015-12-01 14:51:14 <wumpus> it may be that the combination of -datadir, -conf and other things interferes in some way, but I have no idea how, but it would gie some more information
238 2015-12-01 14:53:42 <BW^-> wumpus: i want to see first if the fact that node A is fully synced changes anything ok?
239 2015-12-01 17:04:16 <andytoshi> is there an "idiomatic" way when talking over RPC to determine whether i'm talking to bitcoin or testnet (and preferably, also detect if i'm talking to alpha or some alt)
240 2015-12-01 17:04:41 <andytoshi> i've got a program that deals a lot in libsecp secret keys, which don't have version bytes, and i need to add one when talking to bitcoind
241 2015-12-01 17:05:09 <afk11> andytoshi: getinfo returns testnet => bool in it's response, but not sure about alpha.
242 2015-12-01 17:05:15 <kanzure> testnet addresses should be rejected, so there's that.
243 2015-12-01 17:05:28 <afk11> you could probe the address prefix?
244 2015-12-01 17:05:32 <andytoshi> kanzure: i like it
245 2015-12-01 17:05:43 <andytoshi> yeah, i'll just 'validateaddress' an address with all the version bytes i know
246 2015-12-01 17:06:59 <kanzure> there should..... er.. we should make a more explicit mechanism.
247 2015-12-01 17:07:05 <andytoshi> afk11: yeah, i considered getinfo but i'm pretty sure alhpa will just pretend to be testnet
248 2015-12-01 17:07:12 <andytoshi> yup
249 2015-12-01 17:07:42 <andytoshi> kanzure: well, arguably testnet secret keys and bitcoin secret keys are different things, and the fact that my code doesn't differentiate between them is a sort of type error
250 2015-12-01 17:08:36 <andytoshi> kanzure: and there's also the compressed/uncompressed thing, which is a property of the keys, not the rpc daemon
251 2015-12-01 17:08:53 <afk11> andytosh: what does alpha's addresses begin with? I'd be tempted to use getnewaddress, decode the first byte, and compare against that (if whatever alt you're working on has a unique address version)
252 2015-12-01 17:08:58 <andytoshi> which i also don't track. my solution is "just mark everything compressed"
253 2015-12-01 17:09:08 <kanzure> getnewaddress causes wallet address bloat- seems unnecessary
254 2015-12-01 17:10:19 <andytoshi> afk11: heh, non-confidential addresses in alpha have the same prefix as testnet keys
255 2015-12-01 17:10:29 <andytoshi> i'll ask on sidechains-dev if there's actually any way for me to do this..
256 2015-12-01 17:11:54 <andytoshi> interestingly, `getnewaddress` does work cuz alphad will give me a CT address by default
257 2015-12-01 17:12:11 <afk11> a hypothetical getgenesisblock might help with this, but could be the same problem (some alts share block 0, but checkpoint block 1 differently)
258 2015-12-01 17:12:19 <kanzure> what about getnetworkinfo output ("subversion")
259 2015-12-01 17:13:44 <andytoshi> afk11: that's good, but i need to talk to regtest chains during testing which'll be "same network" but different genesis
260 2015-12-01 17:14:00 <andytoshi> hmmm kanzure
261 2015-12-01 17:14:11 <andytoshi> actually i like that
262 2015-12-01 17:14:26 <kanzure> alright here's the ultimate technique: send a bitcoin transaction to a known address (hardcoded in the source code). then, wait for andytoshi's server to sign a response transaction message. the response transaction will include some bytes about which network the transfer was received on.
263 2015-12-01 17:14:35 <andytoshi> hehehe
264 2015-12-01 17:14:58 <andytoshi> and i'll pay mechanical turk to find the response by looking at various block explorers
265 2015-12-01 17:15:38 <kanzure> er i think regtest always has the same genesis block?
266 2015-12-01 17:16:04 <andytoshi> kanzure: not for alpha, cuz you can change the federation public key on regtest
267 2015-12-01 17:16:10 <andytoshi> but on bitcoin yes
268 2015-12-01 17:16:23 <andytoshi> btw network subversion is the same for bitcoin and testnet on Core
269 2015-12-01 17:16:40 <kanzure> well, what about for alpha?
270 2015-12-01 17:17:08 <kanzure> regtest/testnet/mainnet can be done with getinfo, then hopefully network/client info by "subversion". but wont help with different client implementations i think.... sad.
271 2015-12-01 17:18:42 <kanzure> what exactly is your tool doing such that a user cannot provide as input the type of network?
272 2015-12-01 17:43:33 <gavinandresen> andytoshi: getblockhash 0   gets you the genesis block hash
273 2015-12-01 17:45:07 <gavinandresen> andytoshi: ... if you want to encode a public key, clever use of decoderawtransaction would work
274 2015-12-01 17:45:40 <gavinandresen> (create a dummy transaction paying to that key, I think decoderawtransaction will give you the encoded human-readable address)
275 2015-12-01 18:37:15 <andytoshi> kanzure: the user can provide it as input
276 2015-12-01 18:37:21 <andytoshi> kanzure: it's annoying that the user has to
277 2015-12-01 18:38:30 <andytoshi> given that the user is already giving RPC settings for a daemon that knows full well what network it's on
278 2015-12-01 18:39:02 <andytoshi> gavinandresen: i think trying 'validateaddress' on dummy addresses encoded with various network bytes will be functionally identical
279 2015-12-01 20:11:32 <blocksync> Hello - I have a question about Tx validation.
280 2015-12-01 20:12:05 <sipa> blocksync: it's hard to guess what that question is if you don't ask it!
281 2015-12-01 20:13:01 <blocksync> :) According to https://en.bitcoin.it/wiki/Protocol_rules a broadcast Transaction must be at least 100 bytes to be valid, I have rejected TBTC http://tbtc.blockr.io/tx/info/84FB309ABBBA932C569B3011DFB7D681D5A8CD99BB01D81A693881C63F54D8C5 because of this, however it has made it into a block.
282 2015-12-01 20:13:15 <blocksync> It is 89 bytes in size
283 2015-12-01 20:13:28 <blocksync> Are those rules not up to date?
284 2015-12-01 20:13:56 <sipa> they are absolutely not up to date
285 2015-12-01 20:14:07 <sipa> i have never heard that rule
286 2015-12-01 20:14:29 <blocksync> That sorts that out then!
287 2015-12-01 20:14:55 <blocksync> 6. Check that nLockTime <= INT_MAX[1], size in bytes >= 100[2], and sig opcount <= 2[3]
288 2015-12-01 20:14:57 <sipa> i wonder who put it there
289 2015-12-01 20:15:17 <blocksync> Sorry to bother you, but which file in bitcoin/src are Tx validation rules?
290 2015-12-01 20:15:23 <sipa> nLockTime is always less than INT_MAX, as it's an integer
291 2015-12-01 20:16:26 <sipa> blocksync: src/main.cpp, CheckTransaction, CheckInputs, ...
292 2015-12-01 20:16:32 <blocksync> Does it mean Signed max integer?
293 2015-12-01 20:16:35 <blocksync> Thank you sipa
294 2015-12-01 20:16:36 <sipa> yes
295 2015-12-01 20:16:42 <sipa> and src/script/interpreter.cpp for the script execution
296 2015-12-01 20:16:58 <blocksync> Thank you the script's have all been correct.
297 2015-12-01 20:17:17 <sipa> you should probably consider using libconsensus to verify scripts
298 2015-12-01 20:17:30 <sipa> the execution rules are extremely tricky to get exactly righ
299 2015-12-01 20:17:50 <gmaxwell> I'd sure like there to be a 100 byte transaction size rule, but I don't believe there has ever been one.
300 2015-12-01 20:18:04 <blocksync> "It is conceptually redundant with native functionality within libbitcoin."
301 2015-12-01 20:18:15 <blocksync> There is so much outdated documentation around :(
302 2015-12-01 20:18:17 <gmaxwell> (or, more explicitly a >64 byte rule)
303 2015-12-01 20:18:48 <sipa> blocksync: where do you read that?
304 2015-12-01 20:18:54 <blocksync> https://en.bitcoin.it/wiki/Libbitcoin_Consensus
305 2015-12-01 20:19:12 <blocksync> Line 1
306 2015-12-01 20:19:21 <sipa> not that
307 2015-12-01 20:19:32 <sipa> please, stop using that wiki
308 2015-12-01 20:19:39 <sipa> it's full of outdated and incorrect information
309 2015-12-01 20:19:47 <blocksync> Ok
310 2015-12-01 20:19:57 <sipa> libconsensus is a library that's part of Bitcoin Core's distribution
311 2015-12-01 20:20:09 <sipa> and uses the same validation implementation as Bitcoin Core itself
312 2015-12-01 20:20:49 <blocksync> Understood
313 2015-12-01 20:21:26 <blocksync> Thank you for your help sipa.
314 2015-12-01 20:22:48 <andytoshi> o.O i think that "100 bytes" thing has been there since hal created the page in 2011
315 2015-12-01 20:23:11 <andytoshi> and i've never seen this page before
316 2015-12-01 20:24:16 <blocksync> The main.cpp and concensus checks on Transactions are much looser than that page. I will remove some of my validation.
317 2015-12-01 20:24:47 <andytoshi> blocksync: :/ there has been a lot of work toward cleaning up the wiki over the years but tbh i'm unsure we've made any progress
318 2015-12-01 20:24:52 <andytoshi> as sipa says best to just pretend it doesn't exist
319 2015-12-01 20:25:38 <andytoshi> that libbitcoin comment in particular is borderline shilling, we don't have the time or energy to be noticing things like that
320 2015-12-01 20:25:40 <blocksync> Thank you andytoshi - one last question as all the bods seem to be in the room. Transaction fee validation - there are many interpretations, some I am accepting blockchain.info is denying, and visa versa. Do you know of a repository with good information on that subject?
321 2015-12-01 20:25:58 <sipa> blocksync: also assume blockchain.info does not exist, if you want to learn anything about bitcoin
322 2015-12-01 20:25:59 <andytoshi> blocksync: so, there are no hard network rules around transaction fees
323 2015-12-01 20:26:20 <andytoshi> +1 sipa , bc.i is (deliberately, though i can't see why) misleading
324 2015-12-01 20:26:29 <blocksync> Hmm
325 2015-12-01 20:26:35 <andytoshi> blocksync: so, ordinary nodes consider fees when deciding whether or not to relay transactions
326 2015-12-01 20:26:44 <andytoshi> while miners consider fees when deciding whether to include transactions in blocks
327 2015-12-01 20:26:56 <andytoshi> but both of these are "local", in the sense that everybody can do whatever they feel like
328 2015-12-01 20:27:19 <andytoshi> so it depends on what you're trying to do. if you can i'd avoid thinking about fees at all
329 2015-12-01 20:27:20 <blocksync> I understand, however shouldnt the blockchain explorers accept all transactions too their pool as they may get accepted by a miner?
330 2015-12-01 20:27:44 <andytoshi> that's sensible, though it potentially opens them up to denial-of-service attacks
331 2015-12-01 20:28:08 <blocksync> I agree - I have 40k transactions in my TBTC pool that have not been confirmed, built up in 2 days
332 2015-12-01 20:29:27 <blocksync> I think I will continue to accept all Tx into my pool and time them out after 48 hours.
333 2015-12-01 20:30:55 <andytoshi> i think that's reasonable. again, depends what you're trying to do and what your users' expectations might be. and a fixed-time timeout doesn't protect you from spam-dos attacks
334 2015-12-01 20:31:14 <andytoshi> whereas something like requiring a minimum fee on transactions spending new outputs (which is what Core does) will
335 2015-12-01 20:31:35 <blocksync> andytoshi - sure I will look into that.
336 2015-12-01 20:33:20 <blocksync> sipa, andytoshi, thank you for your help in figuring out my problem. have a good evening.
337 2015-12-01 20:34:17 <andytoshi> np, you too