1 2014-10-26 00:01:58 <vonnklaus> can someone provide a link to the official bitcoin source code (github link preferred) there seem to be many subsets of it
  2 2014-10-26 00:02:26 <phantomcircuit> vonnklaus, that's a bit of a loaded question
  3 2014-10-26 00:02:32 <vonnklaus> ?
  4 2014-10-26 00:02:42 <vonnklaus> i just want to take a look at the original code
  5 2014-10-26 00:02:44 <phantomcircuit> the bitcoin core code which is based on the reference client is at https://github.com/bitcoin/bitcoin.git
  6 2014-10-26 00:02:57 <phantomcircuit> the original original code like from 2009?
  7 2014-10-26 00:03:03 <moa> https://github.com/bitcoin/bitcoin
  8 2014-10-26 00:03:21 <vonnklaus> thanks. I have never actually seen the code before. I just wanted to make sure I was looking at the official distribution
  9 2014-10-26 00:18:44 <kryo_> how do i get the "send" transactions for an address?
 10 2014-10-26 00:19:38 <kryo_> i need something like getreceivedbyaddress, but for sent coins
 11 2014-10-26 00:54:43 <phantomcircuit> kryo_, that doesn't make sense
 12 2014-10-26 00:54:50 <phantomcircuit> ie what your asking for would be non sensical
 13 2014-10-26 00:54:55 <phantomcircuit> nonsensical
 14 2014-10-26 01:08:56 <kryo_> phantomcircuit: i'm trying to design an audit page
 15 2014-10-26 01:09:42 <kryo_> how would i show a list of addresses used by bitcoind with their current balance?
 16 2014-10-26 01:21:16 <kryo_> does anyone know how i can get the remaning balance of an address owned by bitcoind?
 17 2014-10-26 01:47:28 <gwillen> kryo_: the only reasonable way to model a bitcoin wallet is that it has a pool of coins you spend from
 18 2014-10-26 01:47:34 <gwillen> kryo_: those coins are not associated with any particular address
 19 2014-10-26 01:48:03 <gwillen> if you try to associate them with a particular address, it will work in some cases and fail in weird ways in other cases
 20 2014-10-26 01:53:23 <kryo_> gwillen: how is it that blockchain.info is able to supply the balance of an address, but bitcoind is not?
 21 2014-10-26 01:53:34 <gwillen> because blockchain.info makes bad assumptions
 22 2014-10-26 01:53:42 <gwillen> which will work somtimes, and other times will silently give garbage results
 23 2014-10-26 01:53:48 <gwillen> because blockchain.info is kind of poorly coded
 24 2014-10-26 01:54:20 <kryo_> all blockchain.info-like sites have a "balance" for addresses
 25 2014-10-26 01:54:38 <iwilcox> And they're all misleading.
 26 2014-10-26 01:54:50 <kryo_> why are they inconsistent with the way bitcoin actually works?
 27 2014-10-26 01:54:55 <gwillen> for most addresses used by most current clients, you can pretend that they have a balance, and it will mostly work
 28 2014-10-26 01:55:08 <gwillen> but for bitcoin addresses in general, it doesn't make sense and will not work in general
 29 2014-10-26 01:57:05 <gwillen> (also, it is not recommended to receive more than one transaction to a single address; if you obey that, then any operation that spends any coins recieved by that address must necessarily spend all of them)
 30 2014-10-26 01:57:53 <kryo_> so how do i provide a list of all addresses with non-zero balances?
 31 2014-10-26 01:58:13 <kryo_> i'm trying to provide a list of all addresses which are currently holding coins
 32 2014-10-26 01:58:27 <kryo_> this is in order to "prove" that we own the coins
 33 2014-10-26 01:58:36 <gwillen> ahhhh
 34 2014-10-26 01:58:38 <iwilcox> Addresses do not hold coins.  Addresses do not have balances.  Your best option is to rid your mind of that idea.
 35 2014-10-26 01:58:54 <gmaxwell> You'd want listunspent.
 36 2014-10-26 01:59:05 <gwillen> iwilcox: in the context of proving that an entity is holding coins, it does make sense to ask "which addresses have recieved coins that have not yet been spent onward", though
 37 2014-10-26 01:59:13 <gmaxwell> That will list the actual coins you are holding.
 38 2014-10-26 01:59:59 <gmaxwell> gwillen: actually listing the coins themselves is better though... since 'balances' won't do you any good without relaying on some centeralized index service... though txouts can be looked up.
 39 2014-10-26 02:00:18 <gwillen> gmaxwell: but you do have to map the coins to private keys that you can signmsg with
 40 2014-10-26 02:00:31 <gwillen> although I guess it's wrong to assume that ECDSA private keys are in 1:1 correspondence with addresses
 41 2014-10-26 02:00:38 <gmaxwell> gwillen: sure, listunspent will do that.  (though signmessage is kinda limited)
 42 2014-10-26 02:00:39 <gwillen> but in bitcoin-core I sort of assume that they always are
 43 2014-10-26 02:00:42 <gwillen> 
ACTION nods

 44 2014-10-26 02:00:45 <gmaxwell> because of exactly that.
 45 2014-10-26 02:01:52 <gmaxwell> Really there should be a standard form for an unminable transaction for use as a proof of spendability. e.g. one with an extra never to exist vin, and an nlocktime set maximally far in the future.
 46 2014-10-26 02:11:52 <kryo_> gmaxwell: thanks listunspent is exactly what i needed
 47 2014-10-26 02:13:54 <kryo_> since this is a web service and we do not allow mining into deposit addresses, is it ok to sign every entry for listunspent?
 48 2014-10-26 02:37:19 <devrandom> is there a quick way to figure out which block heights had orphans, either with bitcoind or any of the block explorers?
 49 2014-10-26 02:39:34 <justanotheruser> devrandom: you will not get all the orphans if you run a new bitcoind, but some blockchain.info has a list of orphans they have seen https://blockchain.info/orphaned-blocks
 50 2014-10-26 02:48:05 <Luke-Jr> devrandom: you mean stale blocks.
 51 2014-10-26 03:06:42 <devrandom> Luke-Jr: yes
 52 2014-10-26 03:08:48 <devrandom> justanotheruser: I wish blockchain.info supported testnet. trying to figure out a potential reorg bug in my code, but it happened on testnet and I didn't keep bitcoind logs
 53 2014-10-26 03:10:28 <devrandom> Luke-Jr: actually both orphan and stale
 54 2014-10-26 03:11:38 <devrandom> (isn't orphan a superset of stale?)
 55 2014-10-26 03:11:54 <Luke-Jr> devrandom: no, orphan is a block with no know prevblock
 56 2014-10-26 03:12:05 <Luke-Jr> stale is a block that is simply not in the best chain
 57 2014-10-26 03:12:44 <devrandom> ah, that's right... so stales for my case
 58 2014-10-26 03:14:14 <devrandom> BCI is using orphan to mean stale: https://blockchain.info/orphaned-blocks
 59 2014-10-26 03:15:25 <Luke-Jr> of course, BCI is always wrong.
 60 2014-10-26 03:15:33 <Luke-Jr> nothing news
 61 2014-10-26 03:16:02 <justanotheruser> Luke-Jr: so is there not consensus between whether a block is an orphan or stale? I mean, I may have a branch that proves an orphan has a known parent and another person might not.
 62 2014-10-26 03:17:09 <Luke-Jr> justanotheruser: correct, there is not
 63 2014-10-26 03:17:17 <Luke-Jr> justanotheruser: right now, most blocks come into Bitcoin Core as orphans
 64 2014-10-26 03:17:22 <Luke-Jr> until they get connected
 65 2014-10-26 03:17:41 <Luke-Jr> part of the headers-first improvement comes from eliminating that
 66 2014-10-26 03:30:31 <earlz> Possibly off-topic, but one of my hobby experiments has been unleashing genetic algorithms on sha256d to try to find optimizations not to find what the final value of the hash is, but rather how many bits of 0 it will be prefixed with
 67 2014-10-26 03:30:41 <earlz> has anyone heard of anyone doing anything similar?
 68 2014-10-26 03:31:13 <earlz> genetic algorithms are fun to mess with heh. My recent record is 10% accuracy out of 100 hashes with 120 operations
 69 2014-10-26 03:33:02 <earlz> well actually not 10% accuracy.. ugh I need to improve my benchmarking setup
 70 2014-10-26 03:33:18 <CodeShark> if it were possible to achieve anything greater than random accuracy with fewer operations than just trial-and-error it would constitute a break
 71 2014-10-26 03:34:01 <CodeShark> not sure how you're measuring that accuracy
 72 2014-10-26 03:34:05 <earlz> eh, I think I'm going to try scaling down to using md5 instead when I rewrite all this. Start with something a bit easier lol
 73 2014-10-26 03:35:03 <CodeShark> 10% meaning that out of every 100 guesses, 10 are exact? or 10% meaning that for each guess you're off by at most 10%?
 74 2014-10-26 03:35:06 <CodeShark> or?
 75 2014-10-26 03:37:04 <earlz> ah. I remember now (it had been a while since I had dug into it before making minor tweaks and letting it run overnight)
 76 2014-10-26 03:37:14 <earlz>             if ((test.Target & targetbits) == (o.Value & targetbits))
 77 2014-10-26 03:37:14 <earlz>             uint targetbits = 0xFF;
 78 2014-10-26 03:37:26 <earlz> so, I'm only trying to guess the first byte lol
 79 2014-10-26 03:37:40 <earlz> the first byte of the hash, exact
 80 2014-10-26 03:38:19 <earlz> 10% accuracy there probably doesn't mean anything, especially out of only 100 test hashes
 81 2014-10-26 03:38:36 <CodeShark> you should get it exact once every 256 tries :)
 82 2014-10-26 03:38:38 <earlz> My current setup is pretty bad though. I need to make some major improvements
 83 2014-10-26 03:39:36 <earlz> using my own home grown library that was basically hacked together until it worked
 84 2014-10-26 03:40:09 <CodeShark> if you can consistently find an exact partial collision for the first byte with fewer operations than it takes to perform sha256 256 times you could be famous :)
 85 2014-10-26 03:41:31 <sinetek> and very rich indeed
 86 2014-10-26 03:41:48 <earlz> Basically I have a VM setup. So, hash random bytes and store them in an array. Then take the "population" and run them in the VM for each test hash. measure and eliminate/breed/mutate
 87 2014-10-26 03:42:07 <earlz> So it wouldn't be a collision, it'd be an optimization for a very specific case.. I think
 88 2014-10-26 03:42:31 <sinetek> probably easier finding attacks for the crappy RNG in Android etc
 89 2014-10-26 03:42:50 <earlz> lol that's not as fun though
 90 2014-10-26 03:48:56 <CodeShark> let me qualify my earlier statement - obviously, you could construct a table of inputs that produce each of the desired first bytes. so to truly qualify as a break you would need less than exponential space in the number of collision bytes
 91 2014-10-26 03:49:52 <earlz> yea, that's not what I'm searching for
 92 2014-10-26 03:50:53 <earlz> I'm searching for a obscure optimization, not a collision.. though I'd take a collision if one fell in my lap ;)
 93 2014-10-26 03:51:05 <earlz> well, partial collision*
 94 2014-10-26 03:52:33 <CodeShark> good luck :)
 95 2014-10-26 05:33:47 <coderwill> in bitcoin core, what is the schema for time? e.g. "time" : 1231006505
 96 2014-10-26 05:35:00 <coderwill> is that 12:31:00:65:05? approx. 12:31PM?
 97 2014-10-26 05:35:38 <justanotheruser> coderwill: it is unix time?
 98 2014-10-26 05:39:54 <coderwill> justanotheruser: thx :)
 99 2014-10-26 05:40:19 <justanotheruser> thought it was a trick question :p.
100 2014-10-26 06:31:19 <sipa> gmaxwell: so, for bip62 to not restrict the ability to later use p2sh like mechanisms, one possibility is disable the cleanstack requirement when one of the OP_NOPx codes is used
101 2014-10-26 06:31:42 <sipa> gmaxwell: as you're clearly doing something we don't understand yet, there is no way for us to reason about it either
102 2014-10-26 06:34:40 <gmaxwell> Sounds reasonableish. Hm.
103 2014-10-26 06:44:26 <BlueMatt> sipa: I'm not convinced that it matters particularly
104 2014-10-26 06:44:35 <BlueMatt> sipa: p2sh could reasonably have an OP_DROP in its script
105 2014-10-26 06:44:59 <BlueMatt> well, theoretical p2shv2
106 2014-10-26 06:45:15 <sipa> well, p2shv2 doesn't even have to be opcode based
107 2014-10-26 06:45:45 <gmaxwell> it would need to have more than one push due to the limit. :(
108 2014-10-26 06:45:49 <sipa> but if it is, and it has an OP_DROP inside, that means it's malleable
109 2014-10-26 06:46:02 <sipa> unless you first check that it's 0
110 2014-10-26 06:46:05 <sipa> or 11
111 2014-10-26 06:46:16 <sipa> but yes, i agree
112 2014-10-26 06:46:27 <sipa> that is a possible workaround
113 2014-10-26 06:46:42 <gmaxwell> yea, but if you make your own txn malleable, you get to keep the pieces.
114 2014-10-26 06:47:17 <BlueMatt> waiitttt....ok, I misread the original problem...whats the issue here?
115 2014-10-26 06:47:30 <sipa> sorry, i meant to say "if you need an OP_DROP inside the p2shv2 redeemscript, that may result in the script be inevitably malleable"
116 2014-10-26 06:48:02 <sipa> BlueMatt: bip62 rule 6 (requiring exactly 1 stack element remaining) is incompatible with future p2sh schemes
117 2014-10-26 06:48:11 <sipa> as it even now needs special code to interact with p2sh
118 2014-10-26 06:49:56 <BlueMatt> ahh, yes, ok...sorry
119 2014-10-26 06:52:33 <BlueMatt> anyway, yea...so make a malleable-under-v3 tx that is restricted under v4 and is thus no longer malleable
120 2014-10-26 06:52:53 <BlueMatt> 
ACTION doesnt see this as a huge issue (ie doesnt appear to restrict ability to create p2sh-v2 in the future)

121 2014-10-26 06:53:13 <sipa> well we don't know what v4 is going to be, and we may well want to keep the malleability protection for it
122 2014-10-26 06:53:35 <gmaxwell> keep in mind that the spending tx sets the version, but sending creates the scriptpubkey.
123 2014-10-26 06:53:50 <BlueMatt> indeed, but my point is v4 can introduce additional malleability restrictions for its p2sh-v3
124 2014-10-26 06:53:51 <sipa> one way is using the lowest bit of the transaction version, rather than >=3
125 2014-10-26 06:54:26 <BlueMatt> gmaxwell: indeed, so to use p2sh-v2 you'll need an extra tx to keep it non-malleable
126 2014-10-26 06:54:33 <sipa> ewww
127 2014-10-26 06:54:50 <BlueMatt> well, depending on what it even is
128 2014-10-26 06:56:04 <BlueMatt> if it is just a p2sh-v2 (ie p2sh with new encoding!!111one) then it doesnt matter as you need a new scriptpubkey before its applicable anyway
129 2014-10-26 06:56:18 <BlueMatt> so that doesnt matter, but there are cases where it might, I suppose
130 2014-10-26 06:56:31 <sipa> anyway, you are right that it is possible to have p2shv2 do a drop of all unused argument
131 2014-10-26 06:56:43 <BlueMatt> ofc most of this is in the context of multi-tx protocols, so one extra.....
132 2014-10-26 06:56:43 <sipa> (at least if you also require them to be 0, which is perfectly possible)
133 2014-10-26 06:57:04 <BlueMatt> sipa: no
134 2014-10-26 06:57:12 <sipa> no?
135 2014-10-26 06:57:37 <BlueMatt> sipa: if we were to introduce p2sh after bip62, you can just do all the drops, define p2sh to ignore them, and then re-run bip62 after p2sh
136 2014-10-26 06:57:42 <BlueMatt> do you dont care what they are
137 2014-10-26 06:58:11 <Luke-Jr> IMO we shouldn't have the "stack unused" rule based on tx version >=2 alone
138 2014-10-26 06:58:17 <sipa> not sure what you're trying to say
139 2014-10-26 06:58:23 <sipa> (to BlueMatt)
140 2014-10-26 06:58:46 <Luke-Jr> what was wrong with the idea of txver&2 indicate some of the rules?
141 2014-10-26 06:58:57 <sipa> permanently wasting a version bit
142 2014-10-26 06:59:35 <Luke-Jr> 1/32 is better than 99.99999% by far :p
143 2014-10-26 07:00:37 <Luke-Jr> make OP_NOP2 be "fail if stack is not clear at end"?
144 2014-10-26 07:00:38 <gmaxwell> sipa: technically we don't need the empty stack rule.
145 2014-10-26 07:00:39 <BlueMatt> sipa: I'm probably still being thick, ignore
146 2014-10-26 07:00:54 <gmaxwell> End your script with OP_DEPTH 0 OP_EQUALVERIFY or the like.
147 2014-10-26 07:01:12 <sipa> p2sh could require [current p2sh script] + N OP_DROPS (with N the number of scriptSig elements, ignoring the redeemscript)
148 2014-10-26 07:01:32 <sipa> and the p2sh script evaluation could require the unused inputs to be 0
149 2014-10-26 07:01:51 <Luke-Jr> gmaxwell: that won't work for non-p2sh today, I think
150 2014-10-26 07:02:17 <gmaxwell> Luke-Jr: Explain what you're thinking?
151 2014-10-26 07:02:48 <gmaxwell> (you can setup the script so nothing is left on the stack, then check, to eliminate malleability from additional pushes... s'all I'm saying)
152 2014-10-26 07:03:16 <sipa> ooooh we have an OP_DEPTH
153 2014-10-26 07:03:38 <Luke-Jr> gmaxwell: I'm thinking someone may want to receive with 1….. address, but still get malleability protection spending it
154 2014-10-26 07:04:12 <gmaxwell> Luke-Jr: if wishes were horses...
155 2014-10-26 07:04:12 <sipa> right, it would mean protection to specific scripts, but not to currently standard scripts
156 2014-10-26 07:04:13 <BlueMatt> oooo, OP_DEPTH
157 2014-10-26 07:04:38 <sipa> i never realized the unused elements of the stack were observable
158 2014-10-26 07:04:50 <BlueMatt> sipa: anyway, yea, what you wrote above is what I meant
159 2014-10-26 07:05:01 <sipa> oh, so we agree
160 2014-10-26 07:05:06 <BlueMatt> yes
161 2014-10-26 07:05:15 <sipa> always useful in a conversation to know that in advance before you start arguing :p
162 2014-10-26 07:05:30 <BlueMatt> awwww, so now we dont get to have the arguing part?
163 2014-10-26 07:05:32 <BlueMatt> thats no fun
164 2014-10-26 08:44:14 <Luke-Jr> IMO "Only push operations in scriptSig" should also be not >=2
165 2014-10-26 08:47:40 <sipa> i really don't want to introduce a third class of validation flags
166 2014-10-26 08:47:47 <sipa> it's already hard enough to reason about
167 2014-10-26 08:48:38 <sipa> and if it doesn't apply to v4 transactions now, that means no protection from malleability when a switchover to it happens
168 2014-10-26 08:54:49 <Luke-Jr> sipa: when we get to v4 transactions, it requires a softwork anyway, so we can easily softfork in the stricter rules if desired
169 2014-10-26 08:55:19 <Luke-Jr> and we could have it preemptively if we just use 2 as a bit - it reduces the limited-area to 1/32 of the version numbers rather than most of it
170 2014-10-26 08:55:38 <sipa> hmm
171 2014-10-26 08:55:56 <sipa> we could probably just have all of bip62 apply strictly only to v3 transactions
172 2014-10-26 08:56:38 <Luke-Jr> yes, that would work too
173 2014-10-26 13:12:06 <b-itcoinssg> can anyone tell me what the function of length is in def b58decode(v, length) ?
174 2014-10-26 13:12:53 <b-itcoinssg> I want to convert base58 to int, but can't find any existing tools in python, will just have to write one?
175 2014-10-26 13:14:53 <sipa> there are plenty of implementations of bitcoin's base58 encoding/decoding in python
176 2014-10-26 13:17:59 <b-itcoinssg> hey sipa, yeah I found some, but they all convert from base58 to "decode v into a string of len bytes". Do you know of one the directly converts base58 to int ? if you can't remember one right now that's fine.
177 2014-10-26 13:19:11 <sipa> base58 is by definition something that converts a byte array into a character array
178 2014-10-26 13:19:19 <sipa> the int is only used internally
179 2014-10-26 13:19:34 <sipa> you can reinterpret the byte array as an integer if you need to
180 2014-10-26 13:19:50 <b-itcoinssg> ok
181 2014-10-26 13:19:53 <b-itcoinssg> I'll try that
182 2014-10-26 13:20:24 <sipa> it's a big endian base256 number, basically
183 2014-10-26 13:21:45 <b-itcoinssg> k
184 2014-10-26 13:23:57 <justanotheruser> b-itcoinssg: what exactly to use that is base 100,000?
185 2014-10-26 13:24:04 <justanotheruser> words?
186 2014-10-26 13:24:38 <b-itcoinssg> you figured it out, I told you it was a simple concept
187 2014-10-26 13:24:44 <b-itcoinssg> :-)
188 2014-10-26 13:25:09 <justanotheruser> there are a lot of words
189 2014-10-26 13:25:13 <justanotheruser> and a lot of really long words
190 2014-10-26 13:26:30 <b-itcoinssg> yes, I have several implementations right now, include word len filtering, and also only base58 chars just to stay congruent to satoshi's rationale
191 2014-10-26 13:26:59 <b-itcoinssg> I post all the results of the trial when I'm done, might not work out, but it's worth a try
192 2014-10-26 13:27:14 <b-itcoinssg> I'll*
193 2014-10-26 13:27:46 <justanotheruser> b-itcoinssg: what does this accomplish though?
194 2014-10-26 13:28:33 <b-itcoinssg> it might make bitcoin addresses easier to identify and perhaps even memorize
195 2014-10-26 13:29:14 <justanotheruser> you have to remember 11 words that are very long
196 2014-10-26 13:29:28 <justanotheruser> *may be very long
197 2014-10-26 13:29:32 <justanotheruser> actually more like 13
198 2014-10-26 13:29:44 <sipa> people shouldn't memorize addresses
199 2014-10-26 13:29:47 <sipa> they shouldn't even see them
200 2014-10-26 13:31:13 <b-itcoinssg> yes, may be, what's the harm in trying it out. It's not even at the point where I post it to bitcointalk dev where it will probably get shut down even if it successful, then ofcourse it will get shutdown at the bips proposal if it gets through the initial venting. there's a lot of failure to look forward to
201 2014-10-26 13:31:46 <sipa> i just think it's completely the wrong direction
202 2014-10-26 13:32:04 <sipa> addresses are intended to be use once; why would you want them make more rememberable? you'll just encourage reusing them
203 2014-10-26 13:32:12 <justanotheruser> think different(R)
204 2014-10-26 13:34:12 <b-itcoinssg> maybe just be easier to type, if nothing else. I mean if bitcoin addresses were'nt supposed to incorporate some sort of human friendlyness, why base58 ? Didn't Satoshi take into account letters that could be confused?
205 2014-10-26 13:34:29 <b-itcoinssg> could not*
206 2014-10-26 13:34:44 <sipa> bitcoin addresses weren't even intended to be the normal way of communication payment destinations
207 2014-10-26 13:34:57 <sipa> they were a backup in case the normal pay-to-IP couldn't be used
208 2014-10-26 13:35:11 <b-itcoinssg> sure
209 2014-10-26 13:35:13 <sipa> and yes, i think satoshi made a mistake in calling them addresses and making them human readable
210 2014-10-26 13:35:20 <b-itcoinssg> ok
211 2014-10-26 13:35:31 <sipa> and i think we need to get rid of that principle
212 2014-10-26 13:35:35 <sipa> like the payment protocol does
213 2014-10-26 13:35:45 <sipa> completely hiding the cryptographic material from the user
214 2014-10-26 13:35:57 <sipa> and without encouraging reuse
215 2014-10-26 13:40:42 <b-itcoinssg> sipa: do have anything in mind developers should be working on in terms of imporving the protocol that is not being worked on?
216 2014-10-26 13:42:13 <sipa> why do you want to immediately improve the protocol?
217 2014-10-26 13:42:29 <sipa> start by improving some implementation
218 2014-10-26 13:42:44 <sipa> changing the protocol takes ages
219 2014-10-26 13:42:47 <b-itcoinssg> I want to contribute, doesn't have to be an improvement in the protocol
220 2014-10-26 13:42:55 <b-itcoinssg> i'm asking you for advice
221 2014-10-26 13:43:16 <sipa> what languages do you like to work in?
222 2014-10-26 13:43:56 <b-itcoinssg> python optimally, but I can brush up on C/C++ fairly easily
223 2014-10-26 13:44:50 <sipa> there are plenty of python bitcoin projects (libraries, but for example armory also uses python)
224 2014-10-26 13:44:57 <sipa> but none that i'm actively contributing to
225 2014-10-26 13:45:18 <sipa> if you want to work on bitcoin core, it'll likely be C++ (unless some of the test infrastructure which is python)
226 2014-10-26 13:46:03 <b-itcoinssg> ok
227 2014-10-26 13:47:01 <nsh> and also you'll have to join the illuminati, but it's been streamlined now, so shouldn't take long
228 2014-10-26 13:48:50 <b-itcoinssg> do you have anything specific in mind that needs working on visavis the core code, I remember hearing something about the need for more tests, is that true?
229 2014-10-26 13:49:43 <sipa> there is always need for more tests :)
230 2014-10-26 13:49:57 <b-itcoinssg> k, maybe I'll start there
231 2014-10-26 13:50:33 <sipa> that would be very welcome!
232 2014-10-26 13:50:53 <b-itcoinssg> awesome
233 2014-10-26 15:01:01 <todam00n> is there a BIP for merged mining?
234 2014-10-26 15:10:16 <netg> all BIPs are listed at https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposal
235 2014-10-26 15:11:23 <netg> https://en.bitcoin.it/wiki/Merged_mining_specification
236 2014-10-26 15:12:49 <netg> https://en.bitcoin.it/wiki/BIP_MergedMiningScript
237 2014-10-26 15:14:11 <netg> http://dot-bit.org/Merged_Mining
238 2014-10-26 15:20:15 <todam00n> "Coinbase transaction that is in the parent block, linking the AuxPOW block to its parent block"
239 2014-10-26 15:20:18 <todam00n> I don't get this
240 2014-10-26 15:21:31 <todam00n> I don't get why coinbase_txn is needed? couldn't a miner just lie about the coinbase_tx?
241 2014-10-26 15:21:39 <todam00n> it's not part of the block header right?
242 2014-10-26 15:22:02 <todam00n> oh but it affects merkle_root
243 2014-10-26 15:23:12 <todam00n> ahh so this is why coinbase_branch is needed
244 2014-10-26 15:23:14 <todam00n> get it now
245 2014-10-26 16:37:11 <doomtoshi> Is it scheduled to build a decentralized exchange to trade the sidechains? Like a standalone software
246 2014-10-26 16:38:51 <sipa> you don't need an exchange to trade coins across sidechains
247 2014-10-26 16:39:37 <doomtoshi> sipa: How will the end user do it then?
248 2014-10-26 16:39:50 <Vinnie_win> I hear Jed McCaleb is joining the Bitcoin Foundation to port his advanced MtGox trading platform to sidechains
249 2014-10-26 16:40:43 <sipa> doomtoshi: nothing exists; talking about how emd users will do.something is way too early
250 2014-10-26 16:41:25 <sipa> but coins can be traded across sidechains using atomic swaps or pegged transfers
251 2014-10-26 16:42:07 <sipa> as they are pegged, there is no floating exchange rate, and thus no need for a market
252 2014-10-26 17:20:49 <tens0rpan> has anyone read the paper on related random event attacks?
253 2014-10-26 17:25:27 <tens0rpan> in particular the privelage escalation attack propositions?
254 2014-10-26 17:29:02 <justanotheruser> 13:28 < justanotheruser> tens0rlam: what is the title?
255 2014-10-26 17:30:07 <theclaw> hello
256 2014-10-26 17:31:01 <theclaw> when compiling bitcoind for debugging, should I configure it with '--disable-hardening'? When using '--enable-debug', I get the warning '_FORTIFY_SOURCE requires compiling with optimization'
257 2014-10-26 17:32:02 <theclaw> might hardening be useful for debugging purposes?
258 2014-10-26 17:36:07 <sipa> no
259 2014-10-26 17:36:23 <theclaw> sipa: thanks
260 2014-10-26 17:36:47 <sipa> hardening is extra protection against buffer overflows etc
261 2014-10-26 17:40:34 <theclaw> sipa: I wondered whether buffer overflow detection might be useful for debugging
262 2014-10-26 17:41:06 <sipa> well if you're changing code and think a buffer overflow may have been introduced: sure
263 2014-10-26 17:41:06 <theclaw> sipa: i.e., whether it might reveal problems during development
264 2014-10-26 17:41:51 <sipa> but the type of code used doesn't usually result in such bugs
265 2014-10-26 17:52:19 <theclaw> sipa: I see, thanks
266 2014-10-26 17:52:29 <tens0rpan> are private keys on hardware wallets deterministically calculated?
267 2014-10-26 17:54:34 <tens0rpan> or is there a more "crypto" oriented dev irc anyone knows about?
268 2014-10-26 17:55:26 <justanotheruser> tens0rpan: for cryptography discussion ##crypto
269 2014-10-26 17:55:40 <tens0rpan> ty ty
270 2014-10-26 20:57:17 <netg> /8/10
271 2014-10-26 21:07:02 <Iriez> What are the benefits to a altcoin deciding to become a side chain, and if the hash function is diff (sha vs scrypt), what happens to all the miners of the alt coin network who were mining? Does the sidechain become a seperate network?
272 2014-10-26 21:08:27 <justanotheruser> Iriez: altcoins don't have a choice. Their source code can just be copied
273 2014-10-26 21:08:56 <justanotheruser> right now, the only altcoins I can see becomming a sidechain are monero, namecoin and possibly something ethereum like, but better designed
274 2014-10-26 21:10:21 <Iriez> Yes, they can be copied, but why would anyone use them? What im trying to figure out is why a altcoin like litecoin would wish to be pegged to btc on a sidechain
275 2014-10-26 21:11:12 <Iriez> People have claimed sidechains as the 'altcoin killer', but, what incentive do altcoins have to peg themselves to the btc blockchain as a sidechain?
276 2014-10-26 21:11:32 <Iriez> Wouldn't it be in their best interest to continue working as their own network?
277 2014-10-26 21:11:37 <justanotheruser> Iriez: litecoin itself wont be pegged to bitcoin
278 2014-10-26 21:11:49 <Iriez> Because there is no incentive?
279 2014-10-26 21:12:16 <justanotheruser> I don't think there is incentive for either party. Litecoin users have ltc because they think it will do better than btc. same with btc
280 2014-10-26 21:12:41 <Iriez> Im just trying to wrap my head how this whole process effects the market.
281 2014-10-26 21:12:57 <Iriez> I understand the concepts of sidechains now, but I do not understand the incentive model
282 2014-10-26 21:13:08 <justanotheruser> Iriez: well altcoiners like to say "we are better because we broke it in a way that seems good"
283 2014-10-26 21:13:21 <justanotheruser> now bitcoin can have a sidechain broken in the way ltc is if they like
284 2014-10-26 21:13:48 <Iriez> But since the sidechain is secured by its own hashing power, and not the hashing power of the bitcoin blockchain, what would be the net positive?
285 2014-10-26 21:14:02 <Iriez> (or am I incorrect on that?)
286 2014-10-26 21:14:07 <justanotheruser> Iriez: probably not. Most sidechains will probably be merge mined with sha256
287 2014-10-26 21:15:06 <justanotheruser> but if a good number of users want to use a litecoin network on a sidechain they can
288 2014-10-26 21:18:00 <Iriez> but why would they
289 2014-10-26 21:18:46 <justanotheruser> Iriez: maybe litecoin scammers have tricked them into thinking scrypt is better
290 2014-10-26 21:21:29 <Iriez> Yes, but then wouldnt they just wish to work off their own scrypt network then?
291 2014-10-26 21:21:39 <Iriez> why would they desire to peg themselves to a sha256 based blockchain?
292 2014-10-26 21:24:10 <justanotheruser> Iriez: then you can't pay all the people that accept btc
293 2014-10-26 21:24:42 <Iriez> So, the benefit is to enable litecoin users to be able to use ltc to pay people in btc?
294 2014-10-26 21:25:17 <Iriez> does this mean that sidechains are just a simple way to provide cross currency exchange?
295 2014-10-26 21:25:20 <justanotheruser> Iriez: the benefit isn't to litecoin. Litecoin itself isn't involved
296 2014-10-26 21:25:29 <Iriez> yes, but in theory.
297 2014-10-26 21:25:46 <Iriez> 'if' litecoin decided to become pegged
298 2014-10-26 21:25:57 <justanotheruser> litecoin doesn't decide to become pegged
299 2014-10-26 21:26:11 <justanotheruser> a network like litecoins using scrypt would be a sidechain
300 2014-10-26 21:26:27 <Iriez> So your saying LTC as it exists now, can never exist as a sidechain?
301 2014-10-26 21:26:49 <Iriez> it would have to be a clone?
302 2014-10-26 21:26:56 <justanotheruser> it could if for some reason people accepted inflation in their sidechain and ltc hardforked, but that probably wont happen
303 2014-10-26 21:27:10 <Iriez> Yes yes yes, im talking theory here
304 2014-10-26 21:27:13 <Iriez> just go with me
305 2014-10-26 21:27:26 <Iriez> im trying to understand theory and application
306 2014-10-26 21:27:36 <Iriez> i cannot do that unless we assume the unlikely
307 2014-10-26 21:27:47 <justanotheruser> Iriez: if I like how the ltc network works, I would create a scrypt sidechain and send my money to it
308 2014-10-26 21:28:23 <Iriez> But, LTC 'could' fork and have its main repro become a sidechain, yes?
309 2014-10-26 21:28:54 <Iriez> and then you could exchange ltc for btc and back
310 2014-10-26 21:29:10 <justanotheruser> Iriez: the coins would only be valid to some crazy guys on some sidechain who let their bitcoins be diluted by ltc
311 2014-10-26 21:29:24 <justanotheruser> you could have asset exchanges on shared sidechains, but the ltc wouldn't be btc
312 2014-10-26 21:29:34 <justanotheruser> you can have asset exchanges without sidechains though
313 2014-10-26 21:32:08 <Iriez> the more I learn, the more confused I get. :)
314 2014-10-26 21:34:14 <justanotheruser> Iriez: you read the whitepaper?
315 2014-10-26 21:59:27 <Iriez> justanotheruser: yes.
316 2014-10-26 22:14:10 <sipa> Iriez: the benefit of becoming a sidechain is that you get a currency with actual users
317 2014-10-26 22:14:13 <sipa> like, value
318 2014-10-26 22:22:17 <Iriez> what if your altcoin already has a established base of users?
319 2014-10-26 22:22:25 <Iriez> there would be no incentive then, yes?
320 2014-10-26 22:24:10 <sipa> apart that maybe your users would now prefer an altchain that is a sidechain
321 2014-10-26 22:24:13 <sipa> but maybe not
322 2014-10-26 22:25:10 <BlueMatt> Iriez: afaik, there are no altcoins that have an established user base that is anywhere near bitcoin's...and especially not ones which have any kind of technically interesting features (which is why anyone would move their bitcoins to the sidechain anyway)
323 2014-10-26 22:26:51 <sipa> if you have an altcoin whose purpose is make the creator rich, you have no reason to make it a sidechain :)
324 2014-10-26 22:35:35 <Iriez> 160
325 2014-10-26 22:35:35 <Iriez> term, the success of the changes in the sidechain would provide the needed confidence to change
326 2014-10-26 22:35:35 <Iriez> "Then, in the longer
327 2014-10-26 22:35:36 <Iriez> the parent chain, if and when it is deemed necessary to do so.
328 2014-10-26 22:35:55 <Iriez> Wouldnt the core then just NOT introduce the changes and allow the sidechain to flourish?
329 2014-10-26 22:36:12 <Iriez> since it had done such a good job of providing a mechanism for new technological features?
330 2014-10-26 22:36:31 <Iriez> Or would that be  a threat to the bitcoin core itself, in that a sidechain becomes more heavily mined than the parent chain?
331 2014-10-26 22:36:44 <sipa> incorporating them in the main chain has advantages, like no longer needing slow and possible insecure transfers
332 2014-10-26 22:36:54 <Iriez> is that even possible? that a side chain has more hashing power than the parent?
333 2014-10-26 22:37:01 <sipa> yes
334 2014-10-26 22:37:06 <Iriez> ok.
335 2014-10-26 22:37:10 <sipa> but mining power != usage
336 2014-10-26 22:37:58 <Iriez> Well, if a sidechain has these great features that attracts the majority of consensus (mining) then wouldnt it just become the parent chain in theory?
337 2014-10-26 22:38:23 <sipa> that's also possible - and fine
338 2014-10-26 22:38:29 <Iriez> if the parent chain introduced the changes the sidechain has, wouldnt it have a difficult time convincing everyone to switch, since the majority is already using the sidechain?
339 2014-10-26 22:38:52 <Iriez> and then wouldnt that centralize bitcoin to a new party? effectively creating a coup?
340 2014-10-26 22:39:18 <sipa> if the sidechain is controlled by a central party, and people are willing to move their coins there... well, their loss
341 2014-10-26 22:39:35 <Iriez> hum, so interesting.
342 2014-10-26 22:39:39 <sipa> i mean
343 2014-10-26 22:39:47 <sipa> why are people using bitcoin and not paypal?
344 2014-10-26 22:39:55 <sipa> maybe exactly because they don't want that central control
345 2014-10-26 22:40:03 <sipa> (i hope so...)
346 2014-10-26 22:41:24 <Iriez> by central control, i guess i mean the developers of the sidechain
347 2014-10-26 22:41:33 <Iriez> its still decentralized as there's still a consensus needed
348 2014-10-26 22:41:40 <Iriez> but it would change the 'leadership'
349 2014-10-26 22:41:58 <sipa> well control is ultimately whomever runs the full nodes for the system
350 2014-10-26 22:42:13 <sipa> those who do don't necessarily need to agree with the developers
351 2014-10-26 22:42:57 <Iriez> correct and understood
352 2014-10-26 23:40:58 <Iriez> If ring signatures like what is used in monero were introduced as a side chain asset, would it help for bitcoin security? If a assest is held in a locked state, and when the asset is returned from the side chain to the parent chain, wouldnt it then go back to the original addressed used in the lock (or a address specified to be released once unlocked) ?
353 2014-10-26 23:41:09 <Iriez> er, bitcoin privacy* (not security)
354 2014-10-26 23:41:53 <Iriez> i was just thinking that zerocash as a sidechain would not improve privacy as when you convert it back to btc it would just go back to the original linked address?
355 2014-10-26 23:48:47 <sipa> duh
356 2014-10-26 23:49:12 <sipa> whatever advantages or disadvantages a sidechain offers only apply for coins while they are in the sidechain
357 2014-10-26 23:56:21 <Iriez> Will exchanges be able to interface with sidechain assets the same way they do with current alt coins?
358 2014-10-26 23:57:14 <justanotheruser> sipa: ?
359 2014-10-26 23:57:46 <justanotheruser> It shouldn't go back to the original linked address, you should be able to redeem it from the set of outputs paying to that sidechain if my understanding is right
360 2014-10-26 23:58:12 <sipa> when doing a transfer, the locking transaction should specify the script to which it can be unlocked on the other side
361 2014-10-26 23:59:40 <justanotheruser> sipa: right, and the redeem script should verify that you are only taking as much money from the paid-to-sidechain output set as the sidechain specifies you had there.
362 2014-10-26 23:59:46 <sipa> indeed