1 2014-03-08 00:30:00 <TheButterZone> https://bitcointalk.org/index.php?topic=506172.0;topicseen "Help me with a bug in c++ software i'm coding and i'll give you 0.2btc."
  2 2014-03-08 00:45:07 <vegard> did you try ##c++
  3 2014-03-08 00:47:07 <shadders_> gmaxwell: you around?  Been making some notes on coinbase only mining and come across a potential showstopper issue.
  4 2014-03-08 00:47:26 <gmaxwell> shadders_: hm?
  5 2014-03-08 00:47:33 <gmaxwell> (are you stuck on fees?)
  6 2014-03-08 00:47:48 <shadders_> Just thinking about what a pool will need to validate a share from a miner
  7 2014-03-08 00:48:01 <Luke-Jr> shadders_: did you read BIP 23? :P
  8 2014-03-08 00:48:09 <shadders_> Aside from nonces and all the usual stuff.
  9 2014-03-08 00:48:53 <gmaxwell> They don't— except just as a sanity check, in which case they can ask for whole blocks on the first share.  The reason they don't generally is that _intentionally_ sending an invalid block is equivilent to a block withholding attack, which already only takes like a few characters changed in most mining code.
 10 2014-03-08 00:49:19 <gmaxwell> (actually its somewhat less bad than block withholding, since block withholding is fundimentally undetectable.)
 11 2014-03-08 00:49:20 <shadders_> If they select their own txs the pool will need at minimum the merkle root of the tx list.  at maximum the full list of txs (we can't gauruntee the pool has seen them all)
 12 2014-03-08 00:49:48 <Luke-Jr> shadders_: merkle branches work
 13 2014-03-08 00:49:51 <Luke-Jr> with proposals
 14 2014-03-08 00:50:01 <TheButterZone> vegard: yeah, no response yet
 15 2014-03-08 00:50:05 <gmaxwell> shadders_: the pool never needs to see all the trasnactions though it does need the one brach to verify the coinbase.
 16 2014-03-08 00:50:05 <Luke-Jr> welll, "are sufficient in theroy"
 17 2014-03-08 00:50:08 <shadders_> if the pool see's the txs.  They have the opportunity to reject the shares if they don't like what's included...
 18 2014-03-08 00:50:24 <Luke-Jr> shadders_: don't use those pools
 19 2014-03-08 00:50:29 <gmaxwell> shadders_: but thats not their business...
 20 2014-03-08 00:50:46 <gmaxwell> You're complaining that adding centeralization adds bandwidth there. :P
 21 2014-03-08 00:50:56 <gmaxwell> I mean, you can send it all it just takes more bandwidth.
 22 2014-03-08 00:51:16 <shadders_> If they don't see the tx's (merkle only) the pool can't be sure the block isn't bogus.  either deliberately, or because they have a bad implementation
 23 2014-03-08 00:51:32 <Luke-Jr> gmaxwell: someone at the conference had this idea to use a zero-knowledge proof - but not sure it's worth it
 24 2014-03-08 00:51:40 <gmaxwell> I'm sure it's not worth it.
 25 2014-03-08 00:51:49 <gmaxwell> shadders_: I answered deliberately bogus above.
 26 2014-03-08 00:52:07 <shadders_> Luke-Jr: I am considering a scenario where pool turns rogue.
 27 2014-03-08 00:52:16 <gmaxwell> It's precisely equal to a withholding attack which is fundimentally impossible to prevent in the bitcoin protocol today, and only takes like a one line change.
 28 2014-03-08 00:52:25 <Luke-Jr> shadders_: a rogue pool will just claim to accept shares and never pay
 29 2014-03-08 00:52:54 <gmaxwell> As far as bad implementation, sure, the pool should ask miners to return the whole block intermittantly to detect misconfiguration.
 30 2014-03-08 00:52:59 <shadders_> Luke-Jr: No I mean if a few pools got together for a 51% attack.
 31 2014-03-08 00:53:12 <gmaxwell> shadders_: I'm not sure what you're saying there
 32 2014-03-08 00:53:14 <Luke-Jr> shadders_: pools can't 51% if they aren't selecting transactions
 33 2014-03-08 00:53:58 <shadders_> if they can see transactions in a share and reject shares on that basis they are still effectively selecting transactions
 34 2014-03-08 00:54:29 <shadders_> My preference is client sends merkle only because of that ^
 35 2014-03-08 00:54:49 <gmaxwell> shadders_: not unless people actually respond in a way other than failing over to another pool/ solo when their pool starts rejecting shares.
 36 2014-03-08 00:55:08 <shadders_> gmaxwell: intermittent full block validation is probably the answer...
 37 2014-03-08 00:55:27 <gmaxwell> and sure normally most of the time it should be just sending the branch for bandwidth reasons, I do think sampling makes sense for misconfiguration... and I don't think that creates much exposure for censorship.
 38 2014-03-08 00:55:38 <gmaxwell> man, and I thought you were going to complain about the fee problem. :)
 39 2014-03-08 00:56:04 <shadders_> no I haven't got far enough to think about fees yet... Still trying to remember how bitcoin works ;)
 40 2014-03-08 00:56:23 <gmaxwell> :)
 41 2014-03-08 00:56:47 <gmaxwell> when you get stuck on fees come back, I have some thoughs though I'm not completely happy with them.
 42 2014-03-08 00:59:33 <shadders_> fees... you mean the pool can't generate the coinbase because it doesn't know what Txs to include fees from?
 43 2014-03-08 01:00:27 <gmaxwell> yep.
 44 2014-03-08 01:01:17 <gmaxwell> two obvious solutions are (1) don't pool for the fee, which is really fine for now— pool lets you just put in a seperate output for the fees, and you're effectively solo mining them. Pool only pools the subsidy.
 45 2014-03-08 01:01:20 <shadders_> So client will just have to generate CB itself... pool sends payout addresses... possibly auxblock and any other bits it needs
 46 2014-03-08 01:01:44 <gmaxwell> I think this has a lot of attractiveness for simplicity sake esp since fees are that substantal soloing them is fine.
 47 2014-03-08 01:01:45 <shadders_> I'm probably missing something...
 48 2014-03-08 01:02:32 <shadders_> Fees are still pretty insignificant yes?  i.e. not getting a fees unlikely to be a barrier to uptake?
 49 2014-03-08 01:02:47 <gmaxwell> who said anything about not getting any? they're just have high variance.
 50 2014-03-08 01:02:57 <gmaxwell> and I doubt it would bother anyone, they're like 1%.
 51 2014-03-08 01:03:26 <gmaxwell> other alternative is that you do what you're saying— but you have to worry about how to fairly share the fees between (1) people who don't process txns at all (2) people who do ... and depending on how you do solve that (3) people who exploit that solution and have an incentive to submit invalid blocks claiming lots of fees in order to get a greater share.
 52 2014-03-08 01:05:02 <gmaxwell> solving 1/2/3 there starts sounding like you might have to have them constantly submit the whole block unless you want to do something like weigh based on claimed fees, and periodically challenge miners to provide the whole block, and if they fail they forfeit their earnings.
 53 2014-03-08 01:05:18 <gmaxwell> which may well be fine, but probably not pooling fees is much easier to implement. :)
 54 2014-03-08 01:05:27 <gmaxwell> and probably good for a couple years.
 55 2014-03-08 01:06:01 <shadders_> most pools collect fees centrally then distribute now don't they?
 56 2014-03-08 01:06:53 <gmaxwell> yes, though as mentioned, they're like 1% and miners would still earn them. Many pools do a block finder bonus to discourage withholding ... so they'd just be your blockfinder bonus. :)
 57 2014-03-08 01:08:02 <TheBison> Can anyone link me to reading material on how to generate multiple-input unsigned transactions?
 58 2014-03-08 01:08:36 <gmaxwell> TheBison: call the createrawtransaction rpc in bitcoin-qt and give it multiple inputs?
 59 2014-03-08 01:10:14 <TheBison> gmxwell Thanks, I'll take a look at that. Will that work for generating a transaction if I don't have access to the private keys? So I could sign it later on a "cold storage" machine which does have access to the private keys?
 60 2014-03-08 01:11:21 <gmaxwell> yes.
 61 2014-03-08 01:11:25 <sipa> TheBison: yes, signing is done separately using signrawtransaction
 62 2014-03-08 01:11:49 <TheBison> Great, definitely going to play with that. Thanks!
 63 2014-03-08 01:14:44 <comboy> if there is a chain of transactions confirmed within one block, can I be sure they are in a poper order?
 64 2014-03-08 01:16:22 <sipa> yes
 65 2014-03-08 01:16:43 <comboy> thanks
 66 2014-03-08 01:17:06 <shadders_> merged mining still centralized under that model... But that's a whole can of worms wriggling around in the too hard basket.
 67 2014-03-08 01:18:50 <gmaxwell> shadders_: hm? no need for it to be— since you've allowed the coinbase to be malleable you could just choose. e.g. to take a centeralized merge or solo mine your merge... or do recursive coinbase only mining for it.
 68 2014-03-08 01:20:36 <shadders_> ahh true...I was still thinking about the pool generating the CB.  The pool would have to send it's payout addresses for the aux chains as well... I think that can be bolted on afterwards though...
 69 2014-03-08 01:22:25 <shadders_> I suppose in theory you could mine the aux chains with a completely different pool.  If the btc pool would allow it.
 70 2014-03-08 01:22:43 <gmaxwell> sure.
 71 2014-03-08 01:24:34 <shadders_> I'm thinking client side this could be implemented with a drop in replacement for stratum proxy.  Trying to work out the best approach to simplify implementation for pools.  Whether to build a seperate validation agent that the pool can run until it gets a native implementation.  Still mulling over what's need needed poolside
 72 2014-03-08 01:25:31 <shadders_> ease of transition is the key I think.  There's only a 'feelgood' motive for the miners to migrate so it has to be a low cost proposition
 73 2014-03-08 01:26:11 <gmaxwell> ideally it could be setup as proxies, indeed.
 74 2014-03-08 01:26:32 <gmaxwell> both because a pool would want to offer it in parallel, and also because people don't know how to replace the firmware on their hardware :(
 75 2014-03-08 01:26:55 <gmaxwell> also cgminer is almost certian to refuse to implement this... so it would only be native in bfgminer.
 76 2014-03-08 01:27:21 <shadders_> lol... some things haven't changed :)
 77 2014-03-08 01:28:01 <shadders_> Any clues as to why Con won't like it?
 78 2014-03-08 02:01:34 <shadders_> https://en.bitcoin.it/wiki/Getblocktemplate#History cute little rewrite of history there ;_)
 79 2014-03-08 03:36:21 <Luke-Jr> gmaxwell: you forgot 4) people who include transactiosn with fees that are not cost-efficient to the network/pool (similar to 3)
 80 2014-03-08 03:37:58 <Luke-Jr> shadders_: because COn is a troll and motivated by $$
 81 2014-03-08 03:38:40 <Luke-Jr> shadders_: no rewrite of history, that's what actually happened
 82 2014-03-08 03:39:09 <shadders_> https://bitcointalk.org/index.php?topic=61731.0
 83 2014-03-08 03:39:16 <shadders_> https://bitcointalk.org/index.php?topic=51226.20
 84 2014-03-08 03:39:39 <Luke-Jr> point?
 85 2014-03-08 03:39:57 <shadders_> psj wm was released 3 months before
 86 2014-03-08 03:40:05 <Luke-Jr> try checking commit dates
 87 2014-03-08 03:40:48 <Luke-Jr> Eloipool was 2011 Oct 4
 88 2014-03-08 03:42:08 <Luke-Jr> shadders_: actually, aren't you the guy who wrote PSJ? surely you should have known that :P
 89 2014-03-08 03:44:05 <shadders_> I know when you built... discussed it with you extensively at the time... Just thought it was a cute way to frame it.
 90 2014-03-08 03:45:04 <Luke-Jr> shadders_: not sure what you're disputing then? XD
 91 2014-03-08 03:48:21 <Luke-Jr> shadders_: anyhow, client side easiest solution is probably extending libblkmaker
 92 2014-03-08 03:48:31 <Luke-Jr> lachesis already started on that, too
 93 2014-03-08 03:48:40 <Luke-Jr> lechuga_ I mena
 94 2014-03-08 03:48:41 <Luke-Jr> mean*
 95 2014-03-08 03:49:02 <shadders_> what does libbklmaker do?
 96 2014-03-08 03:49:21 <Luke-Jr> makes block headers from GBT data
 97 2014-03-08 03:49:35 <Luke-Jr> specifically designed to be extended to this use case
 98 2014-03-08 03:50:13 <Luke-Jr> I have a branch in git that can generate stratum-like data too
 99 2014-03-08 03:50:40 <Luke-Jr> so making a proxy with it should be pretty straightforward
100 2014-03-08 03:51:02 <Luke-Jr> (BFGMiner does support behaving as such a proxy already, but I can see why a standalone one would be nice)
101 2014-03-08 03:51:02 <shadders_> well that's no fun... I was looking forward to listening to all the whinging about java again
102 2014-03-08 03:51:11 <Luke-Jr> lol
103 2014-03-08 03:51:36 <Luke-Jr> I'm sure DrHaribo would love a Java port! :P
104 2014-03-08 03:52:59 <Luke-Jr> shadders_: there's also python-blkmaker which is essentially libblkmaker pythonised.
105 2014-03-08 03:53:38 <Luke-Jr> (though nobody uses it, so it may not be up to date)
106 2014-03-08 03:54:31 <shadders_> Most of the necessary already exists in PSJ.  Just need to seperate the relevant parts make a validator
107 2014-03-08 03:54:39 <shadders_> necessary code*
108 2014-03-08 03:54:46 <shadders_> and of course implement stratum
109 2014-03-08 03:55:42 <Luke-Jr> stratum doesn't do this :p
110 2014-03-08 03:56:06 <Luke-Jr> or you mean for the client end?
111 2014-03-08 03:56:18 <shadders_> to build a proxy
112 2014-03-08 03:56:22 <Luke-Jr> hm
113 2014-03-08 03:56:53 <Luke-Jr> the upstream end is the harder part IMO
114 2014-03-08 03:57:12 <Luke-Jr> I made an Eloipool branch to "loop back" a while ago, but there were a lot of angles I didn't finish
115 2014-03-08 03:58:11 <shadders_> yes... musing over that now... wether a server end proxy could subsume some of the functions and limit the changes required in the server code so pools can transition gradually
116 2014-03-08 03:59:10 <Luke-Jr> there's a lot of growing interest in this kind of thing. someone else to my surprise brought it up at the Future of Mining panel yesterday before I did!
117 2014-03-08 04:00:35 <Luke-Jr> (or was that you? lol)
118 2014-03-08 04:00:44 <embicoin> http://www.coindesk.com/gavin-andresen-bitcoin-companies-support-open-source/
119 2014-03-08 04:01:02 <embicoin> Tell this to blockchain.info who is bitcoin fundation member..
120 2014-03-08 04:01:06 <shadders_> nope if you're talking about the thing in germany I'm on the wrong side of the planet
121 2014-03-08 04:05:41 <Luke-Jr> shadders_: nah, it was in Texas :p
122 2014-03-08 04:06:06 <Luke-Jr> videos on https://vimeo.com/ondemand/texasbitcoinconference
123 2014-03-08 04:07:47 <shadders_> still on the wrong side of the world
124 2014-03-08 04:09:00 <Luke-Jr> hmm, I wonder if they didn't video all of them :x
125 2014-03-08 04:09:08 <skinnkavaj> Help me, thinking feedback of a security feature for an exchange. People lose things and forget codes right?
126 2014-03-08 04:09:16 <skinnkavaj> After you setup Gauth for the first time.
127 2014-03-08 04:09:17 <skinnkavaj> If you choose not, please buy a second mobile device you can set this up on before you continue.
128 2014-03-08 04:09:17 <skinnkavaj> "Please write down your Google Authenticator code: <insert gauthcode>
129 2014-03-08 04:09:17 <skinnkavaj> You can (blue button=leave this page) and setup Google Authenticator another time."
130 2014-03-08 04:09:17 <skinnkavaj> You should be redirected to another page that say:
131 2014-03-08 04:09:40 <Luke-Jr> skinnkavaj: Google = lolwhatsecurity?
132 2014-03-08 04:09:53 <skinnkavaj> Luke-Jr: For the end user
133 2014-03-08 04:10:03 <skinnkavaj> People lose passwords, devices
134 2014-03-08 04:10:05 <skinnkavaj> Whatever.
135 2014-03-08 04:13:33 <LarsLarsen> Google has thrown a lot of money at the problem of authenticating people.  Its way better to use their solution than to re-invent the wheel.
136 2014-03-08 04:14:25 <Luke-Jr> LarsLarsen: trusting a centralised entity is a bad idea, especially Google
137 2014-03-08 04:16:13 <skinnkavaj> "Or you can continue right now, write down this code, and hereby agree that if you lose this code you lose control of your account and everything deposited."
138 2014-03-08 04:16:38 <skinnkavaj> I am forcing the end-user to write down a code, so he learns it.
139 2014-03-08 04:16:47 <skinnkavaj> To be able to setup Gauth later.
140 2014-03-08 04:17:04 <skinnkavaj> If his device is lost.
141 2014-03-08 04:17:24 <LarsLarsen> luke: it would be awesome if we could easily implement 2 factor auth ourselves for free without google.
142 2014-03-08 04:17:40 <LarsLarsen> luke: but that is beyond most people's means
143 2014-03-08 04:17:52 <skinnkavaj> I have had pin numbers on my site, written 3 BIG WARNINGS on 3 DIFFERENT pages, that if you lose your PIN there is no recover. Yet people ask me how to recover it.
144 2014-03-08 04:18:09 <skinnkavaj> I guess it's just human to forget, and lose things..
145 2014-03-08 04:18:20 <LarsLarsen> skinnkavaj: people come in here asking for help recovering their wallet passwords.  It will ALWAYS happen.
146 2014-03-08 04:18:56 <skinnkavaj> So that's why I am encouraging the end-user to write down this Gauth code.
147 2014-03-08 04:19:45 <arubi> just wanna say, gauth is not phoning home anything to google
148 2014-03-08 04:20:01 <skinnkavaj> Btc-e have a system where the account is locked for two weeks on on Gauth lost, there was reddit thread about it long time ago that someone confused that as well.
149 2014-03-08 04:20:04 <LarsLarsen> skinnkavaj: yes,  post it notes would have saved a lot of grief if they were used universally :)
150 2014-03-08 04:20:10 <skinnkavaj> So to have no recover for Gauth code sounds best for me.
151 2014-03-08 04:20:21 <LarsLarsen> arubi: yes its just a one time pad
152 2014-03-08 04:21:35 <arubi> LarsLarsen, yea I thought somehow you meant that it was not only client sided. sorry
153 2014-03-08 04:23:20 <LarsLarsen> Authenticator is a great system.... combined with a printout of backup keys,  they really can provide security without having to identify a person,  just the account itself
154 2014-03-08 04:24:39 <arubi> I agree. Also, people should start working more with password managers like keepass. That'll solve a
155 2014-03-08 04:24:45 <arubi> a lot of problems
156 2014-03-08 04:25:02 <LarsLarsen> Yeah,  but you just move the problem to one easy to remember passphrase to unlock EVERYTHING
157 2014-03-08 04:25:49 <arubi> it can be used with a 2048 key
158 2014-03-08 04:25:56 <arubi> 2048bit i mean
159 2014-03-08 04:26:02 <LarsLarsen> The system of one time pads as backup passwords is great,  google didnt arrive at it because it wasn't the best solution :)
160 2014-03-08 04:26:30 <arubi> It is great, but you still need passwords
161 2014-03-08 04:26:41 <LarsLarsen> well thats only if you need accounts that need to be authenticated
162 2014-03-08 04:26:53 <LarsLarsen> I mean,  bitcoin needs passwords.  Keys are just long hard to type passwords.
163 2014-03-08 04:27:20 <arubi> they're also technically non crackable with brute force, unlike passwords
164 2014-03-08 04:27:32 <LarsLarsen> you can think of a password then as a very short key
165 2014-03-08 04:27:51 <arubi> exactly, that's why you need both
166 2014-03-08 04:28:08 <LarsLarsen> length doesn't matter,  unless its random.  I can have a 1GB key with almost zero information content,  and I can cram a lot of information into 16 bytes.  :)
167 2014-03-08 04:29:01 <arubi> I don't understand what you mean. The entire length of the key matters if the message is somehow manipulated by it
168 2014-03-08 04:29:21 <arubi> even if it's all zeros
169 2014-03-08 04:30:08 <LarsLarsen> Yes but if it doesn't contain a lot of information,  its not hard to find.  I.e. a 1GB key of english words in random order is easier to find than a truely random 1gb key
170 2014-03-08 04:30:13 <LarsLarsen> its a smaller search space
171 2014-03-08 04:31:16 <LarsLarsen> So,  randomly generated passwords are harder to crack than comparatively longer human readable passphrases.
172 2014-03-08 04:31:18 <arubi> with keys the search space is pre defined to be the length. with passwords, it's usually printable characters, up to what.. 30 chars length?
173 2014-03-08 04:32:13 <LarsLarsen> arubi: yes,  you get 256^keylength instead of like 60^keylength permutations... I am with you there...
174 2014-03-08 04:32:15 <Luke-Jr> LarsLarsen: if someone is running something that needs 2FA, they should be able to afford it
175 2014-03-08 04:32:39 <arubi> Luke-Jr, it is free
176 2014-03-08 04:32:40 <Luke-Jr> "for free" is for non-important things
177 2014-03-08 04:32:51 <arubi> Ah ;)
178 2014-03-08 04:33:17 <Luke-Jr> ie, cases where a simple password is fine
179 2014-03-08 04:33:19 <LarsLarsen> luke: I don't see the downside to using google authenticator,  compared to all the other things google provides us,  I think the risk/benefit ratio is one of the most in our favor
180 2014-03-08 04:33:38 <Luke-Jr> LarsLarsen: Google can hijack anyone's account..
181 2014-03-08 04:34:02 <arubi> Luke-Jr, authenticator does not phone back to your google account
182 2014-03-08 04:34:16 <Luke-Jr> no?
183 2014-03-08 04:34:18 <LarsLarsen> luke: only because they trust their authenticator system implicitly and can ignore it.
184 2014-03-08 04:34:20 <arubi> the secret is only on the 2nd factor device
185 2014-03-08 04:34:32 <venzen> Google have shown themselves to be unethical on numerous occasions
186 2014-03-08 04:34:37 <Luke-Jr> is this not the system where it prompts a Google website to confirm the login?
187 2014-03-08 04:35:13 <arubi> Luke-Jr, no authenticator is time based 2fa
188 2014-03-08 04:35:27 <Luke-Jr> …
189 2014-03-08 04:36:13 <arubi> venzen, the code is open : http://code.google.com/p/google-authenticator/source/checkout
190 2014-03-08 04:36:47 <venzen> arubi: sure - but the company that implements it is dishonest and yields to highest bidder
191 2014-03-08 04:37:33 <venzen> perhaps such open code can be implemented away from Google?
192 2014-03-08 04:37:35 <arubi> venzen, if it's so much of a problem to use them, there are python libs that do exactly that
193 2014-03-08 04:37:40 <LarsLarsen> "The service provider generates an 80-bit secret key for each user. This is provided as a 16 character base32 string or as a QR code. The client creates an HMAC-SHA1 using this secret key. The message that is HMAC-ed can be:  the number of 30 second periods having elapsed since the Unix epoch; or the counter that is incremented with each new code.  A portion of the HMAC is extracted and converted to a 6 digit code."  -- wikipedia
194 2014-03-08 04:38:27 <arubi> you don't even need to be online to use it, since it's always synced
195 2014-03-08 04:38:36 <arubi> the 2nd factor device i mean
196 2014-03-08 04:39:51 <LarsLarsen> The second factor device can also just be the 80 bit secret key (google issues you several,  and they're one-time-use backups in case you loose the auth device)
197 2014-03-08 04:40:18 <LarsLarsen> so you can use it off paper if there is an EMP
198 2014-03-08 04:40:20 <LarsLarsen> :)
199 2014-03-08 04:40:30 <arubi> keep a photo of the original secret offline, problem solved.
200 2014-03-08 04:41:00 <venzen> so anyone can offer 2fa using the open code, but it's just a case of people opting for a "trusted" name -> Google?
201 2014-03-08 04:41:37 <LarsLarsen> venzen: I dont know how the third party thing works,  but from what I can tell you just input a key into their app,  and google doesn't know a damn thing.
202 2014-03-08 04:41:45 <arubi> anyone can offer 2fa with any method, and you can use their 2fa with any other method
203 2014-03-08 04:42:17 <arubi> it's easier to use google's app because really, it's more trusted
204 2014-03-08 04:42:58 <venzen> great, so this project could offer 2fa - because Google (while not knowing the secret) tracks usage - where, when, possibly who...
205 2014-03-08 04:43:44 <LarsLarsen> How could google track usage?
206 2014-03-08 04:43:59 <LarsLarsen> So,  you put a key into authenticator,  and it spits out 6 digit numbers every few seconds forever
207 2014-03-08 04:44:15 <LarsLarsen> all google could know,  is if you run the app,  it could phone home and say "he's looking at the numbers!"
208 2014-03-08 04:44:19 <arubi> yep, there is no usage
209 2014-03-08 04:44:29 <LarsLarsen> it shows you all numbers for all accounts you have set up with it at once
210 2014-03-08 04:44:37 <LarsLarsen> so google doesn't know what you're logging into,  or if you're logging into anything at all
211 2014-03-08 04:44:41 <arubi> it's just refreshing every few seconds, all keys all the time
212 2014-03-08 04:44:55 <venzen> LarsLarsen: who knows? Through the app on the smartphone? Anyhow, we know that usgae tracking is their primary motivation
213 2014-03-08 04:45:18 <LarsLarsen> The only thing they know is that you ran google authenticator and its showing you 4 different keys
214 2014-03-08 04:45:25 <LarsLarsen> or however many its showing
215 2014-03-08 04:45:36 <Luke-Jr> this must be different from what I am thinking of
216 2014-03-08 04:45:38 <venzen> don't trust them
217 2014-03-08 04:45:42 <arubi> they don't know anythin LarsLarsen
218 2014-03-08 04:45:50 <Luke-Jr> websites where you click Login and it gives you a Google page to login with
219 2014-03-08 04:46:12 <arubi> Luke-Jr, that's "sign it with google account"
220 2014-03-08 04:46:22 <arubi> like "sign in with facebook"
221 2014-03-08 04:46:36 <LarsLarsen> Well,  I think the fact they read all my email and my search queries is more troubling than the fact that they know I use two factor auth on coinbase
222 2014-03-08 04:46:43 <Luke-Jr> so "Google Authenticator" is just software?
223 2014-03-08 04:47:01 <arubi> yea, and it's only on the user's side
224 2014-03-08 04:47:04 <LarsLarsen> yes,  its an app
225 2014-03-08 04:47:17 <LarsLarsen> http://en.wikipedia.org/wiki/Google_Authenticator
226 2014-03-08 04:47:21 <LarsLarsen> its free
227 2014-03-08 04:47:25 <Luke-Jr> oh, so it assumes you trust Google enough to run Android..
228 2014-03-08 04:47:47 <arubi> pretty much, but there are python libs that do 2fa exactly the same
229 2014-03-08 04:47:57 <LarsLarsen> well yes,  that is a flaw.... I wish they'd sell us hardware authenticators
230 2014-03-08 04:48:07 <LarsLarsen> :)  Then we could REALLY trust them
231 2014-03-08 04:48:13 <Luke-Jr> i c
232 2014-03-08 04:48:15 <arubi> I have an old offline android phone with google auth, it works perfectly
233 2014-03-08 04:49:09 <LarsLarsen> yeah offline phone is a good call,  why pay money if you dont have to?  It should still work with the QR codes
234 2014-03-08 04:49:57 <arubi> that's what it does
235 2014-03-08 04:50:16 <LarsLarsen> damn,  I think I should cancel my phone,  its all I really use the damn thing for,  lol
236 2014-03-08 04:50:48 <arubi> true :)
237 2014-03-08 04:54:50 <LarsLarsen> oh,  there is an ios version,  and its open source,  so.... yay :)
238 2014-03-08 05:16:59 <jcorgan> more bc.i weirdness.  some transactions showing in "address" view as unconfirmed, but clicking on them shows them with 21 confirmations
239 2014-03-08 05:17:35 <jcorgan> look at incoming txes live for the DN donation address 1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX
240 2014-03-08 05:18:16 <jcorgan> hmm, txes listed for that address that have 1 confirmation in list view show up with 22 confirmations when viewed individually
241 2014-03-08 05:18:29 <jcorgan> so someone has an off-by-20 error :)
242 2014-03-08 05:18:44 <jcorgan> of off-by-21
243 2014-03-08 05:19:39 <Graet> ;;tslb
244 2014-03-08 05:19:41 <gribble> Time since last block: 26 minutes and 50 seconds
245 2014-03-08 05:23:46 <jcorgan> of course now it is magically fixed
246 2014-03-08 06:15:18 <dexX7_> blocks 289100, 288294 are missing txs on blockchain.info, happend the days before too
247 2014-03-08 06:33:13 <jcorgan> someone needs to run fsck.btc
248 2014-03-08 06:39:11 <dexX7_> btc is fine, it's rather blockchain.info that needs to fix their issue. they do this actually, but appearingly there appear new faulty blocks from time to time
249 2014-03-08 06:41:15 <jcorgan> of course i know this is bc.i's database that has the problem
250 2014-03-08 06:41:34 <jcorgan> and it is apparently more than just blocks arriving with missing txes
251 2014-03-08 06:43:18 <dexX7_> what more?
252 2014-03-08 06:43:45 <arubi> do you think that the software that does the transactions rely on blockchain.info's own database, or the actuall blockchain?
253 2014-03-08 06:43:56 <arubi> the software on bc.i that is
254 2014-03-08 06:44:44 <dexX7_> i don't understand the question
255 2014-03-08 06:45:36 <arubi> users can send funds to each other on bc.i right?
256 2014-03-08 06:46:16 <dexX7_> ah
257 2014-03-08 06:46:26 <arubi> do you think they have their own database, with errors to manage those, or do they actually use the network
258 2014-03-08 06:46:27 <arubi> yea
259 2014-03-08 06:49:54 <dexX7_> i can't think of a case where this could be abused
260 2014-03-08 06:50:22 <dexX7_> bci always had less tx in the case of a missmatch, so it's rather the case that some coins are not yet spendable @bci, even if they'd use their own db
261 2014-03-08 06:51:54 <arubi> yea, that makes sense.
262 2014-03-08 06:53:40 <jcorgan> sure, just that when their display of number of confirmations for a given tx is different depending on what screen of theirs you look at, it tells you there is inconsistancy in their db somewhere
263 2014-03-08 06:56:23 <jcorgan> i had always trusted bc.i for small amounts of btc as a "hot wallet" for spending via their phone app, but now i don't trust their back-end database after seeing these oddnesses popping up the last few days
264 2014-03-08 06:58:50 <dexX7_> yea agreed. that doesn't supply confidence
265 2014-03-08 06:59:10 <arubi> https://blockchain.info/rawblock/000000000000000049cc5d6ab637b8e0ec8bf07cfe1be201f1b6660547d1237f
266 2014-03-08 06:59:10 <arubi> this is block 289100 :
267 2014-03-08 06:59:25 <arubi> "block_index":472613,
268 2014-03-08 06:59:33 <arubi> I don't get it..?
269 2014-03-08 07:00:18 <dexX7_> block index is the position within the block file, has nothing to do with the height (which is 289100)
270 2014-03-08 07:00:33 <jcorgan> arubi: they keep track of all the side chains and orphan blocks they see broadcasted, so 'block_index' is probably a id field for all of those
271 2014-03-08 07:00:38 <arubi> oh that's why the previous block has the same #
272 2014-03-08 07:01:08 <arubi> how did I miss height right below it :D?
273 2014-03-08 07:01:17 <dexX7_> huh? "hash":"000000000000000049cc5d6ab637b8e0ec8bf07cfe1be201f1b6660547d1237f", "prev_block":"000000000000000072a03d13245710a6df16bcc6d251870d8b6eb95ed396f2d4" - not similar
274 2014-03-08 07:01:22 <dexX7_> xD
275 2014-03-08 07:01:38 <dexX7_> but this block misses transactions. the real chain has 987 and bci only 935
276 2014-03-08 07:04:27 <arubi> dexX7_, I actually get 986 on my chain (but let me double check)
277 2014-03-08 07:04:43 <arubi> whoops nope 987
278 2014-03-08 07:05:10 <dexX7_> hehe
279 2014-03-08 07:05:20 <dexX7_> there is a nice alternative: www.blockr.io
280 2014-03-08 07:05:56 <arubi> yea I like their interface better. the colors are not so white
281 2014-03-08 07:09:02 <16WAA1NNQ> Hi Guyz
282 2014-03-08 07:09:39 <16WAA1NNQ> reading up on the bitcoin source. What is the CDBEnv class used for ?
283 2014-03-08 07:12:16 <jcorgan> so, i'm looking at a histogram i generated of the number of transactions per block over the entire blockchain
284 2014-03-08 07:12:29 <jcorgan> http://imgur.com/UVhgWDh
285 2014-03-08 07:13:08 <jcorgan> there is a to-be-expected decay as the numbers get larger
286 2014-03-08 07:13:44 <jcorgan> but a very interesting set of "spikes" that correspond to blocks with 32, 64, 128, 256, 512, and 1024 transactions per block
287 2014-03-08 07:13:53 <jcorgan> and one at 12
288 2014-03-08 07:14:22 <jcorgan> very curious where these spikes come from
289 2014-03-08 07:14:35 <arubi> pool software generating blocks?
290 2014-03-08 07:16:34 <jcorgan> btw, it is zoomed in; the right side goes out to 3861 transactions, and on the left it starts at 4 as the height for 1-3 would be too high
291 2014-03-08 07:17:21 <arubi> and if zoomed out, is there a spike between 1 and 3?
292 2014-03-08 07:17:31 <arubi> i guess there's no way to tell actually..
293 2014-03-08 07:17:59 <arubi> maybe the first powers of 2 also have this pattern
294 2014-03-08 07:18:18 <jcorgan> no, it is highest at 1, then decreases monotonically to 7, where you see it go back up to the first visible maxima at 12
295 2014-03-08 07:18:55 <jcorgan> but 30% of the blocks in the blockchain are coinbase only
296 2014-03-08 07:20:11 <jcorgan> then the maxima are the powers of 2 from 32-1024, there isn't an effect at higher powers of 2 though
297 2014-03-08 07:21:50 <arubi> I'm thinking one of the older pool's software maybe be signing blocks with a higher bound on number of txes
298 2014-03-08 07:24:46 <jcorgan> i guess the core-devs all actually have lives are aren't here in IRC discussing statistical aspects of cryptocurrency on a Friday night.
299 2014-03-08 07:25:23 <arubi> sat. morning ;)
300 2014-03-08 07:30:41 <fanquake> sat. afternoon ;)
301 2014-03-08 07:41:18 <aynstein> jcorgan: or they r in barbados
302 2014-03-08 07:41:23 <aynstein> :)
303 2014-03-08 09:18:31 <Engendrure> Hi, I have a question about the rpc interface.. Is it correct, when I do not get a return for a gettxout call, that the output is spent?
304 2014-03-08 09:19:10 <gmaxwell> that it doesn't exist in your current chainstate.
305 2014-03-08 09:19:17 <gmaxwell> maybe it was spent, maybe it never existed.
306 2014-03-08 09:21:10 <Engendrure> Is there a better way to check if an output was spent?
307 2014-03-08 09:38:25 <ebfull> watchonly wallets are enabled on the trunk out of the box right?
308 2014-03-08 09:38:44 <gmaxwell> no.
309 2014-03-08 10:37:45 <wumpus> no, that pull (#3383) still needs some work before it can be merged
310 2014-03-08 10:40:47 <wumpus> @wangbus on github was interested in picking it up, no idea whether he started working on it or how much progress he's made
311 2014-03-08 11:18:09 <dexX7_> wangbus. the guy who renews bitcointalk?
312 2014-03-08 11:48:58 <SomeoneWeird> dexX7_, renews?
313 2014-03-08 11:50:14 <dexX7_> https://bitcointalk.org/index.php?topic=451893.0
314 2014-03-08 12:02:45 <SomeoneWeird> dexX7_, interesting
315 2014-03-08 12:35:21 <vegard> wow, I'm such a noob. I am starting bitcoind with -datadir=foobar without an existing block database and it gives me ": Error opening block database. Do you want to rebuild the block database now?"
316 2014-03-08 12:35:38 <vegard> what do I need to do to initialise the block database?
317 2014-03-08 12:41:05 <vegard> ah... got an IO error, that's why it's not working.
318 2014-03-08 13:12:41 <dexX7_> vegard: you need to define a valid path.. is "foobar" one?
319 2014-03-08 13:18:39 <vegard> yeah. the problem is the filesystem doesn't support fsync() so leveldb syncing was failing
320 2014-03-08 13:39:17 <Luke-Jr> vegard: yeah, I think if the fs doesn't support fsync, failing might be the appropriate thing to do..
321 2014-03-08 14:22:52 <Goonie> Can someone help me with a possible malleability issue?
322 2014-03-08 14:31:59 <andytoshi> Goonie: probably, better to just ask (bearing in mind that this channel is focused on bitcoind and bitcoin-qt)
323 2014-03-08 14:33:07 <coinz4me> Uhh someone mind unbanning me from #bitcoin?  In all honesty I was in fact only making a joke.
324 2014-03-08 14:33:32 <coinz4me> Kick I can understand, but a ban without warning?  Seriously?
325 2014-03-08 14:37:18 <Joric> http://pit.dirty.ru/lepro/2/2014/03/08/174332-2dc7dd31314da31c51add0c014b1f371.jpg
326 2014-03-08 14:55:03 <Goonie> Ok I have two transactions that seem to be equal in all aspects, yet have a different tx hash.
327 2014-03-08 14:56:07 <Goonie> See my last comment on http://code.google.com/p/bitcoinj/issues/detail?id=533
328 2014-03-08 15:54:48 <jaakkos> did someone ever consider optional chargeback mechanism for bitcoin?
329 2014-03-08 15:55:16 <jaakkos> you could specify in output script that the tx redeeming this output can be chargebacked with the private key
330 2014-03-08 15:55:29 <jaakkos> until some time has expired
331 2014-03-08 15:56:03 <jaakkos> well that has a huge problem though
332 2014-03-08 15:56:05 <Luke-Jr> jaakkos: already exists
333 2014-03-08 15:56:11 <Luke-Jr> nLockTime
334 2014-03-08 15:56:23 <jaakkos> if the attacker gets the key, they can stop the original owner from moving them...
335 2014-03-08 16:08:32 <jaakkos> Luke-Jr: but you can't specify that an output has to be redeemed by a timelocked transaction?
336 2014-03-08 16:08:57 <jaakkos> that might not make sense on its own without some other additions
337 2014-03-08 16:11:42 <jaakkos> what if you could say that an output can be redeemed with key A iff there is proper timelock too, or with key B without timelock. the key B would be kept very, very safe, while A could be more exposed.
338 2014-03-08 16:12:58 <jaakkos> is it possible to write such script already?
339 2014-03-08 16:20:21 <gmaxwell> jaakkos: you're over complicating things, or else not being clear about what you were trying to achieve.
340 2014-03-08 16:20:49 <gmaxwell> If you want to pay someone in a way that you can revoke before a timeout, you simply hand them an nlockedtime transaction and if you want to abort you spend it out from under them.
341 2014-03-08 16:21:29 <gmaxwell> If you want a system where you can't defraud someone by improperly reversing, you use a multisignature transaction (e.g. http://bitrated.com/ )
342 2014-03-08 16:21:46 <Goonie> Can anyone give me a hint why these two transactions could have a different tx hash? http://code.google.com/p/bitcoinj/issues/detail?id=533 (last comment)
343 2014-03-08 16:22:37 <Goonie> I compared all the fields you see. nLockTime is not set afaik.
344 2014-03-08 16:25:12 <gmaxwell> Goonie: I couldn't tell you without the actual transaction data.
345 2014-03-08 16:27:01 <Goonie> gmaxwell: Unfortunately I do not have that for the wallet dump. How can it be different? It should consist of exactly the values you see there, plus a version (=1) and the nLockTime field (should be 0 for both).
346 2014-03-08 16:27:14 <Goonie> gmaxwell: Is there any "hidden data"?
347 2014-03-08 16:30:23 <gmaxwell> the data you've shown there is absolutely identical except for the txid and the formatting. You're not displaying anything about the serialization.
348 2014-03-08 16:30:35 <gmaxwell> or the sequence number.
349 2014-03-08 16:31:47 <gmaxwell> e.g. I can't tell what kind of push opcodes are used on the two pushes in the signature there.
350 2014-03-08 16:33:47 <vegard> wow you did a great job making the blockchain download faster.
351 2014-03-08 16:35:14 <Goonie> gmaxwell: Yes, that's what I was saying, it appears to be identical. So the push opcodes can be different? That's the kind of information I was searching for. Thanks.
352 2014-03-08 16:36:12 <Goonie> gmaxwell: But wait, the "push opcodes" should be in the scriptSig, right? That's identical as well.
353 2014-03-08 16:36:17 <Luke-Jr> Goonie: 0.9 and 0.8.7 will be limiting push opcodes as non-standardness, but until then yes
354 2014-03-08 16:36:29 <Luke-Jr> Goonie: you're only displaying pushes as […]
355 2014-03-08 16:36:48 <Luke-Jr> so, don't know if they are OP_PUSHDATA2 or OP_PUSHDATA4 etc
356 2014-03-08 16:37:34 <Goonie> Luke-Jr: Ok thanks I will investigate.
357 2014-03-08 16:39:28 <jaakkos> gmaxwell: i was thinking of a case where the private key gets compromised. the attacker would only be able to initiate a timelocked transaction. if the original owner notices this, he could cancel it with another private key, perhaps still kept secret.
358 2014-03-08 16:46:55 <jaakkos> gmaxwell: then you could have online service that may access the first key (A) that can only create timelocked transactions, but the more powerful key (B) would be kept secret
359 2014-03-08 16:47:20 <jaakkos> if they timelock is, say, an hour, the operators would have that much time to react to hacking
360 2014-03-08 16:48:23 <jaakkos> their customers would also experience an hour delay with withdraws.
361 2014-03-08 16:48:29 <paveljanik> jaakkos: but you have to count that these transaction can be "accountable" only after that time...
362 2014-03-08 16:48:30 <paveljanik> yes
363 2014-03-08 16:48:42 <jaakkos> but perhaps that wouldn't matter in some services like an exchnge.
364 2014-03-08 17:02:58 <Goonie> Luke-Jr: turns out bitcoinj doesn't keep the pushdata opcodes, it keeps just the data itself... http://code.google.com/p/bitcoinj/issues/detail?id=534
365 2014-03-08 17:04:28 <gmaxwell> hm. is that really true? how could the bitcoinj full node stuff validate the chain?  there are txn in the chain which are not in canonical form and if you researalize you'll break the signatures.
366 2014-03-08 17:05:18 <Goonie> gmaxwell: I think it also keeps the full byte array. But anyway, the full node code doesn't relay afaik.
367 2014-03-08 17:05:29 <Goonie> gmaxwell: And its still highly experimental.
368 2014-03-08 17:05:54 <gmaxwell> sure but if it were always reseralizing it couldn't validate... keeping the bytearray would do that.
369 2014-03-08 17:10:52 <Goonie> gmaxwell: How do you mean? It obviously cannot reserialize because if it doesn't keep the PUSHDATA opcodes.
370 2014-03-08 17:11:38 <Goonie> gmaxwell: In the case of pending tx that are relevant to an attached wallet, it just relays the blob of the tx.
371 2014-03-08 17:29:35 <Emcy> fsdfsdf
372 2014-03-08 18:49:01 <Wustenfuchs> Is it possible to create transactions that harness nLockTime using the original client at the moment?
373 2014-03-08 18:49:16 <Luke-Jr> no
374 2014-03-08 18:49:18 <sipa> using createrawtransaction, i believe so
375 2014-03-08 18:49:25 <Luke-Jr> that counts? heh
376 2014-03-08 18:50:11 <Wustenfuchs> sipa: interesting, have you seen any examples around (before I spend several days figuring it out)
377 2014-03-08 18:50:18 <sipa> no
378 2014-03-08 18:51:04 <Wustenfuchs> I've been mislead a bit by certain forum posts, but my impression is the transactions that have nLockTime are not minable until after that time?
379 2014-03-08 18:51:36 <sipa> correct
380 2014-03-08 18:52:51 <Wustenfuchs> And current implementations respect replaceability? (Aka, higher sequence numbers will replace lower transactions?)
381 2014-03-08 18:53:14 <sipa> no
382 2014-03-08 18:54:47 <Wustenfuchs> sipa: Ok, so at this time there is no way to timelock and securely throw around a tx (updating, re-signing) without the risk of a previous tx being broadcast and becoming final?
383 2014-03-08 18:55:09 <sipa> that risk always exists
384 2014-03-08 18:55:13 <sipa> even with replacement
385 2014-03-08 18:55:18 <sipa> replacement is just a policy
386 2014-03-08 18:55:21 <sipa> it is not enforceable
387 2014-03-08 18:55:58 <Wustenfuchs> sipa: true, because it is the miners choice which tx is the latest 'seen' right?
388 2014-03-08 18:56:19 <sipa> indeed
389 2014-03-08 18:56:29 <sipa> or rather, it is the miners choice which they like most
390 2014-03-08 18:59:15 <Wustenfuchs> sipa: so I guess there is no solid way to do a dead man switch at this time?
391 2014-03-08 18:59:40 <Luke-Jr> Wustenfuchs: why not?
392 2014-03-08 18:59:59 <Wustenfuchs> Luke-Jr: without giving others the ability to broadcast before you're dead, that is
393 2014-03-08 19:01:02 <Luke-Jr> Wustenfuchs: just give them a nLockTime'd transaction..
394 2014-03-08 19:01:50 <Wustenfuchs> Luke-Jr: but they could broadcast that even when your not dead?
395 2014-03-08 19:01:58 <Luke-Jr> not until the time passes
396 2014-03-08 19:02:08 <Wustenfuchs> Right, but what if your not dead after the time passes.
397 2014-03-08 19:02:16 <Luke-Jr> then you spend it first
398 2014-03-08 19:02:35 <Wustenfuchs> Right, it would require a continual movement... i guess that works
399 2014-03-08 19:02:43 <sipa> heh?
400 2014-03-08 19:02:53 <Luke-Jr> or just have your server only publish the transaction if you don't tell it you're alive
401 2014-03-08 19:04:38 <Wustenfuchs> Luke-Jr: at which point you don't really need nLockTime :P
402 2014-03-08 19:05:04 <Wustenfuchs> And its not verifiable by others until after you're dead
403 2014-03-08 19:05:43 <vegard> gmaxwell suggested a service that stores your time locked transactions until they can be mined
404 2014-03-08 19:06:03 <Luke-Jr> Wustenfuchs: I don't think there are any better solutions..
405 2014-03-08 19:06:26 <Wustenfuchs> Luke-Jr: most likely, just curious as to what was possible. Thanks :)
406 2014-03-08 19:08:01 <Wustenfuchs> vegard: I wonder if a P2P like service combined with some form of multi sig would be possible
407 2014-03-08 19:08:50 <Wustenfuchs> vegard: would probably need a blockchain of its own etc... probably not worth it
408 2014-03-08 19:13:46 <vegard> or you could just drop it in a public git repository
409 2014-03-08 19:19:42 <dexX7_> can someone tell me how i can redeem https://blockchain.info/tx/dda13a68c445f7022498c86edcc2291719e7435e86a72dc776c5ec5f510903a8? the hash = sha256(sha256(342038203135203136203233203432))
410 2014-03-08 19:20:37 <maaku> scriptSig = [342038203135203136203233203432]
411 2014-03-08 19:20:55 <maaku> not a very safe thing to do on mainnet
412 2014-03-08 19:21:25 <sipa> for $0.24 :)
413 2014-03-08 19:21:47 <Luke-Jr> yeah, not worth the trouble :p
414 2014-03-08 19:23:04 <dexX7_> 0100000001a80309515fecc576c72da7865e43e7191729c2dc6ec8982402f745c4683aa1dd000000000f342038203135203136203233203432ffffffff0130750000000000001976a914487747b3a9d3f7b68ab7f88f7115e91276bc851188ac00000000 is invalid
415 2014-03-08 19:24:16 <sipa> dexX7_: the scriptSig needs to be a push of the byte sequence 342038203135203136203233203432
416 2014-03-08 19:24:22 <sipa> not that bytesequence itself
417 2014-03-08 19:24:37 <maaku> dexX7_: what is 342038203135203136203233203432 -- a hex string? a number?
418 2014-03-08 19:24:45 <sipa> oh
419 2014-03-08 19:24:50 <dexX7_> "4 8 15 16 23 42" :D
420 2014-03-08 19:25:12 <sipa> ok, so you need to prepend it with a push opcode
421 2014-03-08 19:25:39 <dexX7_> i tried it with "0f"
422 2014-03-08 19:25:41 <sipa> 0F342038203135203136203233203432 should do
423 2014-03-08 19:26:46 <justanotheruser> In dexX7_' tx, why doesn't it include PUSH (hash)? It just puts it in the script and OP_HASH doesn't deal with the next item in the buffer, it deals with the stack.
424 2014-03-08 19:26:52 <dexX7_> rejected. 100f is rejected, too
425 2014-03-08 19:26:55 <maaku> shouldn't there also be a CompactSize for the length of the script too?
426 2014-03-08 19:27:51 <dexX7_> 100f at least shows a non faulty asm when decoding
427 2014-03-08 19:36:24 <Luke-Jr> 
ACTION wonders why such effort is being made to fix a non-issue, and notes it probably adds at least IBD overhead to delay things to constant-time…

428 2014-03-08 19:38:10 <sipa> Luke-Jr: which issue?
429 2014-03-08 19:38:13 <sipa> or non-issue?
430 2014-03-08 19:38:26 <Luke-Jr> sipa: the thing where you can get a private key from 300 signatures
431 2014-03-08 19:38:33 <sipa> that is about signing
432 2014-03-08 19:38:36 <Luke-Jr> Bitcoin only signs once per key
433 2014-03-08 19:38:39 <sipa> not verification
434 2014-03-08 19:38:45 <sipa> so it's irrelevant for IBD
435 2014-03-08 19:38:50 <Luke-Jr> ok, true
436 2014-03-08 19:39:05 <Luke-Jr> still, not an issue. is there another benefit to constant time?
437 2014-03-08 19:40:17 <sipa> i think it's unlikely an issue in many practical circumstances
438 2014-03-08 19:40:38 <sipa> still, preventing side-channel leaks (or at least hardening them) is good practice
439 2014-03-08 19:40:44 <Luke-Jr> i c
440 2014-03-08 19:41:18 <sipa> also, i believe libsecp256k1 doesn't suffer the weakness described in that paper (though may have others, obviously)
441 2014-03-08 19:43:20 <Luke-Jr> well, I certainly wouldn't think we need to blacklist OpenSSLs with this issue
442 2014-03-08 19:43:29 <Luke-Jr> especially now that we're actively discouraging address reuse
443 2014-03-08 19:56:47 <dexX7_> according to the debug log the tx won't be accepted due to the nonstandard input + "nonstandard transaction: scriptsig-not-pushonly", if pushed with 11 4c 0f
444 2014-03-08 19:57:33 <sipa> sure
445 2014-03-08 19:57:38 <sipa> bitcoind will not accept it
446 2014-03-08 19:57:55 <sipa> if you want it mined, you'll have to send it to a miner directly
447 2014-03-08 20:00:19 <dexX7_> too bad, not even eligius accepts it
448 2014-03-08 20:00:31 <sipa> wait, scriptsig-not-pushonly... that is wrong
449 2014-03-08 20:00:34 <sipa> it should be push only
450 2014-03-08 20:01:29 <dexX7_> i tried it with 10 0f hex and 11 4c 0f hex. the later results in the not-pushonly message
451 2014-03-08 20:03:52 <sipa> where does the 4c come from?
452 2014-03-08 20:04:43 <sipa> ah, pushdata1
453 2014-03-08 20:04:51 <dexX7_> i looked at the original puzzle
454 2014-03-08 20:04:53 <dexX7_> yup pushdata1
455 2014-03-08 20:05:03 <sipa> don't use that, it's not necessary
456 2014-03-08 20:05:10 <sipa> and recent bitcoin code doesn't allow it
457 2014-03-08 20:05:30 <dexX7_> ah i see
458 2014-03-08 20:06:05 <sipa> though it should not say not-push-only
459 2014-03-08 20:07:08 <dexX7_> that's in the log though :)
460 2014-03-08 20:07:37 <dexX7_> oh wait
461 2014-03-08 20:07:55 <dexX7_> nonstandard transaction: scriptsig-non-canonical-push << that's the one
462 2014-03-08 20:08:00 <dexX7_> sorry
463 2014-03-08 20:16:22 <saracen> will a node broadcast a block, when it itself, doesn't have the previous block the block references?
464 2014-03-08 20:17:29 <sipa> no