1 2014-03-26 00:00:07 <sipa> well, we're using -1 confirmation for 'conflicted' now
  2 2014-03-26 00:00:14 <olalonde> denisx: ah yeah maybe… I'm running bitcoind in a docker container actually
  3 2014-03-26 00:00:20 <davout> sipa: well, you said the tip was reported with one because the latest block counted as a confirmation for itself, technically a reorg'd block would count for a confirmation for itself too if you follow the same reasoning
  4 2014-03-26 00:00:21 <Luke-Jr> sipa: <0, anyway
  5 2014-03-26 00:00:28 <Luke-Jr> sipa: I don't think we need to guarantee it is exactly -1
  6 2014-03-26 00:00:45 <davout> <=
  7 2014-03-26 00:00:51 <davout> will do fine
  8 2014-03-26 00:00:55 <sipa> davout: well, depends whether you're talking about the block tree or the block chain, if you want to discuss semantics
  9 2014-03-26 00:01:01 <denisx> olalonde: on my mac I put the chainstate in a ramdisk to speed up catching the latest block if I am some weeks behind
 10 2014-03-26 00:01:15 <sipa> denisx: use -dbcache=<largenumber> instead; way faster than ramdisk
 11 2014-03-26 00:01:22 <davout> Luke-Jr: the depth-in-main-chain way to explain it sounds more self-consistent :-)
 12 2014-03-26 00:01:27 <sipa> davout: in the block tree, you're right, and that could be well-defined
 13 2014-03-26 00:01:42 <sipa> davout: but we generally don't care about the whole tree, only the currently-active chain in it
 14 2014-03-26 00:01:47 <olalonde> denisx: how do you do that? mount the data directory in a ram filesystem?
 15 2014-03-26 00:01:56 <denisx> sipa: sure, because I think a ramdisk speeds up the writes
 16 2014-03-26 00:02:02 <davout> sipa Luke-Jr thanks a lot for the information, exactly what i was looking for
 17 2014-03-26 00:02:03 <denisx> reads are cached anyway
 18 2014-03-26 00:02:06 <sipa> denisx: and dbcache avoids the writes altogether
 19 2014-03-26 00:02:14 <davout> tty'all later <3
 20 2014-03-26 00:02:14 <olalonde> not sure i have enough ram for that :P
 21 2014-03-26 00:02:15 <denisx> sipa: ok, will try that next time
 22 2014-03-26 00:02:19 <denisx> olalonde: what sipa says
 23 2014-03-26 00:02:24 <sipa> denisx: with a ramdisk you still need to serialize and deserialize all the time
 24 2014-03-26 00:02:41 <olalonde> ah, good
 25 2014-03-26 00:03:25 <denisx> sipa: but how do I start the gui version with that?
 26 2014-03-26 00:03:41 <Luke-Jr> davout: again though, note that reorg'd chains will only return IF you see them before the current chain
 27 2014-03-26 00:03:47 <sipa> denisx: same way?
 28 2014-03-26 00:03:55 <Luke-Jr> davout: the node will ignore reorg'd chains if it already knows a better one
 29 2014-03-26 00:04:01 <Apocalyptic> obviously
 30 2014-03-26 00:04:04 <sipa> denisx: put dbcache=1000 in your bitcoin.conf, or start with -dbcache=1000 on the command line
 31 2014-03-26 00:04:13 <sipa> denisx: or whatever number you like of course
 32 2014-03-26 00:04:14 <denisx> sipa: ah, ok
 33 2014-03-26 00:04:52 <davout> Luke-Jr: yeah i understand, that doesn't really matter in my case, I simply want to be able to take reorgs into account should i encounter one, as in if i record a block i want to come back at it after the next block and be able to tell if i should keep it or throw it away
 34 2014-03-26 00:05:36 <Luke-Jr> k
 35 2014-03-26 00:07:51 <Jimmy06> how do I get the OP_CHECKSIG of a tx
 36 2014-03-26 00:08:06 <Luke-Jr> Jimmy06: what?
 37 2014-03-26 00:08:40 <sipa> a transaction has typically multiple
 38 2014-03-26 00:08:48 <olalonde> getinfo doesn't seem to report any new blocks when i launch bitcoind with dbcache=1000, is this normal?
 39 2014-03-26 00:09:05 <sipa> olalonde: wait
 40 2014-03-26 00:09:08 <olalonde> oh nevermind, server was initializing I guess
 41 2014-03-26 00:09:46 <Jimmy06> Luke-Jr: I need to find something called the OP_CHECKSIG of the genesis block
 42 2014-03-26 00:09:53 <sipa> Jimmy06: you won't
 43 2014-03-26 00:09:58 <Luke-Jr> Jimmy06: blocks don't have opcodes
 44 2014-03-26 00:10:10 <sipa> oh wait, there should be one in its output
 45 2014-03-26 00:10:16 <phantomcircuit> davout, what for?
 46 2014-03-26 00:10:25 <Luke-Jr> and I would academically argue that the genesis block has zero transactions ;)
 47 2014-03-26 00:10:41 <phantomcircuit> Luke-Jr, heh
 48 2014-03-26 00:10:44 <phantomcircuit> technically correct
 49 2014-03-26 00:10:53 <phantomcircuit> THE ONLY KIND OF CORRECT
 50 2014-03-26 00:10:55 <Jimmy06> 04678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5F is Bitcoins
 51 2014-03-26 00:11:06 <sipa> Jimmy06: a block contains a list of transactions (the first one being special), every transaction has inputs and outputs
 52 2014-03-26 00:11:11 <Luke-Jr> merkleroot=4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b means 0 transactions :D
 53 2014-03-26 00:11:20 <Jimmy06> genesis block only 1 in
 54 2014-03-26 00:11:23 <davout> phantomcircuit: keep track of the blocks in which unspent outs we consider ours appear
 55 2014-03-26 00:11:44 <Jimmy06> that being 50 un-spendable coins
 56 2014-03-26 00:12:25 <davout> phantomcircuit: comparing the DB-balance and the actual balance is tricky because it keeps moving all the time, so it's hard to do if you want to be exact
 57 2014-03-26 00:12:34 <Jimmy06> Now if you look here you'll see at line 24 they define an OP_CHECKSIG https://github.com/bitpay/bitcore/blob/master/networks.js
 58 2014-03-26 00:12:53 <davout> so i figured i'd compare balances at a certain block height instead of comparing balances at a certain point o time
 59 2014-03-26 00:13:02 <sipa> Luke-Jr: or, alternatively, hashPrev = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f means "first block"
 60 2014-03-26 00:13:21 <davout> which, if you think about it is simply taking into account the fact that the blockchain *is* the reference timer :D
 61 2014-03-26 00:13:24 <Luke-Jr> sipa: hm!
 62 2014-03-26 00:13:44 <sipa> Luke-Jr: which actually makes sense, as the genesis block is never even validated
 63 2014-03-26 00:13:45 <Luke-Jr> sipa: won't that break the difficulty algorithms, though? :P
 64 2014-03-26 00:13:50 <sipa> hmm, perhaps!
 65 2014-03-26 00:14:11 <Luke-Jr> and halving
 66 2014-03-26 00:14:42 <Luke-Jr> s/break/make unnecessarily confusing/
 67 2014-03-26 00:14:54 <sipa> Jimmy06: what are you actually looking for?
 68 2014-03-26 00:15:04 <Jimmy06> how they got that hex string
 69 2014-03-26 00:15:10 <Luke-Jr> plus, the merkleroot way, you can say bitcoin had ZERO premining :P
 70 2014-03-26 00:15:30 <Jimmy06> I'm attempting to set that up for an alt coin and cant work out where they got that from
 71 2014-03-26 00:15:32 <Luke-Jr> 
ACTION suspects Jimmy06 is trying to do "homework" made by a less-than-competent instructor

 72 2014-03-26 00:15:39 <Luke-Jr> oh, worse. scamcoiner.
 73 2014-03-26 00:15:43 <Jimmy06> nah
 74 2014-03-26 00:15:48 <Jimmy06> no scamcoins :)
 75 2014-03-26 00:15:52 <Luke-Jr> sigh
 76 2014-03-26 00:16:15 <Jimmy06> cant be a scam if it acutally has a market when the coin is setup right ? :D
 77 2014-03-26 00:16:29 <sipa> i'd argue that without a market, it can't be a scam
 78 2014-03-26 00:16:41 <sipa> but anyway, altcoins or homework questions are off topic here
 79 2014-03-26 00:16:43 <sipa> scam or not
 80 2014-03-26 00:16:52 <Jimmy06> right but I havnt asked about that have I
 81 2014-03-26 00:16:53 <denisx> every currency is a scam
 82 2014-03-26 00:17:05 <Jimmy06> I asked where they got that from
 83 2014-03-26 00:17:23 <sipa> Jimmy06: no offence, but if you actually are serious about doing something useful with an altcoin, at least understand bitcoin first
 84 2014-03-26 00:17:32 <sipa> Jimmy06: and this basic question doesn't belong here
 85 2014-03-26 00:17:53 <Jimmy06> how can I understand it your avoding the topic LOL
 86 2014-03-26 00:17:56 <Jimmy06> catch 22 ?
 87 2014-03-26 00:18:07 <Luke-Jr> read the code and docs
 88 2014-03-26 00:18:15 <Jimmy06> what like this https://en.bitcoin.it/wiki/OP_CHECKSIG
 89 2014-03-26 00:18:17 <sipa> by studying the code, reading the wiki, reading stackexchange, reading the whitepaper
 90 2014-03-26 00:18:31 <sipa> if you have specific questions left, i'll be happy to answer
 91 2014-03-26 00:18:40 <sipa> but we can't explain you bitcoin from beginning to end here
 92 2014-03-26 00:19:21 <Jimmy06> I wasn't asking for a Degree from you :)
 93 2014-03-26 00:19:39 <Luke-Jr> making an altcoin requires more than a degree
 94 2014-03-26 00:19:45 <Luke-Jr> it requires you to actually understand things
 95 2014-03-26 00:19:54 <Jimmy06> Alt coin is running and this is indirectly nothing to do with it
 96 2014-03-26 00:21:19 <Jimmy06> right ok script pubkey is what I'm looking for
 97 2014-03-26 00:21:28 <phantomcircuit> davout, so this is for a shared wallet?
 98 2014-03-26 00:21:32 <Jimmy06> thanks :)
 99 2014-03-26 00:21:37 <Jimmy06> lol
100 2014-03-26 00:21:49 <Apocalyptic> phantomcircuit, it's probably for bitcoin-central
101 2014-03-26 00:22:09 <phantomcircuit> Apocalyptic, that's my assumption, but I want to be really clear before i suggest anything
102 2014-03-26 00:22:32 <phantomcircuit> 280k encrypted keys
103 2014-03-26 00:22:37 <phantomcircuit> only 720k more to go
104 2014-03-26 00:22:49 <davout> phantomcircuit: yep
105 2014-03-26 00:24:45 <phantomcircuit> davout, then just keep track of which block a transaction was in and which block was the newest tip
106 2014-03-26 00:25:38 <phantomcircuit> or if you want to be super lazy
107 2014-03-26 00:25:44 <davout> what do you mean by "the newest tip" ?
108 2014-03-26 00:26:01 <phantomcircuit> just call listtransactions "*" 2^32
109 2014-03-26 00:26:08 <phantomcircuit> and do a 1:1 comparison with your database
110 2014-03-26 00:26:18 <phantomcircuit> it sounds retarded but it's actually not bad
111 2014-03-26 00:26:46 <phantomcircuit> just make sure you have a writethrough cache
112 2014-03-26 00:26:59 <Apocalyptic> <phantomcircuit> just call listtransactions "*" 2^32 // is that better than listsinceblock ?
113 2014-03-26 00:27:29 <midnightmagic> :-(
114 2014-03-26 00:27:34 <midnightmagic> yeahhh..   saw that coming.
115 2014-03-26 00:27:40 <Apocalyptic> and regularly updating the checkpointblock (which you choose so old that it's safe)
116 2014-03-26 00:27:41 <phantomcircuit> Apocalyptic, you dont have to keep track of orphans that way
117 2014-03-26 00:27:59 <phantomcircuit> yeah yeah
118 2014-03-26 00:28:02 <phantomcircuit> you can do it either way
119 2014-03-26 00:28:25 <phantomcircuit> but realistically listtransactions is fairly quick even when you have a ridiculous number of transactions
120 2014-03-26 00:29:03 <davout> phantomcircuit: that would work if all your transactions are in the same wallet
121 2014-03-26 00:29:03 <phantomcircuit> im assuming davout is running this on a real server with enough ram to completely avoid swapping
122 2014-03-26 00:29:19 <davout> phantomcircuit: i actually don't use bitcoind that much
123 2014-03-26 00:29:30 <phantomcircuit> davout, it works if you have multiple wallets also...
124 2014-03-26 00:29:45 <davout> phantomcircuit: how would i do a 1-1 check on txes?
125 2014-03-26 00:30:12 <phantomcircuit> davout, bitcoind keeps transactions in the wallet even if they're re organized out
126 2014-03-26 00:31:15 <Apocalyptic> <davout> phantomcircuit: i actually don't use bitcoind that much // *fear* may I ask what you do use ?
127 2014-03-26 00:31:28 <davout> phantomcircuit: i'm using master public keys to generate addies, these get rotated from time to time
128 2014-03-26 00:31:29 <phantomcircuit> dont say bitcoin ruby
129 2014-03-26 00:31:36 <Apocalyptic> ^ just don't
130 2014-03-26 00:31:37 <davout> phantomcircuit: why not ?
131 2014-03-26 00:31:43 <phantomcircuit> oh boy
132 2014-03-26 00:32:07 <phantomcircuit> davout, the only client which is compatible 100% with the reference client is the reference client
133 2014-03-26 00:32:24 <phantomcircuit> for sending bitcoins use whatever you want
134 2014-03-26 00:32:32 <phantomcircuit> for receiving bitcoins use the reference client
135 2014-03-26 00:32:39 <davout> phantomcircuit Apocalyptic maybe you guys should stop assuming that i do things i didn't say i did :-)
136 2014-03-26 00:32:59 <Apocalyptic> davout, it's not funny, you know I have coins @b-c
137 2014-03-26 00:33:02 <phantomcircuit> there is really no reason not to use bitcoind
138 2014-03-26 00:33:12 <Luke-Jr> phantomcircuit: yes there is
139 2014-03-26 00:33:20 <phantomcircuit> Luke-Jr, like what?
140 2014-03-26 00:33:25 <Luke-Jr> like it doesn't scale
141 2014-03-26 00:33:28 <Apocalyptic> lol
142 2014-03-26 00:33:31 <Luke-Jr> like we don't recommend big exchanges use it
143 2014-03-26 00:33:40 <davout> i use bitcoind as a gateway to the network, and bitcoin-ruby as a connection to it, the fact that bitcoind uses eventmachine is pretty sweet to monitor all the flow of passing transactions
144 2014-03-26 00:33:48 <Apocalyptic> Luke-Jr, so what do you recommend big exchanges ?
145 2014-03-26 00:33:50 <phantomcircuit> Luke-Jr, who doesn't recommend big exchanges use it???
146 2014-03-26 00:33:55 <davout> phantomcircuit: there are tons of reasons not to use bitcoind
147 2014-03-26 00:34:00 <Luke-Jr> Apocalyptic: there is no public software for that
148 2014-03-26 00:34:01 <Apocalyptic> "write your own software bro, just like Tux" ?
149 2014-03-26 00:34:12 <Luke-Jr> phantomcircuit: anyone?
150 2014-03-26 00:34:39 <davout> phantomcircuit Apocalyptic for example the 'accounts' functionality that was recommended a while ago didn't scale at all and even had ugly rounding bugs
151 2014-03-26 00:34:54 <davout> bottom line, don't trust a single piece of software, ever
152 2014-03-26 00:34:55 <Luke-Jr> (and is being removed)
153 2014-03-26 00:35:02 <Apocalyptic> davout, the fact accounts are buggy is well known
154 2014-03-26 00:35:04 <phantomcircuit> davout, nobody should be using the accounts functionality for anything ever
155 2014-03-26 00:35:12 <Apocalyptic> I never see someone recommending relying on it tbh
156 2014-03-26 00:35:19 <davout> Apocalyptic: it's well known because i suffered from it in 2010-2011
157 2014-03-26 00:35:22 <Luke-Jr> Apocalyptic: accounts aren't buggy, just not easy to backup and conflict with B-Qt :p
158 2014-03-26 00:35:28 <phantomcircuit> i've been telling people not to use it for a loong time
159 2014-03-26 00:35:40 <phantomcircuit> Luke-Jr, they're effectively impossible to backup
160 2014-03-26 00:35:44 <davout> Apocalyptic phantomcircuit i'm talking 2010-early 2011 here guys
161 2014-03-26 00:35:44 <Luke-Jr> right
162 2014-03-26 00:36:01 <phantomcircuit> davout, yeah and that was years ago
163 2014-03-26 00:36:10 <phantomcircuit> nobody has recommended that seriously for a long time
164 2014-03-26 00:36:16 <aynstein> 
ACTION counts on fingers

165 2014-03-26 00:36:16 <phantomcircuit> it's 2014
166 2014-03-26 00:36:18 <davout> phantomcircuit: well, the lesson to not rely on bitcoind stuck :-)
167 2014-03-26 00:36:34 <phantomcircuit> davout, 0.6.x couldn't handle the volume
168 2014-03-26 00:36:40 <phantomcircuit> 0.7.x was better but still
169 2014-03-26 00:36:54 <phantomcircuit> 0.8.x will handle a very large wallet with minimal difficulty
170 2014-03-26 00:36:59 <davout> phantomcircuit: well yes, it's 2014 and backing up a wallet reliably is still not easy with bitcoind
171 2014-03-26 00:37:08 <davout> the keypool is merely shifting the problem
172 2014-03-26 00:37:19 <phantomcircuit> there is still at least one edge case in the wallet that im aware of
173 2014-03-26 00:37:24 <davout> the correct solution obviously being deterministic wallets
174 2014-03-26 00:37:26 <phantomcircuit> but unless you're doing something ridiculous it wont be an issue
175 2014-03-26 00:37:43 <Apocalyptic> phantomcircuit, care to disclose ?
176 2014-03-26 00:37:45 <warren> saivann: around?
177 2014-03-26 00:37:55 <phantomcircuit> davout, i personally think hd wallets are currently more risk than they are worth
178 2014-03-26 00:37:56 <Luke-Jr> davout: you *could* use pycoin and import HD wallet keys to bitcoind manually
179 2014-03-26 00:37:59 <davout> phantomcircuit: not to mention that bitcoind is a pain to deploy
180 2014-03-26 00:38:04 <Luke-Jr> not necessarily the best idea, but fwiw
181 2014-03-26 00:38:15 <phantomcircuit> Apocalyptic, it's an edge case in IsConfirmed
182 2014-03-26 00:38:23 <davout> phantomcircuit: everyone has an opinion, i'd be interested in the supporting argument
183 2014-03-26 00:38:37 <Luke-Jr> phantomcircuit: the one 0.9.0 fixed?
184 2014-03-26 00:38:46 <phantomcircuit> if you try to spend your own unconfirmed outputs you'll end up in code that is O(!n) or something
185 2014-03-26 00:38:47 <davout> Luke-Jr: i use the electrum-style mpk's
186 2014-03-26 00:38:52 <phantomcircuit> maybe it's O(2^n)
187 2014-03-26 00:38:56 <phantomcircuit> i cant remember exactly
188 2014-03-26 00:38:59 <phantomcircuit> it's horribly slow
189 2014-03-26 00:39:12 <phantomcircuit> Luke-Jr, was that fixed?
190 2014-03-26 00:39:18 <Luke-Jr> phantomcircuit: vSpent stuff, right?
191 2014-03-26 00:39:18 <phantomcircuit> i still have an open pr about it i think
192 2014-03-26 00:39:43 <phantomcircuit> Luke-Jr, no it's the vtxPrev stuff
193 2014-03-26 00:39:56 <Luke-Jr> anyhow, you shouldn't spend even your own unconfirmed change
194 2014-03-26 00:40:15 <phantomcircuit> oh maybe that was fixed as part of the malleability things
195 2014-03-26 00:40:21 <phantomcircuit> that would make sense
196 2014-03-26 00:40:53 <davout> Luke-Jr: i tried an hour ago, wondered why bitcoind wouldn't let me do it
197 2014-03-26 00:46:48 <saivann> warren: yep
198 2014-03-26 00:47:04 <warren> saivann: my intern is reading your developer documentation
199 2014-03-26 00:48:06 <warren> saivann: she intends to work on end-user documentation, hopefully for the same site
200 2014-03-26 00:48:45 <warren> saivann: http://bitcoindev.us.to/en/developer-guide  this is your work in progress right?
201 2014-03-26 00:49:03 <saivann> warren: If she wants to help, she's welcome: https://bitcointalk.org/index.php?topic=511876.0
202 2014-03-26 00:49:28 <saivann> warren: Most of it is not written by me, and is still a draft. Technical mistakes are possible at this point
203 2014-03-26 00:49:49 <phantomcircuit> Luke-Jr, yeah you're right it was fixed
204 2014-03-26 00:50:00 <phantomcircuit> although something about the way it's fixed feels a bit off
205 2014-03-26 00:50:02 <phantomcircuit> but im not sure why
206 2014-03-26 00:50:06 <phantomcircuit> shrug
207 2014-03-26 00:50:32 <phantomcircuit> davout, with that fixed there isn't a good reason not to use bitcoind for an exchange
208 2014-03-26 00:50:41 <phantomcircuit> Luke-Jr, unless there is something other than performance that is an issue
209 2014-03-26 00:52:15 <Luke-Jr> saivann: this document seems to talk a lot about some slow data rate (milli-bits)
210 2014-03-26 00:53:19 <davout> phantomcircuit: the accounts stuff ?
211 2014-03-26 00:53:29 <warren> saivann: ok thanks, glad you wrote that in detail
212 2014-03-26 00:54:23 <saivann> Luke-Jr: We're going to use "satoshis" instead, someone should fix that, there's an issue in my git repository about that
213 2014-03-26 00:55:15 <phantomcircuit> davout, you dont use the accounts
214 2014-03-26 00:55:17 <davout> the only valid reason to use bitcoind for an exchange is to hear about incoming transactions, assuming broadcasting payments in realtime is a bad idea, which it is
215 2014-03-26 00:55:45 <phantomcircuit> you just do everything from the default account ""
216 2014-03-26 00:56:17 <davout> phantomcircuit: you misunderstand, i don't use bitcoind on my servers for any other purpose than hearing about txes, through a bitcoin-ruby proxy
217 2014-03-26 00:59:23 <phantomcircuit> davout, no i believe i do understand exactly what you're doing
218 2014-03-26 00:59:43 <phantomcircuit> and im saying that i believe it is a very very bad idea
219 2014-03-26 01:00:03 <davout> phantomcircuit: well then, go ahead and make a point
220 2014-03-26 01:00:23 <davout> i don't think you'd be mentioning the accounts at all if you actually understood
221 2014-03-26 01:01:14 <phantomcircuit> <phantomcircuit> davout, the only client which is compatible 100% with the reference client is the reference client
222 2014-03-26 01:01:25 <phantomcircuit> your saying you dont use bitcoind because of the accounts stuff
223 2014-03-26 01:01:30 <phantomcircuit> im saying that is irrelevant
224 2014-03-26 01:02:23 <olalonde> am I the only one to think that alternative clients are a good thing for bitcoin?
225 2014-03-26 01:02:53 <phantomcircuit> olalonde, sure, but trusting them with other peoples bitcoins? no that is probably not currently a good idea
226 2014-03-26 01:03:21 <phantomcircuit> im not sure that i can adequately explain how difficult implementing a full verifying node is
227 2014-03-26 01:03:35 <olalonde> maybe not currently, but you seem to imply that such a thing is not desirable / possible
228 2014-03-26 01:03:47 <phantomcircuit> i've heard at least one person say think about aircraft software engineering
229 2014-03-26 01:03:51 <phantomcircuit> except much much harder
230 2014-03-26 01:04:03 <davout> phantomcircuit: please read what i say, you're misrepresenting my words : "i don't use bitcoind on my servers for any other purpose than hearing about txes, through a bitcoin-ruby proxy"
231 2014-03-26 01:04:10 <phantomcircuit> olalonde, not at all, what im saying is that nobody is even close to something that is safe
232 2014-03-26 01:04:46 <phantomcircuit> davout, so you're still trusting bitcoin-ruby to not interpret something incorrectly
233 2014-03-26 01:05:55 <davout> phantomcircuit: bitcoin-ruby only get what my bitcoind sends it, bitcoind is here to act as filter
234 2014-03-26 01:06:19 <phantomcircuit> davout, yes you have exactly the same setup as coinbase
235 2014-03-26 01:06:33 <davout> phantomcircuit: so go ahead, explain how that's bad
236 2014-03-26 01:06:38 <phantomcircuit> i believe this setup to be dangerous to a degree that nobody has yet accepted
237 2014-03-26 01:07:07 <phantomcircuit> for one you're obviously having trouble replicating the reorganization logic
238 2014-03-26 01:07:26 <davout> phantomcircuit: i'm not, i asked a question, which was answered
239 2014-03-26 01:08:01 <phantomcircuit> im sure there is some bizarre edge case in the reference client which is very subtle and likely nobody will realize until something bad happens
240 2014-03-26 01:09:06 <davout> phantomcircuit: is that your point?
241 2014-03-26 01:10:30 <phantomcircuit> shrug
242 2014-03-26 01:10:33 <phantomcircuit> you do you
243 2014-03-26 01:10:40 <phantomcircuit> good luck with that
244 2014-03-26 01:10:58 <davout> so, that was your point i guess...
245 2014-03-26 01:12:44 <davout> phantomcircuit: so basically your argument so far boils down to "you asked a question, therefore you have no idea of what you're doing", and "something bad we know nothing about yet might happen, or might not, which may or may not have terrible consequences"
246 2014-03-26 01:13:16 <olalonde> davout: welcome to #bitcoin-dev :)
247 2014-03-26 01:14:50 <davout> olalonde: i have lots of respect for bitcoin-dev, but somehow i'm kind of disappointed that phantomcircuit implied there was something bad about the setup without being able to put a consistent argument backing it, i expected something juicier tbh :D
248 2014-03-26 01:15:27 <phantomcircuit> davout, no my point is simply that you are doing something which is risky in a way that is difficult to measure which has no significant benefit
249 2014-03-26 01:15:33 <phantomcircuit> that makes no sense
250 2014-03-26 01:16:11 <davout> phantomcircuit: well, i expected something precise
251 2014-03-26 01:16:42 <davout> not some line of reaasoning that could be extended to using bitcoin itself, it's not even 1.0 yet, might be risky to use it you know
252 2014-03-26 01:16:46 <phantomcircuit> davout, the entire point is that you cannot precisely identify the risk
253 2014-03-26 01:17:02 <davout> phantomcircuit: which is true for bitcoind as well
254 2014-03-26 01:18:16 <davout> seriously, how could bitcoin-ruby hear about bogus data if it comfortably sits behind the holy bitcoind?
255 2014-03-26 01:19:31 <phantomcircuit> 2014-03-26 01:18:29 Keys: 0 plaintext, 1000102 encrypted, 1000102 w/ metadata, 1000102 total
256 2014-03-26 01:19:31 <phantomcircuit> 2014-03-26 01:18:29  wallet               108649ms
257 2014-03-26 01:19:48 <phantomcircuit> neat
258 2014-03-26 01:21:24 <davout> Apocalyptic: i hope this discussion at least reassured you a bit with regards to BCs setup :D
259 2014-03-26 01:22:01 <Apocalyptic> Apocalyptic, kinda :)
260 2014-03-26 01:22:51 <olalonde> on that topic , any plans to implement "proof of liabilities" davout?
261 2014-03-26 01:23:30 <davout> olalonde: this is a proof of liability -> http://www.mtgoxprotest.com/wp-content/uploads/2014/02/mtgox-protest.jpg
262 2014-03-26 01:23:45 <davout> but there are plans to implement proof of solvency, yes :D
263 2014-03-26 01:23:57 <olalonde> cool
264 2014-03-26 01:24:21 <davout> but properly, not some audit where some guy says some other dudes have some money
265 2014-03-26 01:24:38 <olalonde> (was referring to https://github.com/olalonde/proof-of-liabilities#specification) the merkle tree stuff
266 2014-03-26 01:24:50 <olalonde> davout: great
267 2014-03-26 01:25:35 <Belxjander> in Weaknesses for DoS rule #12, is it possible to evict a random number of entries? allowing for an "all bits set" cache clearance" ?
268 2014-03-26 01:25:38 <olalonde> there's a ruby implementation btw https://github.com/peatio/liability-proof
269 2014-03-26 01:26:46 <davout> olalonde: nice, i'll have a look
270 2014-03-26 01:27:00 <davout> i'm off, this is getting OT for -dev :D
271 2014-03-26 01:28:01 <olalonde> same same
272 2014-03-26 03:30:33 <olalonde> any reason why bitcoind with testnet=3 is not downloading any block?
273 2014-03-26 03:35:56 <olalonde> and 0 connections
274 2014-03-26 03:36:22 <olalonde> I'm using rpcport=18332 and testnet=3
275 2014-03-26 03:39:02 <olalonde> I'm also running a livenet bitcoind , could that be the issue?
276 2014-03-26 03:41:24 <pigeons> i thought testnet=1 will give you testnet3
277 2014-03-26 03:43:47 <olalonde> getting a bunch of connection timeout in my debug.log
278 2014-03-26 03:46:33 <olalonde> it connects to the IRC chatroom but after that im getting a bunch of connection timeout :(
279 2014-03-26 03:46:46 <olalonde> maybe it's an issue with my ISP
280 2014-03-26 03:50:20 <olalonde> oh, seems I can configure the timeout, lets try that
281 2014-03-26 03:52:11 <venzen> olalonde: i think the value you pass to -testnet is a boolean, so testnet=1 enables testnet3 as pigeons says
282 2014-03-26 03:52:55 <olalonde> ok but it is enabling testnet, that's not the issue :(
283 2014-03-26 03:57:53 <olalonde> I'm getting a bunch of connection timeout and some onnection refused
284 2014-03-26 05:37:35 <venzen> that's normal since bitcoind is trying addresses from peers.dat - some are online, some are not
285 2014-03-26 06:19:48 <aegis> Hi
286 2014-03-26 06:20:08 <aegis> So this transaction was sent on 17 March: https://blockchain.info/tx/126dfd5d30698512b6903bb2cc6e931b923874e01288fe866cee30a744b6b478
287 2014-03-26 06:20:35 <aegis> Does anyone have any idea if/when it will confirm?  And if it doesn't, is there a time it will cancel or return?
288 2014-03-26 06:31:16 <dcousens> what is the purpose of OP_CODESEPARATOR?
289 2014-03-26 06:33:12 <Luke-Jr> dcousens: no purpose anymore
290 2014-03-26 06:33:32 <Luke-Jr> dcousens: once upon a time, scriptSig and scriptPubKey were simply concatenated with OP_CODESEPARATOR in between
291 2014-03-26 06:36:52 <dcousens> Luke-Jr: so why not remove it?
292 2014-03-26 06:36:59 <Luke-Jr> dcousens: that would be a hardfork.
293 2014-03-26 06:37:04 <dcousens> ah.
294 2014-03-26 06:37:47 <dcousens> is that simply because of the history re-write? or because new transactions might be invalid?
295 2014-03-26 06:38:33 <Luke-Jr> dcousens: a hardfork is when formerly invalid blocks/transactions are now valid
296 2014-03-26 06:39:03 <dcousens> right, but how would removing an opcode make previously invalid blocks valid?
297 2014-03-26 06:39:29 <Luke-Jr> …
298 2014-03-26 06:40:12 <Luke-Jr> take for example, the scriptPubKey: OP_0 OP_CODESEPARATOR OP_CHECKSIG
299 2014-03-26 06:40:39 <Luke-Jr> with the current rules, that excludes OP_0 from the ECDSA signed data (IIRC, don't quote me on the specifics)
300 2014-03-26 06:40:45 <Luke-Jr> with the new rules, it would include OP_0
301 2014-03-26 06:41:06 <Luke-Jr> so, if the signature was on the transaction including OP_0, it would have been invalid now, but valid by the new rule
302 2014-03-26 06:41:29 <dcousens> Right, so it would be because of the history rewrite
303 2014-03-26 06:41:30 <Luke-Jr> … assuming OP_CODESEPARATOR was a no-op. if it's now "always invalid", I guess it'd be a softfork. maybe.
304 2014-03-26 06:41:39 <Luke-Jr> it has nothing to do with history.
305 2014-03-26 06:45:22 <Luke-Jr> dcousens: it has to do with people running old versions *in the present*
306 2014-03-26 06:45:27 <dcousens> yeah
307 2014-03-26 06:45:38 <Luke-Jr> if you make that rule change, those people will *presently* reject the new block
308 2014-03-26 06:48:05 <dcousens> Luke-Jr: right, cheers
309 2014-03-26 06:50:46 <dcousens> Luke-Jr: I was completely ignoring old clients, hence why I missed the implications of previously invalid transactions becoming valid,  my mistake :)
310 2014-03-26 06:53:58 <Luke-Jr> dcousens: you know.. I wonder if that might be actually not be so bad an idea..
311 2014-03-26 06:55:58 <dcousens> Luke-Jr: actually, if you just removed the opcode, surely invalid transactions would remain invalid? Since the opcode would be invalid?
312 2014-03-26 06:56:13 <Luke-Jr> [06:41:29] <Luke-Jr> … assuming OP_CODESEPARATOR was a no-op. if it's now "always invalid", I guess it'd be a softfork. maybe. <-- :p
313 2014-03-26 06:56:33 <dcousens> Right, just confirming the same line of thought
314 2014-03-26 07:25:28 <looking_to_learn> Learning C++, currently looking for small ways to contribute to the project, any suggestions? Small ways of getting involved?
315 2014-03-26 07:25:56 <Luke-Jr> unit tests
316 2014-03-26 07:26:07 <Luke-Jr> and/or review of pending merge requests
317 2014-03-26 07:29:01 <wumpus> +1 what Luke-Jr says
318 2014-03-26 07:30:28 <looking_to_learn> Thanks Luke-jr, I will have to do more research, but I will be back with more educated questions. Thanks for your input.
319 2014-03-26 07:30:41 <Luke-Jr> np
320 2014-03-26 07:31:53 <warren> wumpus: before 0.9 a few people were talking about excluding macports and using homebrew for mac builds, did it happen?
321 2014-03-26 07:32:18 <wumpus> warren: I don't know anything about mac
322 2014-03-26 07:32:40 <warren> wumpus: saw my earlier message?  cfields agreed to do our gitian symbol filtering
323 2014-03-26 07:33:00 <SomeoneWeird> ➜  ~  brew cask search bitcoin
324 2014-03-26 07:33:01 <SomeoneWeird> bitcoin
325 2014-03-26 07:33:01 <SomeoneWeird> ==> Exact match
326 2014-03-26 07:33:14 <SomeoneWeird> no source only install, but you can install the bins
327 2014-03-26 07:33:34 <fanquake> heh that's to install the .app on osx
328 2014-03-26 07:33:47 <warren> SomeoneWeird: there was talk of having ./configure explicitly skip macports
329 2014-03-26 07:34:01 <fanquake> now sure if there's a bitcoin formula in the homebrew repo.
330 2014-03-26 07:34:04 <fanquake> *not
331 2014-03-26 07:34:22 <SomeoneWeird> fanquake, I know, there isn't
332 2014-03-26 07:34:39 <fanquake> There are plenty of taps with one in though.
333 2014-03-26 07:34:51 <SomeoneWeird> yeah
334 2014-03-26 07:34:51 <wumpus> warren: well, from what he posted on github yesterday he doesn't have anything more appealing and recommends going on with the static builds https://github.com/bitcoin/bitcoin/pull/3914
335 2014-03-26 07:35:32 <warren> wumpus: he agreed today to do it for dynamic linked builds
336 2014-03-26 07:35:48 <wumpus> ...
337 2014-03-26 07:35:52 <wumpus> so what is it, then?
338 2014-03-26 07:36:04 <warren> wumpus: symbol filtering with shim libraries
339 2014-03-26 07:36:24 <wumpus> okay never mind, I'll just stay out of it
340 2014-03-26 07:37:36 <Luke-Jr> warren: is it sufficient for me to write a Script debugger around? :P
341 2014-03-26 07:37:51 <warren> Luke-Jr: huh?
342 2014-03-26 07:38:14 <wumpus> this is about https://github.com/bitcoin/bitcoin/pull/3914, not my foiled attempt at shared-libing bitcoin
343 2014-03-26 07:38:18 <Luke-Jr> warren: I want to write a GUI that allows single-stepping through and interactively editing Script
344 2014-03-26 07:38:37 <warren> Luke-Jr: what's stopping you?
345 2014-03-26 07:38:37 <wumpus> Luke-Jr: maybe we should do a private libbitcoincore fork
346 2014-03-26 07:38:51 <Luke-Jr> warren: no C++ Script engine I can link to
347 2014-03-26 07:39:08 <wumpus> Luke-Jr: at least until someone defines an application interface for the kiddos :)
348 2014-03-26 07:39:40 <Luke-Jr> wumpus: I guess it'd let us cut the testing out of other changes needed too
349 2014-03-26 07:39:46 <Luke-Jr> (like https://github.com/bitcoin/bitcoin/pull/3901 )
350 2014-03-26 07:40:05 <wumpus> on the other hand, it means keeping a patch set up to date every time with master
351 2014-03-26 07:40:30 <Luke-Jr> if it's minimal, we can just merge master into it
352 2014-03-26 07:41:05 <wumpus> true
353 2014-03-26 07:42:56 <Luke-Jr> libunstablebitcoincore_*? :P
354 2014-03-26 07:43:45 <wumpus> yes may as well put the instability warning into the library name
355 2014-03-26 07:46:14 <Luke-Jr> anyhow, we're all busy, so maybe best to wait and see what cfields comes up with in the next few weeks
356 2014-03-26 07:46:42 <wumpus> yes, let's just get back to waiting :)
357 2014-03-26 07:47:55 <wumpus> the thing is that I don't just need the script interpreter but also the net and rpc stuff, to be able to create an external wallet project
358 2014-03-26 07:51:22 <Luke-Jr> wumpus: right, I don't think there's anything in the current codebase you *don't* need ☺
359 2014-03-26 07:51:57 <wumpus> Luke-Jr: exactly...
360 2014-03-26 07:52:48 <wumpus> though thinking about it, this doesn't need to be based on the satoshi client at all
361 2014-03-26 07:53:35 <Luke-Jr> … unless you want to make the debug window a real RPC client, then you could cut out bitcoind code
362 2014-03-26 07:53:39 <Luke-Jr> true
363 2014-03-26 07:53:42 <wumpus> I can just copy over the src/qt stuff and try to fit it to another interface, maybe I should take a look at Amir Taaki's lib :')
364 2014-03-26 07:54:22 <Luke-Jr> I bet that would be interesting to do even if you didn't end up releasing it
365 2014-03-26 07:54:39 <wumpus> or, there was some other C-based SPV wallet around, with a ncurses interface
366 2014-03-26 07:55:53 <Luke-Jr> I think that was based on Amir's lib?
367 2014-03-26 07:55:58 <Luke-Jr> unless it's jgarzik's picocoin
368 2014-03-26 07:56:04 <wumpus> then again, I'm somewhat more comfortable with the bitcoin core wallet, it's never failed me
369 2014-03-26 07:56:06 <Luke-Jr> but I think picocoin is a full node
370 2014-03-26 07:56:31 <Luke-Jr> wumpus: well, with the proper abstraction, perhaps it could be pluggable ;)
371 2014-03-26 07:56:34 <wumpus> ...but changing it to SPV is some work too
372 2014-03-26 07:57:06 <Luke-Jr> too bad linkers need special hoops to dynamically dynamic link :/
373 2014-03-26 08:00:22 <wumpus> "For now, we assume that the address onto which we want to transfer change is the wallet's main/first key. In the future this will likely change, but for now we'll keep this simple."... ehh huh?
374 2014-03-26 08:00:58 <Luke-Jr> wumpus: O.o
375 2014-03-26 08:01:02 <wumpus> (that's from bitc)
376 2014-03-26 08:01:13 <Luke-Jr> sigh
377 2014-03-26 08:01:32 <Luke-Jr> for a second I was afraid Satoshi wrote that in some old version XD
378 2014-03-26 08:05:51 <wumpus> ideally I'd use Qt for networking, but then I'll have to implement all the P2P stuff myself, and also RPC as I'd like to provide a satoshi-ish interface ... better to borrow as much as possible from bitcoin core
379 2014-03-26 08:06:14 <Luke-Jr> you might want to do that (P2P) anyway. the current code sucks.
380 2014-03-26 08:06:56 <wumpus> nah, a SPV client doesn't need to maintain many connections so it's good enough
381 2014-03-26 08:07:08 <Luke-Jr> doesn't need to, but it could
382 2014-03-26 08:08:58 <wumpus> it's an idea for the future (could also use the Qt5 JSON stuff in my project instead of spirit json)
383 2014-03-26 08:10:05 <Luke-Jr> 
ACTION hopes Gentoo makes Qt5 available sometime..

384 2014-03-26 08:10:07 <wumpus> but my goal is not to reimplement bitcoin core but to have an useable bitcoin-qt based external wallet in the least span of time :p
385 2014-03-26 08:17:34 <qwebirc498195> hi, i write my diploma about bitcoin and i'd like to ask u about hashtypes of the signatures.
386 2014-03-26 08:18:20 <fanquake> qwebirc498195 Don't ask to ask. Just post your question.
387 2014-03-26 08:19:02 <qwebirc498195> hashtype is not a part of signature, it is only appended to signature, right?
388 2014-03-26 08:22:20 <qwebirc388908> sorry, uncontrolled reboot. again, hashtype is not a part of signature, it isonly appended to one, right?
389 2014-03-26 08:24:29 <wumpus> yes, it's a byte appended at the end
390 2014-03-26 08:25:56 <qwebirc388908> who set the hashtype value spender or provider of bitcoins?
391 2014-03-26 08:26:42 <qwebirc388908> spender, right?
392 2014-03-26 08:34:53 <wumpus> yes, the spender provides the signatures
393 2014-03-26 08:38:05 <wumpus> see https://en.bitcoin.it/wiki/OP_CHECKSIG
394 2014-03-26 08:38:31 <qwebirc388908> i have alredy seen it but i was a little confused
395 2014-03-26 08:38:58 <qwebirc388908> just wanted to be sure
396 2014-03-26 08:39:04 <qwebirc388908> thx man
397 2014-03-26 08:47:20 <ribasushi> is it intentional that bitcoind does *not* provide a way to get a pubkey?
398 2014-03-26 08:47:43 <ribasushi> makes generating multisig scripts a massive PITA, since bitcoind itself wants the WIF-style pubkeys
399 2014-03-26 08:49:39 <wumpus> ribasushi: try validateaddress <address> to get the pubkey
400 2014-03-26 08:49:47 <ribasushi> sorry, not wif style, hexencoded
401 2014-03-26 08:49:55 <ribasushi> >.<
402 2014-03-26 08:50:00 <ribasushi> I would have *never* guessed to try that
403 2014-03-26 08:50:17 <wumpus> always the adventure, using the RPC api
404 2014-03-26 08:50:45 <wumpus> when the wallet is enabled, validateaddress sneakily changes into a 'get information about key' method
405 2014-03-26 08:51:06 <ribasushi> do we blame satoshi or someone elses brilliant idea? :)
406 2014-03-26 08:51:47 <dcousens> wumpus: haha, have we not all been there with the RPC api...
407 2014-03-26 08:52:23 <wumpus> dunno, I'm not a fan of the blame game, but it probably seemed like a good idea at the time, "this way we don't have to add another RPC call"
408 2014-03-26 08:53:05 <ribasushi> wumpus: fair enough, thanks for the help!
409 2014-03-26 08:53:36 <wumpus> it has to be overhauled at some point, with specific RPCs for the wallet, blockchain, p2p. and 'general utility' RPCs
410 2014-03-26 08:53:57 <wumpus> wallet.getkeyinfo .. etc
411 2014-03-26 08:53:59 <dcousens> wumpus: we can only hope
412 2014-03-26 08:54:13 <wumpus> no no no don't hope, build stuff! :)
413 2014-03-26 09:05:19 <AmThatsMe> Hi everyone ! i made 3 pull requests regarding RPC testing (some new, some few weeks old). It will be great to get your opinion (ACK/ NACK) so i know I'm on the right track
414 2014-03-26 09:05:25 <AmThatsMe> https://github.com/bitcoin/bitcoin/pull/3837
415 2014-03-26 09:05:29 <AmThatsMe> https://github.com/bitcoin/bitcoin/pull/3956
416 2014-03-26 09:05:33 <AmThatsMe> https://github.com/bitcoin/bitcoin/pull/3837
417 2014-03-26 09:11:09 <wumpus> I've commented
418 2014-03-26 09:55:48 <shaileshg> Hi, its given that
419 2014-03-26 09:55:49 <shaileshg> -walletnotify=<cmd>    Execute command when a wallet transaction changes
420 2014-03-26 09:56:04 <shaileshg> so, i want to ask: when does wallet transaction changes?
421 2014-03-26 09:56:44 <sturles> E.g. when you send or receive coins and, when a transaction involving you is confirmed.
422 2014-03-26 09:56:57 <sturles> Involving an address in your wallet.
423 2014-03-26 09:58:09 <shaileshg> sturles: is there any minimum level of confirmations ?
424 2014-03-26 09:58:39 <shaileshg> and if i want to enable notification to me when i receive bitcoins to any of my addresses, how can i do that..
425 2014-03-26 09:58:41 <shaileshg> any sample?
426 2014-03-26 09:58:48 <epscy> sturles: is it confirmed or just sent?
427 2014-03-26 09:58:55 <epscy> (or received)
428 2014-03-26 09:59:42 <sturles> The walletnotify script is run at 0 and 1 confirmations.  To check for more you may use blocknotify.
429 2014-03-26 10:00:02 <sturles> Or may be more confirmations in case of a reorg.
430 2014-03-26 10:00:19 <sturles> If the tx wansn't confirmed in the first version, but was in the second.
431 2014-03-26 10:01:09 <shaileshg> sturles: hmm. and cmd is path to executable program
432 2014-03-26 10:01:20 <shaileshg> what do you mean by reorg?
433 2014-03-26 10:01:40 <sturles> It is really simple.  Just make a script which notifies you in whatever way you like.  The first argument will be the txid, which you can pull from bitcoind if you want any details about it.
434 2014-03-26 10:02:01 <sturles> A blockchain reorg happens when a chain is overtaken by a longer chain.
435 2014-03-26 10:02:15 <sturles> What you see as orphan blocks on blockchain.info.
436 2014-03-26 10:02:27 <shaileshg> sturles: hmm
437 2014-03-26 10:02:52 <sturles> If you had the orphan, it will be exchanged with the new version in a reorg when the block after the orphan is found.
438 2014-03-26 10:03:29 <sturles> In the other chain, of course.
439 2014-03-26 11:12:32 <shadders> I'm just trying to get my head around my old merkle tree implementation.  It can recalculate the tree is left or right nodes are changed but the comments in my code indicate that modifying a center node means the whole tree needs to be recalculated.  But I don't think that's really the case is it?  You just need to recalculate that nodes branch?
440 2014-03-26 11:15:21 <sipa> yes
441 2014-03-26 11:16:28 <shadders> thanks sipa
442 2014-03-26 11:53:10 <hearn> huh, bitstamp do withdrawals using giant sendmany transactions
443 2014-03-26 11:53:43 <hearn> ouch. $1.46 miner fee on that tx :(
444 2014-03-26 11:55:39 <sipa> assuming a constant fee/byte, it's cheaper than doing it in separate ones :)
445 2014-03-26 11:56:15 <paveljanik> hearn: do you have a txid please?
446 2014-03-26 11:56:34 <hearn> paveljanik: why?
447 2014-03-26 11:57:46 <skinnkavaj> https://bitcointalk.org/index.php?topic=507656.0
448 2014-03-26 11:59:26 <paveljanik> so I can look at it.
449 2014-03-26 12:00:30 <hearn> paveljanik: yes, obviously. i mean why do you want to look at it? it’s nothing special.
450 2014-03-26 12:00:52 <paveljanik> ah, how large it is, how often do they etc.
451 2014-03-26 12:01:06 <paveljanik> how long is it in the mempool etc.
452 2014-03-26 12:03:15 <hearn> it’s 24kb and didn’t confirm yet
453 2014-03-26 12:05:15 <paveljanik> a few days ago, we tracked a Czech user's txid 7be8a9d8f857c1eaa04baacb6df27a6e64569494b3576f503fa16b67377c303f.
454 2014-03-26 12:05:24 <paveljanik> he updated to 0.9 and used the default fee.
455 2014-03-26 12:05:30 <paveljanik> it is still in my mempool
456 2014-03-26 12:05:41 <paveljanik> right now, at 1158 position.
457 2014-03-26 12:05:59 <paveljanik> it is almost a week ago when it was submitted.
458 2014-03-26 12:07:49 <paveljanik> so I wanted to check the large transaction because it is another use-case for strange priority counting.
459 2014-03-26 12:09:56 <hearn> that is weird
460 2014-03-26 12:10:14 <paveljanik> pavel@opencl:~/bitcoin/src> ./bitcoin-cli getrawmempool true | sed -n '/currentprio/ s#.*: ##p' | sort -rn | grep -n `./bitcoin-cli getrawmempool true | grep -A 8 7be8a9d8f857c1eaa04baacb6df27a6e64569494b3576f503fa16b67377c303f | grep current | sed 's#.*: ##'`
461 2014-03-26 12:10:15 <paveljanik> 1146:18962763.30601677,
462 2014-03-26 12:10:41 <hearn> when you say “default fee” it looks like he may have used the new min relay fee
463 2014-03-26 12:10:41 <paveljanik> rough, stupid way to print it, but it is in my history...
464 2014-03-26 12:10:52 <paveljanik> yup.
465 2014-03-26 12:11:02 <paveljanik> yes, sorry. min. fee
466 2014-03-26 12:11:17 <hearn> well, that’s no surprise then
467 2014-03-26 12:11:24 <hearn> probably not many miners upgraded to 0.9 yet
468 2014-03-26 12:11:32 <hearn> 0.9 still generates transactions with the old fee for a reason ..
469 2014-03-26 12:11:40 <paveljanik> yes, this was the reason I told him.
470 2014-03-26 12:12:05 <paveljanik> it is dust for many nodes.
471 2014-03-26 12:13:42 <paveljanik> and now, I'd like to see how long this large tx will be in my mempool with so small fee.
472 2014-03-26 12:14:13 <sipa> if it enters the mempool, it never leaves
473 2014-03-26 12:14:21 <sipa> until mined or a conflict is mined
474 2014-03-26 12:14:50 <michagogo> cloud|Or a restart
475 2014-03-26 12:14:59 <paveljanik> yes, this is clear (res... yes)
476 2014-03-26 12:20:19 <paveljanik> sipa: but right now, I do not know, when it entered my mempool ;-)
477 2014-03-26 12:20:31 <jouke> aschildbach: does bitcoin wallet have a feature to connect to a regtest node?
478 2014-03-26 12:21:03 <aschildbach> jouke: You cannot switch networks at runtime.
479 2014-03-26 12:23:17 <jouke> aschildbach: I am not sure what you are saying. It is possible, but it is not easy to do?
480 2014-03-26 12:24:00 <aschildbach> jouke: The app is open source. You can probably configure it for regtest and compile it yourself. I never tried though.
481 2014-03-26 12:24:23 <aschildbach> I publish binaries for mainnet and testnet only.
482 2014-03-26 12:24:31 <jouke> I wouldn't even know how to begin :P
483 2014-03-26 12:25:02 <jouke> I am not even sure about the specifics of a regtest "blockchain".
484 2014-03-26 12:25:21 <aschildbach> Look at the sections about building the app: https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README
485 2014-03-26 12:26:04 <hearn> i did a regtest version a while back
486 2014-03-26 12:26:06 <hearn> it wasn’t very hard
487 2014-03-26 12:26:24 <aschildbach> Constants.java contains a NETWORK_PARAMETERS constant that needs to be switched
488 2014-03-26 12:26:27 <hearn> jouke: it’s just different NetworkParameters, and then you have to disable checkpointing, and make it connect to your local bitcoind
489 2014-03-26 12:27:46 <jouke> Ok, I'll give it a try. Nice and clear instructions btw aschildbach, thanks :)
490 2014-03-26 12:32:48 <hearn> aschildbach: http://www.reddit.com/r/Bitcoin/comments/21ds80/payment_protocol_android_wallet_super_smooth/
491 2014-03-26 12:34:02 <melvster> im testing bfgminer with gbt ... I send in a coinbase size 0x50 and it finds me a block with a coinbase size 0x54 ... there's a mysterious 02000000 inserted at the end of the coinbase but before the sequence ... any ideas what this is?
492 2014-03-26 12:34:46 <aschildbach> hearn: nice
493 2014-03-26 12:35:43 <melvster> 02000000 looks like a version number ... but do we put the version at the end of the coinbase these days?
494 2014-03-26 12:36:09 <aschildbach> hearn: somehow we need to convince bitpay to optimize their memo. The "Payment request for" seems redundant to me.
495 2014-03-26 12:37:48 <hearn> aschildbach: yes. but you can optimise the gui too :) Stephen agreed that the memo should be changed, i guess they just didn’t get to it yet
496 2014-03-26 12:39:52 <jouke> aschildbach: we also use your app as an example: https://bitonic.nl/news/28/payment-protocol . At the moment we received around 40 paid requests, so it is still marginally compared to our total payments.
497 2014-03-26 12:40:06 <jouke> Have to look at the logs what apps are used to fetch the requests.
498 2014-03-26 12:42:34 <jouke> Mostly bitcoinj/bitcoin wallet
499 2014-03-26 12:43:09 <hearn> this would not surprise me
500 2014-03-26 12:43:18 <hearn> but multibit (hd) and hive are all planning to add support too
501 2014-03-26 12:43:24 <hearn> so hopefully the volume will go up in the coming months
502 2014-03-26 12:43:43 <aschildbach> jouke: Cool! Do you have an english version of the page? (or german)
503 2014-03-26 12:44:28 <jouke> Actually. Only one Satoshi-client fetched a requests, the rest is all BitCoinJ/Bitocoin wallet.
504 2014-03-26 12:44:49 <jouke> aschildbach: no, sorry.
505 2014-03-26 12:45:59 <hearn> aschildbach: google translate my friend :)
506 2014-03-26 12:46:06 <hearn> jouke: does Trezor actually have full support?
507 2014-03-26 12:46:13 <hearn> i thought it was planned for a post-v1 release
508 2014-03-26 12:46:46 <jouke> Oh, might be. Haven't received mine yet
509 2014-03-26 12:48:22 <hearn> yeah, afaik they didn’t ship any yet
510 2014-03-26 13:20:48 <runeks> Say I run bitcoind on a server in my home network. I also have a PC that runs bitcoind, and I'd like it to connect to the always-running bitcoind instance on my server. Problem is that I've set maxconnections to 20 on the server, and when I want to connect to it from my PC, it refuses connection because its 20 connection slots are all used. Is there any clever way around this?
511 2014-03-26 13:55:58 <sipa> etotheipi_: but ehm... no warranty
512 2014-03-26 13:55:58 <sipa> etotheipi_: github.com/bitcoin/secp256k1
513 2014-03-26 13:55:58 <sipa> needs a big fat disclaimer