1 2013-12-22 00:51:34 <saivann> In case you want to comment, I plan to merge this pull req tomorrow: https://github.com/bitcoin/bitcoin.org/pull/286
  2 2013-12-22 00:51:40 <saivann> This pull req temporarily add Google Analytics to bitcoin.org (and will be reverted a week later), so we can have a better estimation of the traffic in order to choose and setup a dedicated server.
  3 2013-12-22 00:57:08 <gmaxwell> saivann: fwiw, I'd asked luke about his comment and got a "I wasn't NACKing, just asking. :p"
  4 2013-12-22 01:01:33 <saivann> gmaxwell: thanks
  5 2013-12-22 01:22:06 <jacob___> hey guys
  6 2013-12-22 01:22:47 <jacob___> in code I see that ssl api key generation is used to generate wallet keys
  7 2013-12-22 01:23:30 <jacob___> how many keys are out there in the blockchain as of this moment?
  8 2013-12-22 01:23:39 <jacob___> what is the chance of collisions?
  9 2013-12-22 01:25:22 <upb> ssl api?!
 10 2013-12-22 01:26:17 <jacob___> yup
 11 2013-12-22 01:26:36 <jacob___> int EC_KEY_generate_key(EC_KEY *key);
 12 2013-12-22 01:26:59 <jacob___> how does it get its randomness?
 13 2013-12-22 01:28:14 <gmaxwell> jacob___: this channel is for the active development and operation of the bitcoin network and software, if you'd like to ask in #bitcoin I'd be glad to answer you there.
 14 2013-12-22 01:28:38 <jacob___> sure np
 15 2013-12-22 02:25:14 <wangbus> warren: hey
 16 2013-12-22 02:46:03 <uiop> \
 17 2013-12-22 02:54:07 <BlueMatt> petertodd: I dont think anyone has ever given the bloom filter stuff any serious thought (I hadnt until I spent ~30 minutes last night staring at it, and realized the spec is fairly broken to begin with)
 18 2013-12-22 02:54:12 <BlueMatt> petertodd: so, no, dont think there's a writeup
 19 2013-12-22 02:55:11 <BlueMatt> petertodd: there are also some subtleties to implementing them right (https://code.google.com/p/bitcoinj/issues/detail?id=502 and https://code.google.com/p/bitcoinj/issues/detail?id=504 though those are partially due to some recent changes that made the api more generic and introduced some bugs)
 20 2013-12-22 02:55:41 <BlueMatt> petertodd: also, the false positive set for a bloom filter does stay constant, given you keep a constant tweak value, which is fairly reasonable
 21 2013-12-22 02:57:18 <BlueMatt> petertodd: I suppose all of that's my fault since I wrote the original spec/implementation when I had like a free few days and then didnt give it any serious thought as I tweaked it to make it work practically...which quite broke it
 22 2013-12-22 03:00:12 <CodeShark> so much complexity in client logic to cope with scalability issues
 23 2013-12-22 03:02:39 <CodeShark> makes me hope we'll ultimately find a much better solution for prunability
 24 2013-12-22 03:09:38 <CodeShark> perhaps a CAS which can provide a set of transactions for a filter, then a way of obtaining minimal proofs from nodes that they are part of the main chain
 25 2013-12-22 03:10:06 <CodeShark> without having to download individual block structures at all
 26 2013-12-22 03:11:15 <CodeShark> combining the proof for multiple transactions without the need to download a chain of merkle blocks
 27 2013-12-22 03:12:03 <CodeShark> also, by introducing an ordering rule to the transactions in a block, we could provide proofs of absence of transactions
 28 2013-12-22 03:13:06 <gmaxwell> CodeShark: they're dependency ordered now. but proving a transaction is not in a single block is not terrible interesting usually.
 29 2013-12-22 03:13:43 <CodeShark> gmaxwell: it makes withholding attacks more difficult
 30 2013-12-22 03:14:24 <CodeShark> although in practice, it is difficult to pull them off unless you control the wire to the device
 31 2013-12-22 03:15:37 <gmaxwell> its the txout you want to prove presence/absense of there.
 32 2013-12-22 03:16:30 <CodeShark> gmaxwell: true - the CAS should be possible to query by output
 33 2013-12-22 03:18:10 <CodeShark> it would be interesting to build a CAS funded by bitcoin :)
 34 2013-12-22 03:18:23 <CodeShark> you get compensated for the resources you provide to the network
 35 2013-12-22 03:23:21 <CodeShark> I suppose even being able to download multiple merkle blocks in a single network roundtrip could significantly speed up client sync times
 36 2013-12-22 03:27:06 <CodeShark> and rather than sending the individual transactions as separate messages, they could be incorporated into the same merkle block message
 37 2013-12-22 03:27:46 <BlueMatt> you can do like 500 blocks per network roundtrip (well, 500 merkle blocks in parallel)
 38 2013-12-22 03:28:03 <BlueMatt> and, meh, as long as they are sent back-to-back the cost of the separate messages isnt that bad
 39 2013-12-22 03:28:17 <BlueMatt> the real cost is the bloom filter design just wasnt that good
 40 2013-12-22 03:28:34 <BlueMatt> (not to say there's an obvious solution, but its not ideal as it is today)
 41 2013-12-22 03:36:38 <CodeShark> well, assuming the client always does a headers-only sync first, it is wasteful for a filtering node to provide trivial merkle blocks
 42 2013-12-22 03:37:42 <CodeShark> say instead the client provided a height range, or a starting timestamp
 43 2013-12-22 03:38:03 <CodeShark> the filtering peer could simply omit the trivial merkle blocks
 44 2013-12-22 03:40:33 <CodeShark> moreover, if the client already has the block headers, the merkle block messages would only need to contain the hash lists
 45 2013-12-22 03:40:41 <CodeShark> and flags field
 46 2013-12-22 03:42:57 <CodeShark> and total transactions, I suppose, to compute the depth
 47 2013-12-22 03:44:21 <CodeShark> we could eliminate up to 80 bits per nontrivial merkle block, and eliminate trivial merkle blocks entirely
 48 2013-12-22 03:46:52 <CodeShark> the headers-only sync can be done in parallel, without giving up any privacy whatsoever
 49 2013-12-22 03:47:54 <BlueMatt> CodeShark: why is the client doing a headers-first sync for merkle blocks? the advantage of headers-first is largely lost if you're only downloading headers and a few extra txn per block
 50 2013-12-22 03:52:24 <CodeShark> BlueMatt: headers-first sync means you can add 2000 headers per network roundtrip with no filtering overhead
 51 2013-12-22 03:52:55 <CodeShark> moreover, once you have a local block tree you can share it between multiple devices or multiple applications
 52 2013-12-22 03:53:31 <BlueMatt> meh, you really dont gain much there
 53 2013-12-22 03:53:52 <CodeShark> you do if you're running, say, 10 different apps that all use the service
 54 2013-12-22 03:53:58 <BlueMatt> you gain some number of headers per network roundtrip (not many), and the filtering overhead isnt much (locally, its more remote, but who cares)
 55 2013-12-22 03:54:25 <BlueMatt> realistically the difference between syncing with a fairly low-fp-rate bloom filter and doing just headers-only isnt much
 56 2013-12-22 03:54:26 <CodeShark> in any case, I like the idea of separating proof-of-work validation from proofs of tx inclusion in blocks
 57 2013-12-22 03:54:38 <BlueMatt> its already separate...
 58 2013-12-22 03:56:40 <CodeShark> it's separate logically - but the two are intertwined in merkle block structures
 59 2013-12-22 03:58:13 <CodeShark> say you already have a local copy of the block tree - you import a set of keys in a wallet, the wallet needs to now go fetch proofs of output existence and inclusion in blocks
 60 2013-12-22 03:58:41 <CodeShark> perhaps there are only a handful of blocks that are relevant at all
 61 2013-12-22 04:03:04 <BlueMatt> true, though key imports of old keys are rare enough...
 62 2013-12-22 04:03:43 <BlueMatt> the two arent intertwined at all, except that the proof of tx inclusion has to point to a specific block
 63 2013-12-22 04:03:57 <BlueMatt> they happen to be in the same message because that makes it easy
 64 2013-12-22 04:07:36 <CodeShark> networking issues aside, the block tree is a universally relevant structure for all nodes while merkle blocks are just specific proofs of inclusions of specific transactions
 65 2013-12-22 04:08:39 <BlueMatt> true, I just dont see the advantage in separating the tiny additional data and downloading it separately, aside from the uncommon case where you only need the merkle tree inclusion proofs
 66 2013-12-22 04:17:34 <CodeShark> I guess what I'm trying to say is that regardless of how we perform filtering, the block header tree structure must be checked. But the way we prove inclusion of transactions/outputs in the block chain affords some creativity
 67 2013-12-22 04:18:04 <BlueMatt> true, and it should be tweaked as there are clearly better ways of doing it
 68 2013-12-22 07:37:50 <stapler> quick question for you guys
 69 2013-12-22 07:37:55 <stapler> how does the p2p work in bitcoin
 70 2013-12-22 07:46:38 <CodeShark> stapler: it might help if you make your question more specific
 71 2013-12-22 07:47:13 <CodeShark> if it's a very broad, basic question I would recommend asking in #bitcoin rather than #bitcoin-dev
 72 2013-12-22 07:51:25 <RoboTeddy> if disk and bandwidth were nearly free, and there was no block size limit, would the market transaction fee be near 0?
 73 2013-12-22 07:51:35 <RoboTeddy> (also if there's a better venue for that question, just yell at me)
 74 2013-12-22 07:52:16 <CodeShark> RoboTeddy: there's also the computational cost of validating and relaying the transaction
 75 2013-12-22 07:53:27 <RoboTeddy> CodeShark: good point. but if moore's law keeps up, so to speak, those things might become cheap more quickly than the amount of important transactional data rises
 76 2013-12-22 07:54:45 <RoboTeddy> long-term, why would we expect tx fees to be high enough to properly secure the network? could we keep an artificial block size limit in place to create competition for space (and thus tx fees?)
 77 2013-12-22 07:58:01 <theboos> Ah, I think I understand what you're getting at. Mining will be self balancing in that difficulty rises and falls to match hashrate, but your concern is that difficulty and hashrate will not increase as quickly as hardware improves and block reward falls?
 78 2013-12-22 08:00:16 <theboos> so that though we might reach 1 billion petahashes/s (I've lost track of the SI prefixes above that :P) in a few tens of years, the actual cost of deploying another billion petahashes/s might be within the ability of nefarious agencies in the longer term?
 79 2013-12-22 08:03:41 <CodeShark> the bigger threat is if there's a sudden collapse in mining power on the network because the block rewards are too low
 80 2013-12-22 08:04:02 <CodeShark> that could quickly kill the coin completely
 81 2013-12-22 08:07:10 <CodeShark> perhaps eventually blockchain-based currencies will evolve to a model where the decentralized pow-based timestamping mechanism will be decoupled from the individual assets and scripts securing them
 82 2013-12-22 08:07:35 <CodeShark> then perhaps a few major block chains can provide security for multiple coins
 83 2013-12-22 08:08:31 <CodeShark> in other words, mining could become essentially agnostic to transaction payload
 84 2013-12-22 08:08:55 <CodeShark> other than fees
 85 2013-12-22 08:09:20 <CodeShark> blockchains would become timestamping services
 86 2013-12-22 08:09:45 <theboos> I like that idea; how would fees be paid for including data in the blockchain?
 87 2013-12-22 08:10:12 <theboos> I like Bitcoin's "miners get the leftovers" model
 88 2013-12-22 08:10:48 <CodeShark> problem with that model is that the payload of the data is no longer opaque to the miner
 89 2013-12-22 08:10:58 <CodeShark> so we cannot decouple the two
 90 2013-12-22 08:11:24 <CodeShark> but yeah, we'd need to come up with a convention for paying fees for inclusion
 91 2013-12-22 08:14:14 <CodeShark> it's not exactly trivial. I guess namecoin has already started moving in this direction, somewhat
 92 2013-12-22 08:14:36 <theboos> I was thinking that mining pools could deal directly with clients
 93 2013-12-22 08:15:27 <CodeShark> yeah
 94 2013-12-22 08:15:35 <theboos> e.g. you'd pay a mining pool in any currency they accept in exchange for including your data in the blockchain, secured by their hashing power
 95 2013-12-22 08:15:42 <CodeShark> right
 96 2013-12-22 08:15:55 <theboos> however that does not adequately compensate the rest of the network for storing that arbitrary data
 97 2013-12-22 08:17:18 <theboos> I run a full node "for free" because 15 GB and negligible bandwidth is reasonable, but I would not want to store potentially terabytes or more of other data that others include in blocks
 98 2013-12-22 08:17:45 <CodeShark> that leads me to another idea I've been thinking about - creating a decentralized CAS, encouraging people to provide resources by compensating them in cryptocurrencies
 99 2013-12-22 08:18:32 <theboos> CAS? central auth service?
100 2013-12-22 08:18:35 <CodeShark> effectively decoupling the storage costs of the network from the mining costs
101 2013-12-22 08:18:42 <CodeShark> content-addressable storage
102 2013-12-22 08:19:08 <theboos> ahh
103 2013-12-22 08:19:12 <theboos> that is interesting
104 2013-12-22 08:22:28 <theboos> that would have to be combined with some proof-of-knowledge scheme
105 2013-12-22 08:22:54 <CodeShark> yes - you could do random samplings
106 2013-12-22 08:23:04 <CodeShark> similar to how mining shares work
107 2013-12-22 08:23:15 <CodeShark> or analogous, I should say
108 2013-12-22 08:25:09 <CodeShark> using cryptographic hash functions as identifiers, it's then simple to verify whether a node stored the given data and returned it uncorrupted
109 2013-12-22 08:26:26 <CodeShark> don't have all the details worked out - but I'm fairly sure a scheme could be constructed
110 2013-12-22 08:26:43 <CodeShark> you'd need to make sure the node can't just query other nodes for that data when asked
111 2013-12-22 08:29:56 <CodeShark> or to make it sufficiently expensive so that they can't game it like that
112 2013-12-22 08:30:17 <theboos> the p2p nature of bitcoin means that there is (nearly) no way to prove that a given IP initiated a transaction, and there is absolutely no way to associate an IP with a fresh address. Is a similar property desirable with distributed storage?
113 2013-12-22 08:30:44 <CodeShark> we'd want each node to have a node identity key
114 2013-12-22 08:30:55 <CodeShark> this would be good to have in bitcoin, too :)
115 2013-12-22 08:31:41 <CodeShark> IP addresses are great for routing messages - but we also need to be able to sign messages to prove their origin
116 2013-12-22 08:31:43 <CodeShark> :)
117 2013-12-22 08:33:07 <theboos> because I was thinking that if anonymity/privacy is not so much of a concern, a node could authenticate someone seeking to download their own content, so a node would not be able to query other nodes for data it did not originate
118 2013-12-22 08:33:43 <CodeShark> the peer querying the data could transmit a public key and have the data encrypted, then whoever answers the query first gets a reward
119 2013-12-22 08:34:10 <CodeShark> by encrypting using the recipient's public key, it ensures that nobody between the sender and recipient can insert itself
120 2013-12-22 08:35:01 <CodeShark> and you could also add authentication like you say for private data, theboos
121 2013-12-22 08:35:28 <CodeShark> or at least encryption
122 2013-12-22 08:36:22 <CodeShark> if we could work out a way to make these exchanges atomic
123 2013-12-22 08:36:39 <CodeShark> and hide the payload entirely from those verifying the atomicity
124 2013-12-22 08:38:52 <CodeShark> I guess this sorta leads to a kind of escrow model
125 2013-12-22 08:39:17 <CodeShark> dunno - lol…too tired to think about this stuff
126 2013-12-22 08:39:54 <theboos> going to have to think this over, heh. I had not thought of using the blockchain to handle distributed storage of things other than the blockchain
127 2013-12-22 08:40:16 <CodeShark> well, this would be a different kind of structure than a block chain
128 2013-12-22 08:40:27 <theboos> but it seems that would be possible
129 2013-12-22 08:40:39 <CodeShark> the way I see it, block chains serve timestamping purposes - we need another kind of structure to serve spacestamping purposes :p
130 2013-12-22 08:41:39 <CodeShark> decentralized spacestamping :)
131 2013-12-22 08:42:25 <theboos> I think it would have to be more closely tied to the blockchain. A user would need to pay nodes on an ongoing basis for storing their data (microtransactions!), and this payment could be tied to the verification of storage somehow
132 2013-12-22 08:42:43 <theboos> If a user paid only to upload data, there is no incentive for nodes to keep it around
133 2013-12-22 08:42:58 <CodeShark> yes, indeed - the two structures would need to work in tandem
134 2013-12-22 08:43:21 <theboos> if a user paid only to retrieve data, there is nothing stopping a user from uploading /dev/random with no intention of downloading in the future
135 2013-12-22 08:43:44 <CodeShark> perhaps a rental model also makes sense - where you package the data along with some coins, which gradually are transferred to whoever stores it. once the coins run out, the data is deleted
136 2013-12-22 08:44:28 <theboos> sounds like a job for convoluted transaction scripts
137 2013-12-22 08:44:54 <CodeShark> these use cases could probably be abstracted as language primitives
138 2013-12-22 08:45:17 <CodeShark> although yeah, I suppose having the flexibility of a customizable script might make sense
139 2013-12-22 08:45:37 <theboos> I meant the existing disabled bitcoin script functionality
140 2013-12-22 08:46:04 <CodeShark> I'd rather dump that script and come up with something better while we're at it :)
141 2013-12-22 08:46:42 <theboos> something along the lines of "this transaction can be spent on block number 345678 by anyone who can provide something that hashes to NNNNNNNNN..."
142 2013-12-22 08:46:53 <CodeShark> we need a script that can reference data external to just a transaction input and output
143 2013-12-22 08:47:35 <theboos> and metadata along the lines of "hint! data[2345:3567] ++ data[8000:8010] hashes to the above value"
144 2013-12-22 08:47:53 <CodeShark> yeah
145 2013-12-22 08:47:56 <CodeShark> exactly
146 2013-12-22 08:48:17 <theboos> the issue with such a construction is that a node would be able to precalculate only the data needed to spend those coins, and throw the rest of the file away
147 2013-12-22 08:48:30 <theboos> since all of the transactions would be public ahead of time
148 2013-12-22 08:48:33 <CodeShark> you could throw nondeterminism into the mix
149 2013-12-22 08:49:21 <CodeShark> i.e. require an HMAC using a key that only becomes available later on and is derived from a bunch of unpredictable (but easy to verify) factors
150 2013-12-22 08:49:47 <CodeShark> hmm
151 2013-12-22 08:49:58 <theboos> nondeterminism wouldn't be necessary if you could ensure that the key would only become available later
152 2013-12-22 08:50:36 <theboos> as you could simply encrypt the metadata hints for a given block number with a key that only becomes available the block before
153 2013-12-22 08:50:50 <CodeShark> right
154 2013-12-22 08:51:14 <theboos> but I can't think of a way to do timed encryption with the blockchain
155 2013-12-22 08:55:07 <CodeShark> http://www.gwern.net/Self-decrypting%20files
156 2013-12-22 08:55:09 <CodeShark> lol
157 2013-12-22 08:55:48 <theboos> in any case, how does a node know that the data block they've been given includes the promised transactions? that is, a malicious user might throw terabytes of data into the system, and nodes might accept it
158 2013-12-22 08:56:24 <CodeShark> using "weak key" decryption - could be used for proof of work, too :)
159 2013-12-22 08:56:48 <theboos> but the transactions it includes cannot be spent with the data - the hashes of the provided ranges do not match the transaction script
160 2013-12-22 08:57:12 <theboos> the logical response from a node would be to throw away the file if it can't continue getting coins out of it
161 2013-12-22 08:57:20 <theboos> but then it's wasted a lot of bandwidth accepting the file
162 2013-12-22 08:58:00 <theboos> that was my first idea too, but consider that that gives nodes an incentive to throw computational power at a file so they can throw it away :P
163 2013-12-22 09:00:00 <theboos> also, it gives very weak guarantees on storage duration, whereas tying the transactions to the blockchain might allow users to upload files to be stored for a duration of "10000 blocks"
164 2013-12-22 09:00:32 <theboos> while not a precise duration, estimates are unlikely to be more than 50% off
165 2013-12-22 09:02:16 <CodeShark> perhaps the difficulty could be adjusted upwards by paying partial rewards for partial breaks and allowing the person who created the file to up the difficulty
166 2013-12-22 09:02:26 <CodeShark> if too many partial breaks are happening
167 2013-12-22 09:05:24 <CodeShark> hmm - would knowledge of the decryption key even be necessary to encrypt data with a predetermined difficulty?
168 2013-12-22 09:05:53 <CodeShark> or nvm :p
169 2013-12-22 09:07:47 <CodeShark> hmm
170 2013-12-22 09:17:47 <theboos> I'm reading about the lock_time field of transactions
171 2013-12-22 09:19:13 <theboos> I don't understand how that field is secured - that is, what is to stop a node from altering the lock_time field and passing the new transaction along
172 2013-12-22 09:20:01 <CodeShark> it's signed, no?
173 2013-12-22 09:20:23 <CodeShark> just like all other parts of the transaction except for input scripts
174 2013-12-22 09:21:54 <theboos> is it signed then? I couldn't find that
175 2013-12-22 09:22:20 <CodeShark> https://en.bitcoin.it/wiki/OP_CHECKSIG
176 2013-12-22 09:28:22 <theboos> if I'm interpreting https://en.bitcoin.it/wiki/Protocol_specification#tx correctly, lock_time is not within the scope of the signature?
177 2013-12-22 09:29:01 <CodeShark> when signing, only the TxIn datastructures are modified
178 2013-12-22 09:29:07 <CodeShark> the rest of the transaction is left in place
179 2013-12-22 09:30:08 <CodeShark> outputs might also be blanked for hashtypes other than SIGHASH_ALL
180 2013-12-22 09:32:20 <maaku> theboos: it is signed
181 2013-12-22 09:33:57 <theboos> it's late enough that I will take your word for it, heh
182 2013-12-22 09:34:28 <theboos> night all
183 2013-12-22 09:44:08 <Intelftw> How do I calculate transaction hash? Is it the hash of serialized transaction?
184 2013-12-22 09:46:45 <CodeShark> yes
185 2013-12-22 09:46:53 <CodeShark> sha256(sha256(serialized tx))
186 2013-12-22 09:47:23 <Intelftw> hm, I tried double hashing transaction data from getblocktemplate but they didn't match
187 2013-12-22 09:47:51 <CodeShark> make sure you've got the endianness correct and that you're hashing binary data rather than ASCII
188 2013-12-22 09:48:34 <Intelftw> ah it's hash of binary data, got it
189 2013-12-22 09:48:34 <Intelftw> thanks
190 2013-12-22 12:13:40 <kapiteined> Hi, i found a small bug in the bitcoinclient (v0.8.5-beta), what is the best place to file a bug report?
191 2013-12-22 12:14:08 <Luke-Jr> kapiteined: first you should try reproducing the bug with a current version
192 2013-12-22 12:14:47 <kapiteined> ah, v0.8.5-beta is old already? let me check the latest and greatest
193 2013-12-22 12:14:48 <Luke-Jr> for bugs that affect the latest release, GitHub is usually the place
194 2013-12-22 12:14:48 <sipa> and search the bug tracker https://github.com/bitcoin/bitcoin/issues
195 2013-12-22 12:22:00 <kapiteined> yes, bug is still present in v0.8.6-beta, so i will file it at github
196 2013-12-22 12:25:11 <zophy> 
ACTION hands kapiteined 9 nano seonds

197 2013-12-22 12:26:01 <zophy> do those usb asics really do hundreds of mega hash/sec ?
198 2013-12-22 12:29:09 <SomeoneWeird> yes, but that's offtopic here.
199 2013-12-22 12:33:49 <kapiteined> ok, filed under:  Issue #3455
200 2013-12-22 12:34:23 <kapiteined> thanks!
201 2013-12-22 12:35:29 <Intelftw> Why is TxOut value int64 but not uint64 ?
202 2013-12-22 12:36:16 <sipa> there is no difference
203 2013-12-22 12:36:43 <sipa> as it's a number between 0 and 21*10^14, which exists in both
204 2013-12-22 12:38:07 <sipa> (and they have the same representation)
205 2013-12-22 12:40:35 <Intelftw> so it's serialized as uint32 without sign bit?
206 2013-12-22 12:40:42 <Intelftw> 64*
207 2013-12-22 12:40:51 <sipa> it's two's complement
208 2013-12-22 12:40:56 <sipa> it does not have a sign bit
209 2013-12-22 12:55:11 <Varan2> Does anyone know where I can find a implementation of SNARKS for C (http://eprint.iacr.org/2013/507.pdf)? or something similar.
210 2013-12-22 12:55:50 <Varan2> I cannot find any implementation of zero knowledge proofs
211 2013-12-22 13:25:45 <phantomcircuit> Intelftw, and the code is full of checks for negative values
212 2013-12-22 13:29:23 <tholenst> Varam2: I would assume that once the code is ready, they publish it here: http://www.scipr-lab.org/
213 2013-12-22 16:12:47 <jacob___> hello
214 2013-12-22 16:12:52 <jacob___> i am looking at ECDSA,.., i studied it and look at the implementation in bitcoin with use of openSSL,
215 2013-12-22 16:12:57 <jacob___> I have a hard time finding how the emphemeral is generated, i dont see it
216 2013-12-22 16:13:17 <jacob___> jgarzik, i am actually looking at your code in wallet.c (github picocoin)
217 2013-12-22 16:16:11 <sipa> jacob___: it's all inside openssl
218 2013-12-22 16:16:40 <jacob___> hold on sipa))
219 2013-12-22 16:16:46 <sipa> you just give the hash to sign and the key to openssl, and get a signature back
220 2013-12-22 16:16:59 <jacob___> i see after initialisation of domain parameters
221 2013-12-22 16:17:02 <jacob___> key->k = EC_KEY_new_by_curve_name(NID_secp256k1);
222 2013-12-22 16:17:05 <jacob___> i see this call
223 2013-12-22 16:17:06 <jacob___> EC_KEY_generate_key(key->k)
224 2013-12-22 16:17:18 <sipa> that's creating a new key
225 2013-12-22 16:17:21 <jacob___> this is just choosing parameter 'd' the provate key right
226 2013-12-22 16:17:30 <sipa> d?
227 2013-12-22 16:17:33 <jacob___> not d*A (where A is g)
228 2013-12-22 16:17:48 <jacob___> d= private key exponent
229 2013-12-22 16:17:53 <sipa> an EC_KEY is both private and public key
230 2013-12-22 16:18:00 <sipa> so it holds both d and d*A
231 2013-12-22 16:18:21 <jacob___> ok
232 2013-12-22 16:19:02 <jacob___> i need to look at internal structure of EC_KEY
233 2013-12-22 16:19:06 <sipa> why?
234 2013-12-22 16:19:16 <sipa> it's opaque
235 2013-12-22 16:19:21 <jacob___> ok
236 2013-12-22 16:19:48 <jacob___> so one extracts data from this opaque structure through functions then
237 2013-12-22 16:19:54 <sipa> no
238 2013-12-22 16:19:55 <jacob___> makes sense
239 2013-12-22 16:20:13 <sipa> well, you call functions to convert it to a serialized data type (for private or public keys)
240 2013-12-22 16:20:14 <jacob___> ok, lets say i want to know the exponent d, how do i get this info
241 2013-12-22 16:20:30 <sipa> you typically don't
242 2013-12-22 16:20:37 <sipa> you ask for the private key in a byte array
243 2013-12-22 16:21:01 <jacob___> sipa, isnt that the same thing
244 2013-12-22 16:21:04 <jacob___> ?
245 2013-12-22 16:21:30 <sipa> the interpretation is different
246 2013-12-22 16:21:39 <jacob___> i want the private key (d) in a uint8_t array
247 2013-12-22 16:21:58 <sipa> if you know how that private key is encoded, sure you can interpret it
248 2013-12-22 16:22:06 <sipa> but it's not really intended to work that way
249 2013-12-22 16:22:15 <sipa> you just serialize it, and give it back to openssl
250 2013-12-22 16:22:40 <jacob___> well i dont care about the interface, i just would like to know its value
251 2013-12-22 16:22:44 <sipa> ok
252 2013-12-22 16:23:02 <sipa> i have a more low-level implementation of just ecdsa for secp256k1
253 2013-12-22 16:23:34 <jacob___> yes i know you made one, but right now i just want to understand jgarziks code, maybe later i will replace it with yours
254 2013-12-22 16:23:35 <sipa> for openssl, you can use some tricks to get the private key directly as a bignum
255 2013-12-22 16:23:42 <jacob___> aha)))
256 2013-12-22 16:23:51 <sipa> you're confusing things
257 2013-12-22 16:23:59 <sipa> jgarzik interfaces with openssl
258 2013-12-22 16:24:05 <sipa> it doesn't implement ecdsa itself
259 2013-12-22 16:24:16 <jacob___> i know, i am looking at his code
260 2013-12-22 16:24:33 <jacob___> i said "..maybe later i will replace it.."
261 2013-12-22 16:24:36 <sipa> you can't replace that by "my code"
262 2013-12-22 16:24:42 <jacob___> oh why not?
263 2013-12-22 16:24:51 <sipa> you can replace openssl by my code
264 2013-12-22 16:25:14 <sipa> but you're just looking at the glue code to turn it into a bitcoin wallet
265 2013-12-22 16:25:56 <jacob___> of course you use different interface
266 2013-12-22 16:26:16 <jacob___> i dont see any bignum in your code, etc,.., but conceptually cannot be different
267 2013-12-22 16:26:28 <sipa> you're really confusing things
268 2013-12-22 16:26:41 <sipa> there are two libraries (well, more) that implement ecdsa/secp256k1, openssl and my library
269 2013-12-22 16:26:42 <jacob___> or you are saying it is impossible to convert jgarzik code
270 2013-12-22 16:26:50 <jacob___> ok tell me
271 2013-12-22 16:27:13 <sipa> i don't know what jeff's code does, but you can't replace it with mine... as it's just an interface
272 2013-12-22 16:27:36 <sipa> it's like saying i'm going to replace internet explorer with linux
273 2013-12-22 16:27:37 <jacob___> i think we have a problem with english semantics
274 2013-12-22 16:28:13 <sipa> maybe let's start over
275 2013-12-22 16:28:17 <sipa> what are you trying to do?
276 2013-12-22 16:28:19 <jacob___> good idea
277 2013-12-22 16:28:28 <jacob___> ))
278 2013-12-22 16:29:03 <jacob___> ok..., i just did some reading on ECSDA from " Christof Paar" book, very nice and all.
279 2013-12-22 16:29:16 <jacob___> So i wanted to learn how it is implemented in bitcoin
280 2013-12-22 16:29:25 <sipa> it is not
281 2013-12-22 16:29:29 <sipa> it's implemented in openssl
282 2013-12-22 16:29:32 <jacob___> i am looking at how he creates wallets
283 2013-12-22 16:29:40 <sipa> a wallet is much higher level than ecdsa
284 2013-12-22 16:29:45 <jacob___> well, anyway, i want to know how bitcoin uses the openssl api
285 2013-12-22 16:29:49 <sipa> ok
286 2013-12-22 16:29:55 <jacob___> yes sipa
287 2013-12-22 16:30:07 <jaakkos> do the signatures take most space in the ledger?
288 2013-12-22 16:30:18 <sipa> define space?
289 2013-12-22 16:30:23 <sipa> memory? disk? pixels?
290 2013-12-22 16:30:24 <jaakkos> bytes
291 2013-12-22 16:30:26 <jaakkos> disk
292 2013-12-22 16:30:32 <jaakkos> pixels? :D
293 2013-12-22 16:30:45 <jacob___> in the book it needs exponent d, public key d*A , this is all what is needed for the wallet?
294 2013-12-22 16:30:55 <jaakkos> i suppose the txhashes take quite a bit of space too?
295 2013-12-22 16:31:27 <sipa> a wallet contains addresses, private keys, transactions, metadata, an address book, comments/notes, ...
296 2013-12-22 16:31:42 <jaakkos> yes but the bitcoin ledger
297 2013-12-22 16:31:46 <sipa> please don't confuse a wallet with a single address or keypair
298 2013-12-22 16:32:00 <jaakkos> oh, not talking to me i suppose
299 2013-12-22 16:32:07 <jacob___> there is no wallet fileformat defined right?
300 2013-12-22 16:32:23 <sipa> every implementation has its own, and they hardly even agree about what "wallet" means
301 2013-12-22 16:32:36 <phantomcircuit> jaakkos, the signatures are a significant part of the blockchain total size
302 2013-12-22 16:32:43 <jacob___> lol, ok, well i am just talking about what is minimalistic needed for a transaction
303 2013-12-22 16:33:02 <jaakkos> phantomcircuit: what about txhashes? each input needs to refer one of those too
304 2013-12-22 16:33:17 <sipa> ok, so you're talking about the storage requirements for transactions?
305 2013-12-22 16:33:25 <sipa> because that's only a small part of what a wallet stores
306 2013-12-22 16:34:04 <jacob___> sure people would like to store some metadata with a public private key pair
307 2013-12-22 16:34:36 <jaakkos> phantomcircuit: i could imagine there might be a way to shorten the txhashes and still be secure, and save a lot of space
308 2013-12-22 16:34:37 <sipa> ok, are we talking about transactions, or about keypairs?
309 2013-12-22 16:34:45 <sipa> they're both things that are stored by wallets
310 2013-12-22 16:34:52 <phantomcircuit> jaakkos, a transactions from an pubkeyhash to a pubkeyhash is about 300 bytes, about half is fixed tx overhead and the other half is the script
311 2013-12-22 16:35:11 <phantomcircuit> jaakkos, there are much better long term solutions than that
312 2013-12-22 16:35:29 <jacob___> from what i see, jgarzik only stores keypair combinations
313 2013-12-22 16:35:32 <jacob___> nothing more
314 2013-12-22 16:35:42 <jacob___> in his wallet
315 2013-12-22 16:36:03 <jacob___> oh-- and the netmagic,.. (header data of the wallet) makes sense
316 2013-12-22 16:36:20 <sipa> i really doubt that... it would mean he needs to rescan or redownload the entire chain every time
317 2013-12-22 16:36:35 <sipa> though i haven't looked at the code
318 2013-12-22 16:36:49 <jaakkos> phantomcircuit: what are some of the suggestions?
319 2013-12-22 16:37:06 <v3ry3l33te> are there any solutions for linking pub address and email/phone id's in works?
320 2013-12-22 16:37:16 <sipa> v3ry3l33te: hell no
321 2013-12-22 16:37:32 <sipa> there is a payment protocol in the works, which essentially lets you send money to a url
322 2013-12-22 16:38:01 <v3ry3l33te> sipa, interesting, alpha/beta users needed? :)
323 2013-12-22 16:38:22 <sipa> you're always welcome to test git head
324 2013-12-22 16:38:30 <sipa> and report problems found in it
325 2013-12-22 16:38:50 <v3ry3l33te> k thanks, i'll have a look
326 2013-12-22 17:13:52 <Matt_von_Mises> Hi. Can anyone explain why the Satoshi client (recent master branch 0.8.99) gives a source and recipient ip of 0.0.0.0 in the version message when connecting to a node via -connect?
327 2013-12-22 17:15:19 <sipa> it means it doesn't know its own ip
328 2013-12-22 17:16:23 <sipa> and for the addrYou address, it only sends it if it believes it's a publically reachable address
329 2013-12-22 17:18:15 <Matt_von_Mises> sipa: OK thanks, that makes sense.
330 2013-12-22 17:19:41 <jacob___> sipa, i am looking at ec.h file (openssl) but cant find the function that verifies the signature
331 2013-12-22 17:19:46 <jacob___> of ECSDA
332 2013-12-22 17:19:50 <jacob___> ECDSA
333 2013-12-22 17:19:52 <jacob___> ooops
334 2013-12-22 17:20:05 <sipa> look at ecdsa.h
335 2013-12-22 17:20:21 <jacob___> oh great, thanks sipa
336 2013-12-22 17:20:21 <phantomcircuit> i'd tell him to ask in #openssl but that would be mean
337 2013-12-22 17:44:56 <jacob___> hello again
338 2013-12-22 17:45:04 <jacob___> I am looking at "script opcodes"
339 2013-12-22 17:45:07 <jacob___> what is that
340 2013-12-22 17:45:09 <jacob___> OP_PUSHDATA1
341 2013-12-22 17:45:57 <sipa> it's a script opcode that pushes a number of bytes onto the stack
342 2013-12-22 17:46:19 <sipa> wgere that number of bytes is specified as asingle byte
343 2013-12-22 18:01:25 <jacob___> sipa,..,  I might ask some silly questions as I am plough through the code
344 2013-12-22 18:03:58 <jacob___> sipa ,.., these opcodes what do they do?
345 2013-12-22 18:04:21 <sipa> jacob___: i can't explain the entire bitcoin script language here
346 2013-12-22 18:04:27 <jacob___> link?
347 2013-12-22 18:04:31 <sipa> ;;google script bitcoin
348 2013-12-22 18:04:33 <gribble> Script - Bitcoin: <https://en.bitcoin.it/wiki/Script>; BIP 0016 - Bitcoin: <https://en.bitcoin.it/wiki/BIP_0016>; OP CHECKSIG - Bitcoin: <https://en.bitcoin.it/wiki/OP_CHECKSIG>
349 2013-12-22 18:04:41 <sipa> first link
350 2013-12-22 18:13:43 <jacob___> sipa the contents of a transaction is basicly "a script"
351 2013-12-22 18:14:24 <jacob___> is this correct?
352 2013-12-22 18:14:41 <sipa> no
353 2013-12-22 18:14:50 <sipa> a transaction has inputs and outputs
354 2013-12-22 18:14:53 <lianj> the contents are inputs and outputs
355 2013-12-22 18:14:55 <sipa> and some metadata
356 2013-12-22 18:15:08 <sipa> outputs are an amount + a script to assign that amount to
357 2013-12-22 18:15:34 <sipa> inputs are a reference to a previous transaction's output + the data to make its script evaluate to true
358 2013-12-22 18:18:34 <jacob___> sipa yes,.., sources and destinations..,., can one add more opcode and make new instructions?
359 2013-12-22 18:19:02 <jacob___> (quick question)
360 2013-12-22 18:19:41 <Matt_von_Mises> If you add new opcodes then the new software will be incompatible with other bitcoin nodes.
361 2013-12-22 18:20:37 <lianj> unless you make it backwards compatible‎ for some time until the majority of network agrees on the new opcode behavior
362 2013-12-22 18:23:41 <jacob___> The older nodes will not verify these transactions if new opcodes are used?
363 2013-12-22 18:24:04 <jacob___> even if provided a valid signature?
364 2013-12-22 18:24:36 <jacob___> (signing)
365 2013-12-22 18:24:36 <sipa> jacob___: "valid signature" is exactly defined by the opcodes!
366 2013-12-22 18:24:46 <jacob___> da!
367 2013-12-22 18:24:48 <jacob___> ok
368 2013-12-22 18:24:57 <sipa> if you add an opcodes, there is no way that old nodes could verify its validity
369 2013-12-22 18:25:20 <jacob___> understood
370 2013-12-22 18:25:25 <Matt_von_Mises> You can add a new opcode and have the miners enforce it, so that the blocks contain transactions which are valid for both new and old nodes. It would be backwards compatible as long as previous nodes see the transactions as valid.
371 2013-12-22 18:25:36 <sipa> depending on whether those new opcodes would be backward compatible, you either have to just upgrade the majority of the hashpower validates it
372 2013-12-22 18:25:55 <sipa> but in general, you have to upgrade 100% of all nodes (not just mining)
373 2013-12-22 18:31:01 <jacob___> sipa, is there a link to the fileformat of the blockchain on disk for qt client?
374 2013-12-22 18:33:25 <maaku> jacob___: file format is dead simple
375 2013-12-22 18:33:26 <maaku> http://james.lab6.com/2012/01/12/bitcoin-285-bytes-that-changed-the-world/
376 2013-12-22 18:50:19 <jacob___> thanks maaku)
377 2013-12-22 19:30:04 <nsh> in what file is the network id 0xD9B4BEF9 defined?
378 2013-12-22 19:30:17 <nsh> chainparams.cpp?
379 2013-12-22 19:31:19 <nsh> oh, main.cpp as pchMessageStart
380 2013-12-22 19:35:07 <nsh> no, it moved i guess
381 2013-12-22 19:36:26 <nsh> ah, it is chainparams.cpp
382 2013-12-22 19:37:27 <Intelftw> What is merkle root of block with only coinbase tx? it's sha256d(t1 + t1) ?
383 2013-12-22 19:41:31 <BlueMatt> not sha256d(t1)?
384 2013-12-22 19:42:21 <Intelftw> I'm dumb... thx :D
385 2013-12-22 19:43:08 <jacob___> HI , what are *.sst files?
386 2013-12-22 20:29:00 <Intelftw> Is there any other stratum specification other than slush website?
387 2013-12-22 20:44:42 <Luke-Jr> Intelftw: not yet, Stratum was basically a proprietary developed protocol
388 2013-12-22 20:44:57 <Luke-Jr> Intelftw: GBT, which will hopefully replace stratum someday, has a few BIPs though
389 2013-12-22 20:45:23 <BlueMatt> gbt == the publicly-developed version that supports all kinds of nice features
390 2013-12-22 20:45:45 <BlueMatt> stratum == the privately-developed version that was just kinda dumped and doesnt support much beyond what was needed to get mining performance on a centralized pool
391 2013-12-22 20:46:37 <kinlo> Intelftw: the forum thread on stratum contains a lot of undocumented stuff, you need to read it to know the entire protocol
392 2013-12-22 20:46:58 <Intelftw> gbt is clear to me but I want to make compatibilty to other popular protocols too
393 2013-12-22 20:48:20 <kinlo> forum thread and slush's site are basicly all what is available.  Slush did once promise to write bip's for stratum, but I've never seen them
394 2013-12-22 20:49:40 <Intelftw> One thing that isn't mentioned on slush website is when work is sent to miners. I know that it's sent once after subscription but when next? It should obviously be sent when block height updates but is it sent periodically too or something like that?
395 2013-12-22 20:50:23 <kinlo> usually a pool server sends work about every 30 seconds, but that's basicly up to the implementer
396 2013-12-22 20:51:54 <Intelftw> So miner mines on the same work until uses up all of extranonce2 or pool requests reset?
397 2013-12-22 20:52:41 <kinlo> pool will have to send new work when a new block is found on the network.  Also, if extranonce2 is used up, something is wrong
398 2013-12-22 20:53:18 <kinlo> you definatly want to send new work periodically so it includes the latest transactions to include in the block, so you have the income of the fee's attached to those transactions
399 2013-12-22 20:54:57 <Intelftw> yeah I know that but work notification has a bool to reset work. Is it always true or just when block is found?
400 2013-12-22 20:56:57 <kinlo> slush's page clearly explains what the bool means, you should be able to answer that question yourself
401 2013-12-22 20:59:46 <Intelftw> Well, it does not say anything about periodic work updates and wether they should reset work or not.
402 2013-12-22 20:59:50 <Intelftw> 
ACTION starts reading topic

403 2013-12-22 21:08:40 <Luke-Jr> Intelftw: pool is free to issue new jobs as it likes
404 2013-12-22 21:09:00 <Luke-Jr> kinlo: extranonce2_size could legally be 1 :p
405 2013-12-22 21:09:48 <kinlo> Luke-Jr: yeah, but let's face it, it has to be 4 or many clients wont work
406 2013-12-22 21:09:57 <kinlo> I know other clients that barf on other values
407 2013-12-22 21:10:06 <Intelftw> Luke-Jr: but if you send new job with new transactions without requesting work reset, the miner will never include new transactions then
408 2013-12-22 21:10:23 <Luke-Jr> kinlo: it's often non-4
409 2013-12-22 21:10:59 <Luke-Jr> Intelftw: work updates should be used immediately, with or without clean_work
410 2013-12-22 21:11:12 <Luke-Jr> Intelftw: clean_work just means older jobs are *invalid*
411 2013-12-22 21:11:20 <Intelftw> ah I c
412 2013-12-22 21:11:27 <kinlo> Luke-Jr: which pool does non-4?
413 2013-12-22 21:11:36 <Luke-Jr> kinlo: any proxy on a 4 pool
414 2013-12-22 21:11:51 <Luke-Jr> also older Eloipool instances on 64-bit
415 2013-12-22 21:12:28 <kinlo> Luke-Jr: true, but proxies are contained
416 2013-12-22 21:12:30 <Luke-Jr> (older Eloipool used pointers)
417 2013-12-22 21:12:49 <Luke-Jr> actually, I may be thinking of extranonce1 for that..
418 2013-12-22 21:13:21 <Luke-Jr> 
ACTION ponders how many clients would work if he sent extranonce2_size=3.875 :P

419 2013-12-22 21:13:40 <kinlo> Luke-Jr: feel free to experiment on your pool :p
420 2013-12-22 21:24:59 <phantomcircuit> Luke-Jr, most of them would
421 2013-12-22 22:25:53 <michagogo> cloud|What was the procedure to downgrade a wallet from 5.1 to 4.8 again?
422 2013-12-22 22:28:20 <michagogo> cloud|`db_dump5.1 wallet.dat.5.1 | db_load4.8 wallet.dat`?
423 2013-12-22 22:32:41 <michagogo> cloud|db5.1_dump*
424 2013-12-22 22:32:52 <michagogo> cloud|db4.8_load*
425 2013-12-22 22:43:52 <Intelftw> What type is stratum job id? ASCII encoded hex value?
426 2013-12-22 22:54:34 <andytoshi> hey guys, the address  1ForFeesAndDonationsSpendHerdtWbWy does not have a version byte on it
427 2013-12-22 22:54:42 <andytoshi> (if you convert it to hex, the first byte is not 1)
428 2013-12-22 22:54:49 <andytoshi> but bitcoind appears happy with it ... why is this?
429 2013-12-22 22:57:19 <gmaxwell> andytoshi: because the first byte is the version byte?
430 2013-12-22 22:57:39 <gmaxwell> it's okay for a base58 encoded key to be short... they are shorter for some numbers.
431 2013-12-22 22:57:54 <andytoshi> the first byte is 162 tho
432 2013-12-22 22:58:23 <andytoshi> 162, 110, 2, 90, 103, 175, 228, 110, 232, 130, 104, 106, 0, 0, 39, 78, 20, 24, 165, 54, 156, 21, 123, 138
433 2013-12-22 22:59:29 <andytoshi> bitcoind should be claiming that it's not a bitcoin address
434 2013-12-22 23:00:39 <andytoshi> so if you create a rawtransaction spending to it, the first byte is not removed
435 2013-12-22 23:00:53 <CodeShark> it is a valid address
436 2013-12-22 23:00:57 <CodeShark> it corresponds to a26e025a67afe46ee882686a0000274e1418a536
437 2013-12-22 23:01:14 <CodeShark> with version byte 0x00
438 2013-12-22 23:01:36 <andytoshi> oh, no kidding
439 2013-12-22 23:01:59 <gmaxwell> I don't understand how you're saying it doesn't have a version byte! it starts with a 1
440 2013-12-22 23:02:19 <andytoshi> it starts with 1 in base 58, but not in base 256
441 2013-12-22 23:02:20 <gmaxwell> 58 < 256, but that suggests it has a version byte. :P
442 2013-12-22 23:02:29 <gmaxwell> oh interesting
443 2013-12-22 23:02:31 <gmaxwell> sounds like a bug
444 2013-12-22 23:02:54 <andytoshi> cool, i can submit a PR once i've determined what should be happening with it
445 2013-12-22 23:03:21 <CodeShark> huh? where's the bug?
446 2013-12-22 23:03:31 <andytoshi> for now i will make a donation address with a lowercase 'f', that fixes it..
447 2013-12-22 23:04:35 <wyager> gmaxwell: You may want to pitch in on the encrypted HD wallet BIP thread. The guy wants a dev to pitch in on hashing the private key for use as a checksum. https://bitcointalk.org/index.php?topic=258678.60
448 2013-12-22 23:06:13 <CodeShark> wait, where's the bug? is it incorrect to say that a26e025a67afe46ee882686a0000274e1418a536 with version byte 0 has base58check encoding 1ForFeesAndDonationsSpendHerdtWbWy?
449 2013-12-22 23:06:25 <CodeShark> I hope not, because that means I've got a bug in all my code, too :)
450 2013-12-22 23:06:34 <gmaxwell> andytoshi: perhaps you should should generate a vanity 3psh address with prefix "3FeeDonate..." so you can actualy spend it if funds accidentally get sent there?
451 2013-12-22 23:07:13 <andytoshi> oh, this is weird, the address 'forFeesAndDonationsSpendHergEsbig' starts with 1 in base 256 but not in base 58, and bitcoind rejects that
452 2013-12-22 23:07:23 <gmaxwell> Luke-Jr: do you have a fast nonce based p2sh generator?
453 2013-12-22 23:07:24 <andytoshi> gmaxwell: i can't vanitygen anything that long
454 2013-12-22 23:07:37 <Luke-Jr> gmaxwell: no, I don't like to encourage that :P
455 2013-12-22 23:07:44 <gmaxwell> andytoshi: you can, if its nonced p2sh. :P
456 2013-12-22 23:07:48 <gmaxwell> Luke-Jr: yea fair enough.
457 2013-12-22 23:07:51 <sipa> andytoshi: a '1' is base58 is value zero
458 2013-12-22 23:08:01 <Luke-Jr> if I made one, I'd make sure the result was non-standard
459 2013-12-22 23:08:09 <gmaxwell> Luke-Jr: that would be fine for andytoshi
460 2013-12-22 23:08:19 <sipa> something starting with one base58 by defibition starts with a 0 byte
461 2013-12-22 23:08:42 <sipa> it's a special rule about the transformation to maintain prefix 0 bytes
462 2013-12-22 23:08:44 <gmaxwell> Luke-Jr: basically his coinjoin thing uses a placeholder address for the server to replace an output. They should never be announced, but in case some genius somehow data, it might be nice if the funds were recoverable.
463 2013-12-22 23:08:56 <andytoshi> sipa: oh, my bad, i meant "starts with 0 in base 256 but not 1 in base 58"
464 2013-12-22 23:09:04 <CodeShark> I just ran three separate tools on 1ForFeesAndDonationsSpendHerdtWbWy, they all confirm that it represents a26e025a67afe46ee882686a0000274e1418a536 with vertions byte 0
465 2013-12-22 23:09:10 <sipa> andytoshi: thay makes no sense
466 2013-12-22 23:09:12 <CodeShark> *version byte
467 2013-12-22 23:09:26 <gmaxwell> andytoshi: yea that makes no sense, the other way around made some sense (though I dunno if it was correct!)
468 2013-12-22 23:10:05 <Luke-Jr> gmaxwell: OP_TRUE?
469 2013-12-22 23:10:25 <CodeShark> you could use a 1-of-2 multisig and have one of the pubkeys be a nonce
470 2013-12-22 23:10:44 <sipa> everything that start with 0x00 in base256 starts with 1 in base58, and the other way around
471 2013-12-22 23:10:47 <gmaxwell> or just a dummy push, it doesn't have to be standard, as it should never get used.
472 2013-12-22 23:10:59 <andytoshi> gmaxwell, sipa: ok thx, i see the problem
473 2013-12-22 23:11:06 <gmaxwell> sipa: I was ... unaware of the other way around, how the hell does it achieve that? padding?
474 2013-12-22 23:11:06 <sipa> either i completely misunderstand the conversion algorithm, or your tool makes a series calculation error
475 2013-12-22 23:11:17 <andytoshi> sipa: it's my tool
476 2013-12-22 23:11:25 <sipa> gmaxwell: prefix bytes are converted to prefix 1's
477 2013-12-22 23:11:32 <sipa> prefix 0x00 bytes
478 2013-12-22 23:11:34 <andytoshi> it sees 0 and interprets that as "i read the whole address"