1 2014-11-17 00:04:01 <Luke-Jr> hate to nag, but block proposal still isn't merged, and is something we really should get in sooner rather than later IMO; wumpus wants to branch for 0.10 on Tuesday, so it's down to the last minute now..
2 2014-11-17 00:04:12 <Luke-Jr> sipa: ^ you had commented positively on IRC, but didn't leave a github comment?
3 2014-11-17 01:43:46 <xuxu> does anyone here use bitcoinj?
4 2014-11-17 01:46:52 <BlueMatt> xuxu: #bitcoinj
5 2014-11-17 01:49:40 <xuxu> thank you BlueMatt
6 2014-11-17 01:56:16 <xuxu> how many satoshis can you send in a micropayment channel before it is no longer considered a micropayment?
7 2014-11-17 01:56:27 <xuxu> are micropayments ideal for tipping?
8 2014-11-17 01:56:32 <xuxu> if you have a lot of people tipping a single person, wouldn't that result in a wallet of dust?
9 2014-11-17 01:57:15 <midnightmagic> xuxu: Probably best to ask that in #bitcoin. This is the dev channel. :)
10 2014-11-17 01:57:39 <xuxu> thanks midnightmagic
11 2014-11-17 01:58:37 <phantomcircuit> huh just noticed there isn't an rpc call to return the full raw block
12 2014-11-17 02:31:10 <harding> phantomcircuit: getblock <hash> false
13 2014-11-17 03:02:37 <phantomcircuit> harding, oh hey
14 2014-11-17 03:02:38 <phantomcircuit> duh
15 2014-11-17 07:39:05 <wumpus> Luke-Jr: will take a look
16 2014-11-17 07:54:29 <BlueMatt> we need an option to connection to *.onion without a proxy set
17 2014-11-17 07:54:57 <BlueMatt> ie using tor's magic dns mapping shit
18 2014-11-17 07:56:31 <phantomcircuit> BlueMatt, -onion
19 2014-11-17 08:04:48 <wumpus> indeed, that's what -onion does, it sets a proxy but it is only used to connect to .onion
20 2014-11-17 08:45:53 <bitbit> Hi, how does the blockchain work with Ethereum? does it differ from how it's used with bitcoin? are there miners?
21 2014-11-17 08:50:22 <justanotheruser> bitbit: #ethereum
22 2014-11-17 08:50:57 <bitbit> I'm there and there's no one talking, I figured theres 4 times more users here :)
23 2014-11-17 08:54:11 <justanotheruser> bitbit: at the very least, make it bitcoin related and ask in #bitcoin
24 2014-11-17 08:59:33 <sipa> gmaxwell: the reason for using block psitions is that they are (much) smaller than block hashes
25 2014-11-17 09:00:20 <sipa> gmaxwell: though ideally i guess blocks would get a local 32-bit or 64-bit id, and we use that for referencing
26 2014-11-17 09:08:00 <gmaxwell> sipa: only the longest chain is in the txindex, so it could use height.
27 2014-11-17 09:08:28 <sipa> no, everything is in the txindex
28 2014-11-17 09:09:13 <sipa> or rather, "last seen"
29 2014-11-17 13:17:21 <wumpus> Luke-Jr: would be nice if #1816 had RPC tests for the new getblocktemplate functionality
30 2014-11-17 13:18:53 <wumpus> I'm not so sure how to go about manually testing it
31 2014-11-17 14:52:32 <jgarzik> wumpus, after watching #bitcoin-commits, still apparent that #bitcoin-dev needs a commit watcher also
32 2014-11-17 14:52:47 <wumpus> why?
33 2014-11-17 14:52:53 <jgarzik> wumpus, As I expected, #bitcoin-commits becomes filled with commits not necessary related to #bitcoin-dev
34 2014-11-17 14:53:03 <jgarzik> it fill up with bfgminer work and other commits
35 2014-11-17 14:53:13 <sipa> yeah, i left the channel too because of that reason
36 2014-11-17 14:53:16 <wumpus> I really prefer to leave bot stuff out of here
37 2014-11-17 14:53:23 <jgarzik> when a nice, low traffic bitcoin/bitcoin.git feed would be on-channel and on-topic here
38 2014-11-17 14:53:33 <jgarzik> it's a balance
39 2014-11-17 14:53:39 <jgarzik> bots are fine, if low traffic and useful
40 2014-11-17 14:53:57 <jgarzik> _just_ the bitcoin/bitcoin.git feed would be fine here
41 2014-11-17 14:54:09 <sipa> no opinion on whether it should be in here (and there has been protest before)... but #bitcoin-commits to me personally is currently too annoying to join
42 2014-11-17 14:54:55 <jgarzik> nod.
43 2014-11-17 14:56:14 <jgarzik> This channel #bitcoin-dev is exceedingly low traffic, except when there's on-topic activity. Adding "or work" (commits) seems reasonable.
44 2014-11-17 14:56:15 <wumpus> but what projects would be ontopic here? that starts that discussion again...
45 2014-11-17 14:56:24 <jgarzik> bitcoin/bitcoin.git
46 2014-11-17 14:56:32 <jgarzik> start small, grow later if needed
47 2014-11-17 14:56:32 <wumpus> btcd? obelisk?
48 2014-11-17 14:57:08 <jgarzik> Let's not overthink it. Active channel denizens seem to intersect most with bitcoin/bitcoin.git.
49 2014-11-17 14:57:21 <jgarzik> If people want more, we can have that discussion
50 2014-11-17 14:58:26 <wumpus> I'm fine with a bitcoin/bitcoin commits only channel, but rather not here
51 2014-11-17 14:58:58 <jgarzik> I think another channel is pointless. Merges to bitcoin/bitcoin.git are infrequent enough that it is IMO on-topic and useful here.
52 2014-11-17 14:59:26 <jgarzik> Most other Linux kernel & Fedora communities I've worked with follow the same logic.
53 2014-11-17 14:59:27 <harding> jgarzik: it looks like all the bfgminer commits made in -commits are by Not-1dff. Maybe you can just /ignore that bot?
54 2014-11-17 15:00:05 <jgarzik> not a valuable use of my time, pruning channel participants to make a useless channel useful
55 2014-11-17 15:00:24 <sipa> i don't like the "bitcoin development is only about bitcoin core" message that that gives
56 2014-11-17 15:00:53 <sipa> those of us who are actively following bitcoin/bitcoin development probably already watch it anyway in their github feed
57 2014-11-17 15:01:07 <Jouke> *rss-feed
58 2014-11-17 15:01:16 <jgarzik> sipa, If and when btcd devs show up and ask, by all means, turn it on.
59 2014-11-17 15:01:16 <sipa> bitcoin/bips could go here perhaps, but meh
60 2014-11-17 15:01:35 <wumpus> rather a no-bot policy here
61 2014-11-17 15:01:45 <jgarzik> -1
62 2014-11-17 15:01:48 <jgarzik> bots are useful
63 2014-11-17 15:02:03 <Jouke> btcd devs have their own irc server and channel
64 2014-11-17 15:02:36 <jgarzik> indeed. it was a rhetorical point.
65 2014-11-17 15:02:39 <jgarzik> they won't
66 2014-11-17 15:02:39 <sipa> maybe we need a separate channel for bitcoin core development (separate from protocol development)
67 2014-11-17 15:02:42 <jonasschnelli> btcd talks on irc.conformal.com:6697
68 2014-11-17 15:03:15 <sipa> other wallet deverlopers are certainly not interested in many of the discussions we're having here either
69 2014-11-17 15:04:19 <jgarzik> the intersection of useful commits and useful devs arrives at bitcoin/bitcoin.git
70 2014-11-17 15:04:41 <jgarzik> other projects already have their own resources. mentioned btcd was a rhetorical point to illustrate that.
71 2014-11-17 15:05:40 <sipa> that effectively establishes this channel as the channel about bitcoin core development
72 2014-11-17 15:05:48 <wumpus> well most of the talk here is pretty high level, I think it still makes sense to be here if you're not a bitcoin/bitcoin dev (and probably other people agree - otherwise there wouldn't be 470 users here...), but if someone wants to split up the channnels I'm not against it
73 2014-11-17 15:05:50 <sipa> and i would rather not have that; even if it already is in practice
74 2014-11-17 15:08:13 <jgarzik> The reference implementation remains a reference implementation. Not "the only" implementation but it is followed more than others.
75 2014-11-17 15:08:18 <wumpus> #bitcoin-core-dev?
76 2014-11-17 15:08:41 <sipa> jgarzik: fully agree with that, but i'm biased
77 2014-11-17 15:09:07 <sipa> and the part that is reference is mostly the consensus code
78 2014-11-17 15:09:26 <sipa> discussions about e.g. our GUI are totally irrelevant to anyone else
79 2014-11-17 15:09:28 <wumpus> yes, if it was just changes to the consensus code it'd be different
80 2014-11-17 15:09:37 <wumpus> if only that was in a separate repository
81 2014-11-17 15:09:51 <wumpus> but indeed, it will flood with gui changes for progress bar fixes etc too
82 2014-11-17 15:10:07 <sipa> #bitcoin-core-dev is fine to me
83 2014-11-17 15:14:08 <hearn> i'd hope anything that affects other implementations/wallets will stay here. not just stuff traditionally considered consensus changes.
84 2014-11-17 15:14:25 <sipa> right, fully agree
85 2014-11-17 15:14:37 <sipa> anything network/protocol/consensus/policy related
86 2014-11-17 15:15:35 <wumpus> hearn: yes, I was just talking about what would be acceptable for a commit bot here, I agree the topic of discussion here by human participants is allowed to be wider...
87 2014-11-17 15:17:13 <hearn> sure
88 2014-11-17 15:45:46 <wiw> Hi all :) Is there any way to see/assume what a mining pool is mining?
89 2014-11-17 15:46:09 <sipa> if they choose to publish it, sure
90 2014-11-17 15:46:21 <wiw> e.g. connect as a miner to the pool, ask for work, then look at the block they gave me to hash
91 2014-11-17 15:50:41 <wumpus> PSA: there is now a Bitcoin Core specific development channel at #bitcoin-core-dev, with commit feed for just bitcoin/bitcoin
92 2014-11-17 15:55:27 <wiw> i'll take that as a no. if i'm looking for a particular txn, i guess i'm only given the merkle root of txns (?), leaving me in the dark...
93 2014-11-17 15:56:10 <sipa> wiw: there's also no guarantee they're giving the same set of transactions to another miner
94 2014-11-17 15:56:27 <sipa> so unless you end up mining the winning block yourself, there's really no way to know
95 2014-11-17 15:56:36 <sipa> at least not with traditional protocols
96 2014-11-17 15:57:06 <wiw> that i know. the question is do i know which txns my mining pool has given me to mine
97 2014-11-17 15:57:17 <wiw> this is all guesswork of course
98 2014-11-17 15:57:21 <sipa> you can't
99 2014-11-17 15:57:27 <sipa> not with traditional mining protocols
100 2014-11-17 15:57:59 <wiw> thanks sipa
101 2014-11-17 15:58:28 <sipa> GBT does support that, but it's not commonly used directly between pools and miners
102 2014-11-17 16:00:19 <wiw> common method these days is getwork as opposed to GBT?
103 2014-11-17 16:00:53 <sipa> or stratum i guess, but i'm no expert
104 2014-11-17 16:01:35 <wiw> ok thx :)
105 2014-11-17 16:06:52 <hearn> wiw: gbt is in general better for miners and the ecosystem, or would be it if was fully used
106 2014-11-17 16:13:40 <kouradas> http://www.dogeraiser.com/c/58 i made this dogeraiser and they scammed me. if you can help there is a hefty sum to be made check this post also http://www.reddit.com/r/dogecoin/comments/2mkfvd/dogeraiser_repost/ 6 MILLION DOGECOIN
107 2014-11-17 16:13:59 <sipa> kouradas: not here
108 2014-11-17 16:28:53 <Luke-Jr> wumpus: there isn't really any easy way - we'd need to run in regtest mode or similar and throw every kind of invalid block at it
109 2014-11-17 16:30:14 <sipa> Luke-Jr: the rpc tests already run in regtest mode, and testing something is certainly preferably to testing nothing imho
110 2014-11-17 16:31:45 <wumpus> right, just a basic test that exercises the new functionality would be a good start
111 2014-11-17 16:32:27 <Luke-Jr> is there a simple way to run them?
112 2014-11-17 16:33:45 <wumpus> cd qa/rpc-tests && python <nameoftest>.py ?
113 2014-11-17 16:34:02 <Luke-Jr> I presume I need to set bitcoind up in some way for that
114 2014-11-17 16:34:06 <wumpus> no
115 2014-11-17 16:34:35 <wumpus> they're self-contained
116 2014-11-17 16:36:32 <Luke-Jr> anyone mind if I keep the new tests independent from the LP ones so they can run fast? what's the best way to do that?
117 2014-11-17 16:37:09 <wumpus> LP ones?
118 2014-11-17 16:37:23 <sipa> longpolling?
119 2014-11-17 16:38:38 <Luke-Jr> right
120 2014-11-17 16:38:46 <Luke-Jr> the existing test takes 70 seconds to complete
121 2014-11-17 16:39:17 <Luke-Jr> side note: I didn't see any disagreement on changing permitbaremultisig default.. just agreement and requests for stats nobody has
122 2014-11-17 16:39:22 <wumpus> oh sure, if you think that makes sense, just copy the testcase to a new one and change it
123 2014-11-17 16:39:48 <wumpus> Luke-Jr: it's controversial
124 2014-11-17 16:40:01 <Luke-Jr> defaults should be considered inherently uncontroversial IMO
125 2014-11-17 16:40:02 <sipa> yes it is :)
126 2014-11-17 16:42:06 <Luke-Jr> re testing: trial run with smartfees.py failed :P
127 2014-11-17 16:42:28 <sipa> bah
128 2014-11-17 16:42:33 <sipa> those tests really need to run in travis
129 2014-11-17 16:43:25 <wumpus> some do now, afaik
130 2014-11-17 16:44:51 <Luke-Jr> anyhow, I think it's setting a bad precedent in a number of ways to NOT change the default when all the comments are in favour of it; dropping it now
131 2014-11-17 16:45:56 <wumpus> have you discussed it on the mailing list too? github issues are pretty limited in scope
132 2014-11-17 16:46:16 <sipa> it definitely needs wider discussion
133 2014-11-17 16:50:05 <Luke-Jr> k, left a few comments on https://github.com/bitcoin/bitcoin/pull/1816/files - will address the rest once I get some testing
134 2014-11-17 16:50:47 <Luke-Jr> ACTION wonders if there's a single rpctest he can use as an example of one passing
135 2014-11-17 16:50:48 <wumpus> Luke-Jr: if you want to give it further discussion on the mailing list, I'm fine with reopening the issue, but it's far from clear-cut enough to me right now
136 2014-11-17 16:51:15 <Luke-Jr> wumpus: well, if the cutoff for this change is tomorrow, I doubt it can resolve that in 1 day, so might as well wait until 0.11
137 2014-11-17 16:51:29 <wumpus> right, it can't make it into 0.10 anyhow anyhow
138 2014-11-17 16:52:34 <Luke-Jr> ok, going to focus on 0.10 stuff until it branches then
139 2014-11-17 16:52:43 <wumpus> let's aim on getting #1816 in
140 2014-11-17 16:52:53 <Luke-Jr> yay qa/rpc-tests/listtransactions.py works
141 2014-11-17 16:56:38 <Luke-Jr> bleh
142 2014-11-17 16:56:47 <Luke-Jr> this will be a pain since we need to create our own coinbase
143 2014-11-17 16:57:38 <Luke-Jr> hm
144 2014-11-17 16:57:47 <Luke-Jr> does regtest allow non-height-in-coinbase? :>
145 2014-11-17 16:58:09 <Luke-Jr> otoh, that's dangerous if it does..
146 2014-11-17 17:26:12 <Luke-Jr> # Copied from Eloipool (AGPLv3); MIT license granted for this snippet
147 2014-11-17 17:26:18 <Luke-Jr> is this sufficient for a few functions copied from Eloipool?
148 2014-11-17 17:26:30 <Luke-Jr> or probably not even necessary since I'm committing it
149 2014-11-17 17:27:22 <Luke-Jr> ?
150 2014-11-17 17:40:33 <Luke-Jr> where are rpctests getting their bitcoind from? they don't seem to be using mine :/
151 2014-11-17 17:41:46 <Luke-Jr> /usr/bin -.-
152 2014-11-17 17:50:56 <gavinandresen> Luke-Jr: bitcoind/bitcoin-cli should be found in ../../src (default for test_framework.py âsrcdir= option)
153 2014-11-17 17:51:34 <Luke-Jr> gavinandresen: I see - in my case, it would be ./src
154 2014-11-17 17:51:54 <gavinandresen> Luke-Jr: okey doke, then pass âsrcdir=./src ....
155 2014-11-17 17:52:15 <Luke-Jr> thx
156 2014-11-17 17:56:28 <wumpus> Luke-Jr: if you're committing code you wrote yourself, you don't need to add that
157 2014-11-17 17:57:20 <Luke-Jr> wumpus: ?
158 2014-11-17 17:57:24 <Luke-Jr> ok
159 2014-11-17 17:58:38 <wumpus> (or at least, hold the copyright to)
160 2014-11-17 18:05:24 <Luke-Jr> ok, so confirmed regtest is failing to enforce block height in coinbase
161 2014-11-17 18:05:30 <Luke-Jr> any easy fix? or should I ignore?
162 2014-11-17 18:05:47 <sipa> it has no switchover date afaik
163 2014-11-17 18:06:01 <sipa> i'd ignore that for now
164 2014-11-17 18:42:05 <cfields> gavinandresen: i'm not quite sure what to do about the win32 rpc tests, they act up on travis quite often
165 2014-11-17 18:42:23 <cfields> gavinandresen: i haven't been able to narrow it down to anything, starting to wonder if it's an issue with wine itself
166 2014-11-17 18:42:57 <sipa> only run them for native architectures?
167 2014-11-17 18:43:16 <kanzure> i don't know any windows people that have time available, but testing in wine does not sound like a good idea to me
168 2014-11-17 18:43:23 <kanzure> i mean, if you are interested in targetting wine itself, that sounds fine
169 2014-11-17 18:44:18 <kanzure> btw microsoft dumped some vagrant boxes of windows finally http://vagrantbox.es/ (at the bottom of the list)
170 2014-11-17 18:45:31 <cfields> sipa: sure, but there are obvious implications there. Afaik wine hasn't given us trouble elsewhere
171 2014-11-17 18:47:28 <cfields> i'll see if i can reproduce locally
172 2014-11-17 19:12:35 <Luke-Jr> ETA 5 mins on #1816 revision
173 2014-11-17 19:14:37 <Luke-Jr> wumpus: can we rename the 'core' directory before 0.10? :/
174 2014-11-17 19:16:17 <Luke-Jr> I think that got hung up in bikeshedding
175 2014-11-17 19:21:05 <Luke-Jr> ok, #1816 comments addressed and tests added
176 2014-11-17 19:21:13 <Luke-Jr> sipa: wumpus: ^
177 2014-11-17 19:43:39 <todam00n> anyone knows something about merged mining? I'm trying to calculate the hash the coinbasetx using the auxpow field returned by getblock and sometimes i get the expeceted txid and on a particular block, it doesn't work
178 2014-11-17 19:43:42 <todam00n> really strange :/
179 2014-11-17 19:44:23 <Luke-Jr> Bitcoin doesn't have any kind of merged mining code
180 2014-11-17 19:44:37 <todam00n> yes I know
181 2014-11-17 19:44:47 <todam00n> I was asking to altcoin devs
182 2014-11-17 19:45:19 <todam00n> is there a better channel for that?
183 2014-11-17 19:49:46 <Luke-Jr> todam00n: ##altcoin-dev ; it's specifically off-topic/not-allowed in here (see topic)
184 2014-11-17 20:12:45 <todam00n> is there any easy way to inspect the raw data of a specific block?
185 2014-11-17 20:13:23 <Luke-Jr> getblock <hash> false
186 2014-11-17 20:17:45 <BlueMatt> phantomcircuit/wumpus: no, no, silly...I can only connect to *.onion WITHOUT a proxy
187 2014-11-17 20:17:51 <BlueMatt> I dont have a proxy to set...
188 2014-11-17 20:19:36 <wumpus> ah, you've redirected DNS to tor itself?
189 2014-11-17 20:19:40 <BlueMatt> yes
190 2014-11-17 20:20:20 <wumpus> we indeed can't handle that at the moment
191 2014-11-17 20:20:41 <wumpus> you could run a dummy socks5 proxy I guess ... :P
192 2014-11-17 20:20:42 <BlueMatt> there should just be an override "I know I can connect to onions, shut up and try"
193 2014-11-17 20:42:54 <todam00n> Luke-Jr: thanks
194 2014-11-17 20:50:39 <isis> BlueMatt: if you're using a Tor Transproxy to redirect all your DNS, you might be able to jankily tell bitcoind to connect to bluemattonion.com and then, connect to Tor's ControlPort and do `MAPADDRESS bluemattonion.com=fubar01234567890.onion`
195 2014-11-17 20:51:20 <isis> BlueMatt: although obviously that's kludgey and having a -no-seriously-onion bitcoind option is nicer. :)
196 2014-11-17 20:51:21 <BlueMatt> actually, I have a dnsmasq proxy in between (to not forward non-onion dns requests to tor)...I could probably tell it to map .btconion to .onion or something
197 2014-11-17 20:51:54 <isis> interesting⦠yes, that might work
198 2014-11-17 20:52:23 <BlueMatt> still, probably quicker for me to implement -no-really-tor than to read dnsmasq man page...
199 2014-11-17 20:52:47 <isis> true :)
200 2014-11-17 21:14:17 <droffel> So, i'm trying to write a program that will listen to the network for transactions relating to an arbitrary address.
201 2014-11-17 21:14:50 <phantomcircuit> droffel, bloom filters and/or parse the full blockchain
202 2014-11-17 21:14:52 <droffel> My current thoughts are to pretend to be a validating node, and run through every transaction to create the next block, at which point I discard the block prior, until i'm caught up
203 2014-11-17 21:15:14 <droffel> and then just pull each block on its own after its mined after that
204 2014-11-17 21:15:27 <droffel> I haven't heard of bloom filters before
205 2014-11-17 21:16:48 <phantomcircuit> droffel, look into spv clients (simple payment verification)
206 2014-11-17 21:17:40 <droffel> phantomcircuit, can I shoot you a few messages in private?
207 2014-11-17 21:18:00 <phantomcircuit> nope
208 2014-11-17 21:18:11 <phantomcircuit> better to ask where there's more eyeballs
209 2014-11-17 21:18:13 <phantomcircuit> also im leaving
210 2014-11-17 21:18:17 <droffel> damn, alright
211 2014-11-17 21:23:55 <todam00n> ah damn it
212 2014-11-17 21:24:17 <todam00n> i was multiplying a float by 1e8 in python
213 2014-11-17 21:24:28 <todam00n> 3 wasted hours
214 2014-11-17 21:24:31 <todam00n> :'(
215 2014-11-17 21:24:45 <Luke-Jr> todam00n: problem
216 2014-11-17 21:24:47 <Luke-Jr> ?
217 2014-11-17 21:25:14 <belcher> 1e8 is the number of satoshis in a bitcoin, if hes doing what i think he is
218 2014-11-17 21:25:25 <todam00n> yes
219 2014-11-17 21:25:37 <belcher> Decimal() baby
220 2014-11-17 21:25:40 <todam00n> that's why some transactions wouldn't hash to the correct txid :(
221 2014-11-17 21:25:49 <Luke-Jr> todam00n: I don't see the problem
222 2014-11-17 21:25:53 <todam00n> i forgot to round after multiplying
223 2014-11-17 21:25:56 <Luke-Jr> oh
224 2014-11-17 21:26:03 <Luke-Jr> yeah, that's important
225 2014-11-17 21:26:23 <todam00n> i just saw this https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC) :/
226 2014-11-17 21:27:45 <todam00n> i was doing s_txout += int_to_hex(int(txout['value'] * COIN), 8) instead of s_txout += int_to_hex(long(round(txout['value'] * COIN)), 8)
227 2014-11-17 21:27:48 <todam00n> anyways, problem solved
228 2014-11-17 21:28:47 <Luke-Jr> ⦠why are you doing it in hex?
229 2014-11-17 21:31:43 <todam00n> im not sure.. trying to reuse electrum functions