1 2014-01-15 00:04:01 <Sleepnbum> do amds new chips have any implications on btc?  http://venturebeat.com/2014/01/14/amd-launches-kaveri-processors-aimed-at-starting-a-computing-revolution/
  2 2014-01-15 00:21:12 <zone117x> if I submit a block to the network, whats the best way to detect if it has been accepted or orphaned?
  3 2014-01-15 00:21:21 <zone117x> and how long should I wait to check?
  4 2014-01-15 00:23:02 <sipa> zone117x: you know the moment a successor to it is mined
  5 2014-01-15 00:23:11 <sipa> and there is no such thing as 'accepted'
  6 2014-01-15 00:23:23 <sipa> every node decides that individually
  7 2014-01-15 00:23:27 <Diablo-D3> sipa: yeah but
  8 2014-01-15 00:23:39 <Diablo-D3> its basically if it has 6 confirms its accepted by most people
  9 2014-01-15 00:23:54 <Diablo-D3> I think what zone is asking is essentially "how do I check the chain for a tx"
 10 2014-01-15 00:28:00 <Apocalyptic> he mentionned "block" not tx though
 11 2014-01-15 00:28:06 <sipa> same thing
 12 2014-01-15 00:28:17 <sipa> confirmations for blocks and transactions align
 13 2014-01-15 00:28:24 <Apocalyptic> confirmations do indeed
 14 2014-01-15 00:28:34 <Diablo-D3> Apocalyptic: confirms of a tx is just the number of blocks that have come after the block the tx is in
 15 2014-01-15 00:28:43 <Apocalyptic> Diablo-D3, thanks I know that
 16 2014-01-15 00:28:50 <Apocalyptic> pretty basic knowledge
 17 2014-01-15 00:30:10 <Diablo-D3> I dunno, Ive met quite a few noobs in #bitcoin*
 18 2014-01-15 00:33:56 <zone117x> I'm close to finishing a stratum server in node.js and sometimes I feel like a noob :(
 19 2014-01-15 00:34:41 <zone117x> if I'm about to send out btc payments to miners, what process should I go through to be confident that a submitted block has not been orphaned?
 20 2014-01-15 00:35:05 <sipa> you can't
 21 2014-01-15 00:35:09 <zone117x> do I use getblock or listsinceblock on some timer to check for block confirmations > 6 ?
 22 2014-01-15 00:35:15 <sipa> you cannot know locally
 23 2014-01-15 00:35:31 <sipa> nodes do not necessarily agree about which chain they consider valid
 24 2014-01-15 00:35:41 <sipa> over time, they converge
 25 2014-01-15 00:36:02 <sipa> if you have a few blocks on top, the chances for it being reorganized away become very quickly smaller
 26 2014-01-15 00:36:05 <zone117x> right, but poolservers have a reasonable amount of confidence about their block being accepted when they send payments
 27 2014-01-15 00:36:24 <sipa> yes, they don't send payments immediately either
 28 2014-01-15 00:36:57 <sipa> (it takes 100 blocks before you can even spend the coins generated by a block)
 29 2014-01-15 00:40:09 <zone117x> so should I setup polling to check for some threshold of confirmations for a block I submitted?
 30 2014-01-15 00:40:22 <zone117x> then once threshold is reached, relatively safe to send out payments?
 31 2014-01-15 00:40:39 <sipa> don't send out payments; credit accounts
 32 2014-01-15 00:40:44 <zone117x> or is there something better than polling. idk, maybe blocknotify?
 33 2014-01-15 00:40:57 <sipa> yes, you could recompute on blocknotify
 34 2014-01-15 00:41:07 <sipa> i'm sure people have implemented all this many times over already
 35 2014-01-15 00:41:43 <zone117x> there are examples in php mpos for stratum-mining. they setup a cron job and check for some threshold of confirmations. I just want to know the best way to do it
 36 2014-01-15 00:48:45 <jspilman> petertodd: ping
 37 2014-01-15 00:48:56 <petertodd> jspilman: hi
 38 2014-01-15 00:49:29 <jspilman> ack on your latest comments on forming the multisig, and p2sh
 39 2014-01-15 00:49:57 <petertodd> jspilman: cool
 40 2014-01-15 00:50:02 <petertodd> jspilman: that reddit story really blew up...
 41 2014-01-15 00:50:29 <jspilman> yeah, this serves a very useful purpose
 42 2014-01-15 00:50:41 <zone117x> reddit link?
 43 2014-01-15 00:51:05 <zone117x> http://sourceforge.net/mailarchive/message.php?msg_id=31813471 ?
 44 2014-01-15 00:51:35 <jspilman> may not be perfect in many ways, but highly pragmatic. solves a longstanding problem
 45 2014-01-15 00:51:53 <petertodd> http://www.reddit.com/r/Bitcoin/comments/1v7ayg/revolution_in_bitcoin_privacy_stealth_addresses/
 46 2014-01-15 00:52:14 <jspilman> I'm wondering about a canonical form which would tie to a address with a standard prefix (eg. xSTL).  could be 2-of-2 multisig P2SH, but I think could also be just standard pay-to-pubkey Q'?
 47 2014-01-15 00:52:46 <petertodd> jspilman: sorry, explain again?
 48 2014-01-15 00:53:10 <jspilman> from my last email "This is assuming we want to put q2New somewhere into the transaction, which, is it even required?"
 49 2014-01-15 00:53:35 <justanotheruser> petertodd: what are the disadvantages of these stealth addresses?
 50 2014-01-15 00:53:37 <jspilman> why not just: stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New)
 51 2014-01-15 00:53:42 <jspilman> stealthTx.Vout.Add(TxOut.OpReturn(P));
 52 2014-01-15 00:54:37 <jspilman> Q2 has to be in the address, of course, but not required for it to be in the resulting transaction
 53 2014-01-15 00:55:23 <petertodd> jspilman: ah right, well, I think the right scheme is for the stealth address to specify one or more pubkeys, one of the pubkeys can be the ECDH pubkey, and one or more go into either  CHECKSIG or CHECKMULTISIG as appropriate
 54 2014-01-15 00:55:49 <petertodd> jspilman: I think it's ok to allow the user to specify to reuse the ECDH pubkey for the payment one, but it may be worth it to just force those to be separate
 55 2014-01-15 00:57:38 <jspilman> address has two keys, I do not want to reuse the ECDH pubkey for the payment one, since it has to be kept hot
 56 2014-01-15 00:58:35 <petertodd> jspilman: right, but do we allow the user to use it as a second-factor in a CHECKMULTISIG? that'd often be totally reasonable
 57 2014-01-15 00:58:41 <jspilman> but the tx that you generate when paying to the address. that tx need only contain a single derived stealth pubkey from Q1, and P in OP_RETURN. I agree the payment TX *can* have two derived/stealth pubKeys, but *must* it?
 58 2014-01-15 00:58:55 <petertodd> oh, definitely not
 59 2014-01-15 00:59:07 <jspilman> k, on the same page.
 60 2014-01-15 00:59:07 <petertodd> hence why I suggest "let the users's wallet app decide"
 61 2014-01-15 00:59:34 <petertodd> I've got nothing against letting them choose to just re-use a hot pubkey - in some setups that'll be fine, and frankly, matches how most wallets end up working
 62 2014-01-15 00:59:38 <jspilman> so now I'm just thinking, we "just" need to standardize some address formats which indicate how to build the tx
 63 2014-01-15 01:01:20 <petertodd> well, funny thing is this almost argues for just making the address be a base58-converted protocol buffers bit of junk, though I sure feel ugly suggesting that
 64 2014-01-15 01:01:34 <petertodd> it's easy to imagine future backwards compatible upgrades
 65 2014-01-15 01:01:45 <jspilman> we may have a address byte (or bytes) which instruct wallet to pay to a P2SH multisig, we may also have a prefix which instructs wallet to create a more typical pay-to-pubKey
 66 2014-01-15 01:02:30 <jspilman> either way, the addresss could itself be carrying one or two pubKeys for hot or not monitoring
 67 2014-01-15 01:02:32 <petertodd> yeah, that's a good thing to have
 68 2014-01-15 01:02:47 <petertodd> yup
 69 2014-01-15 01:02:53 <petertodd> and don't forget the prefix too
 70 2014-01-15 01:04:45 <jspilman> we could pick different 4-byte prefixes which all end up looking like xSTL but cause different tx's underneath, or maybe you want that detail visible to the payer
 71 2014-01-15 01:06:10 <petertodd> well, I'm not so sure the "xSTL" thing is all that important, I'd just prefix it as s<random base 58> myself
 72 2014-01-15 01:06:15 <jspilman> 'visible' is debatable, since the address is in a URI and will populate an address book entry with the name of the payee so 'xSTL' ideally is never even seen.
 73 2014-01-15 01:06:36 <petertodd> yeah, that there is a base58 address encoding for it isn't too important
 74 2014-01-15 01:07:10 <petertodd> mainly I think the idea *of* addresses actually makes a surprising amount of sense given all the contexts where you re-use the notion of specifying an address
 75 2014-01-15 01:07:37 <jspilman> this is example of when an address is actually an address :-)
 76 2014-01-15 01:07:54 <petertodd> yup
 77 2014-01-15 01:08:34 <petertodd> and we'll set a precident for how we encode all the !@#$% options for when soemone inevitably does a BIP32 chain-code scheme
 78 2014-01-15 01:10:51 <petertodd> so I dunno, maybe it just needs to be <version> <# of pubkeys to spend> <# of pubkeys total> {<pubkey>...<pubkey>} <ECDH-pubkey> <prefix length in bits> <prefix> (potential extra stuff for bakwards-compatible upgrades)
 79 2014-01-15 01:11:11 <petertodd> it's either that, or you end up with something that looks like protocol buffers and has tagged fields
 80 2014-01-15 01:12:50 <jspilman> is <prefix> often implicitly taken from the first <pubkey>?
 81 2014-01-15 01:13:03 <petertodd> definitely not
 82 2014-01-15 01:13:33 <petertodd> prefix is just something the recipient chooses at random
 83 2014-01-15 01:13:41 <petertodd> doesn't have to have anything to do with the pubkeys themselves
 84 2014-01-15 01:15:20 <jspilman> k
 85 2014-01-15 01:16:01 <wyager> Quick question about stealth address proposition: Doesn't it require scanning the *entire* blockchain to find transactions intended for you?
 86 2014-01-15 01:16:27 <jspilman> I think I have enough to start making it work in Bitcoin-QT so I can show off the entire use-case / UI flow in a youtube vid and get people really fired up
 87 2014-01-15 01:16:32 <petertodd> wyager: only if you choose that large of an anonymity set
 88 2014-01-15 01:16:33 <wyager> I.e. don't you have to test every single "stealth" send to check if you have the mathcing privkey?
 89 2014-01-15 01:16:44 <wyager> petertodd: What do you mean by anonymity set?
 90 2014-01-15 01:16:49 <petertodd> wyager: read the part about "prefixes" in my paper on it :)
 91 2014-01-15 01:17:06 <wyager> You got a link to the paper? I just read the mailing list
 92 2014-01-15 01:17:25 <petertodd> wyager: the first post in that thread is what I consider my paper :)
 93 2014-01-15 01:18:20 <petertodd> jspilman: nice!
 94 2014-01-15 01:18:32 <petertodd> jspilman: what language are you writing this in?
 95 2014-01-15 01:18:41 <jspilman> speaking of anonymity set, I'm not sure wrapping the multisig in P2SH helps increase it since the OP_RETURN is still there. still worth doing tho
 96 2014-01-15 01:19:09 <jspilman> so far, C#
 97 2014-01-15 01:19:24 <petertodd> jspilman: right, but remember that just tells you the transaction probably has a stealth txout, the tx may be coinjoin, there may be change involved, lots of stuff
 98 2014-01-15 01:20:10 <petertodd> jspilman: C# won't win you any friends, *but* it rpobably is valuable to force a re-implementation of the protocol soon to find the badly specified parts
 99 2014-01-15 01:21:10 <jspilman> I'll write the C to make it work in bitcoind / Bitcoin-QT
100 2014-01-15 01:21:30 <petertodd> jspilman: you mean C++?
101 2014-01-15 01:22:58 <jspilman> heh
102 2014-01-15 01:23:25 <wyager> petertodd: Don't the prefixes pretty much completely eliminate the purpose? OK, so if I use a 16 bit filter, now it could be me and maybe 2 or 3 other people recieving the funds...
103 2014-01-15 01:23:59 <wyager> I guess it allows for a decent middle ground
104 2014-01-15 01:25:50 <petertodd> wyager: exatly, prefixes allow you to choose your anonymity set - if you hide in 1/256 * all transactions and receive one payment a month, that's probably just fine
105 2014-01-15 01:27:24 <gmaxwell> well in particular you could always use a 16 bit token, and only the sender and reciever (maybe even only the reciever) know the real prefix length.
106 2014-01-15 01:28:07 <petertodd> gmaxwell: yeah, I mentioned that possible info leak on the mailing list
107 2014-01-15 01:28:13 <wyager> True. I feel like statistical analysis might show some weird distribution though
108 2014-01-15 01:28:48 <petertodd> wyager: a 16 bit filter is pretty specific - use a shorter filter if it worries you, at cost of bandwidth
109 2014-01-15 01:29:03 <petertodd> wyager: point is the tradeoff is up to you, and a nice easy to control knob
110 2014-01-15 01:29:32 <wyager> What is the outlook for adding SPV support for these transactions?
111 2014-01-15 01:30:38 <wangchun> new blocks pop up like crazy
112 2014-01-15 01:31:23 <petertodd> wyager: very good, prefix filters are going to end up getting implemented - electrum is going that direction
113 2014-01-15 01:41:04 <EasyAt> Is there a more substantial list of neat/clever scripts than those on the wiki?
114 2014-01-15 01:42:12 <petertodd> EasyAt: no, the scripting language is to neutured for any to exist
115 2014-01-15 01:42:27 <EasyAt> :(
116 2014-01-15 01:42:41 <petertodd> EasyAt: if you can think of any, please let us know!
117 2014-01-15 01:43:09 <EasyAt> petertodd: I have been running in circles all day thinking of ideas and then proving them impossible
118 2014-01-15 01:43:35 <EasyAt> Shifts would be nice heh
119 2014-01-15 01:43:54 <petertodd> EasyAt: yup, practically everything even remotely useful got disabled
120 2014-01-15 01:45:09 <Apocalyptic> petertodd, why ?
121 2014-01-15 01:45:35 <sipa> ask satoshi
122 2014-01-15 01:45:59 <EasyAt> All I can really thing of is a bounty for hash cracking
123 2014-01-15 01:49:09 <petertodd> Apocalyptic: there were some early vulnerabilities and people got scared
124 2014-01-15 01:49:27 <petertodd> EasyAt: good job - I did exactly that a few months ago
125 2014-01-15 01:49:58 <EasyAt> petertodd: The bounty idea?
126 2014-01-15 01:50:06 <petertodd> EasyAt: yeah
127 2014-01-15 01:50:17 <petertodd> EasyAt: good on you to reinvent it
128 2014-01-15 01:52:14 <EasyAt> woot
129 2014-01-15 01:52:40 <petertodd> EasyAt: https://bitcointalk.org/index.php?topic=293382.0
130 2014-01-15 01:53:10 <petertodd> EasyAt: heck, if you have the time, write up how that works on the wiki
131 2014-01-15 01:53:21 <sipa> EasyAt: oh, you came up with that independently?
132 2014-01-15 01:53:27 <EasyAt> Yes
133 2014-01-15 01:53:31 <sipa> cool
134 2014-01-15 01:53:56 <EasyAt> I started digigng into the op codes last night and throwing ideas around with my roomate
135 2014-01-15 01:54:07 <sipa> sometimes it's easy to forget how some things are not just "known" to everyone
136 2014-01-15 01:54:33 <EasyAt> sipa: What do you mean?
137 2014-01-15 01:54:38 <petertodd> sipa: so as we were saying and MAST and MMR TXO commitments :P
138 2014-01-15 01:54:40 <petertodd> EasyAt: ^
139 2014-01-15 01:55:27 <sipa> EasyAt: i saw you talking about collision verifying scripts, and i thought "yeah, those are also the only non trivial ones i know of"
140 2014-01-15 01:55:30 <petertodd> EasyAt: bitcoin can be a remarkably obscure field with regard to the fine details :)
141 2014-01-15 01:55:44 <sipa> forgetting that for you, this wasn't prior knowledge already
142 2014-01-15 01:56:01 <petertodd> EasyAt: a lot of people don't even realize how limited scripts are and just hear "programming!"
143 2014-01-15 01:56:13 <EasyAt> Ah, petertodd the rabbit hole keeps going
144 2014-01-15 01:56:38 <petertodd> EasyAt: heh, just wait till you get to almost existential arguments about "proof-of-publication"
145 2014-01-15 01:56:49 <EasyAt> been there done that
146 2014-01-15 01:57:05 <EasyAt> :)
147 2014-01-15 01:57:58 <EasyAt> Unless you mean something other than essentially sticking the hash of a documen tin the blockchain?
148 2014-01-15 01:58:27 <petertodd> EasyAt: see, you timestamped the document, but you didn't prove anything about the document itself
149 2014-01-15 01:58:55 <petertodd> EasyAt: where as proof-of-publication would be to put the whole document in the blockchain, proving the data got published to all bitcoin miners
150 2014-01-15 02:00:11 <EasyAt> Hm
151 2014-01-15 02:00:35 <petertodd> Now, can you think of what this proof-of-publication concept has to do with the double-spend problem?
152 2014-01-15 02:00:59 <EasyAt> don't tell me! :)
153 2014-01-15 02:01:28 <petertodd> :)
154 2014-01-15 02:09:46 <shamoon> what does the "Bits" field of a block mean?
155 2014-01-15 02:10:28 <lechuga__> Current target in compact format
156 2014-01-15 02:10:36 <lechuga__> see: https://en.bitcoin.it/wiki/Block_hashing_algorithm
157 2014-01-15 02:16:09 <EasyAt> petertodd: mmmmmm
158 2014-01-15 02:16:14 <EasyAt> I think I'm close
159 2014-01-15 02:17:13 <lechuga__> double-spend txn attempts miners work on wont have a proof-of-publication?
160 2014-01-15 02:17:28 <shamoon> thanks lechuga__
161 2014-01-15 02:17:32 <lechuga__> np
162 2014-01-15 02:19:19 <EasyAt> NO, I'm not
163 2014-01-15 02:19:59 <EasyAt> Do proof of publicatoin schemes introduce double spending issues
164 2014-01-15 02:20:58 <Apocalyptic> EasyAt, they fix them
165 2014-01-15 02:21:11 <shamoon> are merkle roots unique per block?
166 2014-01-15 02:21:19 <EasyAt> How can you with 0 confs?
167 2014-01-15 02:21:56 <jaakkos> shamoon: only a single merkle root in block
168 2014-01-15 02:22:09 <shamoon> and is that merkle root unique across the entire blockchain?
169 2014-01-15 02:22:19 <lechuga__> the odds of a merkle root colliding with another block are very small
170 2014-01-15 02:22:23 <lechuga__> very very
171 2014-01-15 02:22:29 <EasyAt> shamoon: Since the blockheight is in the header then I imagine so
172 2014-01-15 02:22:41 <EasyAt> oh, wait. I misread your question
173 2014-01-15 02:23:11 <jaakkos> shamoon: the merkle tree provides a way to access the blockchain in trustless manner without having the entire blockchain downloaded (only block headers), as in SPV clients
174 2014-01-15 02:23:19 <shamoon> nice
175 2014-01-15 02:24:15 <shamoon> 50 / 2^(blockheight % 210000)
176 2014-01-15 02:24:19 <shamoon> will give me the reward of that block
177 2014-01-15 02:24:20 <EasyAt> shamoon: Yes, they would be different now that I think about it.  The coinbase TX must cointain the block height
178 2014-01-15 02:24:21 <shamoon> correct?
179 2014-01-15 02:24:40 <EasyAt> BIP 34
180 2014-01-15 02:25:35 <EasyAt> The merkle root in each block would be different as the coinbase TX inside of it will have the blockheight
181 2014-01-15 02:25:49 <shamoon> thanks EasyAt
182 2014-01-15 02:26:55 <EasyAt> But, before BIP 34 was implemented I think it would have been possible.  If you had 2 blocks and each had an identical coinbase
183 2014-01-15 02:27:11 <EasyAt> and output address and script, etc...
184 2014-01-15 02:27:29 <lechuga__> i think a collision is still possible through extreme bad luck
185 2014-01-15 02:27:31 <EasyAt> But contained no other TXs except the coin gneration one
186 2014-01-15 02:27:43 <sipa> EasyAt: bip30 made that illegal
187 2014-01-15 02:27:55 <EasyAt> Ah
188 2014-01-15 02:28:08 <phantomcircuit> a crime against bitcoin
189 2014-01-15 02:28:23 <EasyAt> sipa: So, it would have been possible before bip 30, no?
190 2014-01-15 02:28:31 <phantomcircuit> yes and it did happen
191 2014-01-15 02:28:43 <phantomcircuit> so by rule that tx isn't spendable
192 2014-01-15 02:28:46 <sipa> it happened twice
193 2014-01-15 02:28:58 <phantomcircuit> yeah that's right i forgot it happened twice
194 2014-01-15 02:29:04 <phantomcircuit> dat edge case
195 2014-01-15 02:29:26 <EasyAt> hehe
196 2014-01-15 02:29:26 <phantomcircuit> was useful in verifying the sanity of my sql db relationship constraints
197 2014-01-15 02:29:26 <sipa> blocks 91842 and 91880
198 2014-01-15 02:29:37 <sipa> it was a loooong time ago
199 2014-01-15 02:30:08 <Happzz> ;;ticker --market bitstamp
200 2014-01-15 02:30:08 <Happzz> ;;ticker --market mtgox
201 2014-01-15 02:30:09 <gribble> MtGox BTCUSD ticker | Best bid: 917.83274, Best ask: 922.99499, Bid-ask spread: 5.16225, Last trade: 922.99499, 24 hour volume: 3548.50451790, 24 hour low: 905.0, 24 hour high: 943.0, 24 hour vwap: 923.56112
202 2014-01-15 02:30:10 <gribble> Bitstamp BTCUSD ticker | Best bid: 817.03, Best ask: 818.0, Bid-ask spread: 0.97000, Last trade: 819.99, 24 hour volume: 9457.85243412, 24 hour low: 800.0, 24 hour high: 837.0, 24 hour vwap: 820.864485173
203 2014-01-15 02:32:00 <shamoon> block.blockreward = 100 / 2^(parseInt(blockHeight / 210000))
204 2014-01-15 02:32:37 <sipa> 100?
205 2014-01-15 02:33:58 <EasyAt> phantomcircuit: heh
206 2014-01-15 02:34:53 <gribble> Error: This is not one of the supported markets. Please choose one of ['btcde', 'mtgox', 'bfx', 'btcn', 'coinbase', 'cbx', 'btsp', 'btce', 'btcavg'] or 'all'
207 2014-01-15 02:34:53 <phantomcircuit> ;;ticker --market intersango
208 2014-01-15 02:34:58 <phantomcircuit> :(
209 2014-01-15 02:35:03 <phantomcircuit> ;;ticker --market btcavg
210 2014-01-15 02:35:04 <gribble> BitcoinAverage BTCUSD ticker | Best bid: 835.57, Best ask: 837.46, Bid-ask spread: 1.89000, Last trade: 835.53, 24 hour volume: 23797.43, 24 hour low: None, 24 hour high: None, 24 hour vwap: 840.58
211 2014-01-15 02:35:07 <EasyAt> petertodd: hint?
212 2014-01-15 02:40:58 <kanzure> is there a client-side js library for calculating an address from a stealth address?
213 2014-01-15 02:43:03 <petertodd> EasyAt: what do you need to do to be sure a double-spend doesn't exist?
214 2014-01-15 02:44:08 <EasyAt> Be connected to every node on the network?
215 2014-01-15 02:44:21 <petertodd> EasyAt: nope
216 2014-01-15 02:44:27 <petertodd> EasyAt: I'm talking about in the blockchain
217 2014-01-15 02:44:39 <petertodd> EasyAt: none of this pansy zero-conf crap
218 2014-01-15 02:44:57 <EasyAt> hehe
219 2014-01-15 02:45:15 <lechuga__> make sure an output doesnt appear as an input for any other txn
220 2014-01-15 02:45:31 <lechuga__> ?
221 2014-01-15 02:45:36 <petertodd> lechuga__: good
222 2014-01-15 02:45:59 <petertodd> so if you want to pay me, what do you need to prove to me?
223 2014-01-15 02:46:55 <lechuga__> why do i have to prove it, u dont trust me :)
224 2014-01-15 02:47:03 <sipa> you have to prove exactly because he doesn't trust you
225 2014-01-15 02:47:07 <phantomcircuit> that's why it's called proof
226 2014-01-15 02:47:13 <sipa> if he trusted you, he could just take your word for it
227 2014-01-15 02:47:31 <lechuga__> but shouldnt he verify my output doesnt exist as an input on the published chain?
228 2014-01-15 02:47:34 <lechuga__> current best chain
229 2014-01-15 02:47:42 <EasyAt> I have to prove these outputs haven't been spent.  If they aren't in the UTXO set then you know they are spent or not mine
230 2014-01-15 02:47:48 <petertodd> lechuga__: ah, but then what did you prove to me?
231 2014-01-15 02:48:13 <lechuga__> we're both on the same chain?
232 2014-01-15 02:48:54 <lechuga__> hmm
233 2014-01-15 02:49:39 <petertodd> lechuga__: assume we're "on" the same chain
234 2014-01-15 02:50:12 <lechuga__> i feel liek i only proved to you that this is a single-spend...for now
235 2014-01-15 02:50:23 <lechuga__> if soem fork gets promoted all bets are off
236 2014-01-15 02:50:43 <petertodd> lechuga__: assume for the sake of argument that the bitcoin blockchain works exactly as it's intended too
237 2014-01-15 02:51:27 <lechuga__> im confused then i thought we you guys were talkign about a way to address the current double-spend potential related to an attack w/ a forked chain
238 2014-01-15 02:51:45 <petertodd> lechuga__: no, I mean what does your confirmed transaction prove to me
239 2014-01-15 02:53:11 <lechuga__> guess it must
240 2014-01-15 02:53:11 <lechuga__> so what im spending has >0 confs?
241 2014-01-15 02:53:11 <petertodd> yup
242 2014-01-15 02:53:16 <petertodd> as I say, we don't trust no pansy zero-conf crap 'round here
243 2014-01-15 02:53:40 <lechuga__> can i ask for a quick backtrac, whats the problem u are addressing?
244 2014-01-15 02:53:41 <sipa> lechuga__: what conditions did your transaction have to satisfy for getting confirmed?
245 2014-01-15 02:54:16 <lechuga__> it was in the utxo set..
246 2014-01-15 02:54:19 <sipa> lechuga__: the question is what bitcoin's preventing of double spending have to do with proof-of-publication
247 2014-01-15 02:54:22 <petertodd> lechuga__: EasyAt's question about what the heck proof-of-publication has to do with it
248 2014-01-15 02:54:43 <lechuga__> i guess i dont know what "proof-of-publication" is exactly
249 2014-01-15 02:55:04 <petertodd> lechuga__: means I prove to you that I published something such that some audience could see it
250 2014-01-15 02:55:16 <petertodd> lechuga__: it's actually a term used in the legal field
251 2014-01-15 02:55:39 <lechuga__> ok so proof-of-publciation is just that miners accepted my txn and included it in the chain
252 2014-01-15 02:55:44 <lechuga__> ?
253 2014-01-15 02:55:56 <petertodd> lechuga__: well, why did that prove publication?
254 2014-01-15 02:56:09 <petertodd> lechuga__: and more fundementally, what does that proof mean to me?
255 2014-01-15 02:56:48 <lechuga__> it means the entire network agrees this is a unique spend and that if i give it to u the same entwork should accept your spend of it
256 2014-01-15 02:57:16 <petertodd> lechuga__: closer, but why does it agree it's a unique spend?
257 2014-01-15 02:57:42 <lechuga__> because its a leaf
258 2014-01-15 02:57:49 <petertodd> a leaf?
259 2014-01-15 02:57:51 <lechuga__> well
260 2014-01-15 02:58:26 <sipa> a leaf in the transaction dag, he means
261 2014-01-15 02:59:02 <lechuga__> you could walk the blockchain backwards and verify its origin
262 2014-01-15 02:59:19 <lechuga__> and in doing so verify im the only one who has it now
263 2014-01-15 02:59:26 <petertodd> lechuga__: lets think about how you spend a single txout for a moment
264 2014-01-15 02:59:36 <lechuga__> via scriptSig
265 2014-01-15 02:59:37 <petertodd> lechuga__: ignore the rest of the complexity of a transaction
266 2014-01-15 02:59:38 <petertodd> correct
267 2014-01-15 02:59:53 <lechuga__> which is a signed hash of the prevout + the connected scriptPubKey
268 2014-01-15 02:59:53 <petertodd> so a valid scriptSig is now in the blockchian, what is that?
269 2014-01-15 03:00:30 <lechuga__> proof that i am the keymaster
270 2014-01-15 03:00:39 <lechuga__> from gozar
271 2014-01-15 03:00:55 <lechuga__> it proves i own some key
272 2014-01-15 03:01:18 <petertodd> sure
273 2014-01-15 03:01:22 <petertodd> that's one part of it
274 2014-01-15 03:01:30 <petertodd> but how does it relate to the double-spend problem?
275 2014-01-15 03:01:38 <lechuga__> and it proves we have a consistent view of the prevout
276 2014-01-15 03:02:31 <petertodd> right, and why is our view consistent?
277 2014-01-15 03:02:43 <lechuga__> some1 else cant spend it because my pubkey was in the conected scriptPubKey
278 2014-01-15 03:03:07 <lechuga__> and now ive used my privkey to create the scriptSig and verify that output was meant for me
279 2014-01-15 03:03:23 <petertodd> sure, but lets suppose miners didn't bother actually checking that - they'd happily include *both* transactions in the blockchain, then what?
280 2014-01-15 03:03:28 <sipa> that means it is correct in your view
281 2014-01-15 03:03:38 <sipa> it doesn't have anything to do with why that view is consistant
282 2014-01-15 03:03:54 <sipa> (that was an answer to lechuga__)
283 2014-01-15 03:04:06 <EasyAt> You've never seen those outputs spent before
284 2014-01-15 03:04:41 <lechuga__> the block wouldnt make it onto the blockchain
285 2014-01-15 03:05:00 <lechuga__> the double-spend woudl be invalid because someone couldnt create a redeeming scriptSig w/o my key
286 2014-01-15 03:05:49 <petertodd> lechuga__: suppose it was you that make the double spend
287 2014-01-15 03:06:06 <petertodd> lechuga__: and heck, suppose miners let *invalid* transactions into the blockchain, then what? (like totally invalid)
288 2014-01-15 03:06:20 <lechuga__> nodes would still reject it
289 2014-01-15 03:07:30 <lechuga__> when it came tiem to validate the second txn it woudl be seen that the output was spent
290 2014-01-15 03:07:41 <lechuga__> i feel like im talking in circles :)
291 2014-01-15 03:08:54 <petertodd> lechuga__: assume there are no nodes other than miners
292 2014-01-15 03:09:05 <warren> sipa: ooh, "<sipa> [11:58:28] in src/leveldb/db/builder.cc, replace the call to TableFileName to one to SSTTableFileName" doesn't work as a one liner, the latter isn't in the namespace
293 2014-01-15 03:09:07 <petertodd> lechuga__: rules now are, whatever crap you want in the blockchain, you can put in there
294 2014-01-15 03:09:58 <lechuga__> well you can check it
295 2014-01-15 03:10:06 <petertodd> lechuga__: exactly!
296 2014-01-15 03:10:11 <sipa> warren: uh?
297 2014-01-15 03:10:14 <petertodd> lechuga__: you don't need to rely on other people checking it
298 2014-01-15 03:10:35 <lechuga__> right
299 2014-01-15 03:10:42 <warren> sipa: oops... I was working on the wrong branch
300 2014-01-15 03:11:01 <lechuga__> oh was that all you were getting at? :)
301 2014-01-15 03:11:32 <petertodd> lechuga__: sure, but if no-one is checking anything, other than you, then what purpose did the blockchain serve?
302 2014-01-15 03:13:58 <lechuga__> i could still independenty verify the txn with it
303 2014-01-15 03:14:09 <lechuga__> and verify u own said key
304 2014-01-15 03:14:28 <sipa> lechuga__: that's what you could do independently of the chain
305 2014-01-15 03:14:50 <petertodd> lechuga__: sure you could verify signatures, but how would you convince me you didn't double-spend the tx?
306 2014-01-15 03:14:54 <sipa> lechuga__: but what would the blockchain being there and being mined on, with all crap sent out by people to be included in it, still do?
307 2014-01-15 03:15:25 <lechuga__> its stilla ledger of all the txns
308 2014-01-15 03:15:39 <lechuga__> the crap can be filtered
309 2014-01-15 03:16:11 <sipa> who would have to see the crap?
310 2014-01-15 03:16:18 <petertodd> lechuga__: ok, so it'd a ledger, what did you do *for me* by putting your transaction in that ledger?
311 2014-01-15 03:16:41 <petertodd> lechuga__: it might be more clear if you think in terms of you trying to spend the same coins to both sipa and myself
312 2014-01-15 03:17:18 <lechuga__> ?
313 2014-01-15 03:17:18 <lechuga__> i guess not
314 2014-01-15 03:17:18 <lechuga__> miners
315 2014-01-15 03:18:06 <lechuga__> i proved to you everyone i have the coins
316 2014-01-15 03:18:09 <lechuga__> er
317 2014-01-15 03:18:12 <lechuga__> proved to everyone
318 2014-01-15 03:18:16 <petertodd> lechuga__: you're trying to convince both sipa and myself that you've sent us a valid payment, why doesn't that work?
319 2014-01-15 03:18:50 <lechuga__> you both have a consistent view of the ledger
320 2014-01-15 03:19:00 <petertodd> lechuga__: and why *does* it work if you only send one of us the payment?
321 2014-01-15 03:20:11 <lechuga__> you both can independently verify it with the ledger
322 2014-01-15 03:20:33 <lechuga__> i feel like im beign dense
323 2014-01-15 03:20:41 <EasyAt> me too
324 2014-01-15 03:20:48 <lechuga__> u think im dense? :)
325 2014-01-15 03:20:55 <EasyAt> no, I feel dense
326 2014-01-15 03:20:58 <lechuga__> haha
327 2014-01-15 03:21:12 <petertodd> lechuga__: it only took me, like, 3 years before I thought of the concept of proof-of-publication, no worries :P
328 2014-01-15 03:21:31 <EasyAt> I feel like Im missing something because this seems like all you do is respect the bytes that you move through first while scanning the chain
329 2014-01-15 03:22:35 <lechuga__> hmmmm
330 2014-01-15 03:22:52 <EasyAt> petertodd: Isn't not being in the UTXO set enough?
331 2014-01-15 03:23:13 <petertodd> EasyAt: sure, but when I see those bytes, and my payment comes first, what is that really telling me that *you* did with respect to the rest of the world?
332 2014-01-15 03:23:26 <EasyAt> I choose you
333 2014-01-15 03:23:41 <petertodd> EasyAt: did you "choose me" in secret?
334 2014-01-15 03:24:01 <lechuga__> no its public that he chose you because its been tiemstamped
335 2014-01-15 03:24:06 <EasyAt> No, I've proven publication... i suppose
336 2014-01-15 03:24:39 <lechuga__> its publically recorded that you were paid first
337 2014-01-15 03:24:45 <lechuga__> and that everyone was told so
338 2014-01-15 03:24:53 <petertodd> EasyAt: yup, and by proving publication I can be confident I saw the first spend of that txout, becuase the *definition* of a valid spend is to publish it publicly!
339 2014-01-15 03:25:44 <EasyAt> yes
340 2014-01-15 03:25:52 <petertodd> lechuga__: notably, is it just enough to only timestamp the tx?
341 2014-01-15 03:26:03 <lechuga__> and sign it
342 2014-01-15 03:26:13 <EasyAt> Isn't that th epoint I guess?  I feel like I'm missing something
343 2014-01-15 03:26:27 <lechuga__> the timestamp has to be agreed upon
344 2014-01-15 03:26:35 <lechuga__> and published
345 2014-01-15 03:26:51 <petertodd> lechuga__: signing is a given, but if you gave me a scriptSig that was timestamped, proving it existed on a certain data, does that prove anything about what other valid spends might exist of that same txout?
346 2014-01-15 03:27:06 <EasyAt> So, we blockchain the blockchain
347 2014-01-15 03:27:25 <petertodd> EasyAt: wht do you mean by that?
348 2014-01-15 03:27:50 <lechuga__> no because it needs to be part of the chain as well
349 2014-01-15 03:28:15 <petertodd> lechuga__: right, a timestamp only tells you about existance of data, and nothing about consensus
350 2014-01-15 03:30:30 <lechuga__> so its in a block that has been hashed in a chain and is open for the world to see
351 2014-01-15 03:31:04 <lechuga__> is there still more?
352 2014-01-15 03:31:32 <petertodd> lechuga__: heh, well, that's the basic lesson, the advanced one gets a lot weirder
353 2014-01-15 03:31:48 <petertodd> lechuga__: and I don't think anyone has fully figured out the details of it
354 2014-01-15 03:31:56 <lechuga__> ?
355 2014-01-15 03:32:17 <lechuga__> im curious
356 2014-01-15 03:33:27 <petertodd> lechuga__: tl;dr: you don't actually appear to need consensus over the state of all coins, you just need "local" consensus about some subset of the transaction output space, as little as a single transaction output
357 2014-01-15 03:33:45 <petertodd> lechuga__: but how to actually pull that off in practice without screwing up the economics and security of bitcoin... dunno
358 2014-01-15 03:35:15 <lechuga__> local consensus of some txo w/o referencing the blockchain?
359 2014-01-15 03:36:24 <lechuga__> and what is "local"
360 2014-01-15 03:36:31 <lechuga__> the payer and the payee?
361 2014-01-15 03:36:45 <petertodd> lechuga__: well we're still using a blockchain, but if consensus can be local, what exactly would miners be proving?
362 2014-01-15 03:37:10 <petertodd> lechuga__: remember that we can still have very strong global *timestamping*, it's just that the timestamping isn't proof that the data was shown to anyone
363 2014-01-15 03:37:29 <EasyAt> petertodd: Are you talking about isolated networks?
364 2014-01-15 03:37:35 <petertodd> EasyAt: nope
365 2014-01-15 03:37:45 <lechuga__> local with respect to what
366 2014-01-15 03:37:57 <lechuga__> just some subset of the population?
367 2014-01-15 03:38:01 <lechuga__> arbitrarilty sized?
368 2014-01-15 03:38:47 <petertodd> lechuga__: well, suppose that transaction outputs starting with 0 were handled by some miners, starting with 1 handled by some other, and so on for all 256 possibilities, could those miners still create a strong *tiemstamping* chain? sure
369 2014-01-15 03:39:02 <petertodd> lechuga__: but then, what does the present of a txout in the blockchain mean exactly?
370 2014-01-15 03:39:11 <petertodd> lechuga__: given only 1/256th of all miners ever had anything to do with it
371 2014-01-15 03:39:23 <lechuga__> i sent it to at least one other person?
372 2014-01-15 03:39:37 <lechuga__> er one other node
373 2014-01-15 03:40:28 <petertodd> right, so someone saw it, in fact, 1/256th of all miners did
374 2014-01-15 03:40:42 <petertodd> but how secure is that? and against what types of attacks?
375 2014-01-15 03:43:11 <EasyAt> petertodd: Does each miner verify the whole chain
376 2014-01-15 03:43:50 <lechuga__> i dont *think* its any less secure
377 2014-01-15 03:43:51 <petertodd> EasyAt: forget verification in this example, miners just put junk in the blockchain when requested
378 2014-01-15 03:44:07 <EasyAt> petertodd: I guess I mean do they all have a full copy
379 2014-01-15 03:44:22 <petertodd> nope, just 1/256th of the blockchain
380 2014-01-15 03:44:33 <EasyAt> mercy
381 2014-01-15 03:45:08 <petertodd> EasyAt: heh, you can see why reasoning about this is rather attractive from a scalability point of view
382 2014-01-15 03:45:49 <lechuga__> hmmm
383 2014-01-15 03:46:18 <lechuga__> are u proposing the tx hashspace be consistently divided across the miners?
384 2014-01-15 03:46:20 <lechuga__> for real
385 2014-01-15 03:46:25 <petertodd> lechuga__: yup
386 2014-01-15 03:46:31 <lechuga__> thats interesting
387 2014-01-15 03:46:45 <lechuga__> in orde to double-spend theyd have to hash both their spends to the same space
388 2014-01-15 03:46:49 <petertodd> lechuga__: and since we're imagining a system where miners don't validate anything doing that is pretty easy
389 2014-01-15 03:47:20 <lechuga__> when i say for real what i mean to ask is are u considering doing this for real on the real network?
390 2014-01-15 03:47:50 <petertodd> lechuga__: I'm looking into it, but bitcoin itself is probably too entrenched to change that drasticly
391 2014-01-15 03:48:15 <lechuga__> i think that would seriously mitigate 51% double spends
392 2014-01-15 03:48:42 <lechuga__> and dont see why it wouldnt be just as secure
393 2014-01-15 03:48:59 <petertodd> why would it mitigate 51%?
394 2014-01-15 03:49:11 <lechuga__> well in that attack
395 2014-01-15 03:49:22 <lechuga__> prsumably a pool (or some1 with consolidated hashign power)
396 2014-01-15 03:49:41 <lechuga__> broadcasts a spend
397 2014-01-15 03:49:56 <lechuga__> but internally only work on hashing a spend to some1 else on a forked chain
398 2014-01-15 03:50:17 <lechuga__> back to themself maybe
399 2014-01-15 03:50:32 <petertodd> nah, this stuff has nothign to do with 51% attacks - you can't defend against them
400 2014-01-15 03:50:39 <EasyAt> Why does hashing to the same place matter
401 2014-01-15 03:50:42 <EasyAt> s/place/space
402 2014-01-15 03:51:07 <petertodd> EasyAt: in our model you only "mine" a part of the blockchain by actually having the data, and then doing some PoW problem
403 2014-01-15 03:51:22 <petertodd> EasyAt: easiest is to imagine that the PoW problem involved the blockchain data itself somehow
404 2014-01-15 03:52:31 <lechuga__> and with that i really need to leave the office, bbl
405 2014-01-15 03:54:34 <petertodd> lechuga__: later
406 2014-01-15 03:55:37 <EasyAt> petertodd: If all blockchains are independant I can spend 256 times
407 2014-01-15 03:55:39 <EasyAt> once per chain
408 2014-01-15 03:56:37 <EasyAt> Unless we share a UTXO and Spent TXO set... which is a stripped down blockchain, no?
409 2014-01-15 03:56:57 <petertodd> EasyAt: you kinda share it: it's split across the different chains
410 2014-01-15 03:57:17 <petertodd> EasyAt: like, suppose coins were just tokens moved from person to person - they didnd't get split
411 2014-01-15 03:57:40 <petertodd> EasyAt: if my token's identifier started with 0x01, it goes in the 0x01 chain, 0x02, the 0x02 chain etc.
412 2014-01-15 03:58:18 <EasyAt> sAre coins losing identity to be replaced with how many I own and can provable spend at any time in this system?
413 2014-01-15 03:59:09 <petertodd> EasyAt: easy, the token gets moved backed on a valid scriptSig
414 2014-01-15 04:07:22 <EasyAt> So, how do I make sure my token is in 1 place at any moment?
415 2014-01-15 04:08:54 <petertodd> Well, good question! There's a lot of ways to handle that and none have been tried in real life. :)
416 2014-01-15 04:09:31 <petertodd> if if you want to work with transactions, rather than single purpose tokens, it just gets even more complex
417 2014-01-15 04:13:25 <EasyAt> Unless I have a synopsis of the spent TX set it's impossible
418 2014-01-15 04:14:11 <petertodd> Ah! But that's it, you can get a succinct and compact proof that things exist in some claimed TX set, for example.
419 2014-01-15 04:14:38 <petertodd> So if you *trusted* that chain 0x01 was operating correctly and in honest consensus, on chain 0x05 you could accept such a proof as valid for soemthing or another.
420 2014-01-15 04:14:53 <petertodd> But then, how do you arrange so that you actually can trust that?
421 2014-01-15 04:18:40 <jcorgan> petertodd: not to derail the current thread, just wanted to confirm--your proposed stealth addresses don't require any changes to the bitcoin protocol, but rather rely on embedding a value using OP_RETURN, which now considered standard?
422 2014-01-15 04:20:00 <brianherman> hello I am having trouble compiling bitcoind on windows
423 2014-01-15 04:20:18 <petertodd> jcorgan: correct, and actually, you can implement them without OP_RETURN too, but there's advantages to making the ephemereal pubkey separate
424 2014-01-15 04:21:23 <brianherman> i have cygwin installed and I built autotools and automake from source but it seems not to find the libdb library i compiled the libdb library and installed it but cygwin doesnt seem to find it
425 2014-01-15 04:23:51 <brianherman> I have also tried setting the ld_library_path and the cxx path
426 2014-01-15 04:25:50 <SomeoneWeird> you're trying to compile bitcoind under a unix environment on a windows host?
427 2014-01-15 04:25:53 <SomeoneWeird> uh, why?
428 2014-01-15 04:26:03 <brianherman> is there an easier way?
429 2014-01-15 04:26:06 <brianherman> i have visual studio
430 2014-01-15 04:27:01 <SomeoneWeird> isn't there a cmake or something?
431 2014-01-15 04:27:08 <brianherman> no it uses autotools
432 2014-01-15 04:27:16 <SomeoneWeird> http://bitcoin.stackexchange.com/questions/587/how-do-i-build-bitcoin-source-in-windows-7
433 2014-01-15 04:28:39 <brianherman> bitcoin uses qt instead of wxwidgets
434 2014-01-15 04:29:07 <SomeoneWeird> it does now, yes, it should be relatively the same process though
435 2014-01-15 04:29:23 <brianherman> oh ok
436 2014-01-15 04:30:58 <jcorgan> petertodd: do you have it written up anywhere beside on the list?
437 2014-01-15 04:32:15 <brianherman> someoneweird: this is a better guide https://bitcointalk.org/index.php?topic=149479.0;all
438 2014-01-15 04:32:30 <warren> wumpus: fonts look better in wine with qt5 =)
439 2014-01-15 04:33:09 <petertodd> jcorgan: not yet
440 2014-01-15 04:33:31 <petertodd> jcorgan: it'll probably get turned into a BIP before long - jspilman is already implementing it
441 2014-01-15 04:34:41 <EasyAt> petertodd: Merkle trees full of transaction hashes?
442 2014-01-15 04:36:13 <EasyAt> Hash to the top and embed
443 2014-01-15 04:36:15 <petertodd> EasyAt: yup
444 2014-01-15 04:36:36 <petertodd> EasyAt: problem is, more of a timestamp than real proof of anything
445 2014-01-15 04:38:57 <EasyAt> http://utxo.tumblr.com/ me and my roomate love this
446 2014-01-15 04:40:07 <EasyAt> THough, I'm sure you've all seen it
447 2014-01-15 04:45:23 <EasyAt> petertodd: ^ you? :D
448 2014-01-15 04:48:11 <petertodd> EasyAt: not me, maaku, and I have my objections to his approach :)
449 2014-01-15 04:49:29 <jcorgan> if merchants used stealth addresses to receive payments, it would make it much easier for them to accept payment for a single logical transaction in the form of multiple stealth TXes, which would lessen the need for people to merge up their UTXOs...great benefit
450 2014-01-15 04:56:24 <petertodd> jcorgan: yeah, no-one's really mentioned stealth addr metadata I've noticed
451 2014-01-15 04:57:07 <petertodd> jcorgan: amir taaki did point out you can use one stealthed nonce for multiple payments, although the logic if you want to make multiple simultaneous payments can be a bit ugly
452 2014-01-15 04:58:53 <EasyAt> Is there any information on these stealth addresses?  I google and find nothing
453 2014-01-15 04:59:36 <petertodd> EasyAt: just one thread on bitcoin-development mailing list
454 2014-01-15 04:59:55 <jcorgan> wouldn't reusing the ephemeral pubkey allow the TXes to be linked in the blockchain by the common OP_RETURN data?
455 2014-01-15 05:01:48 <petertodd> jcorgan: I meant re-use as in using a pubkey that was already in the tx for the purpose of being a ephemeral pubkey
456 2014-01-15 05:03:54 <jcorgan> ah, got it
457 2014-01-15 05:08:45 <jcorgan> of course, now that we can have a fixed stealth addresses, someone has to write a generator for *vanity* stealth addresses :)
458 2014-01-15 05:10:03 <petertodd> jcorgan: lol! depending on how the addresses are constructed that might not be very difficult
459 2014-01-15 05:12:49 <jcorgan> well, they're not hashed, so I guess you'd just grind on 'd' until you get a 'Q' that encodes to your specification
460 2014-01-15 05:14:41 <jcorgan> said grinding to be done with a PRNG for 'd'
461 2014-01-15 05:14:57 <gmaxwell> If there is a free-form field for prefix identification you use that as a nonce in order to get an n-fold improvement over point addition.
462 2014-01-15 05:16:03 <jcorgan> can you break that down a bit
463 2014-01-15 05:18:27 <gmaxwell> jcorgan: petertodd was proposing that these addresses encode an optional 'cookie' that could be included in transactions to help limit the number of transactions which you must do expensive calculations to see if they're yours.  E.g. just a 8 bit (for example) random number.  It would reduce your privacy by the size of the prefix.
464 2014-01-15 05:19:24 <gmaxwell> so if you stick that prefix near the front of the address then your can vanity-grind that part very fast without updating one of the ecc points.
465 2014-01-15 05:19:58 <gmaxwell> also the ECC points can be grinded by just continually adding G to them, which is _much_ faster than doing the full multiply (each addition of G increases the private key by 1)
466 2014-01-15 05:20:24 <jcorgan> yeah, great idea
467 2014-01-15 05:20:40 <gmaxwell> if the encoding of the address is right, grinding that prefix could change the whole thing.
468 2014-01-15 05:21:28 <jcorgan> i don't think hashing was proposed, was it?
469 2014-01-15 05:21:56 <petertodd> jcorgan: you mean for scriptPubKey indexes?
470 2014-01-15 05:22:07 <gmaxwell> e.g. say your address material is [prefix][Q][P][flags]  and then change the encoding to [prefix] prefix(repeated) xor [Q][P][FLAGS]
471 2014-01-15 05:22:15 <jcorgan> for the published Q or Q,Q2 data
472 2014-01-15 05:22:35 <petertodd> jcorgan: how would that be hashed?
473 2014-01-15 05:22:37 <gmaxwell> then you could generate a new Q then solve for the prefix to make your vanity match, should such a prefix exist.
474 2014-01-15 05:22:57 <gmaxwell> and then that basically gives you 16 bits of vanity space for free.
475 2014-01-15 05:22:58 <jcorgan> i don't think it could be
476 2014-01-15 05:23:02 <gmaxwell> (e.g. no computation at all)
477 2014-01-15 05:23:56 <jcorgan> but I see now how gmaxwell is getting the "whole thing changes", which I though he was referring to changing a hash output
478 2014-01-15 05:24:13 <gmaxwell> (I'd say you got it for free anyways, but not all Q values points, so some vanity would be unreachable without some kind of permutation)
479 2014-01-15 05:25:21 <jcorgan> you'd start with a random 'd', generate a trial Q, then just keep adding G to it, so there's no risk of someone else duplicating the vanity key if the initial 'd' had high enough entropy, right?
480 2014-01-15 05:25:52 <gmaxwell> OTOH, I've thought before that anti-vanity constructions are better that pro-vanity. :(  The problem is that vanity addresses strongly encourage clearly insecure behavior.
481 2014-01-15 05:26:05 <gmaxwell> jcorgan: correct.
482 2014-01-15 05:26:05 <gmaxwell> (there were hundreds of lookalike silkroad onion domain names)
483 2014-01-15 05:30:34 <jcorgan> ah, like typo'd domain names.  I wonder, without hashing, how to create a checksum for the encoding so simple changes become invalid
484 2014-01-15 05:31:27 <jcorgan> i don't see how it is possible
485 2014-01-15 05:31:43 <gmaxwell> it's not hard to do that, just an error correcting code. The problem is that e.g. my address is gmaxwell29348923849  and someone else gives you gmaxwell589438593  ... it's entirely different but you're only paying attention to the gmaxwell part.
486 2014-01-15 05:31:55 <jcorgan> yeah
487 2014-01-15 05:32:47 <gmaxwell> What can be done instead is just making it more difficulty to generate a vanity address at all. E.g. by requiring that the hash of any valid address begin with 24 zeros.
488 2014-01-15 05:33:43 <jcorgan> i don't suppose there are any economic incentives that would pay for a vanity address generator ASIC development effort :)
489 2014-01-15 05:34:16 <gmaxwell> (if the addresses weren't space constrained, even better would be to require that any vanity addresses encode two addresses such that the hashes of the addresses were partial collisions ... since doing that gives a quadratic advantage to someone who doesn't care what their address looks like)
490 2014-01-15 05:35:12 <gmaxwell> jcorgan: well if someone does that, more power to them. :P
491 2014-01-15 05:35:14 <jcorgan> dude, you should have someone following you around logging everything you say.  oh wait...
492 2014-01-15 05:35:30 <Denim-jdev> I don't understand why you are trying to stamp out vanity addresses.  Just to stop stupid people from making stupid mistakes?
493 2014-01-15 05:35:57 <lechuga__> i want mine to say 1ThUGNazTY... but it's going to take 10 thousand years
494 2014-01-15 05:36:01 <lechuga__> seems worth the wait
495 2014-01-15 05:36:13 <Denim-jdev> It's like trying to remove bitcoin because people get their wallets "hacked"
496 2014-01-15 05:37:24 <maaku> Denim-jdev: he just gave a great reason why people shouldn't use vanity addresses...
497 2014-01-15 05:38:16 <Denim-jdev> and I'm saying that that reason only applies to stupid people making stupid mistakes
498 2014-01-15 05:39:24 <Denim-jdev> should we ban video games because some people confuse fantasy with reality, and act violently IRL?
499 2014-01-15 05:39:31 <Denim-jdev> I feel like it's punishing everyone else
500 2014-01-15 05:39:51 <jcorgan> well, it might actually make a MITM address substitution more effective
501 2014-01-15 05:39:55 <Denim-jdev> If it's really a problem, people will just stop using vanity addresses to prevent people from getting their vanity address confused with another
502 2014-01-15 05:42:14 <maaku> Denim-jdev: as developers, we have a responsibility for making systems where safety is the default even without user education
503 2014-01-15 05:42:26 <gmaxwell> Denim-jdev: the whole purpose of having software is to make things accessible to people. Technically if I gave you nothing more than a terminal and assembler you could write the whole thing yourself.  Part of why we do this is to embed expert understanding into the software— the product of many minds considering for months a single action that your computer does in an instant— and that includes making the software safe against ...
504 2014-01-15 05:42:32 <gmaxwell> ... probable poor use.
505 2014-01-15 05:43:24 <gmaxwell> Obviously this sometimes presents tradeoffs between flexibility and safty. Though usually you can have both.  "Vanity" addresses really skirt the borderline of unsafe-at-any-speed.
506 2014-01-15 05:44:00 <phillipsjk> It is ok if you use a new Vanity address with every transaction :)
507 2014-01-15 05:44:05 <jcorgan> LOL
508 2014-01-15 05:44:08 <gmaxwell> Certantly they're safe if you don't ever look at them, except to the extent that they cause poor practices like bad key management (address reuse, manual key handling...).  But they're also pointless if no one looks at them.
509 2014-01-15 05:44:23 <lechuga__> lol
510 2014-01-15 05:44:26 <gmaxwell> If people do look at them they present extra risks.
511 2014-01-15 05:45:17 <gmaxwell> ... because, you know, you might actually do something based on looking at them. ... like assume a vanity onion beginning with "silkroad" is probably actually silkroad. ... I mean, duh, thats why it's vanity.
512 2014-01-15 05:46:19 <gmaxwell> if people generated vanity addresses in a different way, selecting their name of their service based on picking from a long selection of probably comprehensible vanitys, then that might be interesting... because they might actually end up with a name whos comprehensible part was longer than any attacker was going to match.
513 2014-01-15 05:47:19 <gmaxwell> But then you have to name your service something dorky, because thats the best the tool produced.
514 2014-01-15 05:47:30 <lechuga__> im constantly sending cash to these nigerians @ 1redcrossRJz9TZjr81NtdUQ5XDKitsQHEx
515 2014-01-15 05:48:04 <brianherman> why lechuga_
516 2014-01-15 05:48:14 <lechuga__> falling for their spam
517 2014-01-15 05:48:28 <brianherman> lol
518 2014-01-15 05:48:46 <lechuga__> tab completion is a double-edged sword
519 2014-01-15 05:48:51 <gmaxwell> (e.g. 1KATWALSHTHECuz5DFHoNqJax6hnDbL6KN is an address I grinded out)  ... 2^82 work to reproduce the KATWALSHTHECuz part... but geesh, who'd want to use an address like that.
520 2014-01-15 05:49:21 <lechuga__> lol
521 2014-01-15 05:55:51 <Denim-jdev> I can somewhat understand the onion adresses - it's easier to remember a word than all characters in a word.  This doesn't apply to bitcoin though, as nobody is memorizing an entire address even with vanity
522 2014-01-15 05:56:11 <Denim-jdev> I'll have to think on the other arguments, thanks for clarification
523 2014-01-15 05:57:58 <lechuga__> i was joking but some1 could search 'redcross bitcoin address' and see someone scamming and A) not notice the domain of the url wasnt redcross.org and B) the vanity address and just copy itdirectly from the goog search results without even clicking
524 2014-01-15 05:59:01 <lechuga__> doesnt seem super probable but its a non-0 risk for sure
525 2014-01-15 05:59:13 <lechuga__> and needless really
526 2014-01-15 06:00:29 <andytoshi> as an illustration of this vanity thing, i routinely coinjoin my money to vanity addresses with other IRC user's names in them
527 2014-01-15 06:00:34 <andytoshi> mainly sipa, his is short :)
528 2014-01-15 06:06:30 <lechuga__> do bitpay/coinbase implement BIP 70 yet?
529 2014-01-15 06:08:55 <amiller> who wants to talk about assurance contracts
530 2014-01-15 06:09:10 <lechuga__> listening
531 2014-01-15 06:09:12 <amiller> as usual there's a wiki article, written by mike in this case, that suggests you can do it with bitcoin, but it's not entirely correct and pretty misleading
532 2014-01-15 06:09:15 <amiller> https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts
533 2014-01-15 06:09:44 <amiller> in an assurance contract, a party makes a binding commitment of the form "i will pay $10 to A, as long as $100 of commitments are reached in total before time X"
534 2014-01-15 06:09:49 <amiller> in the protocol described on this wiki, there's a move where a sufficient number of txinputs are collected, a party signs that transaction
535 2014-01-15 06:09:57 <amiller> the problem is, this is *not* a binding commitment
536 2014-01-15 06:10:01 <amiller> that first party could spend their coin away first
537 2014-01-15 06:11:05 <petertodd> amiller: heh, I've heard a few newbies get real confused on that point
538 2014-01-15 06:11:22 <petertodd> amiller: that mechanism is also rather dangerous because it's easy to wind up with huge fees...
539 2014-01-15 06:11:50 <amiller> what sucks is, i want to be able to use assurance contracts and dominant assurance contracts especially, as guiding examples for a more expressive scripting language
540 2014-01-15 06:11:52 <petertodd> amiller: and the "funding network security" bit is hilariously wrong
541 2014-01-15 06:12:16 <amiller> (note to whoever, turing complete has absolutely nothing to do with what expressive means in this case)
542 2014-01-15 06:12:40 <amiller> it's hard to use it as an example when it's already canon that current script is sufficient to implement it
543 2014-01-15 06:12:43 <petertodd> amiller: heh, re-write that section pointing how how badly the mechanism works and see how long it takes to get reverted :)
544 2014-01-15 06:13:05 <amiller> so it gets me pissed when the claim is that it impelments assurance contracts when due to a (admittedly subtle) detail, it doesnt
545 2014-01-15 06:13:20 <petertodd> amiller: I swear, it's like the guy had about a half-dozen semi-good ideas and had held on to them for dear life ever since :P
546 2014-01-15 06:14:23 <petertodd> amiller: oh, actually, given I fixed the funding network security page, you could use that as an actual example...
547 2014-01-15 06:15:02 <petertodd> amiller: or make your example "funding an alt-coin attack via complex scripts" works equally well...
548 2014-01-15 06:15:19 <amiller> so assurance contracts are of financial importance
549 2014-01-15 06:15:24 <amiller> that's pretty different than the example i usually use
550 2014-01-15 06:15:27 <amiller> which is a funded chess game
551 2014-01-15 06:15:29 <amiller> or a funded poker game
552 2014-01-15 06:15:53 <amiller> attacking other altcoins etc, like those, kind of goes under esoteric sort of wacky-finance
553 2014-01-15 06:16:32 <amiller> an auction is the classic economically-meaningful example but i don't want to use that as an example because there's privacy things with it too
554 2014-01-15 06:17:06 <amiller> this wouldn't be the first time i've tried to edit a bunch of crap that mike's written on the wiki, but it's tricky because i don't disagree with the sentiment of it just a detail about whether current script is sufficient
555 2014-01-15 06:17:18 <amiller> i also hate the agents page for similar reasons but... that's separate
556 2014-01-15 06:17:28 <amiller> anyway i'm not sure what i'd revise this page to say
557 2014-01-15 06:17:35 <amiller> "no assurance contracts don't appear to be possible?"
558 2014-01-15 06:17:43 <petertodd> heh, ever noticed I've never bothered toughing the scalability page?
559 2014-01-15 06:17:46 <amiller> "the following script is not an assurance contract but a poor approximation?"
560 2014-01-15 06:18:03 <petertodd> "An approximation of assurance contracts can be made"?
561 2014-01-15 06:18:04 <lechuga__> is the fundamental issue just that the coins can be spent prior to broadcasting the txn?
562 2014-01-15 06:18:13 <lechuga__> or are there more flaws
563 2014-01-15 06:18:31 <lechuga__> the oracle example has a similar issue
564 2014-01-15 06:18:33 <lechuga__> sort of
565 2014-01-15 06:18:42 <amiller> oracle is a woowoo word for trusted third party
566 2014-01-15 06:18:47 <petertodd> lechuga__: that's the reason it's not a contract, and on top of that it's easy to have too many people sign funds to the contract, and create a huge-fee tx
567 2014-01-15 06:19:01 <lechuga__> well also it suggests broadcasting the contract at the time of claim
568 2014-01-15 06:19:04 <amiller> i think that's the only problem with "Assurance Contracts" as such, but i would actually prefer to implement dominant assurance contracts
569 2014-01-15 06:19:28 <amiller> but i want to be clear that a dominant assurance contract is not a contrived extension to make it not-possible-with-current-script
570 2014-01-15 06:19:36 <amiller> even ordinary assurance contracts aren't possible with current script
571 2014-01-15 06:21:16 <lechuga__> when you say "not possible with current script" are you implying extending the script language would make it possible?
572 2014-01-15 06:21:29 <amiller> yes
573 2014-01-15 06:22:04 <lechuga__> i guess i believe that
574 2014-01-15 06:22:38 <lechuga__> seems like people fear allowing a more rich evaluation of the script
575 2014-01-15 06:22:51 <lechuga__> kinda sucks imo but i get it
576 2014-01-15 06:22:55 <petertodd> lechuga__: people fear changing anything, and I can't blame them
577 2014-01-15 06:24:54 <lechuga__> a 0-day bitcoin exploit sort of has more of an immediate financial and social impact than a buffer overflow in splitvt
578 2014-01-15 06:25:37 <petertodd> lechuga__: potentially harder to fix too
579 2014-01-15 06:25:56 <lechuga__> right you might not get a chance to release a patch
580 2014-01-15 06:26:41 <petertodd> lechuga__: yeah, and testing the patch is harder for a lot of reasons...
581 2014-01-15 06:27:28 <lechuga__> im still surprised its comprehensive as it is (accounting for non-standard permutations)
582 2014-01-15 06:27:45 <lechuga__> it wouldnt have occurred to me to to put so many opcodes in v0
583 2014-01-15 06:28:08 <lechuga__> well i dont mean to imply any of the rest of it wouldve been especially obvious to me
584 2014-01-15 06:28:22 <lechuga__> just seems liek a quirky detail
585 2014-01-15 06:29:13 <lechuga__> seems like overkill for a ref impl
586 2014-01-15 06:29:15 <petertodd> ha, yeah, we got lucky satoshi had the idea of contracts... but then it all got disabled ;(
587 2014-01-15 06:29:30 <lechuga__> u seem bitter :)
588 2014-01-15 06:30:52 <petertodd> well I do hold the distinction of doiing the second most sophisticated thing ever with bitcoin scripts... which was to make a bounty for anyone who can find a sha1/sha256/etc hash collission
589 2014-01-15 06:30:53 <lechuga__> and 'contract' doesn't occur at all in the pdf
590 2014-01-15 06:30:56 <petertodd> not exactly rocket surgery
591 2014-01-15 06:31:11 <lechuga__> heh
592 2014-01-15 06:32:44 <gmaxwell> lechuga__: most of the opcodes are standard stack machine fare.
593 2014-01-15 06:32:59 <lechuga__> yeah suppose thats true
594 2014-01-15 06:33:09 <gmaxwell> without them things would be unfun if you tried to actually do anything.
595 2014-01-15 06:33:23 <lechuga__> i dont study finite automata much tho
596 2014-01-15 06:33:30 <petertodd> lechuga__: I'll bet you satoshi looked up "forth" on wikipedia and copied the first opcode list he found
597 2014-01-15 06:33:33 <gmaxwell> unfortunately, there is enough disabled that it's awful tricky to do anything.
598 2014-01-15 06:33:36 <lechuga__> lol
599 2014-01-15 06:34:16 <gmaxwell> petertodd: that lottery transaction is more complex than the collision bounties.
600 2014-01-15 06:34:38 <gmaxwell> the collision bounties are probably the most complex script ever done that can be easily explained, however. :P
601 2014-01-15 06:34:38 <petertodd> gmaxwell: that's why I said second most
602 2014-01-15 06:34:52 <gmaxwell> oh indeed you did, I missed that word.
603 2014-01-15 06:34:56 <petertodd> heh
604 2014-01-15 06:35:08 <petertodd> but for a brief period I was the champ :P
605 2014-01-15 06:35:27 <petertodd> heh, and actually I'll argue announce-commit sacrifices held that too, although for rather different reasons
606 2014-01-15 06:36:03 <gmaxwell> alas bragging about your transactions is adverse to the privacy of your coins.
607 2014-01-15 06:36:29 <petertodd> lol!
608 2014-01-15 06:36:33 <lechuga__> lol
609 2014-01-15 06:36:54 <petertodd> gmaxwell: um, well, I've done a dozen coinswap transactions... where both parties co-operated
610 2014-01-15 06:37:53 <gmaxwell> there may have been some transaction types that I was the first to use on the public network, or not. there was a bunch of stuff I did first in testnet. (mostly I've not done goofy things in the main network since testnet has been around)
611 2014-01-15 06:38:29 <gmaxwell> well, I think I may have been the first person to do a joint transaction of any kind, certantly the first publically known one.
612 2014-01-15 06:38:40 <gmaxwell> well obviously since it was joint its a shared honor. :P
613 2014-01-15 06:38:50 <gmaxwell> But I doubt the other party would reveal themselves!
614 2014-01-15 06:39:03 <petertodd> lol
615 2014-01-15 06:39:49 <lechuga__> what do you mean joint
616 2014-01-15 06:39:51 <lechuga__> like a multisig?
617 2014-01-15 06:40:16 <petertodd> at least you don't hold the dubious distinction of being responsible enough to blame for OP_RETURN...
618 2014-01-15 06:44:36 <gmaxwell> lechuga__: like this https://blockchain.info/tx-index/47371647/69d9d66aae4812b6cf156f32267b773fb2118db696bb847ebd3454a198b59fbd
619 2014-01-15 06:45:17 <petertodd> lechuga__: gmaxwell is basically saying he's either stinking rich, or clever
620 2014-01-15 06:47:28 <gmaxwell> petertodd: oh stop. It's especially halarious now that Bc.i defaults to saying 33 million dollars.
621 2014-01-15 06:47:54 <gmaxwell> lechuga__: this thread explains: https://bitcointalk.org/index.php?topic=139581.0
622 2014-01-15 06:56:36 <HaltingState> sipa, if i have two people A,B and a public key for A and i want B to generate an address than only B has private key
623 2014-01-15 06:56:53 <HaltingState> do i just multiple the secret key as point on a curve with the private key for A
624 2014-01-15 07:12:09 <abrkn> what does "secret key" for m/0'/1 mean in https://en.bitcoin.it/wiki/BIP_0032_TestVectors ? isnt that a public chain?
625 2014-01-15 07:20:59 <abrkn> how can a chain m/0'/1/1' even exist? assuming ' means private derivation
626 2014-01-15 08:00:34 <swulf--> abrkn: m/0'/1 still has a private key associated with it
627 2014-01-15 08:02:34 <abrkn> swulf: then what is the point of the ' notation? i dont think i understand internal vs external vs private vs public
628 2014-01-15 08:02:53 <swulf--> the ' notation tells you what your source of derivation is
629 2014-01-15 08:04:42 <swulf--> if your node _has_ a private key, then you use the k_child = IL + k_parent (mod N) algorithm, and the ' notation denotes whether you use the parents private key or public key to derive IL.
630 2014-01-15 08:05:29 <swulf--> if you node doesn't have a private key, then you can't use the k=IL+kpar formula, you have to use the K_child = IL*G + K_parent formula, and IL has to come from the public key of the parent
631 2014-01-15 08:05:51 <swulf--> (k = private key, K = public key)
632 2014-01-15 08:06:18 <abrkn> ok. what would be a scenario in which you'd have a path like m/0/0'/0?
633 2014-01-15 08:06:30 <swulf--> and 'internal' vs 'external' is just a naming convention given to the derivation paths m/0'/0 and m/0'/1
634 2014-01-15 08:06:57 <swulf--> abrkn: whatever scenario you want to give it; it's an arbitrary usage
635 2014-01-15 08:08:18 <abrkn> ok, i didnt quite understand the naming convention. what is internal and external in this context?
636 2014-01-15 08:08:47 <swulf--> external - addresses you give to other people (m/k'/0/i, where k is the account and i is the keypair index), and internal would be things like change and mixing addresses
637 2014-01-15 08:08:54 <swulf--> abrkn: check out my bip32.org site
638 2014-01-15 08:09:38 <abrkn> swulf: i've been reading it hard. well coded :)
639 2014-01-15 08:09:44 <swulf--> thanks
640 2014-01-15 08:10:08 <swulf--> I'm considering whipping up stealth address transaction generation.. could do it quickly
641 2014-01-15 08:10:18 <abrkn> k(account) like a user id?
642 2014-01-15 08:10:35 <abrkn> or wallet id or whatever
643 2014-01-15 08:10:42 <swulf--> consider something like, Marketing (account=1), Production (account=2), Travel (account=3), etc
644 2014-01-15 08:11:09 <swulf--> it's heirarchical and you can label the accounts anything you want
645 2014-01-15 08:11:56 <abrkn> swulf: i'm looking at this for an exchange. was hoping to have m/0 cold wallets, m/0/0 cold wallet 0, m/userid/depositaddressindex
646 2014-01-15 08:12:10 <abrkn> err, m/1/userid/depositaddressindex for users
647 2014-01-15 08:12:16 <swulf--> m being the master key for the site?
648 2014-01-15 08:12:25 <abrkn> right, so m would be stored offline
649 2014-01-15 08:12:50 <swulf--> I would take the key m/0'/0 as the "master user account key", and derive from that m/user_id'/0/keypair
650 2014-01-15 08:13:10 <swulf--> so the final keys for a user would be m/0'/0/user_id'/0/i  where i increments to create new addresses
651 2014-01-15 08:13:25 <swulf--> if you need internal addresses for users, use m/0'/0/user_id'/1/i
652 2014-01-15 08:14:12 <abrkn> this internal/external level is confusing me :)
653 2014-01-15 08:14:17 <swulf--> ignore it then
654 2014-01-15 08:14:23 <swulf--> its nothing functional, just a naming convention
655 2014-01-15 08:14:34 <abrkn> ok, but im sure theres a good reason for it and im just missing it
656 2014-01-15 08:15:00 <swulf--> you know how bitcoind works?
657 2014-01-15 08:15:07 <swulf--> the wallet contains addresses that are not shown to the user
658 2014-01-15 08:15:14 <swulf--> change addresses, for example
659 2014-01-15 08:15:32 <abrkn> i just use it in console, really
660 2014-01-15 08:15:45 <abrkn> it does getnewaddress to send change to?
661 2014-01-15 08:15:59 <swulf--> when you use getnewaddress, it produces an external address
662 2014-01-15 08:16:14 <swulf--> when you spend from the address, internally a change address is used. that's an internal address
663 2014-01-15 08:16:49 <abrkn> so an external address would be what i consider my wallet
664 2014-01-15 08:16:56 <abrkn> and internal addresses would be change addresses
665 2014-01-15 08:17:02 <swulf--> your wallet is a collection of all your internal + external addresses
666 2014-01-15 08:17:04 <abrkn> so inputs would be both internal/external when sending tx'
667 2014-01-15 08:17:10 <swulf--> yes
668 2014-01-15 08:44:00 <HaltingState> is an ECC private key just inverse of the public key
669 2014-01-15 08:49:14 <gmaxwell> What do you mean?  (if you're asking if its 1/public_key, .. no)
670 2014-01-15 08:55:40 <abrkn> swulf: phew, my code finally starting to pass the test vectors :)
671 2014-01-15 09:14:13 <abrkn> swulf--: https://gist.github.com/abrkn/8910f751a16160287166
672 2014-01-15 10:08:44 <TD> https://googledrive.com/host/0B5ZorpZjIRsZUktlLUc2RWpFNWM/BlockchainInfoGoogleServices.html
673 2014-01-15 10:08:44 <TD> lol
674 2014-01-15 10:08:45 <TD> wtf
675 2014-01-15 10:08:50 <TD> someone put a lot of effort into that
676 2014-01-15 10:12:13 <matjeh> wow
677 2014-01-15 10:12:38 <matjeh> its like those banners "is your credit card stolen? enter your card # here :  ________"
678 2014-01-15 10:13:11 <TD> those sites are amateur though. the best ones say "To comply with US regulations around the distribution of pornographic material, we need to verify your age. Please enter your CC# here _____________"
679 2014-01-15 10:13:25 <TD> not that it really matters for credit cards
680 2014-01-15 10:18:26 <gmaxwell> careful with the links to malicious stuff, someone has been hitting people with an apparent JVM zero-ish-day, and some IRC regulars (not me) have lost over 100 BTC that way. No telling when something nasty will add an additional flavor of nastyness.
681 2014-01-15 10:18:48 <TD> ugh
682 2014-01-15 10:18:54 <TD> chrome, people!
683 2014-01-15 10:19:02 <TD> sandboxes within sandboxes. it's the only way to go
684 2014-01-15 10:20:10 <Eagle[TM]> gmaxwell: on Linux? wow
685 2014-01-15 10:20:12 <gmaxwell> I believe the people hit have been in IE, so — well.. there you go. In any case, if you're going to load known malicious websites best to do it on a sandboxed _machine_, certantly not one with access to lots of coin. :)
686 2014-01-15 10:20:21 <Eagle[TM]> ok IE :)
687 2014-01-15 10:20:21 <TD> ah
688 2014-01-15 10:20:27 <TD> my statement stands ...
689 2014-01-15 10:20:31 <gmaxwell> Eagle[TM]: no on windows, I dunno anyone hit on linux, though the attack payload works on linux/win/macosx.
690 2014-01-15 10:20:40 <TD> Eagle[TM]: technically some java exploits can work on all platforms. write once run anywhere, right?
691 2014-01-15 10:20:53 <gmaxwell> I don't know if the attack vector works outside of windows though.
692 2014-01-15 10:20:58 <TD> though chrome disabled applets a long time ago
693 2014-01-15 10:21:05 <Eagle[TM]> yea i'm glad firefox disables java by default now
694 2014-01-15 10:21:05 <TD> firefox requires you to explicitly activate them
695 2014-01-15 10:21:08 <gmaxwell> Right. Thus IE.
696 2014-01-15 10:21:08 <TD> so ..... i guess that's why it can hit IE
697 2014-01-15 10:21:29 <Eagle[TM]> gmaxwell: Thx for the heads-up!
698 2014-01-15 10:21:38 <gmaxwell> well plus, the web has made us all click monkies, if you haven't clicked on something and regretted it.. I think you're not paying attention. :P
699 2014-01-15 10:25:36 <Arnavion> Latest Java has atleast one fix which is specific to Gnome on Linux
700 2014-01-15 10:26:05 <Arnavion> And most others are applets
701 2014-01-15 10:26:07 <TD> haha, alt coin innovation: https://github.com/sidhujag/devcoin-android/commit/119b0c5ec4595d1d2fbe5dc9dda7aed4c8b85a92
702 2014-01-15 10:26:15 <Arnavion> so not really IE-specific
703 2014-01-15 11:55:41 <sipa> ;;blocks
704 2014-01-15 11:55:42 <gribble> 280614
705 2014-01-15 12:17:47 <fanquake> ;;tslb
706 2014-01-15 12:17:52 <gribble> Time since last block: 10 minutes and 47 seconds
707 2014-01-15 12:28:04 <mrkent> is there a guide on best practice of securing a hot wallet for a bitcoin web app?
708 2014-01-15 12:31:03 <shamoon> in a bitcoin transaction, is the "hex" field guaranteed to be unique?
709 2014-01-15 12:31:26 <sipa> what is the 'hex' field?
710 2014-01-15 12:35:13 <shamoon> https://gist.github.com/anonymous/92a518f60f89fb1e6a55
711 2014-01-15 12:38:11 <shamoon> i assume that hex is the raw transaction
712 2014-01-15 12:38:13 <shamoon> not decoded
713 2014-01-15 12:38:16 <shamoon> and is guaranteed to be unique?
714 2014-01-15 12:39:25 <sipa> yes, that's the entire serialized transaction, encoded as a hex string
715 2014-01-15 12:40:09 <sipa> and within a bitcoin blockchain they are certainly unique
716 2014-01-15 12:41:40 <sipa> a transaction may occur in several branches though
717 2014-01-15 13:33:24 <warren> wumpus: RHEL and Fedora openssl lacks secp256k1.  That means the new gitian binary can't work there and users can't build bitcoin from source without replacing their system openssl.  Totally not cool.