1 2014-06-19 00:05:19 <andytoshi> xabbix: i ./configure with « CRYPTO_CFLAGS=-I/usr/local/ssl/include CRYPTO_LIBS="-L/usr/local/ssl/lib -ldl -lcrypto" SSL_CFLAGS=-I/usr/local/ssl/include SSL_LIBS="-L/usr/local/ssl/lib -lssl" ./configure »
  2 2014-06-19 00:27:34 <xabbix> andytoshi, thanks, trying that now
  3 2014-06-19 00:37:41 <xabbix> Still getting this message "OpenSSL appears to lack support for elliptic curve cryptography", I've compiled openssl with "./config shared --openssldir=/usr/local/ssl"
  4 2014-06-19 00:43:34 <xabbix> any ideas? andytoshi, kazcw, gmaxwell?
  5 2014-06-19 00:46:52 <andytoshi> xabbix: can you confirm that the .so's are in /usr/local/ssl/lib and that the wrong .so is referenced when you do « ldd ./src/bitcoind » ?
  6 2014-06-19 00:47:36 <andytoshi> also you might try doing a « make clean all » on bitcoind after having compiled openssl if you did those things in the wrong order
  7 2014-06-19 00:49:20 <xabbix> andytoshi, cool didn't know about the ldd command. yes I can see that ldd bitcoind shows the wrong libssl: libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f3401129000)
  8 2014-06-19 00:49:33 <xabbix> and /usr/local/ssl/lib has the correct ones.
  9 2014-06-19 00:49:55 <xabbix> How can I fix this?
 10 2014-06-19 00:52:20 <andytoshi> hmm, now that i look i'm using the system ssl libs on my laptop, so i guess i replaced them at some point
 11 2014-06-19 00:52:25 <andytoshi> (and my ./configure line was a placebo)
 12 2014-06-19 00:52:36 <andytoshi> i'll look into it
 13 2014-06-19 00:53:50 <xabbix> thanks
 14 2014-06-19 01:01:21 <xabbix> andytoshi, is there any 'hack' i can apply for now just to make it compile a working version? i.e. copying the files from /usr/local/ssl/lib over to /usr/lib64 maybe?
 15 2014-06-19 01:03:14 <andytoshi> xabbix: yeah, that'll definitely work and i did that actually on my server because of heartbleed
 16 2014-06-19 01:03:47 <andytoshi> and it's probably what i did on my laptop that the ./configure is working..it's nbd if i break my laptop so i'd have done the first hack that occured to me ;)
 17 2014-06-19 01:04:00 <xabbix> andytoshi, cool i'll give it a try now
 18 2014-06-19 01:04:31 <crunk-juice> anyone here use a multi-tier cold storage solution?
 19 2014-06-19 01:05:55 <andytoshi> lol xabbix my build is completely broken and apparently has not worked in a long time
 20 2014-06-19 01:06:14 <andytoshi> that's what i get for doing all my dev on the remote server..
 21 2014-06-19 01:06:24 <andytoshi> what is CAutoBN_CTX and where should it be defined?
 22 2014-06-19 01:06:51 <xabbix> lol
 23 2014-06-19 01:06:53 <xabbix> ;)
 24 2014-06-19 01:08:26 <xabbix> It's 4am here, I've recompiled the Bitcoin source about 15 times now :-\
 25 2014-06-19 01:09:51 <andytoshi> xabbix: if it's any consolation, i remember doing that and it's long in the past now..
 26 2014-06-19 01:09:56 <andytoshi> once you get it setup it works forever
 27 2014-06-19 01:10:20 <andytoshi> (except apparently on my laptop today)
 28 2014-06-19 01:10:23 <xabbix> That's what I keep telling myself - just get the bin working and you can keep it forever :)
 29 2014-06-19 01:11:41 <andytoshi> oh, i found the bug, it's in a commit i made "to make switching from base58 to base64" earlier which obviously rebased badly on some recent commits. i backed out my local stuff and it works now
 30 2014-06-19 01:11:50 <andytoshi> make switching easier*
 31 2014-06-19 01:17:38 <xabbix> andytoshi, looks like it's working now, got some warnings ./bitcoind: /usr/lib64/libssl.so.10: no version information available (required by ./bitcoind)
 32 2014-06-19 01:17:41 <xabbix> but it's running
 33 2014-06-19 01:17:58 <andytoshi> xabbix: awesome, i get those too, it's nbd
 34 2014-06-19 01:18:08 <xabbix> great, thanks for the help! :)
 35 2014-06-19 03:38:03 <venzen> Core 0.9.2 release notes at https://bitcoin.org/en/release/v0.9.2 says this release has updated OpenSSL to deal with the Heartbleed bug. Is there a difference in OpenSSL lib between 0.9.1 and 0.9.2 ?
 36 2014-06-19 03:40:57 <venzen> reading further into the release notes it seems the upgrade (to 1.0.1h) being referred to is for gitian builds only... can someone please confirm
 37 2014-06-19 03:59:41 <CodeShark> what's with this crap? http://pastebin.com/BEMJiJ7n
 38 2014-06-19 03:59:52 <CodeShark> shouldn't the client get blacklisted?
 39 2014-06-19 04:00:47 <CodeShark> or the peer, rather
 40 2014-06-19 05:35:41 <warren> Running into a strange issue with regtest.   Two nodes with an identical blockchain are stopped, restarted and connected only to each other.  One node creates a 0 conf transaction.  The other node doesn't see that transaction at all until it becomes confirmed.
 41 2014-06-19 05:37:43 <warren> Here's the precise sequence.  1) Four regtest nodes started fresh and connected to each other.  2) Node A generates 107 blocks.  Nodes B, C and D quickly see all those blocks.  3) Node C and D are stopped and restarted, then connected only to each other.  This leaves two partitions A-B and C-D.  4) Node B sends a transaction, Node A sees it immediately.  5) Node C sends a transaction.  Node D does not see it.
 42 2014-06-19 05:39:06 <warren> I'm not sure why there is a difference of transaction relay between the A-B and C-D partitions.
 43 2014-06-19 05:40:12 <gmaxwell> yea, in what way are they _at all_ distinguishable. Also, if A did all the mining how do C and D have coins to spend?
 44 2014-06-19 05:41:24 <warren> oh, forgot to mention I copied the wallet.dat from A to C.
 45 2014-06-19 05:42:01 <gmaxwell> and B too, I assume? does A still have it and D does not?
 46 2014-06-19 05:42:27 <warren> oops, node A sends the transaction
 47 2014-06-19 05:43:55 <gmaxwell> okay so the only obvivous difference here is that a,b have not been restarted?
 48 2014-06-19 05:44:00 <warren> yes
 49 2014-06-19 05:44:16 <warren> C,D are not supposed to behave differently, but they are .
 50 2014-06-19 05:44:22 <gmaxwell> can you try to reproduce but then restart A ... then try again and restart B?
 51 2014-06-19 05:44:31 <gmaxwell> e.g. to make sure the restart is the only real difference?
 52 2014-06-19 05:44:36 <warren> I'll have both sides of the partition restart
 53 2014-06-19 05:45:05 <warren> oh
 54 2014-06-19 05:45:09 <gmaxwell> the notion of trying one at a time there was basically to see if it was the sender or the reciever that mattered.
 55 2014-06-19 05:45:18 <gmaxwell> (but it may just be the link bouncing that matters)
 56 2014-06-19 05:58:59 <warren> Frustratingly, restarting A,B doesn't change its behavior.
 57 2014-06-19 06:00:22 <gmaxwell> is it possible that you send the transaction too fast after the restart such that the other node wasn't really up yet?
 58 2014-06-19 06:01:38 <warren> Adding a 5 second sleep between doesn't change it
 59 2014-06-19 06:10:20 <warren> gmaxwell: I'm an idiot.  I was testing for relay of the transaction with gettransaction.  without txindex=1
 60 2014-06-19 06:19:38 <warren> gmaxwell: while that was a problem, it actually isn't getting into the mempool of the C,D peer
 61 2014-06-19 06:19:45 <warren> if I don't restart C,D it works
 62 2014-06-19 06:19:51 <warren> ..
 63 2014-06-19 06:20:37 <gmaxwell> can you watch the log on the reciever when you send the txn?
 64 2014-06-19 06:21:21 <warren> yes, nothing
 65 2014-06-19 06:32:47 <warren> gmaxwell: well.... this makes no apparent sense.  txindex=1 didn't change the behavior of C,D.  What fixed it was copying the wallet of A,B into C,D
 66 2014-06-19 06:33:07 <warren> The peer otherwise didn't see it in the mempool at all.
 67 2014-06-19 06:33:25 <gmaxwell> how do you know it didn't see it in the mempool?
 68 2014-06-19 06:33:34 <warren> doesn't appear in the debug.log
 69 2014-06-19 06:34:01 <gmaxwell> well if you're spending an unconfirmed coin, for example, then you wouldn't know the inputs.. but if the unconfirmed coin is in your own wallet, you will.
 70 2014-06-19 06:34:17 <warren> they're confirmed
 71 2014-06-19 06:34:24 <gmaxwell> I suggest using the getrawmempool rpc.
 72 2014-06-19 06:34:32 <warren> ah
 73 2014-06-19 06:34:40 <gmaxwell> and see if you can spot differences in 'initial' state.
 74 2014-06-19 06:34:50 <warren> thanks
 75 2014-06-19 06:41:40 <warren> Confirmed, it isn't reaching the other mempool unless the wallets are identical, this makes no sense.  For now I'm "fixing" it this way, I'll look into wtf happened later.
 76 2014-06-19 06:42:16 <gmaxwell> is the initial mempool state (before the txn) different in the working/non-working cases?
 77 2014-06-19 06:42:36 <warren> oh, I didn't look at A,B
 78 2014-06-19 06:42:41 <warren> I'll look later.
 79 2014-06-19 07:40:58 <michagogo> 02:36:44 <gmaxwell> If there are no objections I'm going to set this channel to quiet anyone who is currently banned in #bitcoin or in #bitcoin-global-bans (a new freenode feature makes this possible). I intend to use global bans for crapflooding and such. <-- Does that work? I think someone was doign a bunch of testing in #freenode earlier and it seemed
 80 2014-06-19 07:40:58 <michagogo> that setting +q $j: didn't behave as expected
 81 2014-06-19 07:41:26 <michagogo> Quieting everyone, or noone, or something -- I don't remember the exact details
 82 2014-06-19 07:41:48 <gmaxwell> doesn't seem to have done anything bad.
 83 2014-06-19 07:42:22 <michagogo> Wait, did you set it?
 84 2014-06-19 07:42:29 <michagogo> I wonder why it's not in my backlog o_O
 85 2014-06-19 07:43:31 <michagogo> gmaxwell: actually, it's not showing in /mode #bitcoin-dev q either
 86 2014-06-19 07:44:30 <gmaxwell> michagogo: not yet in here, but I've done it in other channels. I was giving people a chance to protest the idea in here.
 87 2014-06-19 07:44:35 <michagogo> Ah, I see
 88 2014-06-19 07:44:42 <michagogo> And it worked as expected there?
 89 2014-06-19 07:44:56 <gmaxwell> It didn't quiet everyone! :)
 90 2014-06-19 07:44:57 <michagogo> Maybe they fixed the weirdness. *shrug*
 91 2014-06-19 07:45:13 <michagogo> gmaxwell: but did it quiet whoever it's supposed to?
 92 2014-06-19 07:45:31 <gmaxwell> didn't test.
 93 2014-06-19 07:45:42 <gmaxwell> easier to let the spammers test it.
 94 2014-06-19 07:52:24 <warren> hmm, debug.log no longer logs txid's entering the mempool if they are non-wallet?
 95 2014-06-19 07:53:07 <wumpus> could be that you need some debug flag
 96 2014-06-19 07:53:21 <warren> 0.8 didn't need it
 97 2014-06-19 07:53:37 <wumpus> logging was pretty much overhauled in 0.9
 98 2014-06-19 07:53:46 <wumpus> lots less spam by default
 99 2014-06-19 07:53:54 <warren> ahhh
100 2014-06-19 07:54:22 <wumpus> debug logging was divided into categories
101 2014-06-19 07:54:23 <wumpus> etc
102 2014-06-19 08:06:41 <ThomasV> hi, is there a proposal on a compact serialization format for partially signed transactions?
103 2014-06-19 08:07:00 <ThomasV> I mean, including bip32 xpub and derivation path
104 2014-06-19 08:07:35 <ThomasV> petertodd: I think you mentionned this in amsterdam ^
105 2014-06-19 08:12:30 <michagogo> wumpus: what's v0.9.2.1?
106 2014-06-19 08:13:17 <michagogo> ...and why does a git fetch not find it?
107 2014-06-19 08:15:34 <michagogo> Uh, wtf? Is github just being weird?
108 2014-06-19 08:16:33 <michagogo> Why is GH showing a v0.9.2.1 tag, while `git fetch upstream` doesn't show it? o_O
109 2014-06-19 08:21:02 <michagogo> Ah, there it is
110 2014-06-19 08:23:41 <wumpus> 0.9.2.1 is a re-release of 0.9.2 which fixes two issues, one macox-only UI with displaying addresses and another that an fixes exception at shutdown in some cases (on all platforms)
111 2014-06-19 08:24:00 <wumpus> if you have no problems with 0.9.2  there is no need to upgrade to it
112 2014-06-19 08:32:37 <michagogo> wumpus: Hm, how come I had to git fetch --tags to get it?
113 2014-06-19 08:32:50 <michagogo> A regular fetch/pull didn't get it like it usually does
114 2014-06-19 08:33:02 <wumpus> michagogo: I have no clue
115 2014-06-19 08:33:18 <wumpus> it worked fine for me (gitian gets the tag, for example)
116 2014-06-19 08:34:05 <michagogo> 
ACTION boots his VM

117 2014-06-19 09:14:52 <ThomasV> oh I see, bip10
118 2014-06-19 09:24:13 <SomeoneWeird> michagogo: heh weird, i had to do that too
119 2014-06-19 10:35:10 <xabbix> I'm running a bunch of full nodes and want to save the debug.logs in a way that will allow me to review them later on in some way. Any ideas? I can stream them all somehow to a central location, not sure how or with what tools.
120 2014-06-19 10:37:13 <SomeoneWeird> rsyslog can probably do it
121 2014-06-19 10:40:21 <upb> syslog-ng can too :p
122 2014-06-19 10:41:14 <Luke-Jr> metalog as well
123 2014-06-19 10:41:19 <Luke-Jr> … I think
124 2014-06-19 10:42:18 <SomeoneWeird> upb: same old, i'm not a sysadmin :P
125 2014-06-19 11:05:08 <bmcgee> hey guys, how many peers does bitcoind try to maintain? And does it try to do anything to increase the diversity of those peers to try and minimise the chance of getting a late notification of a better branch if you know what I mean?
126 2014-06-19 11:05:59 <michagogo> bmcgee: it makes 8 outgoing connections
127 2014-06-19 11:06:31 <michagogo> And IIRC it tries to make them in different IP address blocks
128 2014-06-19 11:06:43 <michagogo> Don't remember if it's /8, /16, or something else
129 2014-06-19 11:06:51 <bmcgee> michagogo: ah I suspected something of the sort
130 2014-06-19 11:07:26 <bmcgee> michagogo: the peers are discovered via IRC and DNS correct?
131 2014-06-19 11:07:31 <michagogo> no
132 2014-06-19 11:07:38 <gribble> https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery | Mar 13, 2014 ... The Satoshi client discovers the IP address and port of nodes in several ... Upon startup, if peer node discovery is needed, the client then issues ...
133 2014-06-19 11:07:38 <michagogo> ;;bc,wiki satoshi client peer discovery
134 2014-06-19 11:07:39 <michagogo> ^
135 2014-06-19 11:07:50 <bmcgee> michagogo: thx i’ll have a look
136 2014-06-19 11:08:13 <michagogo> Basically, it keeps a database on disk of nodes
137 2014-06-19 11:08:25 <michagogo> If needed, it uses dns seeds
138 2014-06-19 11:08:41 <michagogo> And then, if still needed, it falls back on a list of hard-coded peers
139 2014-06-19 11:09:40 <michagogo> But once a node has been on the network for a while, IIRC it doesn't need the DNS seeds, it just uses its list of nodes
140 2014-06-19 11:10:55 <michagogo> bmcgee: https://github.com/bitcoin/bitcoin/blob/v0.9.2.1/src/netbase.cpp#L806
141 2014-06-19 11:11:08 <petertodd> ThomasV: no that I know of
142 2014-06-19 11:11:13 <bmcgee> michagogo: thx for the overview
143 2014-06-19 11:13:47 <bmcgee> michagogo: what’s the term for when you receive a block that has a greater height but not the prevHash you were expecting indicating there is a longer alternative blockchain?
144 2014-06-19 11:14:12 <bmcgee> michagogo: i seem to remember there being one
145 2014-06-19 11:14:21 <michagogo> bmcgee: what do you mean "what's the term"?
146 2014-06-19 11:14:45 <bmcgee> michagogo: sounds stupid i know, i’ve just been calling it a split. But i have a vague memory of a better term being used
147 2014-06-19 11:15:26 <bmcgee> michagogo: don’t worry about it
148 2014-06-19 11:15:39 <wumpus> a chain reorganization?
149 2014-06-19 11:16:15 <wumpus> that's how it's usually called
150 2014-06-19 11:16:39 <michagogo> bmcgee: a reorg is when you switch from one chain to another, if that's what you mean
151 2014-06-19 11:16:52 <bmcgee> michagogo: that’s the one
152 2014-06-19 11:17:11 <michagogo> That happens once you know of a full better chain, though
153 2014-06-19 11:17:29 <bmcgee> typically how often does a reorg happen
154 2014-06-19 11:17:31 <michagogo> Not just "a block that has a greater height but not the prevHash you were expecting"
155 2014-06-19 11:18:08 <bmcgee> michagogo: yeah, i meant was if a node receives a block like that it triggers further processing to determine if a reorg is necessary
156 2014-06-19 11:18:25 <michagogo> bmcgee: well, 1-block reorgs tend to happen whenever two miners find a block on the same previous block
157 2014-06-19 11:18:34 <michagogo> But not for everyone
158 2014-06-19 11:18:52 <michagogo> If you have block A, and two blocks are mined, B1 and B@
159 2014-06-19 11:18:54 <michagogo> B2*
160 2014-06-19 11:19:12 <michagogo> If you first hear of B1, but then a C2 is found on top of B2, you have a small reorg
161 2014-06-19 11:19:30 <michagogo> But if you heard of B2 first, you don't reorg
162 2014-06-19 11:19:44 <bmcgee> I would assume it takes less than 10 mins for knowledge of a block to propogate through the network meaning by the time the next block is found all nodes have caught up if necessary
163 2014-06-19 11:19:52 <michagogo> bmcgee: well, no
164 2014-06-19 11:20:04 <michagogo> It's not a progress bar that takes 10 minutes to fill and then a block is generated
165 2014-06-19 11:20:21 <gribble> 65301873052200001536
166 2014-06-19 11:20:21 <michagogo> ;;calc [nethash] * 1000000000 * 600
167 2014-06-19 11:20:22 <bmcgee> michagogo: i didn’t mean that. I understand the difficulty adjusts to try and aim for 10 mins
168 2014-06-19 11:20:28 <michagogo> Yes
169 2014-06-19 11:20:48 <bmcgee> i just meant that on average, if the 10 min is maintained then most if not all nodes should be caught up before the next block
170 2014-06-19 11:20:50 <michagogo> Basically, each time you hash a block header
171 2014-06-19 11:21:01 <bmcgee> meaning reorgs are typically small and quick
172 2014-06-19 11:21:07 <michagogo> there's a very, very small chance of that turning out a valid block
173 2014-06-19 11:21:23 <michagogo> On average, one in every 65301873052200001536 or so hashes is a valid block
174 2014-06-19 11:21:39 <michagogo> So yes, on average it's one every 10 minutes
175 2014-06-19 11:21:57 <michagogo> But each hash, each attempt at a block, has a tiny chance of succeeding
176 2014-06-19 11:22:12 <gribble> The expected time between blocks taking 1 hour and 0 seconds to generate is 5 days, 9 hours, 23 minutes, and 24 seconds
177 2014-06-19 11:22:12 <michagogo> ;;tblb 3600
178 2014-06-19 11:22:37 <michagogo> Very long or very short amounts of time can pass between blocks
179 2014-06-19 11:22:45 <Apocalyptic> <bmcgee> I would assume it takes less than 10 mins for knowledge of a block to propogate through the network // that is true
180 2014-06-19 11:22:53 <Apocalyptic> not sure why micha negated
181 2014-06-19 11:23:00 <michagogo> Apocalyptic: the first part is true
182 2014-06-19 11:23:08 <michagogo> The second isn't always
183 2014-06-19 11:23:17 <michagogo> Or rather, it doesn't follow from the first part
184 2014-06-19 11:23:25 <bmcgee> indeed.
185 2014-06-19 11:23:29 <michagogo> In some cases, two miners will happen to get lucky at the same time
186 2014-06-19 11:23:45 <michagogo> And both find a block at close to the same time
187 2014-06-19 11:24:25 <bmcgee> What i’m really trying to understand is the likelihood of long chain splits. As in 1 hour later your bitcoind realises there’s a fuller alternative out there and the info it’s been giving you for the last hour is now invalidated
188 2014-06-19 11:24:44 <michagogo> That's unlikely.
189 2014-06-19 11:25:03 <michagogo> Whenever there's a fork, it almost always resolves itself within a block or two
190 2014-06-19 11:25:13 <bmcgee> how unlikely is what I’m trying to understand
191 2014-06-19 11:25:16 <dsnrk> recently we had a 3 block stale chain.
192 2014-06-19 11:25:53 <michagogo> The chances of a fork lasting more than 1 block decrease exponentially (I think?) for each block
193 2014-06-19 11:26:09 <bmcgee> are there any stats on stales chains
194 2014-06-19 11:26:12 <michagogo> Say the chance of a fork were 1 in 600
195 2014-06-19 11:26:24 <gribble> 360000
196 2014-06-19 11:26:24 <michagogo> the chance of a 2-block fork would be 1 in ,,(calc 600**2)
197 2014-06-19 11:26:50 <dsnrk> bmcgee: nothing stops that. you could have multiple side chains at one height.
198 2014-06-19 11:26:53 <michagogo> bmcgee: their very nature makes it very hard to get a comprehensive picture of stale chains or forks
199 2014-06-19 11:27:08 <bmcgee> michagogo: true
200 2014-06-19 11:27:09 <michagogo> Because a block won't be relayed if it's not part of the best chain
201 2014-06-19 11:27:36 <dsnrk> blockchain.info used to track orphan blocks.. but yeah they broke that ages ago and never fixed it.
202 2014-06-19 11:27:38 <michagogo> You can track reorgs, but maybe you happened to hear of the block that ended up in the longest chain first
203 2014-06-19 11:27:55 <dsnrk> and of course bc.i only showed the ones they knew about. not every orphan makes it to every node.
204 2014-06-19 11:28:09 <bmcgee> yeah impossible to track accurately
205 2014-06-19 11:28:29 <blockframe> I'd like to propose a new system for transaction confirmation
206 2014-06-19 11:29:08 <bmcgee> naively speaking increasing the number of outgoing connects and trying to ensure their diversity should help reduce the likelihood of larger stale chains for a node?
207 2014-06-19 11:29:15 <bmcgee> *outgoing connections
208 2014-06-19 11:29:37 <blockframe> Currently, transactions are batched up into individual blocks, requiring an average of 10 minutes to achieve 1 confirmation status. I believe a slight modification can allow transactions to have the same security as 1conf, near instantaneously.
209 2014-06-19 11:30:06 <michagogo> blockframe: You're probably missing a reason why it won't work, but go on...
210 2014-06-19 11:30:41 <blockframe> Rather than mining a block entitling you to put in a snapshot of transactions, mining a block allows you to sign/verify transactions for as long as until someone else mines another block.
211 2014-06-19 11:31:11 <dsnrk> er
212 2014-06-19 11:31:22 <bmcgee> doesn’t that still suffer a reorg problem?
213 2014-06-19 11:31:36 <dsnrk> so a node can be islanded and then the current head can sign any transactions they want?
214 2014-06-19 11:31:57 <blockframe> dsnrk, yes, but this islanded attack is also possible currently, is it not?
215 2014-06-19 11:31:57 <dsnrk> if I solve a block, I can isolate your node and just sign whatever transactions I want.
216 2014-06-19 11:31:59 <Apocalyptic> sounds like a win
217 2014-06-19 11:32:27 <michagogo> blockframe: no, it's not
218 2014-06-19 11:32:34 <blockframe> dsnrk, you already can by just including what transactions you want to double spend when you island..
219 2014-06-19 11:32:45 <dsnrk> blockframe: no it's not, as blocks take a lot of effort to solve. I can't island and feed you false information without solving full blocks worth of work.
220 2014-06-19 11:32:50 <Apocalyptic> blockframe, nobody can sign tx if they don't have the corresponding privkeys
221 2014-06-19 11:33:12 <blockframe> Apocalyptic, ah sorry, I should not have used 'sign' but rather 'verify'
222 2014-06-19 11:33:18 <blockframe> dsnrk, I see your point
223 2014-06-19 11:33:37 <blockframe> confirmations would be tangibly weaker in this system as it would increase the impact of an islanding attack
224 2014-06-19 11:33:46 <dsnrk> yep. anti-islanding is yet another reason we have PoW.
225 2014-06-19 11:34:02 <blockframe> dsnrk, well this would still be PoW :P
226 2014-06-19 11:34:03 <michagogo> Also, what stops the solver of the last block from signing two conflicting transactions?
227 2014-06-19 11:34:11 <michagogo> No, it wouldn't
228 2014-06-19 11:34:27 <michagogo> The point of PoW is that you're expending resources to commit to something
229 2014-06-19 11:34:58 <blockframe> michagogo, nodes reject the current block if there are two conflicting transactions, and verifies must be also down in a merkle root chain
230 2014-06-19 11:35:27 <michagogo> You're calculating a SHA256^2, on average 65 quintillion times, in the process of committing to a block
231 2014-06-19 11:35:32 <dsnrk> blockframe: signing two conflicting transactions would be valid in our network. only in blocks can conflicts not happen.
232 2014-06-19 11:35:53 <blockframe> dsnrk, right, and the miner verifying it is like including it in a block
233 2014-06-19 11:35:58 <michagogo> blockframe: no it's not
234 2014-06-19 11:36:08 <Apocalyptic> indeed it's not
235 2014-06-19 11:36:23 <Apocalyptic> you seem to lack the detailed view of how all this works
236 2014-06-19 11:36:26 <michagogo> Because in your system, once a miner solves a block he can "verify" as many transactions and whatever transactions he wants for free
237 2014-06-19 11:37:01 <blockframe> michagogo, that is correct, OK this isn't PoW as there is no commitment to a particular state
238 2014-06-19 11:37:09 <michagogo> With PoW, you're spending a lot of energy on adding a predetermined set of transactions to the chain
239 2014-06-19 11:37:26 <blockframe> however: 2 confirmations (1 verified, and another block that builds upon the last) would be more secure than 1conf in PoW
240 2014-06-19 11:37:33 <blockframe> michagogo, yes, I understand now thanks :)
241 2014-06-19 11:38:07 <blockframe> 1conf would be near-instant (miners would want to verify txes ASAP due to orphans), and 2conf would happen when there would normally have been 1conf
242 2014-06-19 11:38:13 <michagogo> ...no
243 2014-06-19 11:38:21 <michagogo> ...because the next block can have anything in it
244 2014-06-19 11:38:31 <blockframe> michagogo, it must build upon the last
245 2014-06-19 11:38:38 <michagogo> blockframe: yes
246 2014-06-19 11:38:48 <dsnrk> what if I haven't seen a "verified" transactin and I build a block without it?
247 2014-06-19 11:38:59 <michagogo> I'm saying, your "verifying" of a transaction doesn't add to the block
248 2014-06-19 11:39:27 <blockframe> dsnrk, then that is the same as if you build a block on top of an outdated block, because verifies would be in a merkle root chain
249 2014-06-19 11:39:31 <michagogo> You find a block. You "verify" a transaction. I find a block with a transaction conflicting the one you "verified".
250 2014-06-19 11:40:02 <Apocalyptic> blockframe, please there is no point in discussion your broken proposal further...
251 2014-06-19 11:40:10 <Apocalyptic> *discussing
252 2014-06-19 11:40:10 <blockframe> michagogo, the block you find would include the hash of the last known verify
253 2014-06-19 11:40:22 <blockframe> verifies aren't individual, but the miner must build them on top of each other
254 2014-06-19 11:40:31 <michagogo> blockframe: okay, you just say in your block "I haven't seen any verifys"
255 2014-06-19 11:40:34 <dsnrk> blockframe: you can't assume any peer has seen a particular transaction. what if one peer has seen a "confirmed" transaction and another hasn't? that means two peers with have a different idea of the state of the consensus.. and the chain forks.
256 2014-06-19 11:40:41 <blockframe> michagogo, then your block would not be a valid block.
257 2014-06-19 11:40:46 <michagogo> blockframe: wtf
258 2014-06-19 11:41:01 <michagogo> but what if you actually haven't seen any verifies?
259 2014-06-19 11:41:04 <blockframe> michagogo, the header in your block of the last tx-state merkle root hash would be different to what all other nodes see
260 2014-06-19 11:41:04 <dsnrk> yeah.. see my consensus comment.
261 2014-06-19 11:41:16 <michagogo> You cannot have instant consensus. Ever.
262 2014-06-19 11:41:28 <dsnrk> blockframe: can we take this to #bitcoin please? this is completely off topic for -dev.
263 2014-06-19 11:41:37 <michagogo> The Satoshi blockchain system gives you a mechanism for eventual consensus, and what dsnrk said.
264 2014-06-19 11:41:44 <blockframe> okay, sorry.
265 2014-06-19 12:38:26 <MobChrome> can anyone tell me why my wallet wants to send a .1 tx fee
266 2014-06-19 12:38:54 <MobChrome> and it's not set in the client i checked \
267 2014-06-19 12:41:13 <longfloat> MobChrome: not configured in .bitcoin/bitcoin.conf ?
268 2014-06-19 12:41:48 <hearn> sipa: what do you think about https://github.com/bitcoin/bitcoin/pull/4351#issuecomment-46554983 ?
269 2014-06-19 12:41:57 <MobChrome> longfloat: i'm using the gui for OSX
270 2014-06-19 12:42:11 <MobChrome> my tx is set in the gui to 0.01
271 2014-06-19 12:42:27 <MobChrome> but when i try to send something it wants to send .1
272 2014-06-19 12:42:37 <dsnrk> 0.01 is a huge fee as well
273 2014-06-19 12:42:57 <dsnrk> 0.0001 is enough for almost anything
274 2014-06-19 12:43:26 <dsnrk> remember the fee is per kilobyte, not a set value for every transaction.
275 2014-06-19 12:44:57 <Graet> how much dust are you trying to combine and send in 1 tx?
276 2014-06-19 12:47:04 <dugo> miners should give you a premium instead for cleaning up that much dust/utxo
277 2014-06-19 12:47:17 <MobChrome> i still don't get it
278 2014-06-19 12:47:26 <MobChrome> won't let me send anything now
279 2014-06-19 12:47:38 <MobChrome> was fine until i did the update to 0.9.2
280 2014-06-19 12:48:16 <dsnrk> I guess the first question is why you think 0.01BTC is *ever* necessary for a transaction
281 2014-06-19 12:55:29 <MobChrome> dsnrk: http://i.imgur.com/ec4lbwW.png
282 2014-06-19 12:56:27 <SomeoneWeird> wow
283 2014-06-19 12:56:33 <dsnrk> what
284 2014-06-19 12:57:19 <dsnrk> MobChrome: you should have the fee in the GUI set to 0.0001 BTC/kb, having it set to 0.01BTC is insane. I think that's what's causing that..
285 2014-06-19 12:57:21 <hearn> you must have a lot of dust
286 2014-06-19 12:57:29 <hearn> or yes, changed the ui settings ...
287 2014-06-19 12:58:01 <MobChrome> i did change them
288 2014-06-19 12:58:05 <MobChrome> i will show you guys
289 2014-06-19 13:01:14 <SomeoneWeird> well then, as hearn said, you must have a lot of dust :)
290 2014-06-19 13:01:29 <dsnrk> > my tx is set in the gui to 0.01
291 2014-06-19 13:01:47 <dsnrk> dust and a crazy high fee/kb
292 2014-06-19 13:02:22 <dsnrk> would a transaction with that high of a fee even be relayed? I thought it would be non-standard.
293 2014-06-19 13:05:56 <blockframe> dsnrk, aren't fees >= ? not >= and <=
294 2014-06-19 13:06:01 <MobChrome> lol SomeoneWeird so i can't move it than
295 2014-06-19 13:06:38 <dsnrk> blockframe: there's a sanity check on sendrawtransaction that stops users from sending all of their outputs to fees.
296 2014-06-19 13:07:26 <dsnrk> blockframe: https://github.com/bitcoin/bitcoin/commit/9d14e689c86a395c11a530767db4ddf895446ba8
297 2014-06-19 13:07:31 <blockframe> ah ty.
298 2014-06-19 13:07:36 <MobChrome> dsnrk: yes i sent one .1 and i was charged .2
299 2014-06-19 13:08:06 <dsnrk> MobChrome: you have the fees set far too high! don't change the defaults if you don't understand what they affect
300 2014-06-19 13:08:24 <MobChrome> dsnrk: i didn't change anything
301 2014-06-19 13:08:35 <SomeoneWeird> dsnrk: it might not be settings, he might have a crazy amount of inputs?
302 2014-06-19 13:08:41 <dsnrk> you said it was set to 0.01BTC in the settings though?
303 2014-06-19 13:08:45 <dsnrk> surely that's not default
304 2014-06-19 13:09:12 <MobChrome> well 0.0001
305 2014-06-19 13:09:25 <MobChrome> didn't type it right before sorry
306 2014-06-19 13:09:26 <SomeoneWeird> :\
307 2014-06-19 13:09:29 <dsnrk> alright, so that's not it.
308 2014-06-19 13:09:30 <SomeoneWeird> 
ACTION facepalms

309 2014-06-19 13:09:56 <MobChrome> SomeoneWeird: be nice
310 2014-06-19 13:10:28 <SomeoneWeird> MobChrome: that was me being nice :)
311 2014-06-19 13:10:35 <MobChrome> :P
312 2014-06-19 13:10:52 <dsnrk> MobChrome: would you be happy sending me the TXID of the 0.2BTC fee transaction? I'm sort of curious how your wallet got so dusty.
313 2014-06-19 13:11:40 <MobChrome> dsnrk: did you not get my msg
314 2014-06-19 13:18:45 <MobChrome> so SomeoneWeird you have any ideas on this one
315 2014-06-19 13:19:40 <dsnrk> I've had a look at MobChrome's transaction and it's not *terrible*, it's a bit dusty (5.5KB) but somehow got a 0.12BTC fee for that.
316 2014-06-19 13:19:46 <SomeoneWeird> nope, dsnrk is likely to know more about it than me, sorry
317 2014-06-19 13:21:20 <dsnrk> MobChrome: I don't know much about the fee stuff or the GUI, you'll need to stick around and see what somebody else says about it. the fee does seem to be a little high than it should be though.
318 2014-06-19 13:21:47 <MobChrome> http://i.imgur.com/BBN16kb.png
319 2014-06-19 13:22:12 <crunk-juice> Anyone here have any information on multi-tier cold storage schemes?
320 2014-06-19 13:22:15 <MobChrome> dsnrk: ok guess i will wait and see if someone can help with this
321 2014-06-19 13:22:45 <MobChrome> i know it's not a lot of BTC but something is not right that is for sure
322 2014-06-19 13:23:32 <dsnrk> MobChrome: yow dude that is your problem, it needs to be 100 times lower than that!
323 2014-06-19 13:23:41 <dsnrk> 0.0001BTC not 0.01BTC!
324 2014-06-19 13:24:05 <MobChrome> dsnrk: everytime i change it goes back to the other
325 2014-06-19 13:25:01 <SomeoneWeird> MobChrome: what version of qt are you using?
326 2014-06-19 13:25:13 <MobChrome> 0.9.2
327 2014-06-19 13:25:18 <MobChrome> on OSX
328 2014-06-19 13:25:34 <MobChrome> just very weird thats all
329 2014-06-19 13:27:07 <SomeoneWeird> hrm, wumpus said there was a bug in 0.9.2 osx build for the gui
330 2014-06-19 13:27:33 <dsnrk> SomeoneWeird: that was a font rending thing and a crash on shutdown
331 2014-06-19 13:27:42 <SomeoneWeird> dsnrk: right, just looked
332 2014-06-19 13:27:45 <SomeoneWeird> nevermind me then
333 2014-06-19 13:28:28 <dsnrk> I thought the client was meant to avoid including dust outputs too? the transaction has some outputs like 0.00000002 BTC which just blew out the size of the transaction even more.
334 2014-06-19 13:28:56 <MobChrome> wow i just got it to work
335 2014-06-19 13:29:03 <MobChrome> but lost .1 in the process
336 2014-06-19 13:29:04 <MobChrome> lol
337 2014-06-19 13:29:19 <MobChrome> brb phone and i will tell you dsnrk
338 2014-06-19 13:29:41 <MobChrome> seems like there was a active command line tx fee that was coded in for some odd reson
339 2014-06-19 13:29:45 <MobChrome> reason*
340 2014-06-19 13:29:52 <SomeoneWeird> eh?
341 2014-06-19 13:34:24 <venzen> MobChrome: do you have a bitcoin.conf file? what does it contain?
342 2014-06-19 13:34:44 <MobChrome> venzen: no conf file
343 2014-06-19 14:02:21 <gavinandresen> wumpus: FYI, my OSX gitian builds still don't match after cleaning up my Gitian VMs (uninstalling everything but base packages, then downloading-only-but-not-installing things needed to build).
344 2014-06-19 14:02:41 <wumpus> gavinandresen: very strange!
345 2014-06-19 14:02:45 <gavinandresen> wumpus: My MacOSX10.7.sdk.tar.gz input is different....
346 2014-06-19 14:03:10 <gavinandresen> I downloaded that from Apple directly and did the extract/tar thing.
347 2014-06-19 14:03:21 <wumpus> gavinandresen: that could be the reason in theory but it is created non-deterministically
348 2014-06-19 14:03:30 <wumpus> so everyone's will be different unless they copied it :)
349 2014-06-19 14:04:05 <wumpus> but that depends on what is different, is it just timestamps/file ordering or the headers/libs itself
350 2014-06-19 14:05:54 <gavinandresen> Always possible my cleanup of the VMs didn't do what I thought it would, too….
351 2014-06-19 14:07:02 <wumpus> yes, your non-standard way of doing it complicates things :)
352 2014-06-19 14:07:34 <wumpus> hm we could also send you the dmg (the one that matches the others) for code-signing
353 2014-06-19 14:07:44 <gavinandresen> sure
354 2014-06-19 15:16:35 <skinnkavaj> gmaxwell
355 2014-06-19 15:16:37 <skinnkavaj> Comments about
356 2014-06-19 15:16:38 <skinnkavaj> https://medium.com/@lmgoodman/preventing-mining-pool-concentration-with-lamport-signatures-e7601c474343
357 2014-06-19 15:16:46 <skinnkavaj> ?
358 2014-06-19 15:16:51 <skinnkavaj> Luke-Jr
359 2014-06-19 15:18:29 <gmaxwell> This does not address any of the current concerns, and would potentially make things much worse.
360 2014-06-19 15:18:58 <gmaxwell> The claim that that particular proposal preserves hardware is incorrect, as well.
361 2014-06-19 15:20:30 <gmaxwell> The idea of making miners sign in blocks and testing the signature has been proposed many times before, as far back as 2011. It would be a nussance for all forms of pooling, including P2pool, thus forcing people into hosting.  GHash.io's hashpower is substantially captive hosted hashpower— part of the reason that that negative PR didn't change things... so it's not addressing the issue we have right now.
362 2014-06-19 15:21:46 <gmaxwell> It wouldn't however prevent pooling— pools could require miners make a 25 BTC deposit in order to pool, — since block theft is detectable but not preventable in that model, they could enforce the deposit.
363 2014-06-19 15:23:07 <gmaxwell> WRT hardware, existing hardware can mostly only handle the existing header and nonce structure very specifically. The existing hardware is not a generic sha256 implementation.
364 2014-06-19 15:23:31 <AdrianG> hi all
365 2014-06-19 15:23:45 <AdrianG> is there any talk about non-outsourcable puzzles
366 2014-06-19 15:23:50 <gmaxwell> (though a variation that didn't break hardware could be done— if it were desirable, which I believe it is not)
367 2014-06-19 15:24:34 <gmaxwell> AdrianG: This is really not the channel for it. But I believed the existing proposals are a misguided non-solution.
368 2014-06-19 15:24:45 <AdrianG> gmaxwell: eyal's proposal?
369 2014-06-19 15:25:14 <gmaxwell> skinnkavaj just linked to https://medium.com/@lmgoodman/preventing-mining-pool-concentration-with-lamport-signatures-e7601c474343 moments before you joined and I responded to it.
370 2014-06-19 15:26:00 <AdrianG> so same story, wallet's private key.
371 2014-06-19 15:26:23 <AdrianG> could you re-paste your response then
372 2014-06-19 15:26:54 <gmaxwell> there are logs, please go read them in a moment when they show up. :) It would be rude to flood everyone with a repeat.
373 2014-06-19 15:27:30 <AdrianG> url?
374 2014-06-19 15:29:19 <gmaxwell> Speaking more generally: I think these approaches are fundimentally misguided. They attack the wrong problem: They inhibit pooling for variance reduction, which is beneficial and not harmful— and do nothing about selling your mining vote; just implictly hoping that if you cannot pool for variance reduction you won't sell your vote. Instead, since pooling for variance reduction is a necessary criteria for many to participate in mining ...
375 2014-06-19 15:29:23 <andytoshi> AdrianG: http://bitcoinstats.com/  (public logs are in the /topic on all freenode channels)
376 2014-06-19 15:29:25 <gmaxwell> ... such a change would likely drastically reduce participation (A speculation but an informed one), and would drive people into cloud/hosted mining (which is already quite popular and run in an unauditable manner) which is much worse. I made the point above that this is especially ironic in that ghash.io is primarly a cloud mining operation, — part of the reason the negative press didn't change things much.
377 2014-06-19 15:29:35 <gmaxwell> It's in the topic: http://bitcoinstats.com/
378 2014-06-19 15:30:06 <AdrianG> ic.
379 2014-06-19 15:36:59 <elichai2> hey
380 2014-06-19 15:37:54 <elichai2> there is any way to run use bitcoin-cli(create address, multisig, rawtx etc.) from C code without 'system'?
381 2014-06-19 15:39:36 <gmaxwell> elichai2: #bitcoin
382 2014-06-19 15:41:20 <elichai2> but it is dvelopers connected.... but whatever...
383 2014-06-19 15:41:23 <gmaxwell> AdrianG: Amiller's non-outsourcable puzzle has the advantage over the scheme I commented on above that you cannot recover pooling be requiring a deposit, since you cannot tell who stole, but it has some other limitations.
384 2014-06-19 15:42:34 <gmaxwell> (I unbanned him on PM request, he'd previously been banned for unfriendly tech support requests, I told him on unbanning that this channel was not for tech support and he should ask in #bitcoin)
385 2014-06-19 15:44:05 <gmaxwell> AdrianG: First it requires a CRS ZK-SNARK, ignoring all the tech immaturity (he had to change his mining function to sha1 because the sha256 circuit was too complex for the software he had available, etc) the existing efficient ZK-SNARK solutions require a trusted setup. If violated, it would allow the party with the secret data to mine unlimited blocks for free.
386 2014-06-19 15:44:46 <gmaxwell> Another limitation is that if most of the hashpower wanted pooling to work, they could simply soft-fork out any theft blocks which are created, removing the threat.
387 2014-06-19 15:45:24 <gmaxwell> (relevant when you're already taking about an uncooperative party with nearly most of the hashpower!)
388 2014-06-19 15:47:15 <gmaxwell> There are also some more minor downsides, it effectively reduces all confirmation counts by 1 when there is a theft block. And stealing a block requires about 45 minutes of cpu time but must be done fast enough to avoid you being orphaned, because a miner finds blocks so rarely and the cost of stealing is so high, perhaps it's not really much of a threat after all.
389 2014-06-19 15:49:14 <AdrianG> gmaxwell: but i think all of those are going to fail.
390 2014-06-19 15:49:32 <AdrianG> what if you just have in-trust mining? i.e. you pay me operating costs, and I operate mining for you, turn-key.
391 2014-06-19 15:49:47 <AdrianG> you wouldnt know if im not doing anything fishy.
392 2014-06-19 15:51:43 <gmaxwell> I think that before anyone can 'solve' this we need to better understand the specific nature of the problem.  Is the degree of centeralization because of actual control of hardware being centeralized (e.g. by hardware vendors like KnC or Bitfury/cex/ghash taking their sales profits (>>10x markup) and buying their own hardware at cost), or because of investor funded cloud operations?  Is it because of pools aggregating otherwise ...
393 2014-06-19 15:51:49 <gmaxwell> ... decenteralized miners?  If the latter is it just because people are unaware of alternatives? or because they consider the alternatives inferior? e.g. is it the cost of running a node or do the not like p2pool's accounting?    If it's cloud operations instead, what the exact motivations there?
394 2014-06-19 15:53:05 <gmaxwell> To the extent that the issue is stupid hardware buyers paying vendors to compete with them no technical solution can fix any of it.
395 2014-06-19 15:53:32 <Graet> i see a lot of ppl using cloud hashing to avoid heat + (exoensive in their country) power costs
396 2014-06-19 15:53:42 <Graet> expensive*
397 2014-06-19 15:54:02 <dsnrk> gmaxwell: for me at least the hardware cost of p2pool was annoying. GBT + a small ARM board seems to be a lot better in that department.
398 2014-06-19 15:54:11 <gmaxwell> Graet: I don't believe any of the cloud hashing operations I've seen have costs below the costs where I am, and I have some of the most expensive power in the world.
399 2014-06-19 15:54:37 <dsnrk> gmaxwell: PS claims < 5c/kW
400 2014-06-19 15:54:41 <Graet> thats what ppl tell me, here power can be 48c
401 2014-06-19 15:55:02 <gmaxwell> dsnrk: thats _his_ cost.
402 2014-06-19 15:55:40 <gmaxwell> the actual services are >40c/kWh that I've seen.  Even if I'm right that doesn't mean graet is wrong.
403 2014-06-19 15:56:24 <gmaxwell> dsnrk: So there are two folds to that, one is that p2pool operating costs can be drastically reduced. But they would, of course, be higher than just being a blind hasher.
404 2014-06-19 15:57:02 <gmaxwell> The gap could be reduced to ~0 with a change in the proof of work function. I don't know that the gap needs to be zero, however.
405 2014-06-19 15:57:08 <Graet> noise is also a reason given for not having hardware at home, some asics sound like jets, i know one guy that had neighbors complain to council about the noise lol
406 2014-06-19 15:57:19 <phantomcircuit> gmaxwell, er CH is offering $4.40/Gh today
407 2014-06-19 15:57:25 <dsnrk> gmaxwell: as it stands p2pool can't really run that happily even on a fairly zippy processor. I found that in that case other pools were an awful lot faster at me updating to the latest work.
408 2014-06-19 15:58:06 <dsnrk> Graet: the new Antminers should be good, they've swapped out the leafblower fan for proper thermal design and a fan on each end.
409 2014-06-19 15:59:00 <phantomcircuit> gmaxwell, also literally nobody is paying $292/kW/month
410 2014-06-19 15:59:04 <phantomcircuit> that's crazy talk
411 2014-06-19 15:59:09 <Graet> cool, just passing on info, miners have passed to me re gmaxwell 's query, i talk to a different subset i think ;)
412 2014-06-19 16:03:13 <gmaxwell> phantomcircuit: uh. cloudhashing website appears to no longer disclose the management fees, but when I checked previously they were equal to about 40cts/kwh assuming the cointerra power efficiency.
413 2014-06-19 16:03:32 <gmaxwell> pretty sleezy to not disclose that clearly, fwiw.
414 2014-06-19 16:05:32 <AdrianG> is it possible to ensure decentralization even in theory?
415 2014-06-19 16:05:37 <AdrianG> is it a solvable problem.
416 2014-06-19 16:07:12 <dsnrk> I don't think so. anything a user can do in their home can be done at scale.
417 2014-06-19 16:08:07 <gmaxwell> There is some somewhat wanky argument that heat disappation prefers decenteralization slightly, but its a fairly weak preference. I think the best you can do is avoid the avoidable biases that encourage centeralization.
418 2014-06-19 16:08:08 <Hasimir> only in a way that everyone here would object to
419 2014-06-19 16:08:30 <Hasimir> as it would involve biometric authentication of nodes ...
420 2014-06-19 16:09:05 <dsnrk> biometric stuff normally needs a trusted party. fingerprints and what not are too noisy to use as cryptographic keys.
421 2014-06-19 16:09:45 <Hasimir> what about dna ... it would truly be the bleeding edge
422 2014-06-19 16:09:53 <Hasimir> 
ACTION ducks

423 2014-06-19 16:10:22 <dsnrk> and even if you could do that, it doesn't enforce decentralisation. what stops me from going and getting whatever information is needed from a bunch of people? you can't prove they are present, so you're back to warehouses of central hardware.
424 2014-06-19 16:10:33 <gmaxwell> E.g. a lot of the centeralization today— that which results from people pooling for variance reduction— is completely solvable.  But other sources— that that arises because running a node has costs (even though the costs are $1/month scale)— or because people want to use cloud facilities... not obviously as solvable.
425 2014-06-19 16:11:05 <Hasimir> dsnrk, and a rather nasty interpretation of a slave server ...
426 2014-06-19 16:11:46 <Hasimir> yep, that was definitely one of my worse ideas (and I've had a few)
427 2014-06-19 16:12:01 <dsnrk> gmaxwell: isn't a lot of what makes p2pool nasty to run just due to it being python?
428 2014-06-19 16:12:45 <gmaxwell> dsnrk: presumably. I've never had much cause to profile it, it's stupidly fast on the i7 I run it on.
429 2014-06-19 16:14:02 <dsnrk> gmaxwell: right, well it's treacle slow and runs into swap on all the board I had handy. I don't really have a big enough mining setup to justify burning my only i7 box on p2pool. I'd love to see a cubieboard or odroid image that's optimised and built for p2pool. they could handle it.
430 2014-06-19 16:14:57 <dsnrk> set up a little store. sell a Bitcoin Mining Dectralising Kit at cost.
431 2014-06-19 16:15:39 <dsnrk> you get a ARM board, sd card with the software image on it, some stickers. problem solved.
432 2014-06-19 16:16:28 <gmaxwell> dsnrk: well if you're running into swap then thats explained completely on that basis alone. I dunno about "burning", it's 3% cpu usage on a one month average on the system here... though mine is a bit high as I've artifically forced the pseudoshare diff down to get better stats graphs.
433 2014-06-19 16:17:54 <gmaxwell> dsnrk: none of the existing arm stuff is really all that sutiable. It's almost all limited to 2GB ram, even though ram is cheap. And best available ecdsa is kinda slow on arm, e.g. 400 verifies a second vs 40k/s on the aformentioned i7.
434 2014-06-19 16:18:04 <dsnrk> gmaxwell: it's slow just idling, I've found the memory usage is around 300MB at startup and rises up to about 600MB (which pushes me over the limit). if it was a little better it wouldn't be a problem. "burning" was more a comment that I can't use it for it's purpose, even though it does use a lot of power.
435 2014-06-19 16:18:27 <gmaxwell> 2GB is viable today but you'd want such a device to have reasonable headroom.
436 2014-06-19 16:18:46 <dsnrk> gmaxwell: don't think the cubieboard is *that* terrible at EC. are you just talking openssl benchmarks?
437 2014-06-19 16:19:41 <gmaxwell> dsnrk: libsecp256k1, openssl is half that speed on arm (those numbers are on a cortex-a9 at ~1.2GHz)
438 2014-06-19 16:20:46 <gmaxwell> this isn't to say that it couldn't be a lot better with some optimization work, but I expect that it's still going to remain much lower operations/$ than x86_64.
439 2014-06-19 16:21:19 <dsnrk> gmaxwell: ah, I was going to benchmark my dual A7 board but that'll suck even more :C
440 2014-06-19 16:21:51 <gmaxwell> dsnrk: feel like learning neon? :)
441 2014-06-19 16:23:44 <dsnrk> gmaxwell: a wha?
442 2014-06-19 16:23:59 <dizko> anyone know if mining pools starting using replace-by-fee?
443 2014-06-19 16:31:39 <phantomcircuit> gmaxwell, it doesn't?
444 2014-06-19 16:31:45 <phantomcircuit> hmm
445 2014-06-19 16:31:55 <phantomcircuit> (there is also no registration button anymore)
446 2014-06-19 16:33:20 <phantomcircuit> gmaxwell, anyways the 10% management fee was for the life of the contract, so at the start it was fairly expensive, but towards the end it's less than it costs to operate
447 2014-06-19 16:33:54 <phantomcircuit> currently there is a $1.99/Gh contract w/ monthly fees of $0.20/Gh
448 2014-06-19 16:34:02 <cfields> wumpus: no tag?
449 2014-06-19 16:34:47 <phantomcircuit> which is about $0.21/kWh (but of course includes a lot more than just electricity costs)
450 2014-06-19 16:35:40 <cfields> mm, there it is. weird.
451 2014-06-19 16:40:39 <dizko> anyone?   really, if pools start using replace by fee without any kind of announcement, that's seriously fucked up
452 2014-06-19 16:40:57 <dsnrk> dizko: no it's not. 0conf transactions have never been safe.
453 2014-06-19 16:41:24 <dizko> sure, but if the rules of the game are to be changed, that should be transparent
454 2014-06-19 16:41:36 <justanotheruser> dizko: that isn't a rule
455 2014-06-19 16:41:52 <dizko> its a fairly significant feature of how the ecosystem functions
456 2014-06-19 16:42:08 <justanotheruser> dizko: it is how the ecosystem may funciton currently, but it isn't a rule
457 2014-06-19 16:42:16 <justanotheruser> *function
458 2014-06-19 16:43:03 <justanotheruser> You can't rely on people doing what is best for you, you have to assume they will do what's best for them and set up the incentives so they work for everyone.
459 2014-06-19 16:43:11 <dizko> there really arent any 'rules'  ....  but i dont see how it benefits anyone for the way the pools operate to be so opaque
460 2014-06-19 16:43:18 <justanotheruser> Lol @ Peter Todd reddit post btw
461 2014-06-19 16:43:30 <dizko> for example, filtering specific address is completely contrary to the ethos of bitcoin
462 2014-06-19 16:43:41 <dsnrk> dizko: happens anyway though.
463 2014-06-19 16:44:13 <dsnrk> gmaxwell: the numbers aren't really that terrible. my dual core a7 is not *that* much slower than my quad (with hyperthreading) i7. I'm testing with openssl though, with pieter's library that might be different.
464 2014-06-19 16:44:49 <justanotheruser> dizko: Your security assumptions shouldn't assume tragedy of the commons doesn't exist.
465 2014-06-19 16:45:39 <gmaxwell> dsnrk: libsecp256k1 is ~6x faster than openssl on x86_64.
466 2014-06-19 16:46:14 <dizko> its not like mining pools are one guy doing his own thing.  they represent a huge responsibiltiy and are rewarded very great sums of value in bitcoin for it
467 2014-06-19 16:46:31 <gmaxwell> dizko: reusing addresses in a way that makes that kind of filtering possible (/attractive, perahaps someday obligitory) is also pretty contrary.
468 2014-06-19 16:46:40 <dizko> so changing their rules without letting anyone know isnt a crime, or breaking any rules
469 2014-06-19 16:46:44 <dizko> but it is a dick move
470 2014-06-19 16:46:44 <dsnrk> gmaxwell: for the sake of interest http://0bin.net/paste/X0CiIPynRq461FSq#mbgbyIy0/HaFM6rLl5fEnsKAb7Mtg6lkUHAjEtzG6Bg=
471 2014-06-19 16:46:50 <justanotheruser> dizko: They aren't changing any rules
472 2014-06-19 16:47:10 <justanotheruser> If they changed the network rules, then no full nodes would include their blocks
473 2014-06-19 16:47:35 <gmaxwell> (not that I agree with anyone screwing you over, or anything like that— but just pointing out here that things that reuse addresses are using an insecure approach which is at odd with the design of bitcoin, which increases vulnerabality to censorship— arguably for everyone)
474 2014-06-19 16:48:26 <dizko> i pay miners thousands of dollars a month in fees, it would be basic etiquette to inform the community on the rules theyre playing by
475 2014-06-19 16:48:35 <justanotheruser> dizko: you do???
476 2014-06-19 16:48:45 <dizko> yes
477 2014-06-19 16:49:00 <justanotheruser> Do you make hundreds of thousands of transactions?
478 2014-06-19 16:49:13 <dizko> i didnt say i pay them tens of thousands a month
479 2014-06-19 16:49:18 <dsnrk> dizko: I feel in no way obliged to tell anybody if I switched to that patch. it's better in my mind for the users of bitcoin anyway.
480 2014-06-19 16:50:42 <justanotheruser> dizko: It is much better to not do things that are insecure like accept 0conf tx, than to hope miners will do what is bad for the network.
481 2014-06-19 16:50:51 <hearn> wow, neat, can buy bitcoins at any post office in switzerland! http://www.fastcoin.ch/index
482 2014-06-19 16:51:05 <dsnrk> gmaxwell: er and just to point out, I wasn't trying to prove you wrong by benchmarking. I was just curious to see how one of my underclocked cubieboards would do.
483 2014-06-19 16:51:06 <dizko> i dont really care what rules miners go by, but i'd be nice if the pools would be transaparent about their rules
484 2014-06-19 16:51:09 <dizko> and some consistency would be nice
485 2014-06-19 16:51:34 <dizko> its looking like ill be stopping my service
486 2014-06-19 16:51:38 <dizko> and not paying them thousands a month
487 2014-06-19 16:51:58 <dsnrk> dizko: eh, how do you expect me to tell you all of these things? I don't accept transactions with uncompressed keys in them as a node rule.
488 2014-06-19 16:52:05 <Graet> <dizko> its not like mining pools are one guy doing his own thing.  they represent a huge responsibiltiy and are rewarded very great sums of value in bitcoin for it  << most pools are run by "1 man" and traditional (non asic manufacturer created pools) the bulk of the bitcoin mined went (goes) to the miners contributing hashpower, nott the pool
489 2014-06-19 16:52:58 <dizko> its very arguable that virtual currency can work without rewarding miners so greatly
490 2014-06-19 16:53:01 <justanotheruser> dizko: or you could just practice proper security and not worry about their policy :)
491 2014-06-19 16:53:49 <Graet> "greatly"?
492 2014-06-19 16:54:02 <justanotheruser> ^that too
493 2014-06-19 16:54:05 <Graet> only at todays prices, not at 2011 prices
494 2014-06-19 16:54:07 <justanotheruser> miners barely make anything
495 2014-06-19 16:54:27 <dizko> well, yea fair enough, i understand that mining has very slim margins, so maybe more like "we waste a shitload of money on something that could be done MUCH cheaper"
496 2014-06-19 16:54:32 <hearn> dsnrk: a little data structure or language for expressing policy in the coinbase would be useful. but ultimately bitcoin is a consensus system. it works best when there is .... consensus!
497 2014-06-19 16:54:43 <dizko> so, perhaps i should just put my energy behind something else that uses maybe proof of stake or somethingh
498 2014-06-19 16:55:12 <gmaxwell> dizko: https://download.wpsoftware.net/bitcoin/pos.pdf
499 2014-06-19 16:55:13 <dsnrk> dizko: replace a slightly inconvenient system with a totally broken one. sensible.
500 2014-06-19 16:55:14 <justanotheruser> dizko: PoS doesn't work
501 2014-06-19 16:55:40 <dizko> thanks for the doc, ill read up
502 2014-06-19 16:56:16 <dsnrk> hearn: that might be fun. get the miners to set flags in their coinbase about policies. at least then it would be easy to see what a pool supports and doesn't support. I'm all for it if I can set my evil bit.
503 2014-06-19 16:56:22 <dizko> look, i realize im the one breaking the "rules" ... i just find it rude and fairly incomprehensible why at least the largest pools couldnt publish their filter criteria
504 2014-06-19 16:56:54 <dsnrk> dizko: so get people motivated about it. convince enough people to ask the pools that they public it.
505 2014-06-19 16:57:01 <dizko> if ghash was like "hey, we're doing replace-by-fee now, good luck!"
506 2014-06-19 16:57:03 <dizko> i could deal wit that
507 2014-06-19 16:57:15 <gmaxwell> Anti-spam-ish criteria are, sadly, most effective when not published in great detail... but I'm only aware of one even moderately sized pool that makes its operating details even moderately public.
508 2014-06-19 16:57:38 <dizko> sounds like security through obscurity to me
509 2014-06-19 16:57:41 <dsnrk> pools are people, if enough people asked Graet to change his pools policy in a sensible way I'm sure he would oblige.
510 2014-06-19 16:57:43 <gmaxwell> (not that replace by fee is an anti-spam criteria, but I know that your activity is likely to be burned by some sensible anti-spam criteria)
511 2014-06-19 16:57:45 <justanotheruser> gmaxwell: eligious?
512 2014-06-19 16:57:57 <helo> isn't the point to not believe them until they actually do it? which would be better observed and considered than assumed.
513 2014-06-19 16:58:07 <Graet> we normally run bitcoind defaults with a larger block size
514 2014-06-19 16:58:10 <justanotheruser> dizko: Their policy isn't what is making them secure.
515 2014-06-19 16:58:16 <justanotheruser> *Eligius
516 2014-06-19 16:58:36 <dsnrk> Graet: would you be against publishing a text file with your current policy?
517 2014-06-19 16:58:54 <Graet> not at all,
518 2014-06-19 16:59:01 <justanotheruser> Graet: what pool do you run?
519 2014-06-19 16:59:05 <Graet> ozcoin
520 2014-06-19 16:59:13 <gmaxwell> dsnrk: It doesn't really matter, e.g. doesn't prevent things like ghash's 3k btc theft from betcoin dice.
521 2014-06-19 17:00:26 <dsnrk> gmaxwell: well if they'd set their evil bit we could have rejected the blocks.
522 2014-06-19 17:00:35 <dsnrk> gmaxwell: in seriousness it would be nice to know what pools supported, then you could guide people to make educated choices about what they are mining to support. currently we can't say why one pool has better policies than another because they aren't published.
523 2014-06-19 17:02:10 <gmaxwell> dsnrk: "maybe" transparency is good and important, but it would be very easy for people to think it actually matters in a way that it doesn't. It's completely non-binding.
524 2014-06-19 17:02:15 <hearn> i'm not convinced most pools even have policy, per se, except maybe for block size limit (impacts orphan rate impacts revenue)
525 2014-06-19 17:02:36 <hearn> most pool guys i've talked to just say "well we just upgrade if there's some need otherwise we leave stuff alone"
526 2014-06-19 17:03:05 <hearn> i guess that's a policy :)
527 2014-06-19 17:03:19 <hearn> the don't fix what ain't broken policy
528 2014-06-19 17:04:41 <dsnrk> sure, that's a policy
529 2014-06-19 17:05:22 <Graet> we upgrade to latest asap and increase block size to 750, got caught by that 1 time, but apart from that no issues
530 2014-06-19 17:05:24 <hearn> dizko: what fees are the killed transactions attaching?
531 2014-06-19 17:07:33 <maaku> Graet: you and Luke-Jr are the exceptions
532 2014-06-19 17:07:54 <maaku> as indicated by the fact that you are even on this channel :)
533 2014-06-19 17:08:04 <Graet> :)
534 2014-06-19 17:09:50 <hearn> 
ACTION loves Graet and Luke-Jr  :)

535 2014-06-19 17:10:15 <Graet> lol
536 2014-06-19 17:10:15 <Graet> yay!
537 2014-06-19 17:12:55 <hearn> dizko: i'm asking because it may not be replace-by-fee exactly, just something that looks like it. and if so there is a simple change you can make to fix it
538 2014-06-19 17:13:21 <lechuga_> any1 pretty familiar with the mempool tx resurrection code in the DisconnectTip code path?
539 2014-06-19 17:17:28 <lechuga_> i guess, specifically, in ConnectTip, is the only way we can get a conflict with a memory pool tx if a tx in the block was never relayed? (from our perspective)
540 2014-06-19 17:20:37 <dizko> hearn: hi sorry, they paid 0.0001 on the original, 0.0002 on the double spend
541 2014-06-19 17:21:33 <hearn> can you show me an example tx?
542 2014-06-19 17:22:34 <dizko> here's all the ones they got away with today:  http://pastebin.com/raw.php?i=2W4xfi19
543 2014-06-19 17:23:01 <dizko> i recently had the problem because of the fee differential, some accepting 0.0001 and some 0.00001 so i added code to walk down the unspent outputs and make sure their fees were conservative
544 2014-06-19 17:35:03 <dizko> er s/unspent/unconfirmed/
545 2014-06-19 17:35:37 <dsnrk> my node never even saw those
546 2014-06-19 17:36:35 <dizko> i have a star cluster of open relays on every continent, ive got as many connections to the network as bc.i
547 2014-06-19 17:36:42 <dizko> would be surprised if this was just a network based attack
548 2014-06-19 17:37:28 <maaku> hearn: I think you're right, of course
549 2014-06-19 17:37:50 <maaku> i had a wrong intuition about how getheaders works
550 2014-06-19 17:37:55 <hearn> dizko: ah ok, so you already got the fee drop handled - are you checking for new dust outputs too? as in >= 546 satoshis and <= 5460 satoshis?
551 2014-06-19 17:38:06 <hearn> 
ACTION wishes he could find dgenr8s double spend radar page

552 2014-06-19 17:38:14 <dizko> hearn: yes i also started enforcing rules on output size
553 2014-06-19 17:38:15 <maaku> btw, did you see i greatly expanded my comment via an edit on github? (not sure if you're interacting by github or email)
554 2014-06-19 17:38:57 <hearn> dizko: and you're still getting double spent. damn. that sucks. would be a pretty big deal if ghash has gone replace-by-fee. given that it's only meant to be "better" as a double-spend preventor in combination with child pays for parent and a lot of new behaviour in wallets that doesn't exist yet
555 2014-06-19 17:39:03 <dizko> hearn: all these ones today in that pastebin, they used a single input and a single output, fairly large, and used 0.0001 fee on the original
556 2014-06-19 17:39:09 <hearn> hmm
557 2014-06-19 17:39:27 <hearn> yes for some reason no block explorers seem to know about these transactions. with replace by fee i'd expect them to know about it.
558 2014-06-19 17:39:31 <hearn> odd. there must be something else going on here.
559 2014-06-19 17:39:38 <dizko> hrm?  bc.i lists them
560 2014-06-19 17:39:38 <maaku> i can think of some rather uncontroversial hard-fork modifications to the txout structure, but since it requires updating basically all infrastructure it remains to be seen if it is worth it...
561 2014-06-19 17:39:48 <dizko> like, aybe one isnt listed but the bulk are on bc.i
562 2014-06-19 17:39:59 <maaku> merklized scripts probably are, but that could just as easily be done as a soft-fork script template
563 2014-06-19 17:40:21 <hearn> ah ok
564 2014-06-19 17:40:38 <hearn> dizko: you run satoshibones? yes there has been a lot of double spending against that site. dgenr8 noticed this too.
565 2014-06-19 17:40:50 <dizko> yea i got my ass kicked recently
566 2014-06-19 17:41:02 <dizko> the fee stuff, i coulda foreseen that
567 2014-06-19 17:41:31 <hearn> well, fee's are just a mess right now. that's partly my fault too. sorry about that.
568 2014-06-19 17:41:40 <hearn> https://blockchain.info/tx/c4f8ce4f7d323579d01c7aede7808081c7eab5a436a06a77c78180d3d5684d6c
569 2014-06-19 17:41:40 <hearn> this tx seems to be double spent but the double spend also has the same fee?