1 2014-09-28 00:29:39 <apmapm12> Raffle for an s4 only 2m ( mmxiv ) now called Maieuticoin http://i.imgur.com/CWI80Dt.png. https://bitcointalk.org/index.php?topic=623884.msg8997946#msg8997946
  2 2014-09-28 00:30:45 <sipa> apmapm12: not here
  3 2014-09-28 00:31:02 <earlz> So, is compiling bitcoin-qt on Windows with cygwin a supported scenario?
  4 2014-09-28 00:31:16 <earlz> ie, without compiling dependencies
  5 2014-09-28 00:31:31 <apmapm12> 10-4 sorry bout that :)
  6 2014-09-28 00:32:59 <sipa> earlz: only _supported_ is building on linux and osx afaik
  7 2014-09-28 00:33:25 <sipa> though building with mingw32 on windows is likely possible
  8 2014-09-28 00:33:49 <earlz> I have a mingw setup going already.. but it's high maintenance and fragile
  9 2014-09-28 00:37:52 <goykasi> ive been working on a program that watches transactions that are actively being relayed, but ive noticed that a few peers that im connected to are broadcasting old txids (from previous blocks). why would that be happening?
 10 2014-09-28 00:38:12 <sipa> goykasi: they're broken
 11 2014-09-28 00:38:42 <goykasi> i see. so i will need to actively filter those out
 12 2014-09-28 00:39:24 <sipa> your own node will filter them out
 13 2014-09-28 00:39:36 <goykasi> not a huge deal. i was trying to avoid running an rpc command for each txid i see come in
 14 2014-09-28 00:39:46 <sipa> just run behind your own node?
 15 2014-09-28 00:39:52 <goykasi> this is completely custom — running protocol commands manually
 16 2014-09-28 00:40:08 <goykasi> ill just hit my own node, should be relatively quick
 17 2014-09-28 00:40:08 <prettymuchbryce> Anyone know of a good ecdsa 256k1 library for golang ? or c libraries ?
 18 2014-09-28 00:40:18 <goykasi> but a bit more overhead
 19 2014-09-28 01:39:03 <phantomcircuit> would anybody object to the order of transaction outputs going from random to ordered by value with the last 2 outputs swapped to discourage assumptions about ordering
 20 2014-09-28 01:40:08 <sipa> haha
 21 2014-09-28 01:52:57 <gwillen> phantomcircuit: just off the top of my head, once nice thing about randomness is that even a single person using random ordering generates plausible deniability for everyone
 22 2014-09-28 01:53:01 <gwillen> sorting doesn't have that effect
 23 2014-09-28 01:53:37 <gwillen> but with enough people already being random, that may not make any difference in practice
 24 2014-09-28 01:55:22 <phantomcircuit> gwillen, right it provides cover for coinjoin and friends
 25 2014-09-28 01:55:25 <phantomcircuit> nvm then
 26 2014-09-28 01:56:01 <gwillen> I mean, if _everyone_ sorted then I think it would be as good as random; it's only bad if some people sort and some people don't.
 27 2014-09-28 01:56:19 <earlz> what's the point of sorting?
 28 2014-09-28 01:59:25 <phantomcircuit> gwillen, decentralized coinjoin stuff would be difficult if they had to be ordered
 29 2014-09-28 01:59:41 <gwillen> phantomcircuit: ahhhh, true
 30 2014-09-28 01:59:47 <phantomcircuit> earlz, potential trivial leak of prng state
 31 2014-09-28 01:59:56 <phantomcircuit> but yeah there are good reasons not to do it
 32 2014-09-28 02:00:03 <earlz> hmm
 33 2014-09-28 05:48:59 <leotreasure> hello
 34 2014-09-28 05:49:54 <leotreasure> I was wondering if anyone can help me workout how my computer was compromised?
 35 2014-09-28 05:51:26 <leotreasure> I lost 748.75 bitcoins 5 days ago and I’m offering up to 50% bounty to people who help with information that leads to the hackers arrest and return of my coins
 36 2014-09-28 05:52:33 <leotreasure> for anyone interested in doin blockchain analysis the tx is 7c67634b40d85ae08a6300a0f8613455d5d687772f9b982a11597418d805dd3d
 37 2014-09-28 05:53:07 <leotreasure> i’m running Mac OS X it was version 10.9.4 at the time
 38 2014-09-28 05:53:30 <leotreasure> Bitcoin-QT 10.9.1-beta
 39 2014-09-28 05:53:48 <leotreasure> unencrypted
 40 2014-09-28 05:54:01 <Arnavion> Are you sure it was 10.9.1-beta ?
 41 2014-09-28 05:54:35 <leotreasure> quite sure - that’s what the splash screen and about screen shoes
 42 2014-09-28 05:54:38 <leotreasure> shows*
 43 2014-09-28 05:54:44 <SomeoneWeird> leotreasure: jesus christ man
 44 2014-09-28 05:54:46 <leotreasure> i thought i was running 10.9.2
 45 2014-09-28 05:54:52 <Arnavion> Because that is not a bitcoin-qt version
 46 2014-09-28 05:55:00 <SomeoneWeird> sorry :(
 47 2014-09-28 05:55:22 <leotreasure> thanks SomeoneWeird
 48 2014-09-28 05:55:37 <leotreasure> Arnavion: is there a differnce between bitcoin qt and bitcoin core?
 49 2014-09-28 05:56:08 <Arnavion> Both are versioned the same so that's not relevant
 50 2014-09-28 05:56:23 <SomeoneWeird> leotreasure: 5 days ago? hmm, i don't suppose you had an internet facing service running on your laptop?
 51 2014-09-28 05:56:24 <Arnavion> The latest version of bitcoin-qt is 0.9.3 from a few days ago
 52 2014-09-28 05:56:43 <sipa> #bitcoin please
 53 2014-09-28 05:56:44 <Arnavion> so if yours says 10.9... then it's something else, not bitcoin-qt
 54 2014-09-28 05:56:56 <leotreasure> SomeoneWeird: not that i’m aware of
 55 2014-09-28 05:57:13 <sipa> very sad to hear you lost that much... but this is not a support channel
 56 2014-09-28 05:57:15 <SomeoneWeird> yeh move it to #bitcoin, didn't realise we were in dev
 57 2014-09-28 05:57:19 <leotreasure> Arnavion i’m sorry my mistake - it shows v0.9.1-beta
 58 2014-09-28 05:57:34 <leotreasure> ok
 59 2014-09-28 06:43:10 <phantomcircuit> leotreasure, did you wipe the os x system already?
 60 2014-09-28 06:43:19 <leotreasure> no
 61 2014-09-28 06:43:42 <leotreasure> should i?
 62 2014-09-28 06:43:46 <phantomcircuit> no
 63 2014-09-28 06:43:59 <phantomcircuit> search the hdd for java .jar files with random names
 64 2014-09-28 06:44:10 <phantomcircuit> they wont have the .jar extension
 65 2014-09-28 06:45:54 <leotreasure> search like this? *jar
 66 2014-09-28 06:50:24 <sipa> please, not here
 67 2014-09-28 10:33:15 <Akima> Does BitCoin Core (GUI) tell you if some bitcoin you have received is part of a doublespend?  (obviously; this assumes that it has received the double-spend transaction from the network).
 68 2014-09-28 11:09:44 <skinnkavaj> https://www.cryptocoinsnews.com/solution-trustless-bitcoin-microtransactions/
 69 2014-09-28 11:09:45 <skinnkavaj> ?
 70 2014-09-28 11:31:49 <jgarzik> BlueMatt, did you ever manage to run your crashing build inside gdb?
 71 2014-09-28 14:27:23 <Happzz> you know what feature i'd like? a limited rpc that would only let me generate new addresses remotely
 72 2014-09-28 14:28:07 <brisque> if you think you want that, you'll love BIP-32 wallets.
 73 2014-09-28 14:28:18 <brisque> (and you don't want that anyway)
 74 2014-09-28 14:28:49 <brisque> (you want split-key BIP32, which can make addresses for a HD wallet offline, no RPC needed at all)
 75 2014-09-28 14:29:47 <Happzz> why dont i want that?
 76 2014-09-28 14:30:24 <brisque> bitcoin's RPC is not safe to expose to the internet. if you want a limited RPC interface as a security thing, you've probably already lost in other ways.
 77 2014-09-28 14:31:53 <brisque> and if you are exposing your RPC interface to the internet, stop it pronto.
 78 2014-09-28 14:32:21 <Belxjander> brisque: I'm thinking about the libbitcoin implimentations myself and making them a local equivalent to a DLL with direct applciation calling...everything inside the library being contained seperate from the calling applications
 79 2014-09-28 14:34:54 <brisque> I'm not sure I see the point. bitcoin core's wallet is next to useless for anything except personal use, as soon as you move beyond into writing applications with it, you need to be using something else entirely.
 80 2014-09-28 14:45:50 <Happzz> bip32 sounds cool. are there any common wallets that implemented that?
 81 2014-09-28 14:46:26 <brisque> Electrum is a lite wallet that does, there's a number of them that use slightly different bip32 forms.
 82 2014-09-28 14:47:03 <brisque> the core client will eventually.
 83 2014-09-28 16:17:54 <dgenr8> Akima: not yet, see https://github.com/bitcoin/bitcoin/pull/4570
 84 2014-09-28 16:22:52 <dgenr8> Happzz: answered on #bitcoin.  And yes, bip32 is beautiful.
 85 2014-09-28 16:26:21 <brisque> wish people stuck to it as a standard though.
 86 2014-09-28 16:26:53 <brisque> as it stands there's like 20 different "x word seed" varitations that aren't interoperable
 87 2014-09-28 16:27:12 <brisque> even Electrum has at least 3 versions
 88 2014-09-28 16:42:57 <aschildbach> brisque: The problem is apps have different needs (e.g. SPV vs. centralized).
 89 2014-09-28 16:43:11 <aschildbach> brisque: And wordlists aren't even part of BIP32…
 90 2014-09-28 16:43:54 <brisque> sure, that's bip39. people still use the underlying structure differently.
 91 2014-09-28 16:44:40 <aschildbach> Right. BIP32-hierarchy, as I call the second half of BIP32, shouldn't have happened.
 92 2014-09-28 16:44:48 <brisque> what I was getting at is that to a user, they look identical
 93 2014-09-28 16:45:16 <brisque> bip38 shouldn't have happened either
 94 2014-09-28 16:45:46 <aschildbach> That's right, but it's unrelated to HD wallets isn't it?
 95 2014-09-28 16:46:07 <brisque> related to the topic of "weird wallet stuff we don't like" though
 96 2014-09-28 16:46:24 <aschildbach> Ok, agreed (-
 97 2014-09-28 16:47:56 <aschildbach> I'm hoping that one day, when HD is better understood, we'll get together and create the one standard that unifies all… (or most)
 98 2014-09-28 16:48:48 <brisque> most wallets don't even support compressed point EC keys, so I don't see them changing their HD setup any time soon
 99 2014-09-28 16:49:26 <brisque> and compressed point public keys are easy, and have a clear financial motive (lower fees)
100 2014-09-28 16:49:57 <aschildbach> Which non-webwallets don't support compressed ECKeys?
101 2014-09-28 16:51:09 <brisque> Electrum
102 2014-09-28 16:51:13 <brisque> Armory
103 2014-09-28 16:51:53 <aschildbach> Oh Armory still exists?
104 2014-09-28 16:52:00 <aschildbach> Ok didn't know
105 2014-09-28 16:52:26 <aschildbach> What about Electrum? Doesn't support sending to or receiving to compressed keys?
106 2014-09-28 16:52:30 <brisque> Armory is almost brokenly slow, but yes, it still exists
107 2014-09-28 16:53:12 <brisque> sending is not a problem, there's no way of telling if an address is masking a compressed or uncompressed point
108 2014-09-28 16:53:53 <brisque> Electrum creates uncompressed point private keys, which is the problem. I don't know if it supports importing compressed point keys.
109 2014-09-28 16:54:16 <brisque> Armory certainly does not support compressed keys in any way but sending to them.
110 2014-09-28 16:56:23 <aschildbach> Did ThomasV say anything about planned support for compressed keys?
111 2014-09-28 16:56:55 <brisque> I don't know, I haven't followed Electrum development except for electrum-server.
112 2014-09-28 16:56:56 <ThomasV> aschildbach: what do you mean?
113 2014-09-28 16:57:11 <aschildbach> ThomasV: Were talking about Electrum
114 2014-09-28 16:57:29 <aschildbach> …and whether you're planning to support compressed keys.
115 2014-09-28 16:57:30 <ThomasV> aschildbach: bip32 is compressed, no?
116 2014-09-28 16:58:16 <brisque> I believe bip32 doesn't state if keys are to be compressed or uncompressed point.
117 2014-09-28 16:58:17 <aschildbach> Oh is it? Are all BIP32-derived keys compressed?
118 2014-09-28 16:58:50 <ThomasV> aschildbach: yes
119 2014-09-28 16:59:15 <aschildbach> Nice
120 2014-09-28 16:59:32 <brisque> huh? I could have sworn there was at least one bip32 application which uses uncompressed point keys
121 2014-09-28 17:00:53 <brisque> ThomasV: no, you're right, BIP32 explicitly states compressed point keys.
122 2014-09-28 17:01:45 <aschildbach> brisque: That leaves only Armory on your list. (-:
123 2014-09-28 17:02:21 <brisque> as of Electrum 1.9.8 it is using uncompressed keys, I'm assuming compressed keys are a 2.0 feature?
124 2014-09-28 17:03:09 <ThomasV> brisque: yes
125 2014-09-28 17:03:23 <ThomasV> 2.0 is almost ready
126 2014-09-28 17:03:50 <ThomasV> but you can already import compressed keys in 1.9.8
127 2014-09-28 17:04:05 <ThomasV> (probably since 1.7, iirc)
128 2014-09-28 17:04:15 <brisque> I'm very happy that bip32 states compressed point keys, that should clear up other problem clients too
129 2014-09-28 17:04:55 <brisque> aschildbach: thing is, a lot of the total transaction traffic is blockchain.info's, and I don't see them changing any time soon.
130 2014-09-28 17:05:10 <aschildbach> I assume the problems are only if you move keys around… ?
131 2014-09-28 17:05:22 <aschildbach> How do you know its blockchain.info?
132 2014-09-28 17:05:44 <ThomasV> at some point they claimed to handle 50% of all transactions
133 2014-09-28 17:05:56 <brisque> and I don't doubt that in the least.
134 2014-09-28 17:07:21 <aschildbach> They claim a lot of ridiculous numbers.
135 2014-09-28 17:08:10 <aschildbach> If I counted each address as a wallet like bc.i do, Bitcoin Wallet has ~2 mio wallets. But it would be ridiculous to count like that.
136 2014-09-28 17:09:14 <brisque> I thought your wallet used bitcoinj, how do you know which addresses are made by it?
137 2014-09-28 17:09:46 <aschildbach> I know how many installs (according to Google) + I know from the people who report bugs how many addresses they usually have
138 2014-09-28 17:09:58 <brisque> got it
139 2014-09-28 17:10:02 <aschildbach> Of course its just an estimation.
140 2014-09-28 17:10:49 <ThomasV> I guess Electrum makes between 5% and 10% of all transactions. this is an estimation based on server logs
141 2014-09-28 17:10:59 <brisque> oddly enough blockchain.info claim exactly the same number of individual wallets (not addresses)
142 2014-09-28 17:11:18 <aschildbach> ThomasV: That's great numbers!
143 2014-09-28 17:11:40 <ThomasV> aschildbach: yeah, but you know the xkcd about extrapolating
144 2014-09-28 17:11:56 <aschildbach> hmm no
145 2014-09-28 17:12:02 <ThomasV> http://xkcd.com/605/
146 2014-09-28 17:12:42 <aschildbach> lol!
147 2014-09-28 17:13:50 <ThomasV> ok, dinner time. bbl
148 2014-09-28 18:46:45 <chmod755> hi everyone
149 2014-09-28 18:49:15 <chmod755> "bad-txns-inputs-spent" << just got that message - does that mean my client might try to use inputs that are already spent until it's sync'd?
150 2014-09-28 18:52:05 <sipa> it means the node received a transaction that cannot enter the mempool because one or more inputs are not available in either the mempool or the utxo set
151 2014-09-28 18:54:57 <therp> I noticed that the style of introducing validation rule changes went from time based in BIP 16 to block version voting in BIP 62. is there anything fundamentially different between those val.rule changes or is it that the latter is just more cautious concensus split-wise?
152 2014-09-28 18:55:31 <sipa> therp: BIP62 suggests the same mechanism as was used in BIP34
153 2014-09-28 18:55:47 <sipa> and yes, just the realization that using block versions is more cautious
154 2014-09-28 18:59:36 <therp> sipa: thanks, I thought so. is there any consensus change that was done based on block height? not that it's that much different from time...
155 2014-09-28 19:00:12 <therp> s/consensus/val.rules/
156 2014-09-28 19:00:27 <BlueMatt> jgarzik: no, linux took a shit and spewed something causing my motherboard to no longer post
157 2014-09-28 19:00:35 <BlueMatt> jgarzik: so...gotta wait for rma
158 2014-09-28 19:01:12 <Happzz> is there a way to force bitcoind to broadcast a transaction, even though it was already broadcasted?
159 2014-09-28 19:01:31 <sipa> therp: afaik, the only post-satoshi softforks have been bip16, bip30 and bip34
160 2014-09-28 19:02:06 <sipa> and in satoshi times it was just "here is a new version; upgrade"
161 2014-09-28 19:05:31 <chmod755> sipa, how do i remove this invalid transaction?
162 2014-09-28 19:05:41 <michagogo> chmod755: you don't
163 2014-09-28 19:05:44 <michagogo> it was rejected
164 2014-09-28 19:05:46 <michagogo> just ignore it
165 2014-09-28 19:05:56 <chmod755> michagogo, but it's still in my client?
166 2014-09-28 19:06:02 <michagogo> It's not, no
167 2014-09-28 19:06:11 <michagogo> I mean, it wasn't your transaction, was it?
168 2014-09-28 19:06:46 <chmod755> it was
169 2014-09-28 19:08:52 <sipa> chmod755: you can play with -zapwallettxes, but have a backup
170 2014-09-28 19:09:26 <chmod755> ok
171 2014-09-28 19:10:29 <kdomanski> <aschildbach> I'm hoping that one day, when HD is better understood, we'll get together and create the one standard that unifies all… (or most)
172 2014-09-28 19:10:31 <kdomanski> http://xkcd.com/927/
173 2014-09-28 19:11:06 <sipa> i don't even need to click that link to know what xkcd you're referring to :)
174 2014-09-28 19:11:34 <kdomanski> heh
175 2014-09-28 19:33:41 <melvster> when a public key is hashed to create a bitcoin address is it a single sha256 or double sha256?
176 2014-09-28 19:34:07 <sipa> it's sha256 + ripemd160
177 2014-09-28 19:35:39 <melvster> sipa:  i know the ripemd160 part, but is that first sha256, single or double?
178 2014-09-28 19:36:21 <sipa> single
179 2014-09-28 19:36:38 <melvster> sipa: thanks!  must be one of the few times single sha256 is used in the codebase ...
180 2014-09-28 19:36:54 <sipa> it's always either sha256+sha256 or sha256+ripemd160
181 2014-09-28 19:36:59 <melvster> ty!
182 2014-09-28 19:38:10 <therp> why is it that only the hash is part of the output script and not the pubkey? it ends up being part of the block chain anyway once it's spent. was satoshi trying to minimize public key crypto attack windows?
183 2014-09-28 19:38:43 <sipa> in the original design, full public keys went in
184 2014-09-28 19:39:05 <sipa> "addresses" were just something added later for the case where you couldn't directly talk to your recipient
185 2014-09-28 19:39:41 <sipa> and as he probably didn't know about compressed public keys, sending 65 bytes of binary data was probably considered too much, so he wanted something shorter
186 2014-09-28 19:39:54 <earlz> I find it interesting that originally you sent not to public keys or addresses, but rather to an IP address that sent back a public key/address
187 2014-09-28 19:40:02 <sipa> yup
188 2014-09-28 19:40:08 <sipa> same as in the payment protocol now, really
189 2014-09-28 19:40:11 <sipa> just a bit more secure
190 2014-09-28 19:40:22 <earlz> a shame NAT makes all that complicated
191 2014-09-28 19:40:26 <therp> sending to an IP seems terribly insecure
192 2014-09-28 19:40:30 <sipa> it was
193 2014-09-28 19:40:38 <sipa> which is one of the reasons for deprecating it
194 2014-09-28 19:41:14 <sipa> but architecturally, it's much nicer, as it allows you to send comments on transactions (which don't go into the blockchain), verify that the receiver still has the key, avoids address reuse, ...
195 2014-09-28 19:41:53 <sipa> therp: however, there is a good reason now, which is that the output scripts end up in the UTXO set, while input scripts don't
196 2014-09-28 19:43:19 <sipa> and what you mention too- computing a preimage for sha256+ripemd160 is presumably harder than solving 256-bit ecdlp
197 2014-09-28 19:43:42 <therp> well, the output script domain is so limited anyway due to standard vs. non-standard, one might just compress the UTXO set using templates for all the transactions
198 2014-09-28 19:43:44 <sipa> (160 bit vs 128 bit security)
199 2014-09-28 19:43:49 <sipa> therp: we do
200 2014-09-28 19:44:03 <sipa> but you can't throw away data
201 2014-09-28 19:44:10 <therp> I should start to read the source code for leisure
202 2014-09-28 19:44:12 <earlz> a good hashing algorithm's brute force complexity is "heat death of the universe" lol
203 2014-09-28 19:44:22 <earlz> doesn't matter if it's 128 bit, 256, or 512
204 2014-09-28 19:44:42 <sipa> counting to 2^128 is beyond human reach now, but it's not universe-scala
205 2014-09-28 19:44:49 <sipa> 2^256 is
206 2014-09-28 19:44:56 <sipa> *universe-scale
207 2014-09-28 19:45:14 <therp> sipa: what's the devs thinking on scripts in general? to me they seem to be a blind alley, something to do away with entirely
208 2014-09-28 19:45:22 <sipa> therp: heh
209 2014-09-28 19:45:36 <therp> 
ACTION note to myself: check on how etherum is doing.

210 2014-09-28 19:45:37 <sipa> i think they are the coolest and most underused feature :)
211 2014-09-28 19:45:48 <earlz> scripts are what make bitcoin future proof
212 2014-09-28 19:45:56 <sipa> it's just the user experience part that is unsolved
213 2014-09-28 19:46:25 <therp> sipa: what interesting scripts could I write? (not considering that they are non-standard)
214 2014-09-28 19:46:43 <sipa> therp: i think the most interesting ones are standard now (in git head)
215 2014-09-28 19:46:55 <sipa> just various multisig things
216 2014-09-28 19:46:56 <edcba> i think scripts are useless if there is not a bit of introspection...
217 2014-09-28 19:47:27 <sipa> atomic cross-chain swapping is nice
218 2014-09-28 19:47:28 <edcba> best to just codify transaction types imo
219 2014-09-28 19:47:53 <sipa> edcba: that requires a hardfork any time someone comes up with a new use case
220 2014-09-28 19:48:05 <sipa> a generic scripting engine allows gradual introduction
221 2014-09-28 19:48:28 <edcba> hmm
222 2014-09-28 19:49:00 <edcba> unless you can accept results of a transaction even without validating it
223 2014-09-28 19:49:07 <earlz> I've had dreams of a "MVBC" minimum viable blockchain, as an experiment of understanding how bitcoin works at it's lowest level... One of my first thoughts on scripts was making it so that there be some way to make new transaction types standardized without code changes
224 2014-09-28 19:49:22 <edcba> ie you don't know some type but some miner validated it, you validate it nonetheless
225 2014-09-28 19:49:42 <edcba> but that looks a bit dangerous :/
226 2014-09-28 19:49:42 <sipa> edcba: that's SPV security
227 2014-09-28 19:50:39 <therp> earlz: I found http://cryptonite.info/files/mbc-scheme-rev2.pdf an interesting read.
228 2014-09-28 19:50:41 <earlz> Like where there are 2 tx types to start, send to address, send to public key.. and then to add a new transaction type, some grand event must happen where a lot of coins are spent and miners vote in some way on the blockchain... and the idea being that once a new tx type is standardized, code changes can be made for optimizations
229 2014-09-28 19:51:02 <sipa> earlz: you confuse the trust model in bitcoin
230 2014-09-28 19:51:18 <sipa> miners don't set the rules; full nodes do - miners are clients trying to satisfy those rules
231 2014-09-28 19:51:28 <therp> earlz: but I am not sure if that's what you are talking about.... as this is not really about transactions rather about taking the blockchain apart
232 2014-09-28 19:51:39 <sipa> indeed
233 2014-09-28 19:51:41 <earlz> hmm.. good point. It's a shaem there is no real benefit to running a node though
234 2014-09-28 19:51:48 <sipa> of course there is!
235 2014-09-28 19:51:49 <Apocalyptic> there is
236 2014-09-28 19:51:57 <sipa> it allows you to accept transactions without needing to trust anyone
237 2014-09-28 19:52:08 <earlz> Also I envision a turing complete blockchain script (evilgrin)
238 2014-09-28 19:52:16 <Apocalyptic> sigh
239 2014-09-28 19:52:22 <sipa> i think that would be the Worst Idea Ever(tm)
240 2014-09-28 19:52:30 <sipa> in terms of DoS protection and economic incentives
241 2014-09-28 19:52:46 <earlz> But couldn't you just limit the number of instructions that could be executed?
242 2014-09-28 19:52:57 <sipa> then it isn't turing complete :p
243 2014-09-28 19:53:01 <edcba> almost turing complete with # of limited cycles :)
244 2014-09-28 19:53:20 <earlz> well of course.. nothing is turing complete at some level
245 2014-09-28 19:53:37 <CodeShark> I have an infinitely long piece of tape
246 2014-09-28 19:53:37 <earlz> your computer isn't turing complete unless you have infinite memory, etc
247 2014-09-28 19:54:08 <sipa> CodeShark: can you please write a '1' on position (Graham's number) ?
248 2014-09-28 19:54:47 <edcba> well he will just redefine the origin according to '1' position :)
249 2014-09-28 19:56:02 <CodeShark> I could, but it would take me an infinite amount of time
250 2014-09-28 19:56:29 <CodeShark> or an unboundedly large amount of time
251 2014-09-28 19:57:27 <CodeShark> anyhow, the scripting language shouldn't be part of the core protocol
252 2014-09-28 19:57:43 <sipa> it's perfectly abstractable
253 2014-09-28 19:57:44 <CodeShark> the core protocol should just concern itself with decentralized consensus on ordering
254 2014-09-28 19:58:26 <CodeShark> as to the exact contents on the stuff being ordered, that's for other layers to deal with
255 2014-09-28 19:58:32 <therp> CodeShark: then your network/blockchain is vulnerable to flooding, no?
256 2014-09-28 19:59:01 <sipa> you could have a blockchain that has no validity rules, and is only used for publishing data and getting the world to get single view
257 2014-09-28 19:59:03 <CodeShark> you probably still need an intrinsic currency of some form and a very simple transaction format (that is not scriptable)
258 2014-09-28 19:59:23 <CodeShark> just to incentivize mining and prevent flooding
259 2014-09-28 19:59:23 <sipa> but that has little dos protection
260 2014-09-28 19:59:27 <sipa> and has no support for SPV
261 2014-09-28 20:00:06 <edcba> satoshi needs to invent a protocol to get consensus on IRC
262 2014-09-28 20:02:22 <therp> CodeShark: that miners need block reward will go away at some point.. so that's a temporay problem :)
263 2014-09-28 20:02:35 <CodeShark> why would they go away at some point?
264 2014-09-28 20:02:48 <CodeShark> the intrinsic currency could be exchanged for others
265 2014-09-28 20:03:04 <CodeShark> others that DO support sophisticated scripting
266 2014-09-28 20:03:24 <therp> CodeShark: I could pay miners to mine my transaction in the next layer
267 2014-09-28 20:03:51 <CodeShark> yes, you could
268 2014-09-28 20:04:24 <CodeShark> but that might not be the optimal arrangement
269 2014-09-28 20:04:37 <CodeShark> mining hardware could be optimized for the very simple protocol
270 2014-09-28 20:04:55 <CodeShark> with no need to execute complex programs
271 2014-09-28 20:05:11 <therp> mining hardware isn't optimized for anything in bitcoin protocol, right now. it's not even optimized for full sha256 IIRC
272 2014-09-28 20:06:33 <CodeShark> the other obvious advantage of not having the scripting be done at the raw level is the ability to massively merge mine
273 2014-09-28 20:07:22 <CodeShark> you could have a single blockchain securing the ordering of many, many databases
274 2014-09-28 20:07:47 <earlz> heh I think there is a hardfork BIP that discusses that somewhat
275 2014-09-28 20:07:48 <therp> CodeShark: mining nowadays doesn't involve validation at all unfortunately.
276 2014-09-28 20:08:10 <therp> CodeShark: but yes, the block header could be rearranged I supposed to better support merged mining
277 2014-09-28 20:09:19 <earlz> I was a 128 bit nonce field instead of 32bit,while we're making wishes lol
278 2014-09-28 20:09:23 <earlz> want*
279 2014-09-28 20:09:39 <melvster> sorry if this is off-topic but on the subject of sha256, just saw this -- genius!  http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html
280 2014-09-28 20:10:04 <earlz> lol that reminds me of an onion article
281 2014-09-28 20:10:15 <CodeShark> heh
282 2014-09-28 20:11:44 <CodeShark> "…performing the algorithm manually is a good way to understand exactly how it works." - or you could just write a program and get a similar level of understanding without actually having to manually compute xors
283 2014-09-28 20:11:56 <melvster> lol
284 2014-09-28 20:12:29 <melvster> actually studies have shown that reading a physical book gives you more knowledge than a digital one
285 2014-09-28 20:12:31 <therp> CodeShark: :) nod.
286 2014-09-28 20:13:08 <therp> CodeShark: knuth once said something along the lines, "he needs to implement algorithms a couple of times to understand them."
287 2014-09-28 20:13:35 <CodeShark> I still don't fully understand the Risch algorithm
288 2014-09-28 20:13:35 <therp> oh good old knuth. I would wish he would destroy the scientific publishers.. but that' s OT.
289 2014-09-28 20:17:20 <gmaxwell> 12:02 < sipa> and in satoshi times it was just "here is a new version; upgrade"
290 2014-09-28 20:17:29 <gmaxwell> there were several height triggered.
291 2014-09-28 21:04:33 <mrebola> Good day everyone :D
292 2014-09-28 21:04:53 <OGF> 
ACTION tips his fedora

293 2014-09-28 23:09:58 <HaltingState> #define SECP256K1_START_SIGN   (1 << 1)  why is that not just #define X 0, #define Y 1
294 2014-09-28 23:09:58 <HaltingState> sipa.... #define SECP256K1_START_VERIFY (1 << 0)
295 2014-09-28 23:11:42 <gmaxwell> HaltingState: makes it clear that you can OR them.
296 2014-09-28 23:12:53 <HaltingState> ahh
297 2014-09-28 23:34:29 <bliljerk101> Anyone active with a lot of experience using bitcoind, the accounts db API, and also raw transactions API?
298 2014-09-28 23:35:00 <michagogo> bliljerk101: I'm actually about to go to sleep, but I can tell you a couple things
299 2014-09-28 23:35:22 <bliljerk101> PMing you
300 2014-09-28 23:35:22 <michagogo> Mainly that accounts probably don't do what you think they do and you very likely shouldn't be using them
301 2014-09-28 23:35:34 <michagogo> keep your books outside of bitcoind.
302 2014-09-28 23:36:51 <bliljerk101> you get my PM's?
303 2014-09-28 23:41:02 <bliljerk101> Anybody else around with a lot of expertise and a few minutes? I can pay you for your time.