1 2014-02-14 00:04:00 <BlueMatt> sinacc: hmm...ok, well I'll add it to my todo list to (finally) redo the build system over there
2 2014-02-14 00:04:07 <BlueMatt> mabye in a few months I'll get to it :(
3 2014-02-14 00:07:25 <sinacc> Well so do you experience the same problem?
4 2014-02-14 00:30:33 <sinacc> Is there anyone who uses builds from the pull-tester (http://jenkins.bluematt.me/pull-tester/) and for whom they work?
5 2014-02-14 00:31:12 <lianj> somehow pr-3656 and gox is getting nowhere :/
6 2014-02-14 00:31:30 <BlueMatt> sinacc: I dont have a windows vm handy atm
7 2014-02-14 00:35:50 <Burrito> *cough*
8 2014-02-14 00:37:25 <hasha> 586
9 2014-02-14 00:37:31 <hasha> sorry
10 2014-02-14 01:17:00 <gdsl-> This cant be good: https://blockchain.info/address/1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z
11 2014-02-14 01:17:27 <gdsl-> Looks like some sort of DOS attack to me
12 2014-02-14 01:21:40 <xiando> gdsl-: That's spam for a website, those have a message attached, old news.
13 2014-02-14 01:23:47 <gdsl-> Spam in the blockchain :(
14 2014-02-14 01:24:43 <gdsl-> Someone needs to be nuked
15 2014-02-14 01:30:00 <lysobit> is transaction malleability considered a "bug"?
16 2014-02-14 01:30:44 <guest111> it's a design flaw
17 2014-02-14 01:32:13 <ibtc> not critical design flaw, which can be worked around
18 2014-02-14 01:40:51 <Emcy> why in the fuck cant b.i restrict tagging txns to people who can show they own the address with a signed message
19 2014-02-14 01:41:05 <Emcy> do they enjoy being a free advertising platform
20 2014-02-14 01:48:27 <dangerm00se> anyone know what's going on? bitcointalk offline ?
21 2014-02-14 01:56:32 <devrandom> since 1Enjoy addresses are showing up in blockchain.info, doesn't that mean that their bitcoind is relaying spam? it could be one of the main reason it's propagating, since they have high connectivity
22 2014-02-14 02:02:05 <dangerm00se> bitcointalk back for me *shrug*
23 2014-02-14 02:24:01 <danwalton> hi
24 2014-02-14 02:45:54 <volante> I'm reading the wiki and trying to understand transaction signatures, particularly Pay-to-PubkeyHash. it looks like each input needs to have a valid signature over its public key. how do the signatures become invalid if someone modifies the outputs? isnt the signature just signing the public key?
25 2014-02-14 03:14:46 <lechuga_> how r conflicted txns going to get purged from the mempool
26 2014-02-14 03:29:20 <nezZario> Ok, so seriously
27 2014-02-14 03:30:50 <nezZario> I wrote some code a few nights ago under the assumption that the txn id could be used as a primary key in a sql database
28 2014-02-14 03:30:58 <nezZario> It obviously cannot :)
29 2014-02-14 03:31:21 <nezZario> I mean, what's the most realistic way to sync an account to a SQL database for further processing?
30 2014-02-14 03:31:34 <etotheipi_> nezZario: use a pre-signed ID
31 2014-02-14 03:31:39 <etotheipi_> zero the txIn scripts
32 2014-02-14 03:31:46 <etotheipi_> and keep a mapping of PSIDs to TxIDs
33 2014-02-14 03:32:19 <nezZario> Wait a second..
34 2014-02-14 03:32:24 <etotheipi_> make sure you make the scriptLength VAR_INTs equal to zero when you do it
35 2014-02-14 03:32:50 <nezZario> I mean, wait a sec, .. I'm using the API here..
36 2014-02-14 03:32:55 <etotheipi_> oh, nm
37 2014-02-14 03:33:04 <nezZario> Yeah, I had a feeling I was missing something =)
38 2014-02-14 03:33:15 <etotheipi_> though techincally you can still do it
39 2014-02-14 03:33:25 <etotheipi_> but it will require some manual work
40 2014-02-14 03:33:43 <etotheipi_> fetch the tx, parse it, zero the scripts, reserialize it, hash it to get the PSID
41 2014-02-14 03:34:07 <nezZario> parse it, as in fetch raw ?
42 2014-02-14 03:34:18 <etotheipi_> okay, I don't think this recommendation is for you :)
43 2014-02-14 03:34:40 <etotheipi_> I'll leave it to someone more knowledgeable about the API to respond
44 2014-02-14 03:34:40 <nezZario> No I'm a really decent programmer.. I'm getting that the txn id can only change if the script is changed?
45 2014-02-14 03:35:01 <etotheipi_> the TxID is the hash of the raw tx
46 2014-02-14 03:35:18 <etotheipi_> I'm saying, get the raw tx, blank out the scripts, reserialize it, and hash that
47 2014-02-14 03:36:12 <etotheipi_> that hash will be the same no matter how the tx is mutated when it hits the blockchain
48 2014-02-14 03:36:14 <andytoshi> nezZario: it really depends on what you consider to be the 'same transaction'
49 2014-02-14 03:36:31 <njaard> hi etotheipi_
50 2014-02-14 03:36:32 <andytoshi> probably etotheipi_ is right if you're doing something blockchain.info-ish
51 2014-02-14 03:36:53 <andytoshi> also hi etotheipi_, haven't seen you in a million years. thanks a billion for the diagrams you drew in 2011
52 2014-02-14 03:37:06 <etotheipi_> andytoshi: thanks :)
53 2014-02-14 03:37:13 <nezZario> andytoshi: if I wait for it to confirm 2 or 3 times, it should be safe, right?
54 2014-02-14 03:37:31 <etotheipi_> yeah, I have been avoiding IRC because I lose entire days here, discussing things like how much TNT it would take to reorg 30 blocks :)
55 2014-02-14 03:37:59 <andytoshi> nezZario: yeah, there'd have to be pool involvement to change txids on confirmed transactions. i'd consider them safe after a few..
56 2014-02-14 03:38:25 <andytoshi> but strictly speaking it is possible, and there have been 3-blocks-deep reorgs many times before
57 2014-02-14 03:38:31 <etotheipi_> nezZario: it depends what you're doing... if you are trying to link broadcast transactions to accounts, you'll need to store the PSID somewhere with the account, not just the TxID
58 2014-02-14 03:39:14 <etotheipi_> or watch for coins that have the same inputs and outputs of the tx you are expecting
59 2014-02-14 03:39:16 <andytoshi> so you need to consider what happens to you when it turns out you're wrong. if there is manual database fixing, i guess 3 confirms is a good risk. if there is actual money loss i'd say absolutely not
60 2014-02-14 04:20:29 <topace_> hey, i got this error on attempting a withdraw from my wallet, and now the transaction is "stuck" at 0 confirmations...
61 2014-02-14 04:20:32 <topace_> Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here. [-4]
62 2014-02-14 04:21:25 <topace_> whats the best way to proceed ?
63 2014-02-14 04:29:12 <denisx> topace: wait until a fix is out
64 2014-02-14 04:43:35 <lifeofcray> test
65 2014-02-14 04:43:36 <lifeofcray> alright
66 2014-02-14 04:43:51 <lifeofcray> guys, i'm looking to host a bitcoin wallet for multiple users
67 2014-02-14 04:44:06 <lifeofcray> do you guys have any suggestion of good, opensource, wallets?
68 2014-02-14 04:44:13 <lifeofcray> php, mysql, json
69 2014-02-14 04:44:17 <lifeofcray> or similar
70 2014-02-14 04:48:21 <richardus> nice try wallet stealer
71 2014-02-14 04:56:34 <lifeofcray> richardus naa
72 2014-02-14 04:57:08 <lifeofcray> one of the owners of http://bitember.com
73 2014-02-14 04:57:13 <lifeofcray> looking into expanding
74 2014-02-14 04:58:57 <mappum> does bitcoind keep the list of all unspent outputs in memory, or is that too large?
75 2014-02-14 05:42:16 <andytoshi> is there a way to get information about the output in listtransactions?
76 2014-02-14 05:42:25 <andytoshi> i have figured out the story of all my unconfirmed transactions except one
77 2014-02-14 05:42:41 <andytoshi> gmaxwell: ^
78 2014-02-14 05:43:06 <andytoshi> i'm pretty sure i found the tx which invalidated it on bc.i, but i don't remember the story on this one so i'm not sure
79 2014-02-14 05:45:02 <andytoshi> wait, i do, this one was a no-fee tx which i tried to double-spend and failed (the no-fee version eventually got through)
80 2014-02-14 05:46:21 <andytoshi> so of the 16 0-conf entries in my listunspent, ten of them are one double-spend, four of them are another, and the remaining two are two individual attempts to steal PT's OP_CHECKSIG OP_NOT coins
81 2014-02-14 05:46:31 <andytoshi> neither of the latter are confirmed, but they conflict with each other
82 2014-02-14 05:47:53 <gmaxwell> wow you got tx in your wallet that conflict with each other but not one of them is in the chain? I dunno how thats possible.
83 2014-02-14 05:48:18 <gmaxwell> andytoshi: you try with that patch?
84 2014-02-14 05:48:37 <andytoshi> gmaxwell: i constructed both of them by copy/pasting hex from other transactions :P
85 2014-02-14 05:48:47 <andytoshi> yep, just tried with the patch, things look good, one sec
86 2014-02-14 05:49:20 <andytoshi> (both are completely nonstandard. i tried to push to eligius -- the first pushed but had no fee, and wasn't mined. the second was rejected because it conflicted)
87 2014-02-14 05:50:11 <andytoshi> ok, so one conflicted transaction originally appeared four times (as a send and as a receive, and these were duped for some reason)....with the patch it appears only twice (as a send and as a receive, no dupe) and is marked conflicted. success ....
88 2014-02-14 05:51:47 <gmaxwell> hm. I'm not sure why it would have been duped or why the patch would have changed that
89 2014-02-14 05:52:10 <gmaxwell> patch should have just added the conflicted display and confirms -1 to dommed txn (unconfirmed and not in your memory pool)
90 2014-02-14 05:52:26 <andytoshi> oops, it wasn't duped, there were two addresses involved.
91 2014-02-14 05:53:02 <andytoshi> originally it appeared both as a send and as a recieve. now it appears just once, as 'conflicted'. i think that's correct
92 2014-02-14 05:53:11 <gmaxwell> ah yea, sounds fine.
93 2014-02-14 05:53:42 <andytoshi> the other conflicted transaction originally appeared 10 times. now it appears 8. it is marked conflicted now, which is great. i'm checking where the 10 and 8 come from..
94 2014-02-14 05:54:36 <andytoshi> cool, originally it was there twice as a receive and eight times as a send. now it's just eight times as conflicted. so that's correct also
95 2014-02-14 05:54:44 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/3671 I'd suggest also trying this, but the fact that it only shows normid conflicts makes it unintersting on your wallet, not sure why gavin decided to do it that way, I don't think it's a great approach.
96 2014-02-14 05:55:36 <andytoshi> as for the two which were actually unconfirmed, they have vanished from the list.
97 2014-02-14 05:55:39 <andytoshi> is that right?
98 2014-02-14 05:55:54 <andytoshi> they conflicted each other but not anything confirmed
99 2014-02-14 05:56:16 <andytoshi> oh! the way that i got in that state is i disabled all the checks on sendrawtransaction..
100 2014-02-14 05:56:32 <gmaxwell> andytoshi: ah, okay, makes a lot more sense now
101 2014-02-14 05:56:49 <andytoshi> so i think this is the correct behaviour for pepole like me :) it is what i want to have happened anyway
102 2014-02-14 05:56:54 <gmaxwell> you had me going through the code looking for a way we could annoucne a txn without putting it in the mempool.
103 2014-02-14 05:57:03 <andytoshi> :P sorry, i forgot i'd done that..
104 2014-02-14 05:57:12 <gmaxwell> feel free to go post a review on the patch.
105 2014-02-14 05:57:40 <andytoshi> will do. then i'll try the other one..
106 2014-02-14 06:11:19 <topace_> gmaxwell I've got a transaction stuck: "The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here"
107 2014-02-14 06:11:45 <topace_> its deducted my balance from the wallet
108 2014-02-14 06:11:49 <topace_> and is stuck at 0 confirmations
109 2014-02-14 06:11:55 <gmaxwell> topace_: what version of bitcoin are you running?
110 2014-02-14 06:11:58 <topace_> 0.8.6
111 2014-02-14 06:12:23 <gmaxwell> topace_: what platform?
112 2014-02-14 06:12:47 <topace_> linux
113 2014-02-14 06:12:48 <gmaxwell> topace_: feel like running some pre-release code with some fixes?
114 2014-02-14 06:12:49 <topace_> 64bit
115 2014-02-14 06:13:20 <topace_> i can
116 2014-02-14 06:13:29 <topace_> i've got a copy of the wallet on a different system
117 2014-02-14 06:13:38 <topace_> i can take the live wallet offline though
118 2014-02-14 06:13:51 <gmaxwell> basically you've got a spend of unconfirmed change that will never confirm. Salvage wallet may fix it but its a bit of a blunt instrument and it blows away all of your metadata.
119 2014-02-14 06:13:51 <topace_> (until I'm sure it'll be fixed)
120 2014-02-14 06:14:18 <topace_> its a huge wallet.. ~650MB, takes a solid hour to -rescan
121 2014-02-14 06:14:40 <denisx> what happens to the comments on a zeroconf tx when a patch appears?
122 2014-02-14 06:15:02 <gmaxwell> There are patches that implement a zapwallettx that will knock them out, which is a nicer thing than salvage but takes a long time to rescan, and patches to show those txn as conflicted and ignore them for the purpose of authoring new transactions.
123 2014-02-14 06:15:25 <gmaxwell> denisx: metadata assc is currently lost on those.
124 2014-02-14 06:16:09 <topace_> i can try zapwallettx fix if you think thats best
125 2014-02-14 06:16:20 <gmaxwell> topace_: are you able to avoid generating new addresses on it for a while while the wallet is rescanned on another system?
126 2014-02-14 06:16:55 <topace_> i can't stop the live system from generating new addresses
127 2014-02-14 06:17:04 <denisx> how long is long?
128 2014-02-14 06:17:38 <topace_> but the copy i have has the same issue even after a -rescan, so i can play/fudge with the copy
129 2014-02-14 06:17:46 <topace_> until i find affix
130 2014-02-14 06:17:59 <topace_> then ill just have to shut the live system down once i know how to fix it there
131 2014-02-14 06:18:16 <gmaxwell> topace_: I think running with -spendzeroconfchange=0 right now is most prudent, then using https://github.com/bitcoin/bitcoin/pull/3669 is probably best at the moment. And should avoid the rescan.
132 2014-02-14 06:18:59 <topace_> -spendzeroconfchange=0 on the LIVE system?
133 2014-02-14 06:19:13 <gmaxwell> yes, but if it's 0.8.6 unpatched then you don't have that.
134 2014-02-14 06:19:34 <gmaxwell> spending unconfirmed change is just going to make your problems potentially worse if people are throwing mutants.
135 2014-02-14 06:20:06 <gmaxwell> There are patches for that for 0.8.6 I'd have to go hunting for themâ I don't know where they are. (it's a trivial set of changes)
136 2014-02-14 06:20:13 <topace_> live is 0.8.6 stock, so i guess i can't do much on it at the moment.
137 2014-02-14 06:20:20 <flound1129> what's a safe maximum # of outputs per transaction? is 50 too high?
138 2014-02-14 06:20:58 <gmaxwell> flound1129: 50 sounds fine to me.
139 2014-02-14 06:21:58 <andytoshi> does gavin's normtxid order the outputs in some canonical way?
140 2014-02-14 06:22:04 <gmaxwell> topace_: any case where you spend unconfirmed change is change that your change gets conflicted and you'll end up with coins tied up.
141 2014-02-14 06:22:12 <warren> andytoshi: gavin's?
142 2014-02-14 06:22:17 <gmaxwell> andytoshi: read the code.
143 2014-02-14 06:22:35 <gmaxwell> andytoshi: it's just a templatized transaction. why?
144 2014-02-14 06:22:55 <flound1129> gmaxwell: thx
145 2014-02-14 06:23:17 <andytoshi> gmaxwell: it turns out one of my double-spends is actually malleated. but this occured before the malleability bot was running.
146 2014-02-14 06:23:32 <andytoshi> it's a coinjoin so i think they just differ in input/output ordering
147 2014-02-14 06:23:38 <gmaxwell> er.
148 2014-02-14 06:23:49 <gmaxwell> that shouldn't match. are you sure they don't match from someone resigning?
149 2014-02-14 06:24:09 <andytoshi> not sure at all, one sec
150 2014-02-14 06:24:23 <topace_> okay I'm a git newb, how do i pull that patch into my local code?
151 2014-02-14 06:24:37 <gmaxwell> just getrawtxn 1 on it. and diff.
152 2014-02-14 06:25:29 <gmaxwell> topace_: there are a bunch of ways ... wget https://github.com/bitcoin/bitcoin/pull/3669.patch and applying it with git am -3 or patch, is one way.
153 2014-02-14 06:25:45 <andytoshi> if i do getrawtransaction it says 'no information available' about the unconfirmed version
154 2014-02-14 06:25:56 <gmaxwell> topace_: on second thought -spendzeroconfchange=0 + 3669 will not release any coins you currently have tied up in a conflicted transaction, so you still may need to zap.
155 2014-02-14 06:27:51 <topace_> is zapwallettx not 3669?
156 2014-02-14 06:28:51 <lnovy> no
157 2014-02-14 06:29:10 <lnovy> 3659 is zapwallet
158 2014-02-14 06:29:22 <andytoshi> gmaxwell: you're right, i must've resigned this, the ordering would be the same because my joiner only randomizes the ordering once
159 2014-02-14 06:29:38 <andytoshi> and i remember when this happened, the joiner server was in a stable state
160 2014-02-14 06:31:22 <topace_> and zapwallettx is better than salvage in this case?
161 2014-02-14 06:31:30 <topace_> or might either fix the problem?
162 2014-02-14 06:31:53 <topace_> salvage is in 0.8.6? i could run it on my wallet copy
163 2014-02-14 06:32:33 <gmaxwell> zapwallettx is better than salvage. Salvage is a very blunt instrument, doesn't always work completely right, and erases everything except keys.
164 2014-02-14 06:32:56 <gmaxwell> I'd strongly recommend zapwallettx over salvage.
165 2014-02-14 06:33:19 <gmaxwell> I've got a testnet wallet here which is completely savaged by salvagewallet. Of course, make a backup first no matter what.
166 2014-02-14 06:34:05 <topace_> should i put both 3669 and 3569 in?
167 2014-02-14 06:34:15 <gmaxwell> yes.
168 2014-02-14 06:34:33 <volante> hi. I'm reading the wiki and need some help understanding transaction signatures, specifically Pay-to-PubkeyHash. it looks like each input needs to have a valid signature over its public key. how do the signatures become invalid if someone modifies the transaction outputs? isnt the signature just signing the public key?
169 2014-02-14 06:35:06 <gmaxwell> volante: no the signature signs the whole transaction with the signatures masked out (assuming sighash_all)
170 2014-02-14 06:36:47 <volante> oh i see. thanks.
171 2014-02-14 06:37:14 <andytoshi> gmaxwell: tested both of gavin's PRs, posted comments on both. both worked correctly, and i had a good mix of double-spends.
172 2014-02-14 06:39:12 <gmaxwell> andytoshi: can you check getunconfirmedbalance ? I assume it's incorrect as noted on the pull: counting the conflicted txn... when it probably shouldn't.
173 2014-02-14 06:39:15 <topace_> hmm what libdb version do i need? saw something about binary incompatibility across versions..?
174 2014-02-14 06:39:36 <gmaxwell> topace_: 4.8 assuming you are using the published bitcoin binaries normally.
175 2014-02-14 06:40:23 <topace_> ugh this is gonna be a mess on ubuntu
176 2014-02-14 06:40:39 <topace_> it already has 5.1 as a dependency for other packages
177 2014-02-14 06:40:50 <gmaxwell> you can have both installed at once, they don't conflict.
178 2014-02-14 06:41:08 <gmaxwell> If there isn't a 4.8 package for your version I believe the bitcoin ppa run by bluematt has one.
179 2014-02-14 06:41:16 <gmaxwell> (sorry, I'm not an ubuntu user myself)
180 2014-02-14 06:41:20 <topace_> ii libdb4.8 4.8.30-11ubuntu1 Berkeley v4.8 Database Libraries [runtime]
181 2014-02-14 06:41:20 <topace_> ii libdb4.8-dev 4.8.30-11ubuntu1 Berkeley v4.8 Database Libraries [development]
182 2014-02-14 06:41:59 <topace_> configure doesn't find them
183 2014-02-14 06:43:29 <flound1129> gmaxwell: while you're here, do you know why bitcoind strace is spammed with futex errors?
184 2014-02-14 06:43:56 <andytoshi> gmaxwell: yup, getunconfirmedbalance includes conflicts on both patches. i edited my comments to reflect this
185 2014-02-14 06:48:49 <venzen> topace: you also need libdb4.8++-dev
186 2014-02-14 06:50:41 <andytoshi> it's 1am here, i'm headed to bed. thx to all the devs for the hard work they have put into bitcoind over the last 72 hours!
187 2014-02-14 06:50:54 <topace_> indeed
188 2014-02-14 06:51:14 <topace_> can't wait for next full release, maybe things will go back to "normal"
189 2014-02-14 06:51:16 <topace_> lol whatever that is
190 2014-02-14 06:51:41 <BlueMatt> topace: need to add the ppa
191 2014-02-14 06:51:42 <topace_> venzen, thanks, thats what i was missing
192 2014-02-14 06:51:47 <BlueMatt> like apt-add-repository or something
193 2014-02-14 06:52:35 <topace_> which ppa ?
194 2014-02-14 06:52:45 <maaku> the bitcoin ppa
195 2014-02-14 06:52:56 <maaku> ;;google bitcoin ppa stable
196 2014-02-14 06:52:57 <gribble> Bitcoin - Stable Channel : âBitcoinâ team - Launchpad: <https://launchpad.net/~bitcoin/+archive/bitcoin>; Packages in âBitcoin - Stable Channelâ - Launchpad: <https://launchpad.net/~bitcoin/+archive/bitcoin/+packages>; Stable releases : âYacoinâ team - Launchpad: <https://launchpad.net/~yacoin/+archive/yacoin>
197 2014-02-14 06:53:50 <venzen> topace_: you're welcome. be sure to check the doc at bitcoin/doc/build-unix.md ... saved me many hours (the second time round)
198 2014-02-14 06:53:53 <BlueMatt> ACTION -> bed
199 2014-02-14 07:03:57 <topace_> starting up now
200 2014-02-14 07:04:01 <topace_> 2014-02-14 07:03:22 init message: Zapping all transactions from wallet...
201 2014-02-14 07:04:20 <topace_> zap implies -rescan, so that'll be an hour at least..
202 2014-02-14 07:05:43 <topace_> 2014-02-14 07:05:12 init message: Loading wallet...
203 2014-02-14 07:11:22 <gmaxwell> "-nuketxns"
204 2014-02-14 07:11:29 <gmaxwell> :P
205 2014-02-14 07:13:11 <muhoo> my god. what kind of help do you need to resolve the shitshow that is the corporate media handling of this issue?
206 2014-02-14 07:13:50 <muhoo> writing docs? reviewing docs? is there a wiki somewhere?
207 2014-02-14 07:17:07 <muhoo> it seems that the best communicators have their heads down writing code, reviewing code, thinking, solving problems, etc. and haven't had time to really educate the financial media. so in stead they're parroting mtgox fud, etc.
208 2014-02-14 07:21:34 <gmaxwell> muhoo: probably bitstamp getting withdrawls on line would accomplish 10x more than anything else.
209 2014-02-14 07:22:02 <muhoo> aye.
210 2014-02-14 07:22:43 <muhoo> are they blocked on anything from anyone else? or just goign through their own internal process?
211 2014-02-14 07:23:14 <muhoo> btw "best communicators" is basically, you, and gavin, and a couple others.
212 2014-02-14 07:23:36 <anddam> gmaxwell: yea, when you open your exchange let me know and I'll jump in
213 2014-02-14 07:24:13 <muhoo> i don't think any sane person would want to run an exchange
214 2014-02-14 07:24:20 <gmaxwell> muhoo: I don't know at this point. There was past communication but it's died down now.
215 2014-02-14 07:24:30 <gmaxwell> muhoo: exactly (wrt: sane and exchanges)
216 2014-02-14 07:25:10 <Luke-Jr> ^
217 2014-02-14 07:25:46 <anddam> the Base58Check(version byte,RIPEMD160(SHA256(script))) address formula at https://en.bitcoin.it/wiki/Base58Check_encoding#Encoding_a_Bitcoin_address is the short version of https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses right?
218 2014-02-14 07:26:04 <maaku> "-nuketxns" is better than "-zapwallettx" (singular)
219 2014-02-14 07:26:12 <anddam> I should refer to te latter for getting an address from script hash
220 2014-02-14 07:26:30 <wumpus> muhoo: one good thing to come from this is that I'm seeing a huge spike in interest in bitcoin's internal workings
221 2014-02-14 07:26:35 <anddam> is there a function in API already for doing that?
222 2014-02-14 07:27:01 <maaku> wumpus: yes, that's very good
223 2014-02-14 07:37:22 <muhoo> wumpus: sure, in the long run it makes the system stronger.
224 2014-02-14 07:38:08 <murr4y> hi all - is there a changelog for protocol changes somewhere?
225 2014-02-14 07:40:31 <wumpus> murr4y: not specifically, though generally protocol changes are first described in a bip which you can fine here: https://github.com/bitcoin/bips
226 2014-02-14 07:43:05 <murr4y> aha, thanks
227 2014-02-14 07:49:08 <venzen> muhoo: re- corporate/mainstream gorefest - it's the social mood in general IMO - nothing would detract them now... had this happened during the highs the headlines would have been "Bitcoin exchanges successfully defend against DDoS"
228 2014-02-14 07:51:02 <venzen> once the exchanges re-enable withdrawals and this upgrade is released; there should be a wider turn in mood around the same time... the devs are doing great work here.
229 2014-02-14 07:51:12 <wumpus> it will die down anyway, and in a few weeks everyone will have forgotten what the fuss was about
230 2014-02-14 07:51:37 <muhoo> that's been the pattern, true.
231 2014-02-14 07:52:20 <wumpus> ... and there will be lots of new people which never went through this to cry wolf about the next issue happens
232 2014-02-14 07:52:42 <muhoo> so far i've been through 3 bubbles and crashes
233 2014-02-14 07:54:30 <tommygunner> just another case of webwallets
234 2014-02-14 07:54:43 <tommygunner> people always need to learn the hard way
235 2014-02-14 07:55:46 <muhoo> it's the inexorable march of technology. stuff grows, flaws get exposed (or exploited), bugs get fixed, system gets stronger.
236 2014-02-14 07:56:19 <wumpus> well not people in general, there could just as well be a majority of people getting things right, but you never hear them.. that's the distortion lens of the internet
237 2014-02-14 07:58:09 <wumpus> you only hear about problems problems problems
238 2014-02-14 07:59:55 <muhoo> i remember this: http://www.phworld.org/history/attcrash.htm somehow the phone network is still here
239 2014-02-14 08:03:02 <anddam> http://goo.gl/1vGGFS has two transactions from the mtgox missing pool api, the second has an ['out']['addr'] value that start with 6, I guess that's not a bitcoin address, right?
240 2014-02-14 08:05:12 <wumpus> looks like hex not base58
241 2014-02-14 08:05:47 <wumpus> (and no, it doesn't look like the decoded hex form of the address either, no version byte for example)
242 2014-02-14 08:07:48 <wumpus> it's 160 bits so it is likely the raw hash160(sha256(pubkey))
243 2014-02-14 08:09:48 <anddam> hash160 is RIPEMD-160 right?
244 2014-02-14 08:10:16 <wumpus> yes
245 2014-02-14 08:11:22 <wumpus> https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
246 2014-02-14 08:12:34 <anddam> wumpus: that's what I'm reading
247 2014-02-14 08:15:26 <wumpus> oh I see now it was posted a few lines before too, sorry \o/
248 2014-02-14 08:46:44 <anddam> ok that was straight forward https://gist.github.com/anddam/8997785
249 2014-02-14 08:47:01 <anddam> without the space
250 2014-02-14 08:51:13 <anddam> the blockchain I have on my computer contains info about all transactions, doesn't it?
251 2014-02-14 08:51:43 <tommygunner> naturally
252 2014-02-14 08:51:47 <wumpus> anddam: you could remove some intermediate encode/ .decode('hex') steps, but looks ok
253 2014-02-14 08:53:11 <wumpus> anddam: depends on what you mean with 'all transactions', it will contain all confirmed transactions up until the point you are synchronized
254 2014-02-14 08:53:41 <anddam> wumpus: I prefer readability, in this case adherence to the wiki page, over code optimization
255 2014-02-14 08:53:48 <anddam> I mean I only have to parse a handful of tx once
256 2014-02-14 08:53:55 <Logicwax> question about malleability.....
257 2014-02-14 08:54:29 <Logicwax> if someone has a donation address that people donate to, and they keep using that address, and its cleared out every so often (money tx'd from it to another holding address)....
258 2014-02-14 08:54:37 <wumpus> anddam: I'm not sure it is good for readability to do extra steps, but ok, I don't really mind it was just a suggestion
259 2014-02-14 08:54:45 <anddam> wumpus: I see, thanks
260 2014-02-14 08:55:37 <Logicwax> lets say, i convince someone who controls a donation address to send me a few BTC from it. couldn't I record that transaction, malform it so it gets another TXID, and then replay it back at a later time?
261 2014-02-14 08:56:28 <anddam> Logicwax: replay it?
262 2014-02-14 08:56:43 <Logicwax> like if wikipedia accepts donations at an address, and i convince the webmaster to send me 1BTC from that address at any point in time.....couldnt i keep submitting that TX again and again with a new txid if i malform it?
263 2014-02-14 08:56:55 <Logicwax> anddam: re-submit it
264 2014-02-14 08:57:52 <wumpus> Logicwax: you can, but it would be pointless, only one variant will count
265 2014-02-14 08:57:53 <anddam> you mean because the input would eventually have available non spent money (UTXO?)
266 2014-02-14 08:58:08 <Logicwax> yeah.
267 2014-02-14 08:58:14 <wumpus> Logicwax: if it was THAT easy, don't you think everyone would be bankrupted by now :-)
268 2014-02-14 08:58:16 <Logicwax> it sounded like from this URL: https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35055553 that it could happen
269 2014-02-14 08:58:30 <Logicwax> i know wumpus, thats why im asking. what exactly stops that from happening?
270 2014-02-14 08:59:12 <wumpus> Logicwax: all nodes and miners validate transactions, and they reject transactions that conflict with a prior transactions, no conflicting transactions (such as double spends) can make it into the block chain
271 2014-02-14 08:59:17 <Logicwax> thepiratebay has a constant re-usable donation address. im sure they transfer money out of it every so often. but even as it gets filled back up with more transactions, what stops the replay?
272 2014-02-14 08:59:20 <wumpus> Logicwax: read up on double spending protection in bitcoin
273 2014-02-14 08:59:46 <anddam> I think the conflict is not obvious to him in this case (to me neither actually)
274 2014-02-14 08:59:47 <Logicwax> i know, but wouldnt this NOT be a double spend if the address is re-filled?
275 2014-02-14 09:00:19 <wumpus> It would certainly a double spend. Everything that tries to spend the same inputs twice is a double-spend
276 2014-02-14 09:00:27 <anddam> it'd be like an automated ATM withdraw from your PoV
277 2014-02-14 09:00:30 <wumpus> for a second time*
278 2014-02-14 09:00:37 <anddam> so inputs are unique
279 2014-02-14 09:00:44 <Logicwax> well then how does emptying an address a second time different than this?
280 2014-02-14 09:01:20 <wumpus> Logicwax: this has nothing to do with addresses, transactions happen on a lower level (inputs and outputs)
281 2014-02-14 09:01:28 <Logicwax> if you send me 10 BTC to XXXXX, i then TX 10 BTC out of that to YYYYY. then later someone else TX 10 BTC to XXXXX, then why cant i respend whats in XXXXXX
282 2014-02-14 09:01:41 <Logicwax> hrmm
283 2014-02-14 09:01:55 <anddam> tommygunner: about "Works only for addresses in the local wallet, external addresses will always show 0." how would I go for querying external addresses?
284 2014-02-14 09:02:14 <Logicwax> ohhh wait, perhaps even when they re-empty the address, it still uses the prev outputs of all those who donated
285 2014-02-14 09:03:02 <Logicwax> yeah i get it now....stupid question
286 2014-02-14 09:05:52 <wumpus> Logicwax: when a transaction spends prior coins it needs to identify the exact input (txid-vout) pair that it spends, you can see the addresses and keys as an authentication layer on top but they don't identify 'coins'
287 2014-02-14 09:06:35 <Logicwax> yeah
288 2014-02-14 09:07:47 <wumpus> and even if you understand all that, you can still mess up, bitcoin is complex and please stop asking stupid questions instead of making stupid assumptions :)
289 2014-02-14 09:08:02 <wumpus> -stop
290 2014-02-14 09:08:36 <Logicwax> well i wasnt assuming, heh. i knew it wouldn't work
291 2014-02-14 09:08:47 <Logicwax> but it was my way of proposing "what mechanism stops this?"
292 2014-02-14 09:09:01 <wumpus> yes but I mean it's better to ask instead of just doing something which turns out to be wrong later
293 2014-02-14 09:09:13 <Logicwax> but then i realized, the Malleability doesnt change the situation
294 2014-02-14 09:09:16 <wumpus> like using txids for persistently identifying transactions like people did
295 2014-02-14 09:09:27 <Logicwax> oh yeah definitely
296 2014-02-14 09:09:39 <wumpus> if they bothered to ask a 'dumb question' here it probably wouldnt have happened
297 2014-02-14 09:09:44 <lnovy> txids are not unique ;)
298 2014-02-14 09:10:57 <wumpus> lnovy: oh really? :P
299 2014-02-14 09:11:35 <lnovy> wumpus: really really... only those of transactions with unspent outputs are unique
300 2014-02-14 09:12:42 <wumpus> they are entirely unique, just not stable over mutations that don't affect the signature/validity, so you can have multiple txids for what you would call one transaction, but you still can't have multiple transactions with one txid (unless you count sha256 collisions...)
301 2014-02-14 09:12:54 <lnovy> It is like hour or so when I revealed this secret to mr. karpales :)
302 2014-02-14 09:12:56 <wumpus> anyway that's splitting hairs
303 2014-02-14 09:13:14 <Logicwax> dont the current proposed fixes still leave the problem of zeroconf change?
304 2014-02-14 09:13:30 <lnovy> you can have two instances of exactly the same transaction to byte in blockchain
305 2014-02-14 09:13:36 <wumpus> Logicwax: yes, using zeroconf change will remain a gamble
306 2014-02-14 09:13:41 <lnovy> therefore txid is not unique
307 2014-02-14 09:13:58 <wumpus> Logicwax: you can solve that problem by not spending zeroconf change
308 2014-02-14 09:14:07 <wumpus> lnovy: no, you can't have that!
309 2014-02-14 09:14:22 <wumpus> lnovy: you cannot have duplicate transaction in the block chain!
310 2014-02-14 09:14:38 <lnovy> wumpus: read and learn: 00~https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki01
311 2014-02-14 09:14:56 <lnovy> https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
312 2014-02-14 09:14:56 <Logicwax> yeah..easier said than done i bet. im sure lots of POS systems need to use zeroconf change
313 2014-02-14 09:15:38 <wumpus> Logicwax: or you can spend zeroconf change but you have to take care that the transaction may change under you, so you may have to re-sign
314 2014-02-14 09:15:39 <lnovy> Logicwax: in that situation you either have to wait or just have more spare coins
315 2014-02-14 09:16:28 <Logicwax> oh geez...according to that link, coinbase TXs were hit too? ouch
316 2014-02-14 09:17:12 <Logicwax> wumpus: well why the hell do transactions need to reference other TXs in the same block left over from change by their TXID? isnt the input identifer enough?
317 2014-02-14 09:17:27 <wumpus> Logicwax: lnovy is just confusing things, the duplicates that bip 0030 is talking about have nothing to do with the duplicates used in the DOS
318 2014-02-14 09:18:16 <wumpus> Logicwax: because thransactions don't 'know' they will end up in the same block in advance
319 2014-02-14 09:18:22 <lnovy> Logicwax: imagine a situation when you are solo-mining directly to the exchange address and suddenly they are unable to process any outgoing transaction for 100 blocks
320 2014-02-14 09:19:49 <Logicwax> but what good does the TXID help? during validation, wouldn't the inputs->outputs->inputs be all stringed together?
321 2014-02-14 09:20:02 <Logicwax> cus in the end, thats all that matters
322 2014-02-14 09:20:16 <Logicwax> so why bother using TXID as the indentifier of a prev transaction
323 2014-02-14 09:20:21 <wumpus> Logicwax: because it identifies (together with vout id#) what coin your input wants to spend
324 2014-02-14 09:20:42 <wumpus> Logicwax: it is what is used to chain the transactions together
325 2014-02-14 09:20:44 <Logicwax> right. so couldnt it JUST be vout id#?
326 2014-02-14 09:21:04 <wumpus> eh no... vout id is a small integer, usually 0
327 2014-02-14 09:21:13 <Logicwax> ah
328 2014-02-14 09:21:15 <wumpus> (depending on the number of outputs the prev tx has)
329 2014-02-14 09:22:25 <Logicwax> hypothetically speaking, it sounds like using the inputs/output identifiers as truth would make more sense, if you cant garuntee TXIDs to be truth
330 2014-02-14 09:23:04 <lnovy> txid:vout is unique in your unspent coins, but not in all coins you could have possibly recieved... you need to have this in mind when you do eg. accounting
331 2014-02-14 09:23:41 <Logicwax> good point
332 2014-02-14 09:23:46 <lnovy> but even thou txid is not unique, you can make ntxid unique on your outgoing transactions
333 2014-02-14 09:24:11 <lnovy> but you need to slip a transaction in between
334 2014-02-14 09:26:09 <lnovy> in the end, I thought this was first usable thing of ntxid that would deserve standardisation, but then blocknum:txid is much more effective
335 2014-02-14 09:26:31 <wumpus> blocknum is not a good measure as it may change under reorganizations
336 2014-02-14 09:27:03 <lnovy> it is good enough, it's solid after short time
337 2014-02-14 09:27:31 <Logicwax> i have to read up on what ntxid is
338 2014-02-14 09:27:32 <wumpus> no, it's not good enough, please don't get people from one broken solution to another
339 2014-02-14 09:27:36 <Logicwax> thats a new one for me
340 2014-02-14 09:27:53 <lnovy> and probability of having same txids closer than 100 blocks is very very small
341 2014-02-14 09:28:41 <lnovy> wumpus: at least it is unique by definition, ntxid is not, you have to be carefull to make them so
342 2014-02-14 09:28:43 <wumpus> yes but if it happens it would be disastrous if people use that way of identifying transactions
343 2014-02-14 09:29:20 <lnovy> no, I'm not speaking about identifiing transaction to other party, I'm talking accounting here
344 2014-02-14 09:29:40 <wumpus> at least if they reissue with different inputs, if they reissue with the same inputs it's always ok
345 2014-02-14 09:30:09 <Logicwax> is ntxid a new proposal?
346 2014-02-14 09:30:25 <lnovy> no, txid is not unique -> ntxid is not unique
347 2014-02-14 09:30:38 <lnovy> yes, I'm trying to kill it
348 2014-02-14 09:30:51 <lianj> b/win21
349 2014-02-14 09:31:13 <Logicwax> oh...the gox proposed thingy
350 2014-02-14 09:40:10 <xiando> 10:39 <AvalonSales> I SELL: Avalon1 110GH/s bitcoin mining machines. Message me for more info!
351 2014-02-14 09:40:41 <wumpus> xiando: please don't relay spam here
352 2014-02-14 09:40:42 <xiando> onjoin spam when joining this channel from that thing, that nick not in channel so something/some other nick here triggers it
353 2014-02-14 09:41:16 <wumpus> I think you can report spammers in #freenode
354 2014-02-14 09:41:46 <Elio19> I totally want one of those ^
355 2014-02-14 09:45:14 <Mallstromm> may I ask if there is an ETA for a fix for the malleability issue? I know there won't be a fix that will make txid immutable, but something that will clean up our QT's and will make the balance to be displayed correctly
356 2014-02-14 09:45:51 <under_hood> Mallstromm: look at github
357 2014-02-14 09:46:11 <under_hood> Mallstromm: https://github.com/bitcoin/bitcoin/pull/3671
358 2014-02-14 09:46:34 <Mallstromm> "I need to sleep on the last commit, I'm afraid it might open up services to a double-spend attack if a blockchain re-org is done."
359 2014-02-14 09:46:43 <under_hood> however take in to account bitcoin is security criticall software so code review and acceptance can take long time
360 2014-02-14 09:47:12 <anddam> sorry to re-ask but who am I supposed to query bitcoind for coins received by a non-mine address?
361 2014-02-14 09:47:30 <anddam> oh, "mine" is a double-entendre in the bitcoin context
362 2014-02-14 09:47:34 <under_hood> Mallstromm: there is work done. ETA is unknown. But it is on good way. example Sipahash(tm)
363 2014-02-14 09:47:36 <Elio19> Mallstromm, did you consider take the money from their account before asking bitcoind for a txid?
364 2014-02-14 09:47:50 <anddam> should I use some third-party API like blockchain.info?
365 2014-02-14 09:48:14 <wumpus> anddam: you can't with the stock bitcoind, there is a patch floating around for building a by-address index
366 2014-02-14 09:48:58 <Mallstromm> Elio19: I did not understand what you mean, sorry
367 2014-02-14 09:49:25 <Elio19> Mallstromm, it's okay.
368 2014-02-14 09:52:21 <Logicwax> yeah the guy who devs coinpunk refers to that patch
369 2014-02-14 09:52:26 <Logicwax> the bitcoind watchonly patch
370 2014-02-14 09:53:17 <Logicwax> https://github.com/bitcoin/bitcoin/pull/2861
371 2014-02-14 09:53:28 <Logicwax> ^^ thats the watchonly patch
372 2014-02-14 09:54:51 <Elio19> For example: when the users click the withdraw button, shrink their balance then relay the transaction to bitcoind. Not confirm a txid is potential workaround, right?
373 2014-02-14 10:03:22 <anddam> wumpus: is there a third party tool better suited? like an external program rather than patching my running bitcoind?
374 2014-02-14 10:04:02 <anddam> wumpus: I'm sorry but I don't know how blockchain is stored, I thought that since it has info about all txs it could be queried
375 2014-02-14 10:04:47 <wumpus> anddam: all the info is stored in the blockchain that you downloaded, the only thing missing is an index for efficient loopups
376 2014-02-14 10:04:52 <maaku> anddam: that information would have to be indexed to be efficiently queried
377 2014-02-14 10:04:54 <wumpus> lookups*
378 2014-02-14 10:05:05 <wumpus> anddam: which is what the patched bitcoind's would do
379 2014-02-14 10:05:14 <wumpus> (+ add an RPC to query the index)
380 2014-02-14 10:05:32 <anddam> wumpus: ok what if I want to query inefficiently?
381 2014-02-14 10:05:43 <wumpus> anddam: see https://github.com/bitcoin/bitcoin/pull/2802
382 2014-02-14 10:05:45 <anddam> I mean is that a matter of efficiency or vanilla bitcoind cannot do it at all?
383 2014-02-14 10:05:48 <anddam> thanks
384 2014-02-14 10:05:56 <wumpus> anddam: you can query all blocks one-by-one and look for transactions
385 2014-02-14 10:06:28 <anddam> that's like the ~300k blocks
386 2014-02-14 10:07:06 <anddam> so I should iteratively go through each block, get each transaction and check output of each of those, right?
387 2014-02-14 10:07:12 <wumpus> anddam: iterate over all existing blocks with getblockhash, then you can query the blocks with getblock
388 2014-02-14 10:07:16 <anddam> the output of a transaction is an address, right?
389 2014-02-14 10:07:37 <wumpus> yes, that is what the indexing process does, but if you want to do a linear query you need to go through everything for every query
390 2014-02-14 10:07:51 <anddam> I see the complexity there
391 2014-02-14 10:08:02 <maaku> anddam: vanilla bitcoind doesn't expose any capability to scan the entire block chain for information
392 2014-02-14 10:08:16 <anddam> how's the blockchain stored? isn't there a RDBMS?
393 2014-02-14 10:08:27 <maaku> (think about how long it would take to scan 17GB of data for each and every query)
394 2014-02-14 10:08:31 <maaku> no
395 2014-02-14 10:08:37 <maaku> it's a series of flat files
396 2014-02-14 10:08:43 <maaku> definately not a rdbms
397 2014-02-14 10:08:52 <wumpus> maaku: yes it does, you can query all the data using getblockhash/getblock
398 2014-02-14 10:08:54 <anddam> I guess the adoption of a rdbms has been discussed
399 2014-02-14 10:09:10 <maaku> wumpus: those use the indices...
400 2014-02-14 10:09:24 <maaku> you can't query by e.g. address which is what he's asking about
401 2014-02-14 10:09:30 <maaku> (unless you apply the addressindex patch)
402 2014-02-14 10:09:40 <anddam> maaku: btw I didn't realize you were talking as well because the color scheme in this term has highlight almost the same as regular text
403 2014-02-14 10:09:46 <wumpus> maaku: sure, you'd have to iterate over all blocks with those calls and find the matching transactions yourself
404 2014-02-14 10:09:55 <wumpus> maaku: it's super-super-slow but possible, that was the point
405 2014-02-14 10:11:09 <anddam> and isn't there a dedicated querying tool, I have to patch bitcoin
406 2014-02-14 10:11:28 <anddam> what happens if I try to start two bitcoind instances?
407 2014-02-14 10:11:38 <maaku> anddam: why would you want to?
408 2014-02-14 10:11:43 <anddam> can it corrupt my chain/wallet/chair?
409 2014-02-14 10:11:47 <maaku> don't do it in the same data directory
410 2014-02-14 10:11:49 <anddam> maaku: by mistake, for instance
411 2014-02-14 10:12:01 <maaku> the 2nd one will recognize what is going on and shut down
412 2014-02-14 10:12:04 <anddam> I have the Qt program running and I run bitcoind
413 2014-02-14 10:12:28 <wumpus> anddam: you can't, the datadir is protected against simultaneous instances
414 2014-02-14 10:12:40 <wumpus> you can of course run multiple instances with different data dirs
415 2014-02-14 10:13:06 <Xman> is there anynews about the bug
416 2014-02-14 10:13:16 <maaku> and to a limited extent you can share blockchain files that have already been fully downloaded
417 2014-02-14 10:13:27 <maaku> Xman: what bug
418 2014-02-14 10:21:00 <anddam> wumpus: that is now https://github.com/bitcoin/bitcoin/pull/3652
419 2014-02-14 10:23:57 <wumpus> maaku: yes, you can swap out the blockchain data when the processes are not running
420 2014-02-14 10:26:48 <anddam> what is bitcoin-cli?
421 2014-02-14 10:27:03 <anddam> or better, how does it differ from bitcoind?
422 2014-02-14 10:27:13 <anddam> I built using makefile.osx and got only bitcoin-qt and bitcoind
423 2014-02-14 10:27:47 <anddam> but I see how a client would be more likely be called bitcoin or bitcoin-cli rather than bitcoind
424 2014-02-14 10:28:44 <wumpus> anddam: bitcoin-cli is the RPC client for bitcoind/-qt
425 2014-02-14 10:29:06 <anddam> wumpus: is it a different target?
426 2014-02-14 10:29:09 <wumpus> anddam: it is in the process of being split off from bitcoind, but for 0.9.x you can still use bitcoind as a RPC client too (after that, it will only be a server)
427 2014-02-14 10:29:10 <anddam> I'd like to build it as well
428 2014-02-14 10:29:30 <anddam> oh nice, because that's what I expected from the "bitcoind" name
429 2014-02-14 10:29:37 <anddam> I'm on 0.8.6
430 2014-02-14 10:29:50 <wumpus> only 0.9 has bitcoin-cli; on 0.8.6 you still need to use bitcoind
431 2014-02-14 10:30:11 <wumpus> (or you can copy a bitcoin-cli from a 0.9 build and use it for 0.8.6, that would work but is overkill)
432 2014-02-14 10:30:31 <anddam> wumpus: thanks, I just had to understand that
433 2014-02-14 10:30:55 <wumpus> if you want forward compatibility you could symlink bitcoind to bitcoin-cli already
434 2014-02-14 10:31:01 <Logicwax> [02:08] <maaku> (think about how long it would take to scan 17GB of data for each and every query)
435 2014-02-14 10:31:08 <Logicwax> then how are TXs verified so quickly?
436 2014-02-14 10:31:11 <wumpus> or make an alias, or...
437 2014-02-14 10:31:37 <Logicwax> how does each TX get checked against its inputs that are prev outputs so quickly without iterating and finding which blocks those prev ones are in
438 2014-02-14 10:31:51 <wumpus> Logicwax: because that uses a different kind of indexing
439 2014-02-14 10:32:03 <shaileshg> test
440 2014-02-14 10:32:15 <wumpus> Logicwax: verifying txes is done by keeping the current UTXO, it has nothing to do with an index by address
441 2014-02-14 10:32:20 <anddam> point is I'm using 0.8.6 that is several months old, I guess I should go with pull request 2802 rather than the updated 3652
442 2014-02-14 10:33:12 <Logicwax> wumpus: so you mean, whenever a TX is checked....no one actually goes back (however far) to the previous TX to check?
443 2014-02-14 10:33:26 <Logicwax> all the info in the input is included?
444 2014-02-14 10:34:49 <shaileshg> I know OP_RETURN can be used to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc
445 2014-02-14 10:34:52 <jouke> There is no difference in the way .9 and .8 use the wallet, so I should be able to load our .9 wallet in .8 client right?
446 2014-02-14 10:35:06 <shaileshg> However, a note on wikipedia says that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.
447 2014-02-14 10:35:19 <wumpus> jouke: yes, certainly
448 2014-02-14 10:35:29 <shaileshg> can anyone suggest how can i add data to a transaction with it being accepted in blockchain
449 2014-02-14 10:36:10 <wumpus> wallets are backward and forward compatible across bitcoin versions (given that the same berkelydb version is used for building both versions)
450 2014-02-14 10:36:53 <wumpus> (also given that you don't do -upgradewallet, which can break older versions with that wallet, but between 0.8 and 0.9 there have been no incompatible wallet changes)
451 2014-02-14 10:37:18 <lnovy> shaileshg: like this? http://www.thenoteblock.com/notes/89
452 2014-02-14 10:37:33 <Logicwax> wumpus: so when checking a TX, the software never finds the prevouts back in the blockchain from long ago?
453 2014-02-14 10:37:40 <wumpus> Logicwax: part of the verification is to go back to the the previous tx'es, but those are handily kept around in the utxo index
454 2014-02-14 10:38:04 <Logicwax> oh i thought the utxo index was optional
455 2014-02-14 10:38:25 <wumpus> Logicwax: the utxo is a dynamic set of outputs that haven't been spent yet
456 2014-02-14 10:39:05 <Logicwax> is that index just an index of pointers to the TXs themselves in the blockchain binary files? or is it the TXs themselves?
457 2014-02-14 10:39:45 <shaileshg> lnovy: yes.. but i can't see where the note is in txn https://helloblock.io/mainnet/transactions/9e24e1de1489f88e4b405417aa04e79915cf9467621cba35e6887539df31b0d2
458 2014-02-14 10:40:17 <wumpus> Logicwax: afaik the UTXO set contains the actual transactions not pointers, but I'm not 100% sure there, use the source if you want to be sure
459 2014-02-14 10:40:52 <wumpus> Logicwax: it's coins.cpp/h
460 2014-02-14 10:41:28 <Logicwax> thanks wumpus
461 2014-02-14 10:41:45 <Logicwax> that UTXO db must be huge.....for it *is* the actual bitcoins in existence
462 2014-02-14 10:42:24 <shaileshg> lnovy: ?
463 2014-02-14 10:42:53 <lnovy> shaileshg: the message is encoded in adresses
464 2014-02-14 10:43:15 <wumpus> Logicwax: it's not that large, remember that it only contains the data about unspent txes, spent ones are thrown out
465 2014-02-14 10:43:30 <wumpus> fully spent*
466 2014-02-14 10:43:49 <lnovy> shaileshg: click on the address, take hash160 and display it in ascii
467 2014-02-14 10:43:56 <Logicwax> yeah...but all unspent TXs are really any and all coins that are in existence
468 2014-02-14 10:44:14 <lnovy> shaileshg: output adresses of course
469 2014-02-14 10:44:16 <Logicwax> (as coins dont exist, only a path of TXs from coinbase to UXTO is)
470 2014-02-14 10:44:24 <shaileshg> hmm
471 2014-02-14 10:44:30 <shaileshg> lnovy: let me check
472 2014-02-14 10:45:00 <wumpus> Logicwax: ~/.bitcoin/chainstate is only 370MB here
473 2014-02-14 10:45:32 <Logicwax> lnovy: sounds like a way to destroy some BTC ;P
474 2014-02-14 10:45:50 <lnovy> yep, it's not very creative :)
475 2014-02-14 10:45:54 <Logicwax> oh wow. 370MB? that must be pointers than........riiiiight?
476 2014-02-14 10:46:10 <Logicwax> heh
477 2014-02-14 10:46:43 <Logicwax> so if TXs are *only* verified via the UTXO db and not by going back before those TXs and before those and so on..........then why keep the blockchain around then?
478 2014-02-14 10:47:03 <wumpus> Logicwax: to spread the love
479 2014-02-14 10:47:19 <Logicwax> just prune blocks older than 100 blocks ago off
480 2014-02-14 10:47:29 <lnovy> to check other other peoples coins
481 2014-02-14 10:47:38 <wumpus> when you want to *build* the UTXO set, you need the whole blockchain
482 2014-02-14 10:47:43 <Logicwax> why keep all those blocks? (and here i thought the whole time, that TXs were checked by tracing them all the way back to their coinbase)
483 2014-02-14 10:47:47 <wumpus> so you might as well keep it around to spread it to others that need it
484 2014-02-14 10:47:51 <wumpus> that's P2P :)
485 2014-02-14 10:48:34 <Logicwax> yeah...but why does everyone need it? i mean we can all agree on a UTXO set on a certain day at a certain time and the hash of it, and go home happy right?
486 2014-02-14 10:48:56 <wumpus> because you sometimes need to roll back (for example, in the case of reorganizations)
487 2014-02-14 10:48:59 <lnovy> utxo keeps all the existing coins? holy fsm now I get why the d***coin's wallet is so big...
488 2014-02-14 10:49:09 <Logicwax> yeah....thats why i said like 100 blocks
489 2014-02-14 10:49:23 <wumpus> Logicwax: but yes you could code a client that do that
490 2014-02-14 10:49:31 <wumpus> Logicwax: it's be just another security tradeoff
491 2014-02-14 10:49:52 <wumpus> lnovy: hehe
492 2014-02-14 10:50:13 <Logicwax> im still impressed that 370MB holds all of the bitcoins that exist
493 2014-02-14 10:50:44 <lnovy> alt the coins, not bitcoins :)
494 2014-02-14 10:50:52 <lnovy> if you get me
495 2014-02-14 10:51:02 <Logicwax> you mean divisions, yeah
496 2014-02-14 10:52:16 <Logicwax> any of you know a thing or two about stealth addresses? I've been asking around for a bit, about why its better to use a separate nonce then the pubkey from the payor
497 2014-02-14 10:52:57 <Logicwax> after looking at: http://imgur.com/rHhNKL6
498 2014-02-14 10:53:11 <Logicwax> it looks like using the pubkey from the TX would be fine, and wouldnt decrease security
499 2014-02-14 10:55:51 <Logicwax> as a payee....id just take every TX on the network, grind my privkey against the payor's pubkey, now that becomes shared secret. now add that to my pubkey addr, and check if thats the address the BTC was sent to
500 2014-02-14 10:57:11 <shaileshg> lnovy: is there any better way or provision in bitcoin protocol to include some kind of short msg without wasting some bitcoins
501 2014-02-14 10:58:01 <shaileshg> lnovy: it also works using OP_RETURN
502 2014-02-14 10:58:22 <shaileshg> does it means if i have OP_RETURN in txn, it will get accepted in mainnet
503 2014-02-14 10:58:23 <shaileshg> ?
504 2014-02-14 10:58:40 <lnovy> shaileshg: yes, upcomming OP_RETURN and you can also put same garbage in coinbase transaction
505 2014-02-14 10:59:18 <lnovy> it wouldn't get relayed, but it should be valid even now
506 2014-02-14 10:59:20 <shaileshg> lnovy: coinbase txn is the first txn in block.. you mean to say only in coinbase txn or any txn?
507 2014-02-14 10:59:55 <shaileshg> lnovy: what does it mean not getting relayed?
508 2014-02-14 11:00:43 <lnovy> shaileshg: there is mandatory number of 1 inputs, which is ignored in coinbase transaction