1 2014-02-12 00:03:22 <BB-Martino> Total confirmed: 172.99321013 (24)
2 2014-02-12 00:03:36 <BB-Martino> [23:48] <michagogo|cloud> Your balance is 156.18406013
3 2014-02-12 00:03:41 <BB-Martino> take that.
4 2014-02-12 00:03:43 <BB-Martino> :P
5 2014-02-12 00:04:35 <BB-Martino> the listaccounts feature is completely out of sync with getbalance, which is out of sync with the total number of spendable coins as well
6 2014-02-12 00:04:50 <BB-Martino> time for rescan? :)
7 2014-02-12 00:05:46 <jgarzik> BB-Martino, make sure all queries are asking for the same number of confirmations
8 2014-02-12 00:05:53 <jgarzik> otherwise balances will differ naturally
9 2014-02-12 00:06:17 <BB-Martino> jgarzik: I did listunspent and listunspent 1 as well
10 2014-02-12 00:06:20 <BB-Martino> same output
11 2014-02-12 00:06:24 <BB-Martino> all coins are confirmed
12 2014-02-12 00:06:26 <BB-Martino> with at least 1
13 2014-02-12 00:07:16 <jgarzik> BB-Martino, listaccounts can definitely get out of sync :/ Sometimes I use an adjustment account to fix balances manually :(
14 2014-02-12 00:07:18 <BB-Martino> same with >3
15 2014-02-12 00:07:35 <BB-Martino> that's the fun part
16 2014-02-12 00:07:37 <BB-Martino> if i re-adjusted it
17 2014-02-12 00:07:42 <BB-Martino> and moved the negative over to the main account
18 2014-02-12 00:07:46 <BB-Martino> THEN it would be out of sync
19 2014-02-12 00:07:59 <BB-Martino> because the getbalance bitbargain command gives back the right value
20 2014-02-12 00:08:11 <BB-Martino> if i -20'd it, my accounting would show missing coins
21 2014-02-12 00:08:20 <BB-Martino> but listunspent confirmed it that i do actually have that much coin, AND confirmed
22 2014-02-12 00:09:04 <BB-Martino> (which i'm really happy for btw)
23 2014-02-12 00:09:40 <BB-Martino> i'd be even happier if that ridiculous 350+ BTC getbalance result was real
24 2014-02-12 00:14:06 <BB-Martino> jgarzik: Seriously, i wrote a php script in 2 minutes to add up the numbers from the json output, confirmed coins only, it gives the right balance as expected. But with bitcoind, there's currently no way of getting even close to that number by doing getbalance, except I do getbalance on the bitbargain account directly and ignore the negative 20 in the "" account
25 2014-02-12 00:14:34 <BB-Martino> (talking about listunspent)
26 2014-02-12 00:15:00 <BB-Martino> hi pieh0
27 2014-02-12 00:15:14 <BB-Martino> oh.
28 2014-02-12 00:15:32 <BB-Martino> mistook a part for a join (also, sorry for making it look like i'm spamming, apparently everyone's asleep)
29 2014-02-12 00:16:38 <jgarzik> BB-Martino, yah, fundamentally, the account system is a bolt-on, optional, top layer. listunspent and friends peek under the covers of that layer.
30 2014-02-12 00:18:01 <BB-Martino> is 'getbalance' included in that?
31 2014-02-12 00:18:07 <BB-Martino> a bolt-on, optional top layer?
32 2014-02-12 00:18:27 <lechuga_> it's #ifdef'd
33 2014-02-12 00:20:22 <maaku> can someone send me some testnet coins plz? moECsK8Xo5DZaGDiJM6pweMzzP8cYNpKy3
34 2014-02-12 00:22:30 <Imbue> maaku: sent
35 2014-02-12 00:28:54 <maaku> thanks!
36 2014-02-12 00:40:53 <Luke-Jr> why does 0.8.6 contain so many commits not in master? O.o
37 2014-02-12 00:44:45 <gmaxwell> Luke-Jr: backports that weren't clean?
38 2014-02-12 00:49:56 <Luke-Jr> gmaxwell: I can't find a number of them in master at all :/
39 2014-02-12 00:49:58 <Luke-Jr> eg * c4892eb Log reason for non-standard transaction rejection
40 2014-02-12 00:50:11 <Luke-Jr> hrm
41 2014-02-12 00:50:21 <Luke-Jr> master's full log has it.. /me pokes git
42 2014-02-12 00:50:21 <SeksiCKret> anyone getting 1 satoshi donations from randoms sending 100's of 1 satoshis in one tx to individual outputs for those 1 sats?
43 2014-02-12 00:50:48 <Luke-Jr> aha, I see why. I bet I consider that a feature
44 2014-02-12 00:50:52 <gmaxwell> SeksiCKret: it appears to be a dos attack.
45 2014-02-12 00:51:23 <SeksiCKret> if it was sent to my paper wallet do i have security to fear at all?
46 2014-02-12 00:51:27 <SeksiCKret> i read about the botnet thingy
47 2014-02-12 00:51:44 <Luke-Jr> there is no botnet thing
48 2014-02-12 00:51:48 <SeksiCKret> i believe i generated them in a secure fashion, offline, restart before going on line, not online prior to gen etc.
49 2014-02-12 00:52:17 <Luke-Jr> SeksiCKret: what generated the entropy?
50 2014-02-12 00:52:17 <SeksiCKret> well the "attack" i glanced at the FUD and thought it wouldnt affect much if I wasnt moving $ in or out of exchange, wallets, or 2part wallets
51 2014-02-12 00:52:26 <SeksiCKret> mouse movements
52 2014-02-12 00:52:41 <Luke-Jr> SeksiCKret: the DoS spam thing isn't a risk, but I wouldn't bet on weak entropy
53 2014-02-12 00:53:08 <Luke-Jr> I don't consider mouse movements strong personally, but it seems popular among some things I'd expect to be secure so *shrug*
54 2014-02-12 00:53:13 <SeksiCKret> okay
55 2014-02-12 00:53:26 <SeksiCKret> after botnet clears ill do a real hardwallet with researched entropy techniques
56 2014-02-12 00:53:39 <Luke-Jr> SeksiCKret: right now, Armory is the most proven way
57 2014-02-12 00:53:42 <SeksiCKret> so my security isnt to risk with this ddos more than the generalized risk of a 2part wallet being hacked?
58 2014-02-12 00:53:44 <SeksiCKret> check
59 2014-02-12 00:53:52 <SeksiCKret> i was also having another q relating to a project im doing
60 2014-02-12 00:54:01 <SeksiCKret> using cas bitcoin utility to make privkey codes
61 2014-02-12 00:54:09 <SeksiCKret> is that a secure methodology on a fresh install/boot/run
62 2014-02-12 00:54:17 <Luke-Jr> SeksiCKret: if you send to your offline address more than once, and also spend from it, *that* may introduce a risk
63 2014-02-12 00:54:21 <lnovy> also some techniques of feeding the mouse input into the seed of prng i have seen were... interesting at least :)
64 2014-02-12 00:54:21 <SeksiCKret> i need like 7mm across privkey qrs
65 2014-02-12 00:54:32 <SeksiCKret> its a paper wallet that never gets spent only my deposits to savings go there
66 2014-02-12 00:54:33 <Luke-Jr> SeksiCKret: I suggest a never-online netbook with Armory
67 2014-02-12 00:54:44 <SeksiCKret> does it generate minipriv key pub key combos?
68 2014-02-12 00:54:59 <SeksiCKret> QR code size/readability is a factor for me.
69 2014-02-12 00:55:03 <SeksiCKret> Thanks for the help btw
70 2014-02-12 00:55:06 <SeksiCKret> :)
71 2014-02-12 00:55:18 <SeksiCKret> ive read about armory generator but havent explored it yet.
72 2014-02-12 00:55:34 <Luke-Jr> SeksiCKret: "minipriv key" is not something I'd consider secure.
73 2014-02-12 00:55:39 <Luke-Jr> SeksiCKret: Armory generates real paper wallets
74 2014-02-12 00:56:22 <SeksiCKret> oh
75 2014-02-12 00:56:34 <SeksiCKret> casascius uses minipriv key stuff and is considered secure no?
76 2014-02-12 00:56:55 <Luke-Jr> no comment :p
77 2014-02-12 00:57:01 <lnovy> :))
78 2014-02-12 00:57:32 <SeksiCKret> [:
79 2014-02-12 00:57:33 <SeksiCKret> ty
80 2014-02-12 00:57:53 <SeksiCKret> i havent sent them to proof pending this issue so ill keep testing to create security for my friends :D
81 2014-02-12 01:15:05 <SeksiCKret> qr code research is neat
82 2014-02-12 02:34:51 <uiop> maaku: (re: BSD reed solomon) https://github.com/dlbeer/quirc is a BSD qrcode decoding lib, and src code looks well-done
83 2014-02-12 02:35:13 <uiop> maaku: (if not the context your searching in, possibly adaptable)
84 2014-02-12 02:36:04 <uiop> see lib/decode.c
85 2014-02-12 02:37:56 <uiop> (also, there's libqrencode, which is BSD and presumably must have the matching encoding functions http://fukuchi.org/works/qrencode/ )
86 2014-02-12 02:46:05 <BB-Martino> I know it's late, but would anyone with a decent amount of transactions, and using accounts care to compare their getbalance "*" 3 output with the output of my script when fed the result of listunspent 3 ?
87 2014-02-12 02:46:15 <BB-Martino> https://bitbargain.co.uk/unspentcount.txt
88 2014-02-12 02:46:33 <BB-Martino> (and of course let me know if there's a difference)
89 2014-02-12 03:15:13 <P4Titan> Hello
90 2014-02-12 03:15:28 <SuSEno> World
91 2014-02-12 03:19:13 <P4Titan> Within the blockchain, can the sending address of a transaction be found?
92 2014-02-12 03:20:44 <lechuga_> if you mean the first broadcaster of the txn
93 2014-02-12 03:20:44 <lechuga_> no
94 2014-02-12 03:20:57 <andytoshi> P4Titan: there is no 'sending address'. sometimes there is an address which the coin used to be associated to, but that's not useful for anything
95 2014-02-12 03:21:01 <lechuga_> (their IP address)
96 2014-02-12 03:21:22 <andytoshi> as in, there is no reason to expect it is associated to the sender
97 2014-02-12 03:21:35 <andytoshi> this is in the /topic, actually
98 2014-02-12 03:21:37 <P4Titan> So when I send coins, my seding address is not recorded anywhere
99 2014-02-12 03:22:22 <andytoshi> P4Titan: um, if you are asking because you want to hide from the NSA, no, the address that your coins are associated to is indeed public
100 2014-02-12 03:23:04 <lechuga_> you can know the address associated with the key that signed a txin used for the payment
101 2014-02-12 03:23:07 <andytoshi> P4Titan: so data analyzers can get it because there's a good chance it's an actual "sending address". people who want return addresses or something can't use it for that though because "a good chance" is not good enough
102 2014-02-12 03:23:14 <Luke-Jr> P4Titan: there isn't a sending address
103 2014-02-12 03:23:36 <Luke-Jr> P4Titan: coins aren't held by addresses, they're *sent to* them.
104 2014-02-12 03:24:08 <andytoshi> what Luke-Jr said. that's how you want to think about this.
105 2014-02-12 03:25:12 <P4Titan> Yes, I am aware, but I am trying to implement something for my own project, and it requires a transaction to be verified if it came from a specific address. I need something unique that the sender can show that proves the coins came from them. I guess I could use the signature somehow.
106 2014-02-12 03:27:07 <andytoshi> ok, there is no sending address so you are barking up the wrong tree there. if you want to authenticate people use a normal way of authenticating people
107 2014-02-12 03:27:10 <c--O-O> <@MagicalTux> [12:03:59] <Concurrent581072> MagicalTux, are you waiting on the btc devs to make a fix regarding malleability, or is mtgox working on something on their end(like other exchanges) to keep it from being exploited? <- we are working with the bitcoin devs to work out a standard way to solve this, then will implement it
108 2014-02-12 03:27:15 <c--O-O> is this true?
109 2014-02-12 03:27:48 <Luke-Jr> P4Titan: it's impossible to verify a transaction "came from a specific address", because they DON'T come from addresses
110 2014-02-12 03:28:14 <P4Titan> In what sense?
111 2014-02-12 03:28:22 <Luke-Jr> you can verify a person has the ability to RECEIVE WITH an address, but there is no sending identifier to verify
112 2014-02-12 03:28:34 <Luke-Jr> P4Titan: addresses are only used to receive, not to send
113 2014-02-12 03:28:53 <P4Titan> Ok, but is there not a signing aspect that is unique
114 2014-02-12 03:29:00 <Luke-Jr> c--O-O: more like an excuse really
115 2014-02-12 03:29:04 <Luke-Jr> c--O-O: off-topic here tho
116 2014-02-12 03:29:12 <c--O-O> LUKE
117 2014-02-12 03:29:20 <Luke-Jr> P4Titan: there is no sending identifier at all, only receiving. you can have a receiver sign.
118 2014-02-12 03:29:23 <c--O-O> I asked in #BITCOIN THEY SENT ME HERE
119 2014-02-12 03:29:29 <lechuga_> lol
120 2014-02-12 03:30:21 <lechuga_> all of the dice sites work by inferring sender based on the signer of the inputs
121 2014-02-12 03:30:46 <lechuga_> and assuming if you pay to the first address in the txins it gets back to the spender
122 2014-02-12 03:31:00 <lechuga_> but that is really bad
123 2014-02-12 03:32:03 <Luke-Jr> lechuga_: there is no address in txins. you're just confusing him more >_<
124 2014-02-12 03:32:15 <lechuga_> well the address associated with the key that signed the txin
125 2014-02-12 03:33:07 <lechuga_> which you can infer from its previous txout but i should stop because im making this worse for him
126 2014-02-12 03:34:37 <Luke-Jr> yeah, it's like Joe's sister's half-brother's first roommate :D
127 2014-02-12 03:34:44 <lechuga_> lol exactly
128 2014-02-12 03:35:51 <andytoshi> everyone in my family marries their sister's half-brother's first roommate, so my software will treat that as 'wife', thx for the help guies
129 2014-02-12 03:36:06 <Luke-Jr> lol
130 2014-02-12 03:36:11 <lechuga_> lool
131 2014-02-12 03:36:20 <P4Titan> loool
132 2014-02-12 03:36:28 <Luke-Jr> andytoshi: excellent explanation there :D
133 2014-02-12 04:10:21 <jMyles> I have the following question: http://www.reddit.com/r/Bitcoin/comments/1xofsj/eli31_and_understand_p2p_networking_and_crypto/
134 2014-02-12 04:16:29 <berndj> jMyles, is this in relation to gox? if so, i'd say it just shifts the problem. now the malleability issue moves from "waiting for a particular txid to confirm" to the "knowing how to recognize a tx as the one you've been waiting to get confirmed"
135 2014-02-12 04:18:58 <jMyles> berndj: So there's no way to refer to an unconfirmed transaction other than by ID? (I'm sorry if this is unduly elementary for this channel, feel free to RTFM me).
136 2014-02-12 04:18:58 <lechuga_> i may or may not have answered you
137 2014-02-12 04:18:58 <lechuga_> via reddit
138 2014-02-12 04:32:49 <phantomcircuit> gavinandresen, so what's going on with bitstamp?
139 2014-02-12 04:33:52 <Ontolog> i have 0.8.6-beta installed on os x and the database became corrupted; now i can't even start the app. any way for me to trigger a redownload of the entire database?
140 2014-02-12 04:34:00 <Ontolog> like a directory i can remove?
141 2014-02-12 04:34:33 <phantomcircuit> Ontolog, it did?
142 2014-02-12 04:34:34 <phantomcircuit> shit
143 2014-02-12 04:34:41 <phantomcircuit> that was supposed to have been fixed in 0.8.6
144 2014-02-12 04:34:49 <Ontolog> yeah i had 0.8.5
145 2014-02-12 04:34:50 <phantomcircuit> Ontolog, what's the exact error?
146 2014-02-12 04:34:54 <phantomcircuit> oh
147 2014-02-12 04:34:57 <Ontolog> and then because of the error
148 2014-02-12 04:35:00 <Ontolog> i tried using 0.8.6
149 2014-02-12 04:35:05 <phantomcircuit> Ontolog, running bitcoin-qt or bitcoind
150 2014-02-12 04:35:10 <Ontolog> qt
151 2014-02-12 04:35:13 <Ontolog> via the gui launcher
152 2014-02-12 04:35:29 <phantomcircuit> it should ask you if you want to reindex
153 2014-02-12 04:35:32 <phantomcircuit> did it not ?
154 2014-02-12 04:35:51 <Ontolog> Assertion failed: (pfork != NULL), function SetBestChain, file src/main.cpp, line 1769.
155 2014-02-12 04:36:01 <Ontolog> it was starting the reindex but then crashes
156 2014-02-12 04:36:08 <Ontolog> in fact with 0.8.5 it was reindexing
157 2014-02-12 04:36:12 <Ontolog> but it would never complete
158 2014-02-12 04:36:15 <Ontolog> it was just stay stuck
159 2014-02-12 04:36:18 <Ontolog> for days on end
160 2014-02-12 04:36:30 <Ontolog> so now i just want to download again so i guess i just delete the blocks directory?
161 2014-02-12 04:37:28 <Luke-Jr> have you considered bad hardware?
162 2014-02-12 04:39:30 <freewil> what happens if you start to run out of disk space
163 2014-02-12 04:44:17 <maaku> uiop: thanks, that looks adaptable
164 2014-02-12 04:53:03 <gfawkes_> le sigh.. looks like im gonna have to write a something to get rid of these annoying sochi spam coins =\
165 2014-02-12 04:53:48 <gfawkes_> bundle 'em into a transaction and send them to a blackhole address i guess
166 2014-02-12 04:54:10 <gmaxwell> gfawkes_: no you won't!
167 2014-02-12 04:54:22 <gmaxwell> gfawkes_: https://github.com/petertodd/dust-b-gone
168 2014-02-12 04:54:34 <Cusipzzz> +1 dust-b-gone
169 2014-02-12 04:55:00 <gmaxwell> gfawkes_: sending to a blackhole address is bad for the network too, since it creates more utxo that must persist forever.
170 2014-02-12 05:00:49 <torokun> mmm. a lot of these things could be fixed, couldn't they? If you had to prime an address by publishing something signed before using it, you could help avoid black hole addresses maybe.
171 2014-02-12 05:03:12 <gmaxwell> torokun: no, not really.
172 2014-02-12 05:03:26 <gmaxwell> torokun: a destroyed private key is no less a blackholed address.
173 2014-02-12 05:03:54 <torokun> true, but at least you'd know someone had the private key before using the address.
174 2014-02-12 05:04:04 <torokun> can't do anything about their throwing it away...
175 2014-02-12 05:04:44 <gmaxwell> no, you wouldn't even then. It's possible to back-construct a public key from a provably random signature and a message. but then no one has the private key so no _other_ message could ever be signed with it.
176 2014-02-12 05:05:04 <phantomcircuit> lol
177 2014-02-12 05:05:23 <gmaxwell> torokun: its not like a blackhole address thing is something that happens by chance, people intentionally do it. there existing just one intentional way is enough.
178 2014-02-12 05:06:10 <gmaxwell> besides, there are protocols where where disclosing the signature in advance breaks security.
179 2014-02-12 05:06:18 <torokun> true, it's moot i guess.
180 2014-02-12 05:06:34 <gmaxwell> (e.g. ones where the signature is coerced to reveal a secret someone else wants)
181 2014-02-12 05:08:19 <torokun> gm: do you think there will be some sort of fix that gets exchange wallets functioning correctly again relatively soon?
182 2014-02-12 05:09:07 <gmaxwell> torokun: ask the exchanges.
183 2014-02-12 05:10:05 <exfor> I'm this room was interesting today.
184 2014-02-12 05:10:11 <exfor> sure*
185 2014-02-12 05:10:26 <torokun> it looked like the reference client might be undergoing updates to deal with it.
186 2014-02-12 05:10:41 <BB-Martino> reserve keys are keys to use for change addresses and newly generated addresses with getnewaddress, correect?
187 2014-02-12 05:11:26 <BB-Martino> dumped my walllet, wondering why such a large number of them
188 2014-02-12 05:14:10 <BB-Martino> whatever they are, my question is: aren't they reserved for later use? do they become unreserved at some point? and if so, should there not be just 100 of them or so?
189 2014-02-12 05:21:02 <lechuga_> hmm
190 2014-02-12 05:21:31 <lechuga_> its not obvious to me how exchanges which levergae headless client with their own external wallet impl
191 2014-02-12 05:21:52 <lechuga_> are going to safely use inputs/outputs to identify transactions
192 2014-02-12 05:22:05 <lechuga_> actually nm
193 2014-02-12 05:22:35 <lechuga_> was hng up on sendtoaddress returning the txid and then you need to query for the raw txn to get the inputs/outputs
194 2014-02-12 05:22:39 <lechuga_> hung*
195 2014-02-12 05:22:57 <lechuga_> and a race with the txn hitting the blockchain before you get the raw txn
196 2014-02-12 05:23:25 <lechuga_> but if you do it right it seems fine
197 2014-02-12 05:29:59 <flotsamuel> I've been out. Any luck figuring out the balance issue, BB-Martino?
198 2014-02-12 05:40:59 <jMyles> In my barely-educated-on-the-matter mind, I'm increasingly in favor of wontfix on most of the "malleable" properties of transactions.
199 2014-02-12 05:41:29 <jMyles> It seems to me that inputs and outputs are the proper way to identify unconfirmed transactions.
200 2014-02-12 05:43:43 <BB-Martino> flotsamuel: yes and no. listunspent more or less matches with the expected balance of users, but listaccounts and getbalance report the craziest things. So now i've written a script to create a csv from the pywallet dump with the requested account names, and i'm importing the .csv into a newly created fresh wallet
201 2014-02-12 05:45:00 <flotsamuel> BB-Martino: bummer. good luck man. Were you using the account system at all beyond getbalance?
202 2014-02-12 05:48:14 <BB-Martino> yeah, but now i'm importting everything into ""
203 2014-02-12 05:48:17 <BB-Martino> and that's what i'll use
204 2014-02-12 05:48:24 <flotsamuel> And did you do a -salvagewallet to get to this current state?
205 2014-02-12 05:48:45 <BB-Martino> no, see above (rm wallet.dat, import with filtered labels)
206 2014-02-12 05:48:54 <flotsamuel> gotchya
207 2014-02-12 05:48:56 <BB-Martino> it won't finish any time soon tho
208 2014-02-12 05:55:15 <helo> jMyles: you are right!
209 2014-02-12 05:56:00 <justanotheruser1> Does any bitcoin dev want a free domain name?
210 2014-02-12 05:56:17 <helo> what domain? (not a dev, just curious)
211 2014-02-12 05:56:51 <justanotheruser1> helo: *.(com||info||net||org)
212 2014-02-12 05:57:11 <justanotheruser1> I really need to brush up on regex
213 2014-02-12 05:57:24 <amiller> google.com is an element of *.(com||info||net||org)
214 2014-02-12 05:57:31 <amiller> can you get that one, it would be useful
215 2014-02-12 05:57:32 <helo> yeah, i think they'd like google.com
216 2014-02-12 05:57:50 <jMyles> justanotheruser1: Don't we all. A friend of mine and I made a new year's resolution to be seriously good at regexs and grep arguments by the end of the year
217 2014-02-12 05:58:20 <justanotheruser1> Don't you get technical with me
218 2014-02-12 05:59:10 <justanotheruser1> I was probably just going to waste my free domain and buy coinstealingmalware.com
219 2014-02-12 06:01:31 <jcorgan> justanotheruser1: i find this very useful http://www.debuggex.com/
220 2014-02-12 06:02:23 <justanotheruser1> thanks jcorgan. Do you want a free domain?
221 2014-02-12 06:02:53 <jcorgan> if i get to pick it
222 2014-02-12 06:03:13 <jcorgan> dontbesuchadogehole.com
223 2014-02-12 06:04:51 <helo> can we get whywasibanned.com with a cname to dontbesuchadogehole.com?
224 2014-02-12 06:05:42 <helo> (taking full advantage of the devs getting sleep after a busy day to go waaaay offtopic in here...)
225 2014-02-12 06:05:57 <jcorgan> lold
226 2014-02-12 06:18:17 <jcorgan> cool, grabbed dontbesuchadogehole.com, now I need something to point it to.
227 2014-02-12 06:21:55 <justanotheruser1> jcorgan: perhaps the pastebin where dogecoiners discuss manipulating the market?
228 2014-02-12 06:22:57 <jcorgan> that could work
229 2014-02-12 06:23:31 <jcorgan> not exactly sure how to set up a redirect (never used namecheap before) but i'd be happy to let you walk me through it
230 2014-02-12 06:24:19 <justanotheruser1> jcorgan: me either :P, I just got a bunch of codes. They were giving them out at a hackathon
231 2014-02-12 06:24:51 <justanotheruser1> They actually announced that I won .5btc for our teams product, but they changed it to $250 in namecheap credits
232 2014-02-12 06:25:19 <jcorgan> i'm not arguing ith free domains
233 2014-02-12 06:25:38 <jcorgan> btw, whydidyoubanme.com is indeed free (though whywasibanned.com is not)
234 2014-02-12 06:27:17 <lechuga_> it seems like sendtoaddress should return the raw txn
235 2014-02-12 06:27:51 <super3> hmmm it would be cool to have some bitcoin rpc domains
236 2014-02-12 06:27:53 <lechuga_> seems silly to force you to call getrawtransaction to get enough details to properly identify the first call
237 2014-02-12 06:28:58 <gmaxwell> This stuff is offtopic for here, guys.
238 2014-02-12 06:29:24 <justanotheruser1> So... I was under the assumption that a transaction was propagated iff the output wasn't being used as an input in the mempool. How does tx malleability change this?
239 2014-02-12 06:32:26 <gmaxwell> justanotheruser1: it doesn't.
240 2014-02-12 06:32:50 <gmaxwell> assuming that what you said means what it does.
241 2014-02-12 06:33:12 <gmaxwell> (a tx is propagated if accepted into the mempool, which can only happen if its inputs aren't already spent there)
242 2014-02-12 06:34:05 <justanotheruser1> gmaxwell: but the dos is based on transaction malleability right? And the dos happens because doublespends can be propagated right? And doublespends being propagated isn't related to malleability right?
243 2014-02-12 06:35:13 <thrasher> is the attacker still at it?
244 2014-02-12 06:36:16 <gmaxwell> justanotheruser1: doublespends are not propagated.
245 2014-02-12 06:38:25 <flotsamuel> thrasher: answered in #bitcoin
246 2014-02-12 06:38:44 <justanotheruser1> gmaxwell: oh? Is there somewhere I can read about how this is happening then?
247 2014-02-12 06:38:48 <bitblender> Are the changes to the reference client workarounds to make the reference client work with TM or is the changes planned a "real" fix to remove the possibility of TM?
248 2014-02-12 06:39:18 <jMyles> Where is the main discussion about whether TM is a "bug" and whether it's appropriate to "fix" it?
249 2014-02-12 06:39:41 <bitblender> jMyles that was two days ago ;)
250 2014-02-12 06:39:50 <jMyles> bitblender: Where can I read it?
251 2014-02-12 06:40:07 <bitblender> history of this channel and #bitcoin
252 2014-02-12 06:40:23 <gmaxwell> bitblender: removing transaction mutability will take a very long time, and has been in progress for a very long time.
253 2014-02-12 06:41:12 <bitblender> gmaxwell ty
254 2014-02-12 06:41:43 <gmaxwell> (at the moment, its still possible that it is impossible to remove it completely too.)
255 2014-02-12 06:41:57 <justanotheruser1> gmaxwell: Do you have any idea when the DoS will stop? Why are these 1 satoshi tx being propogated?
256 2014-02-12 06:42:02 <gmaxwell> though we can remove all the forms we know of.
257 2014-02-12 06:42:07 <jMyles> gmaxwell, bitblender: I'm surprised that there's no talk over whether or not its even desirable to remove it.
258 2014-02-12 06:42:45 <warren> hm, why isn't that satoshi flood being stopped by IsDust?
259 2014-02-12 06:42:46 <gmaxwell> justanotheruser1: the 1satoshi should only be propagated only by people who have overridden the minrelayfee settings.
260 2014-02-12 06:43:06 <gmaxwell> warren: because people have overridden that because we gave them a knob.
261 2014-02-12 06:43:07 <justanotheruser1> gmaxwell: is that the entirety of the DoS?
262 2014-02-12 06:43:26 <gmaxwell> justanotheruser1: some miners are mining the 1satoshi spam too.
263 2014-02-12 06:43:29 <warren> are they being confirmed into blocks?
264 2014-02-12 06:43:33 <warren> ugh
265 2014-02-12 06:43:35 <warren> why!?!
266 2014-02-12 06:44:39 <bitblender> gmaxwell: but these changes will make it so only original txid's will make it into the blockchain, not any that has muted?
267 2014-02-12 06:44:47 <justanotheruser1> gmaxwell: So the DoS is entirely the fault of users propagating these tx?
268 2014-02-12 06:44:59 <bitblender> still they can fly around, but should never be confirmed into blocks?
269 2014-02-12 06:45:27 <gmaxwell> justanotheruser1: the 1satoshis? yea, pretty much.
270 2014-02-12 06:45:42 <gmaxwell> bitblender: what changes?
271 2014-02-12 06:46:25 <jcorgan> aegis: ouch. i do a lot of trading there, but glad i leave 0 BTC in the wallet there
272 2014-02-12 06:46:33 <gmaxwell> fixing mutability? no. We fix it by first making non-canonical forms non-standard so nodes neither relay or mine them. Then after they are completely dead on the network we can introduce a new network rule that prevents anyone from mining them.
273 2014-02-12 06:46:47 <gmaxwell> jcorgan: hm?
274 2014-02-12 06:46:52 <bitblender> gmaxwell: to the reference client to help fix the TM thing
275 2014-02-12 06:47:00 <jcorgan> wrong channel, but looks like localbitcoins.com is down
276 2014-02-12 06:47:11 <bitblender> after these fixes, will we only get real txid's in the blockchain?
277 2014-02-12 06:47:36 <gmaxwell> bitblender: yes, in perhaps one or two years.
278 2014-02-12 06:47:48 <gmaxwell> assuming that hardware wallets don't make it become infeasable to deploy.
279 2014-02-12 06:49:56 <bitblender> ok
280 2014-02-12 06:53:09 <Luke-Jr> bitblender: there's still no guarantee about immutability even then tho
281 2014-02-12 06:54:02 <gmaxwell> Luke-Jr: well perhaps a year from now we'll actually have one.
282 2014-02-12 07:16:14 <jspilman> where's the best place to go to understand the issues from txid tracking vs input address tracking? it sounds like some recent developments may need some fixes in bitcoind, or at least I think a more comprehensize guide on the "right way" people should be doing it?
283 2014-02-12 07:18:44 <gmaxwell> jspilman: I think your question is too vague. Tracking for what purpose?
284 2014-02-12 07:20:19 <jspilman> was looking at some recently press releases, and then this channel's history, and it sounds like some people are having issues with balance tracking showing dupes? so I mean tracking as in balances (unconfirmed as well as confirmed)
285 2014-02-12 07:21:12 <jspilman> ok, I can be more specific. does bitcoind show mutliple unconfirmed transactions if txid is unique but inputs and outputs are the same?
286 2014-02-12 07:25:16 <jspilman> Kind of tricky terminology, there are double spends which you might actually care about tracking, and there are 'same spend / diff txid' a subclass of double-spend but actually it's the "same" transaction.
287 2014-02-12 07:25:46 <warren> Bitcoin master is failing to build for me (and gmaxwell apparently). http://pastebin.com/i4SVuTMY
288 2014-02-12 07:26:03 <gmaxwell> meh, go fix it.
289 2014-02-12 07:26:07 <Luke-Jr> lol
290 2014-02-12 07:26:28 <jspilman> Is bitcoind oblivious to same-spend? It seems like the best defense to malleability is not to try to prevent propagation, but to be oblivious to same-spends in any case
291 2014-02-12 07:26:33 <gmaxwell> I didn't mention it because whatever it is it should be trivial to fix.
292 2014-02-12 07:27:06 <gmaxwell> jspilman: no, thats a myopic perspective because it assumes the cosmetic problem of both potentially showing up in the transaction list is the only problem.
293 2014-02-12 07:27:56 <gmaxwell> jspilman: a mutation also invalidates all child transactions, so it is potentially more disruptive than just the stuff in the list.
294 2014-02-12 07:28:34 <gmaxwell> more importantly, making the non-canonical forms not propagate is the first step towards making them invalid in the blockchain entirely.
295 2014-02-12 07:29:39 <jspilman> right, since txid is used for indexing inputs
296 2014-02-12 07:30:20 <jspilman> and child transactions can't be updated to reference the new txid without resigning
297 2014-02-12 07:31:05 <jspilman> so mutability creates a real drag on the network because you can't queue up more transactions than you have input set
298 2014-02-12 07:31:58 <wumpus> warren: do a make clean first
299 2014-02-12 07:32:02 <gmaxwell> well, you _can_ but there is some risk that the transactions will be invalidated in that case.
300 2014-02-12 07:32:17 <gmaxwell> oh see thats why I didn't go further, the problem went away for me. :P
301 2014-02-12 07:34:13 <jspilman> so to the extend that you chain unconfirmed transactions, which may not be recommended, but does allow leeway when batching transactions, an active mutator can cause problems
302 2014-02-12 07:42:03 <warren> wumpus: that fixed it, didn't want to do it because my laptop is slow
303 2014-02-12 07:50:46 <wumpus> warren: then get a faster laptop, your development time is worth more than a stupid piece of hw :)
304 2014-02-12 07:50:51 <jspilman> do miners currently prioritize or penalize long unconfirmed chains? I guess profit maximization would be to include chains if fees are decent all the way down? are there downsides to including chains in blocks?
305 2014-02-12 07:51:11 <warren> wumpus: perhaps after I get a job ... a little concerned at the moment
306 2014-02-12 07:51:49 <gjs278> I thought everyone here got rich off the $1k days
307 2014-02-12 07:54:19 <jspilman> if bitcoind receives a transaction does it detect it's a mutated same-spend and discard it? or does it let it into the mempool? if it gets into mempool, does it increase getbalance?
308 2014-02-12 07:54:31 <BlueMatt> its a double-spend, effectively
309 2014-02-12 07:54:34 <BlueMatt> so, no
310 2014-02-12 07:54:40 <BlueMatt> (as in, discarded)
311 2014-02-12 07:55:52 <wumpus> jspilman: it can affect getbalance if there are unconfirmed change outputs that get duplicated, for example if there is one version of the outgoing transaction in a block and another forever unconfirmed
312 2014-02-12 07:57:12 <jspilman> @wumpus that sounds like you are saying that the double-spend (actually a same-spend) does get into the mempool?
313 2014-02-12 07:57:29 <wumpus> jspilman: I'm talking about tha wallet; the mempool is unrelated here
314 2014-02-12 07:57:52 <jspilman> wumpus: what is getbalance looking at for unconfirmed transactions if not the mempool?
315 2014-02-12 07:57:57 <wumpus> jspilman: only one version of the transaction can be in the mempool, and it gets purged if that or another version makes it into a block
316 2014-02-12 07:58:10 <gmaxwell> getbalance only ever looks at the wallet.
317 2014-02-12 07:58:40 <jspilman> unconfirmed transactions in the wallet are distinct from transactions in mempool? I would have thought they would be a strict subset?
318 2014-02-12 07:59:24 <wumpus> also unconfirmed outgoing transactions are counted against the balance (so that the balance is updated after you spent) -- not entirely sure there what will happen
319 2014-02-12 08:00:04 <jspilman> how do both get into the wallet without them both touching mempool? is this a case where one tx is in mempool+wallet and then times out only from mempool, and then the mutated tx gets into mempool and then ends up duplicated in the wallet?
320 2014-02-12 08:00:08 <gmaxwell> say you recive a transaction for you, you add it to the wallet. Then that transaction gets doublespent and the doublespend is confirmed instead of the one in the wallet, say the double spend is also paying you. Now it shows up in a block and you add it to your wallet too.
321 2014-02-12 08:00:25 <gmaxwell> at the end the first transaction is still unconfirmed, but it is not in your mempool.
322 2014-02-12 08:00:29 <wumpus> jspilman: one comes in through the mempool the other through a block
323 2014-02-12 08:00:56 <jspilman> @gmaxwell: still unconfirmed? at the end isn't the first transaction completey dead? it should be gone from wallet and mempool
324 2014-02-12 08:01:28 <wumpus> yes it should be hidden from the wallet in the case it is invalidated by a block, but that doesn't happen currently
325 2014-02-12 08:01:35 <gmaxwell> It absolutely should not be gone from the wallet.
326 2014-02-12 08:02:02 <jspilman> if they were double or same spend? why would you want to keep the orphan in the wallet AND have it effect getbalance?
327 2014-02-12 08:02:04 <gmaxwell> Do you want to destroy the evidence that someone defrauded you with a doublespend? (in the general caseâ not even talking about mutation there)
328 2014-02-12 08:02:25 <jspilman> I can understand keeping a log of the orphan, but orphans can't increase getbalance yes?
329 2014-02-12 08:02:29 <gmaxwell> it doesn't effects getbalance unless you authored it, which is a special case indeed.
330 2014-02-12 08:02:36 <jspilman> oh damn
331 2014-02-12 08:03:21 <jspilman> is that considered a bug?
332 2014-02-12 08:04:10 <gmaxwell> jspilman: that your change can get mutated on you and goof stuff up? yes. Though its one we've known about for a long time.
333 2014-02-12 08:05:11 <jspilman> gmaxwell: I mean more specifically that mutatation hitting a block cause getbalance to count the orphan and therefore appear too high?
334 2014-02-12 08:05:54 <warren> I agree the original tx should be kept somehow in the case of a confirmed mutant.
335 2014-02-12 08:06:06 <warren> The rest of the wallet should gracefully deal with it, but not delete it.
336 2014-02-12 08:06:12 <warren> You need it for records.
337 2014-02-12 08:06:20 <wumpus> jspilman: the invalidated transaction should be hidden, and no longer count toward balance, but it can't be removed
338 2014-02-12 08:07:27 <gmaxwell> I've long wanted a notion of negative confirmation countâ how deep a reorg would have to be to have any hope of saving a transaction, I tried to implement it once but it's actually quite a gnarly layer violating mess.
339 2014-02-12 08:07:51 <gmaxwell> If we had that, though, it would be easy, never count a negative confirmed transaction is IsConfirmed() .. mine or not.
340 2014-02-12 08:07:54 <jspilman> yeah, that sounds like a can of worms
341 2014-02-12 08:08:10 <wumpus> gmaxwell: ... makes sense
342 2014-02-12 08:09:02 <jspilman> without that currently the only way to 'cleanup' is to forget? at some point there has to be a way to release it, -10, -100...
343 2014-02-12 08:09:23 <wumpus> because a reorg can always bring back the transaction, so *marking* it permanently as dead is not a solution either
344 2014-02-12 08:09:27 <wumpus> darn this is complicated...
345 2014-02-12 08:09:39 <gmaxwell> yea, a reorg can switch the cases.
346 2014-02-12 08:09:58 <wumpus> or it could bring a third case in case our happy mutator continues
347 2014-02-12 08:10:45 <wumpus> jspilman: I don't think it matters, you could keep it around forever at not much cost just hide it from the user
348 2014-02-12 08:11:57 <jspilman> does that require having a 'negative confirmation count' or is it enough to have an 'IsOrphan' flag?
349 2014-02-12 08:13:34 <gmaxwell> Sipa's proposal was 16:04 <sipa> what if we make the wallettx.isactive() criterion: mature && confirmed || inmempool
350 2014-02-12 08:14:44 <jspilman> would you say.... wallettx.isorphan == !wallettx.isactive
351 2014-02-12 08:15:50 <wumpus> gmaxwell: I can see no holes in that, though the mempool would have to be careful then never to evict your own unconfirmed transactions
352 2014-02-12 08:16:38 <warren> wumpus: I know at least one entity that might want to expire its own unconfirmed transactions ...
353 2014-02-12 08:17:36 <wumpus> gmaxwell: (as long as they're not orphaned, that is)
354 2014-02-12 08:24:08 <jspilman> how is it that self-authored double-spends / mutators effect getbalance while other orphans and double-spends do not?
355 2014-02-12 08:25:26 <gmaxwell> because unconfirmed third party transactions never change the default balance display.
356 2014-02-12 08:25:49 <jspilman> of course, self-authored are special cased to begin with
357 2014-02-12 08:25:57 <jspilman> ok, thanks, makes sense.
358 2014-02-12 08:30:28 <jspilman> on a completely different topic, has anyone thought up an alternative to weil pairings for making an SPV-ready stealth address?
359 2014-02-12 08:31:50 <jspilman> are there more implementations available other than that stanford library? I'm finding it a bit hard to approach
360 2014-02-12 08:43:57 <flotsamuel> jspilman: the sx python implementation is pretty simple
361 2014-02-12 08:44:19 <flotsamuel> Code: https://github.com/spesmilo/sx/blob/master/src/sx-stealth-new https://github.com/spesmilo/sx/blob/master/src/sx-stealth-send https://github.com/spesmilo/sx/blob/master/src/sx-stealth-recv
362 2014-02-12 08:44:35 <flotsamuel> Operation: https://en.bitcoin.it/wiki/Sx/Stealth
363 2014-02-12 08:52:50 <flotsamuel> From what I understand that implementation was actually inspired by yours, jspilman, so maybe that's not what you looking for when you're asking for "implementations"? :)
364 2014-02-12 08:55:21 <Cocodude> Quick question. The patch involving bSpendZeroConfChange - is that enough to get things moving again safely, even though there will be some major throughput issues?
365 2014-02-12 08:58:56 <gmaxwell> jspilman: the library pond is using is another alternative.
366 2014-02-12 08:59:16 <gmaxwell> Cocodude: moving again for what?
367 2014-02-12 08:59:29 <wumpus> Cocodude: it is enough to make sure that you don't build chains of unconfirmed transactions which can be broken (and thus get stuck forever) by mutability abuse
368 2014-02-12 08:59:44 <wumpus> malleability*
369 2014-02-12 08:59:45 <Cocodude> gmaxwell/wumpus: Thanks, that'll do for now
370 2014-02-12 09:00:47 <Cocodude> Idea being is that I'm going to decrease throughput by only allowing large purchases/withdrawals. If I start running out of confirmed change regularly, I'll just increase the minimum purchase/withdrawal amount.
371 2014-02-12 09:08:06 <koryu> hi, is thats the place to get in contact with core developers?
372 2014-02-12 09:11:07 <kinlo> koryu: what do you want to ask?
373 2014-02-12 09:13:10 <koryu> i am a developer but i never worked on an open source project. i wonder if bitcoin needs more developers and how many hours the main developers spend on bitcoin.
374 2014-02-12 09:13:37 <wumpus> koryu: yes, we can always use more developers!
375 2014-02-12 09:13:40 <DiabloD3> koryu: bitcoin always needs more
376 2014-02-12 09:13:44 <DiabloD3> damnit wumpus
377 2014-02-12 09:13:48 <kinlo> koryu: opensource projects indeed always need more
378 2014-02-12 09:13:55 <kinlo> koryu: you can spend as much time as you want
379 2014-02-12 09:14:03 <DiabloD3> ACTION hunts the wumpus
380 2014-02-12 09:14:36 <kinlo> koryu: gavin is fulltime, others are just writing in their free time
381 2014-02-12 09:15:55 <koryu> so you have a regular job and after that you spend time in developing btc. how long would a new dev need to get familiar with the code and be any useful for the team?
382 2014-02-12 09:16:39 <kinlo> koryu: depends on the skillset of the dev... I'd recommend just to get familiar with the code first.... just go over to github, build it, read it, browse the tickets...
383 2014-02-12 09:16:45 <wumpus> koryu: gmaxwell had useful advice for new contributors yesterday, let me look it up
384 2014-02-12 09:16:47 <DiabloD3> koryu: there are no full time bitcoin devs atm I think
385 2014-02-12 09:16:56 <wumpus> <gmaxwell> and a little more directed than just reading the whole thing yourself for the sake of reading it.
386 2014-02-12 09:16:56 <wumpus> <gmaxwell> The advice I give to new contributors goes like: Test things and report bugs, start reviewing pulls, submit test cases, and add improvements in areas that you understand to solve problems that you care about.
387 2014-02-12 09:16:56 <wumpus> <gmaxwell> wumpus: It also is a great way to learn about more of the software.
388 2014-02-12 09:16:56 <wumpus> <wumpus> gmaxwell: especially more people reviewing changes would be useful
389 2014-02-12 09:16:58 <kinlo> DiabloD3: gavin is fulltime, no ? :)
390 2014-02-12 09:17:04 <DiabloD3> kinlo: not as dev
391 2014-02-12 09:17:11 <DiabloD3> kinlo: he wears a bunch of hats for the foundation
392 2014-02-12 09:17:12 <wumpus> I'm working full time on bitcoin at the moment
393 2014-02-12 09:17:44 <kinlo> wumpus: how do you survive ? :)
394 2014-02-12 09:18:07 <DiabloD3> duh
395 2014-02-12 09:18:07 <DiabloD3> hes not human
396 2014-02-12 09:18:12 <wumpus> kinlo: I don't :) no, I get a grant from the bitcoin foundation
397 2014-02-12 09:18:32 <kinlo> wumpus: I assumed only gavin got foundation backing
398 2014-02-12 09:19:11 <kinlo> oh well, doesn't really matter, as long as bitcoin improves
399 2014-02-12 09:19:32 <wumpus> kinlo: yes, that used to be the case, but I'm also helping full time for the last few months
400 2014-02-12 09:19:57 <koryu> ok thank you. i will start downloading the repository and take a look. is there any faq for new devs?
401 2014-02-12 09:20:13 <DiabloD3> kinlo: you do realize who gavin is, right?
402 2014-02-12 09:20:26 <wumpus> koryu: read the stuff in doc/ for your platform, at least
403 2014-02-12 09:20:42 <DiabloD3> kinlo: he has an actual title at the foundation
404 2014-02-12 09:20:57 <kinlo> DiabloD3: ofcourse...
405 2014-02-12 09:21:12 <Plarkplark_> Are devs working on a fix for malleability? Is that even possible?
406 2014-02-12 09:21:34 <kinlo> Plarkplark_: there is a fix scheduled to be included in next version afaik, sipa has been working on it
407 2014-02-12 09:21:37 <Plarkplark_> That would make your coins unspendable after each transaction, because the change address needs to confirm first...
408 2014-02-12 09:21:52 <koryu> ok thx :) then i will continue working and take a look at this in the evening
409 2014-02-12 09:21:53 <kinlo> koryu: there was a nice talk on fosdem about helping open source projects, perhaps you should see it
410 2014-02-12 09:22:01 <wumpus> working on a fix for malleability *abuse*, malleability itself won't be solved that quickly if possible at all
411 2014-02-12 09:22:16 <Plarkplark_> kinlo: not to nag, but is there an eta? Should be think hours, days or weeks or months?
412 2014-02-12 09:22:22 <wumpus> but it should no longer be possible to use it as a DOS attack
413 2014-02-12 09:22:35 <koryu> link me pls :)
414 2014-02-12 09:22:36 <Plarkplark_> Sorry, I mean *abuse* fix indeed.
415 2014-02-12 09:22:41 <kinlo> Plarkplark_: there is no real issue...
416 2014-02-12 09:23:05 <kinlo> Plarkplark_: it's just an anoyance people implementing wallets must take notice of, not a big problem
417 2014-02-12 09:23:08 <kinlo> koryu: http://video.fosdem.org/2014/Janson/Saturday/Software_Archaeology_for_Beginners.webm
418 2014-02-12 09:23:15 <wumpus> Plarkplark_: some stuff is already merged in master
419 2014-02-12 09:23:26 <wumpus> software archeology, haha
420 2014-02-12 09:23:34 <kinlo> wumpus: it was a nice talk :)
421 2014-02-12 09:23:35 <koryu> ty
422 2014-02-12 09:24:06 <Plarkplark_> can we limit dust transactions further, for the time being?
423 2014-02-12 09:24:24 <Plarkplark_> like minimal send = 0.00001 or something? making it econom. unfeasable?
424 2014-02-12 09:24:27 <wumpus> what would that do? dust is not even the problem
425 2014-02-12 09:24:54 <Plarkplark_> Kinda related to the spam on the network lately. but ok, yes not really related.
426 2014-02-12 09:24:57 <Plarkplark_> i need some sleep.
427 2014-02-12 09:25:03 <Plarkplark_> thanks for the feedback, bye.
428 2014-02-12 09:29:13 <koryu> ok, thx for the talk :) cya guys
429 2014-02-12 09:40:54 <GamerSg> Can anyone tell me if getbalance "xx" 3 is still reliable?
430 2014-02-12 10:00:09 <maaku> is uint256 stored little endian or big endian?
431 2014-02-12 10:00:59 <wumpus> where?
432 2014-02-12 10:01:08 <maaku> in memory
433 2014-02-12 10:01:48 <maaku> wait i just had the bright idea of looking at openerator<
434 2014-02-12 10:02:01 <maaku> it starts with the last element so i guess little endian. n/m
435 2014-02-12 10:02:16 <wumpus> yes, little endian
436 2014-02-12 10:02:58 <wumpus> (to be precise it's stored as a little-endian array of uint32's, if your system would be big endian you'd get some kind of hybrid...but we don't do big endian architectures here )
437 2014-02-12 10:04:02 <maaku> yeah, what i'm doing will sadly add one more thing that has to change for a big endian architecture
438 2014-02-12 10:04:08 <maaku> though i wonder if that will ever happen
439 2014-02-12 10:05:13 <Eliel> will there be a bugfix release soon to help wallets not become confused due to transaction malleability?
440 2014-02-12 10:06:31 <wumpus> maaku: well only one person has to care enough about bigendian architectures and step up and do a lot of work, it could happen (though I honestly don't think so, either, AFAIK none of th architectures in common use is be anymore)
441 2014-02-12 10:06:48 <maaku> Eliel: people are working on many things. when we know, it will undoubtedly be discussed here. please be patient
442 2014-02-12 10:07:50 <maaku> wumpus: yeah as far as I know even those which are traditionally BE now have LE emulation modes, for exactly this reason
443 2014-02-12 10:19:05 <GamerSg> Can anyone tell me if getbalance "accName" 3 is still reliable?
444 2014-02-12 10:23:28 <thermoman> is there a (private) irc channel where bitcoin devs and exchange operators can chat?
445 2014-02-12 10:29:13 <Datavetaren> Malleability: Can anyone give a quick comment on 2nd posting of https://bitcointalk.org/index.php?topic=460467.0 ?
446 2014-02-12 10:30:14 <uiop> bitcoin devs: it would be exceedingly professional of you if you made an official statement on your position/plans for addressing (or not) the issues at hand, since the vast majority of exchange operators/etc seem to be relying 100% on bitcoind (not implying they shouldn't).
447 2014-02-12 10:30:55 <maaku> Datavetaren: having consensus-critical data which is not protected by hash in the merkle structure is a very bad idea
448 2014-02-12 10:30:59 <uiop> or alternatively, concrete and explicit implementation advice to avoid the recently highlighted pitfalls
449 2014-02-12 10:31:33 <Datavetaren> +maaku: No, the 2nd posting, not the 1st.
450 2014-02-12 10:31:41 <t7> uiop remove leading zeros?
451 2014-02-12 10:31:53 <t7> store data in the correct format?
452 2014-02-12 10:32:18 <t7> convert data to the correct format before comparing?
453 2014-02-12 10:33:13 <uiop> t7: i had more in mind "you must build a database of the blockchain, create an index on txouts/blahs, and where before you were searching by txid, not you must (1) .., (2) .., (3).. , (4a) .., .."
454 2014-02-12 10:33:36 <maaku> Datavetaren: there's no way to know what the 'smallest' transaction is
455 2014-02-12 10:33:57 <t7> uiop: should be covered in the original paper, i think
456 2014-02-12 10:33:59 <uiop> t7: "the options for parsing the blockchain data are as follows..."
457 2014-02-12 10:34:01 <uiop> t7: etc
458 2014-02-12 10:34:19 <Datavetaren> +maaku: Are you sure? I think for the majority of cases it should be relatively easy.
459 2014-02-12 10:35:31 <uiop> t7: perhaps, but for the benefit of all the exchange/equiv operators scrambling to properly implement automated mass-withdrawal systems, an official statement with official implementation advice would be very welcome on many different levels
460 2014-02-12 10:35:56 <maaku> Datavetaren: we don't know if script signatures are malleable
461 2014-02-12 10:36:16 <maaku> and if they are, then we don't know or may not be able know which signature form is 'smallest'
462 2014-02-12 10:36:37 <t7> uiop: it would be helpful but it may be a lot of work
463 2014-02-12 10:36:57 <uiop> t7: what would be a lot of work?
464 2014-02-12 10:37:10 <t7> all that documentation
465 2014-02-12 10:37:21 <Datavetaren> +maaku: I think public script signatures are mallaeble (you can push/pop dummy data, right?), but I still think it should be relatively easy to find the smallest for simple transactions. After all, it's not a TM complete language.
466 2014-02-12 10:37:38 <maaku> Datavetaren: no i don't mean scriptSig - i mean the signature itself
467 2014-02-12 10:37:47 <t7> uiop: its a good idea, you should get started and people will likely help out :)
468 2014-02-12 10:37:54 <maaku> it may or may not be possible to aglebraicly modify the signature so that a different number is stored, but it is still valid
469 2014-02-12 10:38:05 <uiop> t7: for fuck's sake, i'm talking about a one page official statement and rough implementation sketch :)
470 2014-02-12 10:38:22 <uiop> t7: are not at least some devs being paid?
471 2014-02-12 10:38:32 <dexX7> they are
472 2014-02-12 10:38:35 <dexX7> at least some
473 2014-02-12 10:38:40 <dexX7> afaik
474 2014-02-12 10:38:47 <maaku> that's just the first example I could think of something for which it isn't possible to easily enumerate values; there are probably others
475 2014-02-12 10:39:00 <t7> uiop: it will not be one page lol
476 2014-02-12 10:39:05 <uiop> t7: anyways, i'm not trying to be confrontational, just suggesting what i feel would be very welcome at this point
477 2014-02-12 10:39:46 <Datavetaren> +maaku: Hmmm
478 2014-02-12 10:39:48 <uiop> t7: anything can be one page, if you zoom out enough.
479 2014-02-12 10:45:51 <uiop> t7: said an another way, given a set of sql "CREATE TABLE"'s, what is the one-liner that would replace "SELECT .. FROM transactions WHERE txid = ..;". this would be the content of the sketch.
480 2014-02-12 10:46:10 <uiop> (along with the "CREATE TABLE"'s)
481 2014-02-12 10:46:26 <maaku> uiop: no, most of the devs are not paid
482 2014-02-12 10:46:37 <maaku> at this this is not people's day job
483 2014-02-12 10:46:45 <Datavetaren> +maaku: I see, you're talking about (r, -s (mod N)) for example?
484 2014-02-12 10:46:45 <maaku> with a small, small handful of exceptions
485 2014-02-12 10:46:50 <uiop> maaku: ah, ok
486 2014-02-12 10:46:52 <maaku> Datavetaren: yes
487 2014-02-12 10:48:09 <uiop> t7: (of course, it could be phrased in s/sql/<whatever>/)
488 2014-02-12 10:49:33 <maaku> uiop: though one solution is for people to step up and start paying core developers ;)
489 2014-02-12 10:49:39 <Datavetaren> +maaku: Shouldn't it be possible to restrict that? (So it is more difficult to choose a "random" s). The rest of my argument should be ok, right?
490 2014-02-12 10:50:02 <maaku> Datavetaren: it *is* random, and needs to be
491 2014-02-12 10:50:19 <maaku> beyond that we don't know much about the math here. no one has explored it
492 2014-02-12 10:50:27 <uiop> maaku: i wholeheartedly agree.
493 2014-02-12 10:50:42 <maaku> regarding the rest of your argument; it must be all or nothing
494 2014-02-12 10:51:13 <uiop> t7: "uiop: its a good idea, you should get started and people will likely help out :)"
495 2014-02-12 10:51:19 <maaku> you'd better be able to prove that the transaction you generated is the lexographically smallest possible transaction, or else you've made the situation worse
496 2014-02-12 10:51:34 <maaku> (beause the attacker just figures out a smaller one and gets all nodes to switch to his)
497 2014-02-12 10:51:39 <uiop> t7: ok. however i am not a bitcoin developer, so any such "statement" from me would not be "official"
498 2014-02-12 10:52:05 <uiop> t7: which is the more important part imo ("official statement")
499 2014-02-12 10:52:42 <Datavetaren> +maaku: True
500 2014-02-12 11:03:15 <uiop> is there a particular reason the "value" field in the "TxOut" structure is an int64_t instead of a uint64_t?
501 2014-02-12 11:04:28 <uiop> (in other words, "value" can't be negative, can it?)
502 2014-02-12 11:05:06 <random_cat> is there a convenient way to find all bids and offers i have open?
503 2014-02-12 11:05:18 <uiop> random_cat: wrong channel?
504 2014-02-12 11:06:38 <random_cat> yes -- i thought this was ripple. sorry
505 2014-02-12 11:10:08 <Tykling> soooo.. I have these two transactions from yesterday that still have 0 confirmations and seem "stuck"
506 2014-02-12 11:11:05 <Tykling> I got this error error: {"code":-4,"message":"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."} when I ran "bitcoind sendtoaddress ...."
507 2014-02-12 11:12:08 <Tykling> but I don't see how that could be the case :)
508 2014-02-12 11:15:21 <wumpus> Tykling: that problem is explained pretty well here http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_active_malleable_transaction_relayers_it/
509 2014-02-12 11:16:07 <wumpus> Tykling: master already has a change to not spend unconfirmed change because of that
510 2014-02-12 11:18:09 <Tykling> wumpus: I see, so.. what, where are the btc now ?
511 2014-02-12 11:18:31 <Tykling> they will reappear in the sending wallet when bitcoind gets upgraded
512 2014-02-12 11:19:48 <Billdr> Can you post your transaction id Tykling? I'm curious about something.
513 2014-02-12 11:20:14 <Tykling> sure but I can't find it anywhere except in my local listtransactions, blockchain.info doesn't see it
514 2014-02-12 11:20:19 <Tykling> sec
515 2014-02-12 11:21:46 <Billdr> Is it possible that you're attempting to spend coins from an unconfirmed transaction?
516 2014-02-12 11:23:41 <Billdr> I misread your initial issue Tykling. Sorry about that. Should probably wait until after coffee to speak.
517 2014-02-12 11:24:21 <Tykling> Billdr: the last "receive" transaction I see is from january and has over 2000 confirmations so I do
518 2014-02-12 11:24:24 <Tykling> ok
519 2014-02-12 11:24:26 <Tykling> :)
520 2014-02-12 11:29:52 <Datavetaren> +maaku: Thanks for making me wiser :) (I felt that something had to be wrong.) It looks like the malleability problem is quite unsolvable (or is there a solution long-term)?
521 2014-02-12 11:34:53 <BW^-> so the mtgox press release was about a non issue
522 2014-02-12 11:43:18 <BW^-> http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
523 2014-02-12 11:45:04 <mathis98> thats the ticket
524 2014-02-12 11:49:14 <BW^-> mathis98: ticket, what do you mean?
525 2014-02-12 11:49:36 <uiop> is there a reference for script canonicalization rules?
526 2014-02-12 11:49:48 <mathis98> http://www.youtube.com/watch?v=iyp9fh-u4w8
527 2014-02-12 11:49:54 <BW^-> it was kind of unwise of them to blame the bitcoin protocol for an internal issue of their own
528 2014-02-12 11:50:14 <mathis98> it was, but that doesnt mean there is not a wider problem
529 2014-02-12 11:50:23 <swulf--> to be fair, bitcoind doesn't make it "trivial" to not use txids
530 2014-02-12 11:50:42 <mathis98> mark needs to deflect from the fact that hes just a bad developer... that or they need to crash the market and recoup the coins that were stolen
531 2014-02-12 11:50:42 <swulf--> listtransactions rpc call lists a txid for unconfirmed transactions - that right there is already asking to be abused
532 2014-02-12 11:52:20 <Tykling> wumpus: can you explain where the btc I tried to send are now - they appear neither at the sending or at the receiving end - do I need to wait for the new version of bitcoind or is there something I can do now ? thanks!
533 2014-02-12 11:53:09 <uiop> oh, n/m.
534 2014-02-12 11:53:44 <wumpus> Tykling: if they're only held up by a never-confirming transaction they're still in your wallet... with -salvagewallet -rescan you get rid of them and see the true balance (but do this with a copy, as you'll lose all metadata like labels)
535 2014-02-12 11:54:00 <wumpus> Tykling: and yes, there will be an update that cleans this up
536 2014-02-12 11:54:13 <Tykling> wumpus: <3 awesome, thank you for your help!
537 2014-02-12 11:54:33 <uiop> what's the max number of operands a script opcode has?
538 2014-02-12 11:54:54 <Cocodude> I've got a nasty, hacky idea to increase throughput of Bitcoin transactions (i.e. the number of unspent inputs available that have > 0 confirmations).
539 2014-02-12 11:56:11 <Cocodude> Can I: 1. Send 10 BTC to another Bitcoin address from wallet A. 2. Send 1 BTC back, wait for a confirm, send another BTC back, wait for a confirm etc. until all are sent. 3. End up with 10 usable 1 BTC inputs at the first wallet?
540 2014-02-12 11:56:46 <BW^-> anyhow i guess it's positive that the market learns to be resistent against weird news.
541 2014-02-12 11:57:08 <airbreather> uiop: https://en.bitcoin.it/wiki/Script -- I think it would depend on how you define "operand". For my latest project, I'm defining an operand as "number of items that the script runner has to pop off the stack", which can be indefinitely many with things like OP_PICK / OP_ROLL
542 2014-02-12 11:57:17 <wumpus> Cocodude: yes, you can do a sendmany to yourself with 10 1 BTC outputs for example
543 2014-02-12 11:57:34 <wumpus> Cocodude: once that confirms you'll have 10 1 BTC inputs
544 2014-02-12 11:57:37 <Cocodude> wumpus: Ah, that's an even nicer idea. Thanks. I think that'll help as a workaround.
545 2014-02-12 11:58:03 <uiop> airbreather: nice, thanks
546 2014-02-12 11:59:40 <uiop> airbreather: oh, right. by "operand" i meant "data following the opcode in the insn stream that is associated with that opcode"
547 2014-02-12 12:02:11 <airbreather> uiop: 0x4e 0xFF 0xFF 0xFF 0xFF (+4294967295 bytes)
548 2014-02-12 12:02:25 <airbreather> Gonna be hard to beat that one
549 2014-02-12 12:03:57 <uiop> i'll issue you a preliminary "heh", to be confimed once i "get it" :)
550 2014-02-12 12:04:40 <uiop> ah
551 2014-02-12 12:04:53 <uiop> OP_PUSHDATA4 <size> <data>
552 2014-02-12 12:05:17 <wumpus> I suspect noone is going to need OP_PUSHDATA4 any time this century :)
553 2014-02-12 12:06:49 <airbreather> wumpus: well.. OP_PUSHDATA2 only lets you push a single data field up to 64k onto the stack... are you saying 64k ought to be enough for anyone?
554 2014-02-12 12:08:23 <wumpus> airbreather: yes, but I said suspect, not I know for sure!
555 2014-02-12 12:08:39 <wumpus> airbreather: so I don't hope that my statement will be (mis)quoted by generation after generation of trolls... the horror :)
556 2014-02-12 12:08:47 <airbreather> :-D
557 2014-02-12 12:10:20 <uiop> wumpus: i'm marking you down as saying "64k is enough for anyone!"
558 2014-02-12 12:10:37 <uiop> :)
559 2014-02-12 12:11:27 <uiop> ACTION feels like he heard that one before, right after being told how you use to have to walk to school uphill both ways
560 2014-02-12 12:12:52 <wumpus> hehehe
561 2014-02-12 12:18:19 <uiop> ok, so the part i'm unclear on is whether (suppose you now need to search for a transaction you've issued which may be mangled to the maximum possible degree), do you need to (after you've narrowed it down/whatever) essentially canonicalize the scripts of all possible candidates in order to determine if a transaction really is the one you issued?