1 2014-02-10 00:33:08 <copumpkin> hmm, my computer froze and when I restarted it, bitcoin-qt complained that it couldn't read the block index and had to reindex the whole thing. I thought there was some reasonable database that didn't suffer from this backing the program?
2 2014-02-10 00:34:32 <andytoshi> reasonable databases aren't fast
3 2014-02-10 00:36:29 <copumpkin> I know we moved away from bdb, but can't remember what replaced it
4 2014-02-10 00:36:53 <emowataji> leveldb
5 2014-02-10 00:38:02 <copumpkin> hmm, and I guess that doesn't try to provide magic durability guarantees?
6 2014-02-10 00:41:21 <BB-Martino> thx again for the help back there
7 2014-02-10 00:53:38 <sipa> copumpkin: in theory, it does
8 2014-02-10 00:53:50 <kostagr33k> can someone tell me why i get this after using bitcoind SENDMANY function: Warning! this transaction is a double spend of 112348699. You should be extremely careful when trusting any transactions to/from this sender.
9 2014-02-10 00:53:59 <kostagr33k> i had about 72 outputs from 1 single input
10 2014-02-10 00:54:11 <sipa> i'm sure it's not bitcoind telling you this
11 2014-02-10 00:54:19 <kostagr33k> blockchain.info is
12 2014-02-10 00:54:25 <Luke-Jr> ignore that website
13 2014-02-10 00:54:31 <Luke-Jr> it is full of useless misinformation
14 2014-02-10 00:54:39 <kostagr33k> that bad?
15 2014-02-10 00:54:49 <copumpkin> sipa: :(
16 2014-02-10 00:54:56 <sipa> copumpkin: which version?
17 2014-02-10 00:55:07 <copumpkin> 0.8.5-beta
18 2014-02-10 00:55:24 <sipa> git head / 0.9.0rc1 may improve things
19 2014-02-10 00:55:27 <Luke-Jr> copumpkin: 0.8.6 fixed stuff like that :P
20 2014-02-10 00:55:33 <copumpkin> gah
21 2014-02-10 00:55:38 <sipa> on osx, 0.8.6 fixes some issues too
22 2014-02-10 00:55:54 <copumpkin> why doesn't this thing have an update notification mechanism built into it yet? :P
23 2014-02-10 00:56:01 <sipa> why do you think?
24 2014-02-10 00:56:07 <copumpkin> cause someone hasn't implemented it yet
25 2014-02-10 00:56:10 <copumpkin> ACTION touches his nose
26 2014-02-10 00:56:34 <sipa> no, because it'd be one hell of a responsibility for the one that controls the update notification mechanism
27 2014-02-10 00:56:56 <Luke-Jr> copumpkin: too much power
28 2014-02-10 00:57:09 <Luke-Jr> Joe Update Deployment essentially owns the network then
29 2014-02-10 00:57:22 <copumpkin> who runs the bitcoin-qt site or bitcoin.org?
30 2014-02-10 00:57:29 <Luke-Jr> copumpkin: random people
31 2014-02-10 00:57:46 <sipa> copumpkin: even if someone hacks the website, it doesn't cause an instant update of every node
32 2014-02-10 00:57:49 <Luke-Jr> bitcoin-qt doesn't *really* have a site..
33 2014-02-10 00:57:51 <copumpkin> sure
34 2014-02-10 00:57:58 <sipa> but yes, the problem exists already
35 2014-02-10 00:58:13 <sipa> there have been proposals to have auto-update, controlled by several developer's keys
36 2014-02-10 00:58:14 <Luke-Jr> copumpkin: the long-term plan is to *offer* an update when N of M developers sign a release binary
37 2014-02-10 00:58:18 <copumpkin> ah
38 2014-02-10 00:58:23 <Luke-Jr> copumpkin: but that's new tech that isn't really done
39 2014-02-10 00:58:32 <sipa> eh s/auto-update/update notification/
40 2014-02-10 00:58:47 <sipa> i don't think i want auto-update at all
41 2014-02-10 00:58:48 <kostagr33k> luke-jr: how long do I wait before i should be worried? any other site I can verify with?
42 2014-02-10 00:59:07 <Luke-Jr> kostagr33k: worried about what? if you sent it, nothing to worry about..
43 2014-02-10 00:59:20 <kostagr33k> luke-jr: i sure hope so
44 2014-02-10 00:59:22 <Luke-Jr> other side can verify when it's 6 or 7 blocks deep in the blockchain
45 2014-02-10 00:59:44 <kostagr33k> i just want 1 confirmation to pop in so i can feel at ease. i guess its smoke time
46 2014-02-10 00:59:46 <Luke-Jr> kostagr33k: note that your txid *might* change in the process of this. txid is not guarateed to be the same
47 2014-02-10 01:00:02 <kostagr33k> really? i thought the output from send many is the txid?
48 2014-02-10 01:00:07 <Luke-Jr> it is
49 2014-02-10 01:00:12 <Luke-Jr> but it could change
50 2014-02-10 01:00:17 <sipa> kostagr33k: there's an attack that modifies transactions in-flight, which does barely more than annoy people and confuse some software
51 2014-02-10 01:00:26 <sipa> kostagr33k: it doesn't actually steal or invalidate or double spend
52 2014-02-10 01:00:30 <copumpkin> are people actively doing that?
53 2014-02-10 01:00:41 <sipa> we've seen several reports the past few days
54 2014-02-10 01:00:47 <Luke-Jr> copumpkin: ever since a certain well-known exchange was found to be vulnerable..
55 2014-02-10 01:00:49 <copumpkin> lol
56 2014-02-10 01:01:19 <kostagr33k> will bitcoin-qt show the new txid in the Transactions tab?
57 2014-02-10 01:01:38 <Luke-Jr> kostagr33k: when it gets in a block, I think it will
58 2014-02-10 01:01:48 <sipa> yes, it will show both
59 2014-02-10 01:01:53 <kostagr33k> ok thanks luke-jr and sipa
60 2014-02-10 01:02:09 <kostagr33k> 14 minutes and counting
61 2014-02-10 01:02:16 <sipa> wait 2 hours
62 2014-02-10 01:02:21 <Luke-Jr> I suspect the "original" txid/transaction will be a zombie unconfirmed forever
63 2014-02-10 01:02:26 <sipa> yup
64 2014-02-10 01:02:43 <sipa> or confirm :)
65 2014-02-10 01:02:51 <Luke-Jr> sipa: I wonder if we should hold 0.9 off for a fix to that, since it seems someone is automatically doing it all the time now..
66 2014-02-10 01:03:06 <Luke-Jr> well, if the original confirms, the mutation will never show
67 2014-02-10 01:03:22 <copumpkin> anyone know more about the O((n^2)!) algorithm?
68 2014-02-10 01:03:26 <jaakkos> do the openssl devs care?
69 2014-02-10 01:03:28 <kostagr33k> so i guess i guess sit and wait? i was going to e-mail the end users but not if the TXID could be FUD
70 2014-02-10 01:03:46 <copumpkin> jaakkos?
71 2014-02-10 01:03:59 <jaakkos> about the malleability
72 2014-02-10 01:04:09 <copumpkin> I thought it was just a bitcoin issue, not including txid in signature
73 2014-02-10 01:04:18 <copumpkin> or other metadata, I guess
74 2014-02-10 01:04:37 <gmaxwell> copumpkin: I was talking about the recursive ismine() check for confirmed inputs on unconfirmed transactions, I think it's factorial complexity, the n^2 is a bit of an an exageration.
75 2014-02-10 01:05:04 <jcorgan> sipa: can i get your help with something?
76 2014-02-10 01:05:30 <copumpkin> gmaxwell: interesting! is there a writeup of that anywhere or do I just need to dig into the code?
77 2014-02-10 01:05:31 <kostagr33k> luke-jr: ok i checked one of the addresses and I see the payment .. ill sit and wait. Thanks for the help as well sipa
78 2014-02-10 01:05:40 <jaakkos> what is the proposed fix to the malleability issues?
79 2014-02-10 01:05:47 <gmaxwell> copumpkin: phantom wrote about it.
80 2014-02-10 01:06:16 <gmaxwell> jaakkos: it won't be fixed for a long time, services need to be robust against it.
81 2014-02-10 01:07:30 <jcorgan> sipa: i have your 'addrindex' branch *almost* compatible with current master
82 2014-02-10 01:08:04 <jcorgan> it's current up to Dec. 20, but there is a merge conflict with current master since then that should be straightforward, but I can't quite resolve it
83 2014-02-10 01:08:42 <jaakkos> yeah, i see it can't be changed...
84 2014-02-10 01:16:26 <sipa> jcorgan: ok?
85 2014-02-10 01:17:24 <jcorgan> so i was hoping you could do a trial merge of current master into my branch, and either resolve or help me to resolve the conflict in main.cpp and txdb.cpp
86 2014-02-10 01:17:58 <sipa> not now
87 2014-02-10 01:18:11 <sipa> i expect the largest problem is the changed leveldb wrapper interface
88 2014-02-10 01:18:20 <jcorgan> that's all taken care of
89 2014-02-10 01:18:27 <sipa> ok, so what's the problem?
90 2014-02-10 01:18:46 <jcorgan> i've been incrementally merging master since you branched off, and fixing up the merge conflicts commit by commit
91 2014-02-10 01:19:07 <jcorgan> the conflict is actually quite small now
92 2014-02-10 01:19:10 <sipa> sounds painful
93 2014-02-10 01:19:15 <jcorgan> it has taken hours
94 2014-02-10 01:19:54 <jcorgan> but i've got a addrindex branch on my github, and right now there's a node reindexing its database with it for testing, but the last master merge is from dec. 20
95 2014-02-10 01:21:07 <jcorgan> i think it is just one problematic commit away from being a ready for testing
96 2014-02-10 01:21:43 <jcorgan> i can pastebin it if you want
97 2014-02-10 01:25:06 <jcorgan> http://pastebin.com/SuYr8eQu
98 2014-02-10 01:25:58 <jcorgan> this particular conflict was introduced in 96e5f61d
99 2014-02-10 01:26:26 <jcorgan> anyway, i understand if you don't have time right now
100 2014-02-10 01:27:38 <sipa> yeah, that's the encapsulated leveldb iterator
101 2014-02-10 01:27:52 <sipa> i might PR that independently from addrindex at some point
102 2014-02-10 01:29:31 <jcorgan> well, so far the reworked addrindex branch i have is working against master @ 086d7ec2, i just need to test the RPC interface
103 2014-02-10 01:29:43 <jcorgan> (that's Dec. 24)
104 2014-02-10 01:38:53 <aynstein> WilsonNL: what are u compiling?
105 2014-02-10 01:40:58 <zapsoda> Whats the proper way to convert BTC to satoshi (because a function needs intergers) and back again using python? Is it just divide and multiply by 100,000,000? Should I store the BTC values as floats?
106 2014-02-10 01:41:25 <jcorgan> zapsoda: no
107 2014-02-10 01:41:36 <jcorgan> store them as integer satoshi's and convert for display
108 2014-02-10 01:44:00 <zapsoda> Ok, thanks, And to get them to satoshi do I multiply by 100 million?
109 2014-02-10 01:44:09 <zapsoda> satoshi's(
110 2014-02-10 01:44:32 <zapsoda> And for send functions I need to convert them back to *floats*?
111 2014-02-10 01:44:37 <zapsoda> or decimals?
112 2014-02-10 01:44:41 <zapsoda> sorry, noob here :p
113 2014-02-10 01:49:03 <emowataji> pity the send and display functions in the rpc interface don't use integer satoshis
114 2014-02-10 01:50:01 <sipa> yes, very much so
115 2014-02-10 01:50:12 <Luke-Jr> zapsoda: round(btc * 1e8)
116 2014-02-10 01:50:30 <zapsoda> Thanks Luke-Jr
117 2014-02-10 01:50:50 <Luke-Jr> sending, prob best to use Decimal type and /1e8
118 2014-02-10 01:52:51 <zapsoda> Luke-Jr, I'm getting TypeError: unsupported operand type(s) for *: 'Decimal' and 'float'
119 2014-02-10 01:53:04 <zapsoda> Oh, Does your second reply have something to do with that :p
120 2014-02-10 02:00:34 <zapsoda> Oh I see, You were saying for sending it would be best to use decimal type and divide by 1e8
121 2014-02-10 02:00:49 <zapsoda> And idea why I'm getting unsupported operand type(s)/
122 2014-02-10 02:10:10 <Cryo> ^
123 2014-02-10 02:20:31 <phantomcircuit> sipa, the last i heard you were writing a patch to remove vtxPrev
124 2014-02-10 02:20:33 <phantomcircuit> is that still true?
125 2014-02-10 02:20:58 <sipa> phantomcircuit: lost track of that
126 2014-02-10 02:21:02 <sipa> feel free to bring yours up to date
127 2014-02-10 02:21:08 <sipa> i think i've made comments there
128 2014-02-10 02:30:00 <gmaxwell> https://bitcointalk.org/index.php?topic=457546.msg5034918 weee1
129 2014-02-10 02:30:45 <sipa> that's the 3rd one today here
130 2014-02-10 02:30:56 <sipa> someone is running a malleability bot, i think
131 2014-02-10 02:31:47 <andytoshi> sipa: thx for the malleability writeup
132 2014-02-10 02:32:02 <sipa> yw
133 2014-02-10 02:34:35 <fanquake> ACTION wonder why people don't upgrade their clients
134 2014-02-10 02:35:45 <petertodd> sipa: keep in mind that there may be some very deep malleability issues with ECC sigs themselves
135 2014-02-10 02:36:42 <petertodd> sipa: I think we need to separate malleability that is annoying because of poorly coded wallet software and malleability that fundementally makes multi-party protocols dangerous - the latter can IMO be better fixed with a new CHECKSIG type
136 2014-02-10 02:36:49 <gmaxwell> petertodd: well we've enumerated the only one we know of, and be darned we certantly tried to find another algebraic manipulation.
137 2014-02-10 02:37:10 <petertodd> gmaxwell: last I heard from adam he still wasn't sure; has that changed?
138 2014-02-10 02:37:47 <petertodd> gmaxwell: I'd just hate to see people rely on "fix malleability via whack-a-mole" and have that fail
139 2014-02-10 02:38:07 <sipa> apparently people have relied on non-malleability for a long time already
140 2014-02-10 02:38:10 <gmaxwell> he's not sure, I'm not sure. To be sure we'd need to find a proof that rerandomizing a DSA signature lets you solve discrete logs.
141 2014-02-10 02:38:37 <petertodd> gmaxwell: sounds like a lot of not sure :)
142 2014-02-10 02:38:46 <andytoshi> ACTION is also not sure ;)
143 2014-02-10 02:38:47 <petertodd> sipa: well, people rely on zeroconf being safe so...
144 2014-02-10 02:39:00 <gmaxwell> on the other hand, we spent a couple hours futzing with algebra and didn't find a way to do it.
145 2014-02-10 02:39:27 <petertodd> gmaxwell: yeah, i still haven't broken the block cipher I made, must be good stuff :P
146 2014-02-10 02:40:16 <phantomcircuit> gmaxwell, bc.i doesn't show any difference between them
147 2014-02-10 02:40:17 <phantomcircuit> amusing
148 2014-02-10 02:40:31 <sipa> phantomcircuit: one of the pushes is changed to a OP_PUSHDATA4
149 2014-02-10 02:40:59 <phantomcircuit> ah that explains why they appear identical
150 2014-02-10 02:56:33 <zapsoda> Luke-Jr, when I convert them to decimals and divide by 1e8 I get numbers with alot of decimal places, Would I have to round down to the nearest 8th decimal place? Or is there a better way to do this?
151 2014-02-10 02:58:43 <Luke-Jr> zapsoda: convert to Decimal before you divide
152 2014-02-10 02:59:06 <maaku> zapsoda: did you divide by 1e8 or Decimal(100000000)?
153 2014-02-10 03:01:03 <jaakkos> imo the whole mtgox mess just shows how damn difficult it is to come up with bitcoind-compliant implementation
154 2014-02-10 03:01:36 <jaakkos> would it make sense to separate the core functionality into a library and encourage everyone to use it in their wallet implementations?
155 2014-02-10 03:02:18 <jaakkos> anyone implementing their own wallet from scratch seems to be screaming for trouble
156 2014-02-10 03:02:23 <jaakkos> no matter how good you are
157 2014-02-10 03:02:45 <andytoshi> they weren't good
158 2014-02-10 03:02:49 <jaakkos> :D
159 2014-02-10 03:03:03 <maaku> jaakkos: doesn't mtgox use (ancient, archaic, heavilly modded) bitcoind?
160 2014-02-10 03:03:33 <jaakkos> i don't know anything else but just keep hearing it's "custom"
161 2014-02-10 03:04:23 <zapsoda> Luke-Jr, I was converting the divided value to decimal but when I convert the int to decimal first then divide by 1e8 I get
162 2014-02-10 03:04:24 <zapsoda> TypeError: unsupported operand type(s) for /: 'Decimal' and 'float'
163 2014-02-10 03:07:27 <sipa> jaakkos: not sure what you understand under 'core' functionality, but in my view, it certainly excludes the wallet
164 2014-02-10 03:08:44 <jaakkos> perhaps i wanted to say node
165 2014-02-10 03:11:59 <jaakkos> oh well, not sure how to go about it. i'm just trying to think what could be done to avoid such issues in the future.
166 2014-02-10 03:12:20 <sipa> i don't think it's really an implementation issue
167 2014-02-10 03:12:36 <sipa> the problem is infrastructure depending on an incorrect assumption
168 2014-02-10 03:14:03 <jaakkos> the assumption being that coins are not spent if the gox-generated tx isn't in ledger?
169 2014-02-10 03:14:30 <jaakkos> gotta stop thinking about it and wait for the announcement :)
170 2014-02-10 03:14:40 <sipa> announcement of what?
171 2014-02-10 03:14:52 <jaakkos> the one gox is supposed to release today
172 2014-02-10 03:14:57 <phantomcircuit> sipa, they put in place a self imposed timeline of an annoucement on monday
173 2014-02-10 03:15:04 <sipa> yeah sure
174 2014-02-10 03:15:12 <sipa> but i'm not expecting anything interesting there
175 2014-02-10 03:15:28 <phantomcircuit> jaakkos, at the time mtgox implemented their own client they didn't have a lot of great options for handling the volume of payments they were supporting
176 2014-02-10 03:15:30 <sipa> either it will be "still too much problems" or "withdrawals possible again"
177 2014-02-10 03:15:46 <sipa> i assume
178 2014-02-10 03:16:34 <jaakkos> i don't even have funds at gox but i'm just very much interested in hearing what the problems are
179 2014-02-10 03:16:43 <phantomcircuit> jaakkos, giant accounting mess would be my guess
180 2014-02-10 03:16:55 <sipa> jaakkos: http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac
181 2014-02-10 03:17:07 <phantomcircuit> fixing the underlying problem should be relatively simple, but the giant tangle of thousands of cross referenced transactions isn't
182 2014-02-10 03:17:23 <jaakkos> sipa: yeah, this i saw, i actually asked:
183 2014-02-10 03:17:40 <jaakkos> > i wonder if someone can show a set of 3 txs such that: 1) tx that attempts to double spend output X, 2) tx that spent X but signature was malformed and 3) modified tx 2 that was accepted in ledger that really ended up spending X
184 2014-02-10 03:18:34 <jaakkos> i had the feeling that would give ground to gmaxwell's theory?
185 2014-02-10 03:29:00 <zapsoda> Finally got the values to round down using:
186 2014-02-10 03:29:01 <zapsoda> But now I'm getting "TypeError: Decimal('0.00300986') is not JSON serializable" any ideas?
187 2014-02-10 03:29:01 <zapsoda> Decimal(amounts[i] / 1e8).quantize(Decimal(10) ** -8, rounding=ROUND_DOWN)
188 2014-02-10 03:34:45 <phantomcircuit> zapsoda, the decimal object isn't serializable
189 2014-02-10 03:35:06 <phantomcircuit> you need to convert to a float and/or write an encoding routine for decimal.Decimal objects
190 2014-02-10 03:35:23 <zapsoda> float seems alot easier but wont I lose to much precision?
191 2014-02-10 03:36:09 <zapsoda> If you need to encode decimals to use them in RPC there must be a already made function for bitcoin right?
192 2014-02-10 03:36:31 <phantomcircuit> zapsoda, with standard floating point you will lose no precision
193 2014-02-10 03:36:46 <phantomcircuit> zapsoda, check jgarzik's github
194 2014-02-10 03:36:50 <phantomcircuit> python-bitcoinrpc
195 2014-02-10 03:36:57 <phantomcircuit> or maybe it's in python-bitcoinlib now
196 2014-02-10 03:36:59 <phantomcircuit> i cant remember
197 2014-02-10 04:56:06 <fanquake> Finally found a decent mirror to download qt 5.2.1
198 2014-02-10 04:56:37 <fanquake> Half of the available mirrors seem to be down, or want me to wait a good 10 hours..
199 2014-02-10 05:00:02 <benkay> if anyone in here has some java experience I'd appreciate a bit of help reading something that's totally opaque to me: https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/Utils.java#130 i get that we're stepping through a 4-byte-wide byte array and setting each byte individually but this hairy (0xFF & (val >> 24)) stuff is breaking my poor brain
200 2014-02-10 09:22:58 <abrkn> what's error code -4 when submitting a tx using json api?
201 2014-02-10 09:27:20 <wumpus> huh, -4 is RPC_WALLET_ERROR an 'unspecified wallet error', it shouldn't happen while submitting a tx
202 2014-02-10 09:28:14 <wumpus> or at least, what command are you using?
203 2014-02-10 10:03:27 <gmaxwell> ::sigh:: https://www.mtgox.com/press_release_20140210.html
204 2014-02-10 10:12:43 <wumpus> indeed, sigh
205 2014-02-10 10:14:14 <airbreather> trying to understand... can't MtGox just scan each block for transactions that spend the same inputs as the transactions they created, rather than one that matches by hash?
206 2014-02-10 10:14:14 <sipa> they should do that
207 2014-02-10 10:14:18 <Apocalyptic> <SarahCoinBit> ibtc The issue is much bigger than Mt.Gox, it affects all bitcoins
208 2014-02-10 10:14:23 <Apocalyptic> such fud...
209 2014-02-10 10:14:25 <wumpus> airbreather: of course they can
210 2014-02-10 10:14:47 <sipa> but the problem is apparently services where people use the txid to prove a transaction from them didn't confirm
211 2014-02-10 10:14:50 <sipa> which is broken
212 2014-02-10 10:14:56 <airbreather> ahh
213 2014-02-10 10:15:01 <wumpus> but they like to call it a protocol bug because that allows them to pretent they're not responsible
214 2014-02-10 10:15:33 <sipa> admittedly, no wallet client deals well with this situation afaik
215 2014-02-10 10:15:42 <Apocalyptic> indeed sipa
216 2014-02-10 10:15:52 <Blitzboom> gmaxwell: do they speak the truth?
217 2014-02-10 10:15:56 <Blitzboom> is it on the devs to change this?
218 2014-02-10 10:15:56 <wumpus> and yes maybe it is a bug that transaction malleability is allowed, but they were generating transactions that were not accepted by the network that's their problem
219 2014-02-10 10:16:32 <Apocalyptic> Blitzboom, are you serious ?
220 2014-02-10 10:16:35 <wumpus> Blitzboom: reducing the maleability was already under way a long time
221 2014-02-10 10:16:39 <sipa> Blitzboom: he has talked to us in private, and we suggested some things, but i certainly wasn't aware of them relying on us to get the whole bitcoin ecosystem on this
222 2014-02-10 10:16:52 <Apocalyptic> why should the dev change the way mtgox check if the tx did or did not go through ?
223 2014-02-10 10:16:56 <gmaxwell> Blitzboom: It is exceptionally unlikely that malleability will be fixed in the year. We've been slowly moving towards improving it, v0.8 closed of many forms of it.
224 2014-02-10 10:17:01 <Blitzboom> wow
225 2014-02-10 10:17:06 <Blitzboom> mtgoxBTC are fucked?
226 2014-02-10 10:17:16 <sipa> no
227 2014-02-10 10:17:18 <gmaxwell> Blitzboom: no.
228 2014-02-10 10:17:18 <wumpus> no, they're not, they just need to change *their* software
229 2014-02-10 10:17:39 <gmaxwell> They just need to change how they identify transactions.
230 2014-02-10 10:17:40 <Blitzboom> doesn't sound like they intend to do that
231 2014-02-10 10:17:47 <Blitzboom> but thanks
232 2014-02-10 10:17:57 <gmaxwell> They're also talking about having another kind of txid so customers could look up normalized transactions.
233 2014-02-10 10:18:05 <torokun> gmaxwell: why do they have to wait for a standard to implement their own unique txn hashing?
234 2014-02-10 10:18:23 <torokun> couldn't they just do it their own way?
235 2014-02-10 10:18:24 <sipa> anyway, if they want an approved and implemented standard: i suggezted this: compute the sighash of all of a tx's inputs (while setting the prevout script to []), and hash all these sighashes together
236 2014-02-10 10:18:30 <wumpus> Blitzboom: I'm sure they're working on that very hard right now
237 2014-02-10 10:18:32 <gmaxwell> I'm a little disinclined to spend a lot of resources on that, because it doesn't solve a bunch of the other problems malleability presents, like griefers killing chains of unconfirmed txn.
238 2014-02-10 10:18:34 <torokun> it's just a matter of accounting...
239 2014-02-10 10:19:19 <gmaxwell> sipa: otoh, it's not something thats free to support as a first class ui feature, e.g. lookup by that ID would require another large index.
240 2014-02-10 10:21:19 <sipa> what about some python tool checked into the repository that can calculate the normalized txid for a raw transaction?
241 2014-02-10 10:21:59 <gmaxwell> doesn't really address the "where is my transaction? this txid you gave me matches nothing!" case though
242 2014-02-10 10:22:42 <sipa> yeah, but what does adding it to the bitcoin core wallet help? i doubt few involved services use tbat wallet
243 2014-02-10 10:22:56 <sipa> it'd be easy to add though
244 2014-02-10 10:26:10 <orweinberger> gmaxwell Doesn't mtgox's announcement contradicts your technical explanation?
245 2014-02-10 10:26:13 <airbreather> I dunno... it seems to me that this is a social problem rather than a technical one. Worst-case, MtGox support gets flooded with people who try to scam them this way, and then after a trivial amount of scanning, they can verify that this is going on and then ban those customers.
246 2014-02-10 10:27:32 <xeroc> basically: mtgox accounting software is broken .. other exchanges not necessarily broken, too?!? is that right?
247 2014-02-10 10:28:42 <dandroper> seems unclear atm
248 2014-02-10 10:28:55 <gmaxwell> orweinberger: not really. It makes some implications which are just flat out untrue.
249 2014-02-10 10:29:07 <gmaxwell> E.g. that this is something new.
250 2014-02-10 10:29:27 <orweinberger> So it's possible they are lying to buy some more time..
251 2014-02-10 10:29:30 <gmaxwell> Rather than something we've known long enough about that there are posts in 2011 about it and a page on bitcoin.it wiki.
252 2014-02-10 10:29:36 <gmaxwell> I don't think they're lying.
253 2014-02-10 10:29:42 <gmaxwell> but who knows.
254 2014-02-10 10:29:58 <wumpus> indeed, that's what they skip over: why does mtgox suffer from this so badly, while other exchanges continue functioning as normal
255 2014-02-10 10:30:10 <comboy> but it would be nice to have a reliable handle to transaction in general, I mean when nobody reuses addresses it is solved I guess, but until then..
256 2014-02-10 10:30:12 <wumpus> blame it on the protocol, why not
257 2014-02-10 10:30:18 <dkog> "We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized." ... WHAT ?!? I wish I was in a smaller room so I could bang my head against more walls at once...
258 2014-02-10 10:30:20 <orweinberger> They're saying this is a 'weakness' in the bitcoin protocol and not specifically related to MtGox, if that's true why aren't we seeing these issues on Bitstamp or any other exchange
259 2014-02-10 10:30:31 <gmaxwell> I was surprised by the tone and approach of their announcement. There are support related issues why they'd want something to be externally adopted but nothing I know or in the press releases suggests a reason that their withdraws need to be held until that happens.
260 2014-02-10 10:30:49 <Apocalyptic> orweinberger, it's not true... ffs
261 2014-02-10 10:30:58 <orweinberger> Apocalyptic, I agree
262 2014-02-10 10:31:11 <sipa> the only problem is relying on txids to remain unique
263 2014-02-10 10:31:14 <Apocalyptic> ^
264 2014-02-10 10:31:26 <gmaxwell> orweinberger: my explaination was 1/4 about that, it's the stuff at https://en.bitcoin.it/wiki/Transaction_Malleability
265 2014-02-10 10:31:28 <comboy> their dummy support people are not able to verify transaction in any meaningful way probably other than copy pasting txid in their internal checker, so they probably need to fix that
266 2014-02-10 10:31:46 <gmaxwell> comboy: sure but is that a reason to hold all withdraws entirely?
267 2014-02-10 10:32:12 <gmaxwell> and thats not up to any bitcoin core developers, for dummy compat they need bc.i buy in.
268 2014-02-10 10:32:47 <comboy> gmaxwell: not for me, I guess they have been scammed and need to clean up before proceeding
269 2014-02-10 10:32:57 <dkog> I don't understand why they can't just hash transactions however they want.
270 2014-02-10 10:33:27 <gmaxwell> dkog: they can.
271 2014-02-10 10:35:16 <dkog> So... why couldn't they just hash on txin, or the signatures themselves, .. I don't get why they make it out like it's impossible
272 2014-02-10 10:36:07 <gmaxwell> dkog: they want some standard string fools can look up on bc.i, I still can't understand why its gating.
273 2014-02-10 10:36:34 <airbreather> other than the output address, of course
274 2014-02-10 10:36:37 <airbreather> ...
275 2014-02-10 10:36:59 <orweinberger> gmaxwell, do you think this entire issue can be solved solely by mtgox by implementing their withdrawal process in a different way and without having to change anything in the bitcoin protocol? (I'm guessing the answer is yes, since other exchanges are able to do so)
276 2014-02-10 10:37:28 <sipa> this has nothing to do with the protocol
277 2014-02-10 10:37:34 <airbreather> they can just implement their own nonstandard hashing scheme and expose it in a web service
278 2014-02-10 10:37:34 <dkog> gmaxwell: are you reading between the lines or have other info? I don't see them say outright that's what they want
279 2014-02-10 10:37:52 <dkog> orweinberger: yes!
280 2014-02-10 10:38:23 <gmaxwell> dkog: somewhat both. I know they want that, I don't know if thats what they're reffering to as gating. If so I can't figure out why.
281 2014-02-10 10:38:24 <maaku> orweinberger: yes
282 2014-02-10 10:38:25 <airbreather> "here's some numbers, go to http://mtgox.com/wheres-my-money and plug them into that box to track your withdrawal"
283 2014-02-10 10:38:58 <Plarkplark> Mtgox statement: Can the bug block a transaction forever? Or just a while to fool the sending party? What is the time and computing power required to block longer then 10 minutes?
284 2014-02-10 10:39:11 <maaku> orweinberger: instead of reporting only the hash to the user, they should record, report, and track the transaction itself
285 2014-02-10 10:39:30 <airbreather> hell, they could even make "some numbers" be the original txid, and implement a translation scheme that's resistant to this behind the scenes if they want
286 2014-02-10 10:40:13 <dkog> IN related news, Amazon refuses to ship any packages to Florida until the state builds a dome over it to prevent rain from damaging the cardboard boxes that are left uncovered in front of people's houses...
287 2014-02-10 10:44:05 <gmaxwell> dkog: I'm at least glad to see your comments. :)
288 2014-02-10 10:44:19 <dkog> it was a real conversation killer :)
289 2014-02-10 10:45:30 <coffeecoco> dont be shy due to me
290 2014-02-10 10:45:34 <coffeecoco> do tell!
291 2014-02-10 10:47:59 <maaku> gmaxwell: nice writeup on reddit, thank you
292 2014-02-10 10:48:05 <Plarkplark> gmaxwell: +1
293 2014-02-10 10:50:14 <nkuttler> link?
294 2014-02-10 10:51:01 <midnightmagic> nkuttler: http://www.reddit.com/user/nullc and check comments, backwards.
295 2014-02-10 10:51:14 <nkuttler> midnightmagic: oh, that one. thanks :) was confused because of the nick
296 2014-02-10 10:51:21 <midnightmagic> yah
297 2014-02-10 10:54:24 <maaku> for others who might be lazy: http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac
298 2014-02-10 10:58:05 <thermoman> is there a problem with BTC transactions?
299 2014-02-10 10:58:13 <thermoman> because we had a problem some hours ago
300 2014-02-10 10:58:23 <thermoman> and now mt gox says it has problems with transactions
301 2014-02-10 10:59:26 <cazalla> are the mtgox claims true?
302 2014-02-10 11:00:16 <sipa> depends on how you interpret them
303 2014-02-10 11:00:36 <thermoman> is there something wrong with the official bitcoin client?
304 2014-02-10 11:00:38 <thermoman> 0.8.6
305 2014-02-10 11:00:41 <thermoman> or the protocol?
306 2014-02-10 11:00:54 <thermoman> can i resume operation or should i suspend?
307 2014-02-10 11:01:43 <sipa> neither has any problem, and neither will be changed
308 2014-02-10 11:02:16 <sipa> the problem is in infrastructure apparently making the assumption that transaction ids cannot change - something which has been known for years to be not true
309 2014-02-10 11:02:30 <sipa> mtgox refers to a suggested standard for dealing with this
310 2014-02-10 11:03:36 <maaku> thermoman: there is nothing wrong if you are following standard accepted practices
311 2014-02-10 11:03:47 <jddebug> Still keeping the same sha256 or would mining change?
312 2014-02-10 11:04:22 <maaku> jddebug: ?
313 2014-02-10 11:04:24 <sipa> jddebug: NOTHING WILL CHANGE
314 2014-02-10 11:04:25 <airbreather> (does this happen every time someone spreads FUD?)
315 2014-02-10 11:04:30 <sipa> there is nothing wrong with the protocol
316 2014-02-10 11:05:02 <wumpus> no, mining has nothing to do with this at all
317 2014-02-10 11:05:14 <wumpus> where do people get those idiot ideas?
318 2014-02-10 11:05:47 <coffeecoco> fear^
319 2014-02-10 11:06:53 <jddebug> Hey. Was asking if thats what was meant by their rederal to change in protocol. Geesh
320 2014-02-10 11:07:07 <jddebug> *referal
321 2014-02-10 11:07:09 <sipa> jddebug: sorry, we're kinda overwhelmed by that statement
322 2014-02-10 11:07:28 <jddebug> Kk
323 2014-02-10 11:07:35 <wumpus> before you ask question about specific details that make no sense, I suggest you try to understand the big picture
324 2014-02-10 11:10:31 <midnightmagic> wumpus: Knowledge hierarchies which go through minds that don't understand bitcoin, but answer questions for scared people. It's normal, it's going to continue happening too.
325 2014-02-10 11:10:54 <michagogo> cloud|wumpus: Why do I keep getting emails from pulltester?
326 2014-02-10 11:12:22 <Wild0wnes> whoever killed the gmaxwell dialog in here i hate you
327 2014-02-10 11:12:47 <wumpus> michagogo|cloud: probably because you are subscribed to some pull request
328 2014-02-10 11:12:58 <michagogo> cloud|wumpus: Yes, your two gitian PRs
329 2014-02-10 11:12:59 <wumpus> michagogo|cloud: there's an unsubscribe button
330 2014-02-10 11:13:07 <michagogo> cloud|Are you updating them or something?
331 2014-02-10 11:13:09 <wumpus> yes
332 2014-02-10 11:13:12 <michagogo> cloud|Ah
333 2014-02-10 11:13:19 <michagogo> cloud|(with what?)
334 2014-02-10 11:13:49 <wumpus> still trying to get things deterministic
335 2014-02-10 11:13:57 <michagogo> cloud|I don't mind, I was just wondering what was changing, since there didn't appear to be a change on the page
336 2014-02-10 11:14:17 <wumpus> I promise I'll give up today if it's still not going to work
337 2014-02-10 11:14:47 <michagogo> cloud|Who are you promising that to? :P
338 2014-02-10 11:15:33 <wumpus> I think even the .tar.gz is deterministic now, though
339 2014-02-10 11:16:23 <gmaxwell> I'm hearing from a lot of people who are asking things like if it's safe for them to send bitcoins now.
340 2014-02-10 11:16:24 <midnightmagic> whoah how did you do that? I couldn't get deterministic tar even by manipulating datestamps in the origin files.
341 2014-02-10 11:16:34 <wumpus> gzip even includes a timestamp field in its header, isn't that wonderful
342 2014-02-10 11:17:36 <wumpus> midnightmagic: file names through a sort, normalize all permission/uid/gid/timestamp information, and tell gzip to not add a timestamp
343 2014-02-10 11:17:40 <UukGoblin> maaku, what writeup on reddit?
344 2014-02-10 11:17:53 <warren> wumpus: oooooh
345 2014-02-10 11:17:54 <maaku> UukGoblin: http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac
346 2014-02-10 11:17:54 <wumpus> midnightmagic: tar -xvf $HOME/build/bitcoin/$DISTNAME | sort | tar --no-recursion -cT /dev/stdin --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 --mtime="$REFERENCE_DATETIME" | gzip -n > $OUTDIR/src/$DISTNAME
347 2014-02-10 11:18:03 <UukGoblin> maaku, thanks
348 2014-02-10 11:19:32 <midnightmagic> wumpus: Awesome, thanks.
349 2014-02-10 11:22:02 <davout> fun fact: i just deposited to my bitcoin-central account and it appeared twice under two different TXIDs, so apparently someone is out there, randomonly mutating TXIDs
350 2014-02-10 11:22:46 <CrackRockerson> ghosts
351 2014-02-10 11:23:11 <davout> dem leprechauns
352 2014-02-10 11:23:30 <randy-waterhouse> davout: fun fact : Instawallet funds disappeared without a trace
353 2014-02-10 11:23:41 <randy-waterhouse> leprechauns?
354 2014-02-10 11:24:16 <randy-waterhouse> maybe they appeared in your bitcoin-central account twice already?
355 2014-02-10 11:25:25 <davout> randy-waterhouse: this is -dev not -kindergarten
356 2014-02-10 11:25:38 <randy-waterhouse> right you better leave
357 2014-02-10 11:26:20 <airbreather> davout: https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410 it's Enochian's echo bot!
358 2014-02-10 11:26:38 <gmaxwell> sipa http://www.nu.nl/internet/3697861/bitcoin-weer-onderuit-lek-in-software.html
359 2014-02-10 11:26:56 <sipa> gmaxwell: see my mail
360 2014-02-10 11:27:17 <wumpus> goddamnit
361 2014-02-10 11:27:30 <davout> airbreather: did the guy actually make a bot??
362 2014-02-10 11:27:38 <davout> first time i witness this
363 2014-02-10 11:27:41 <airbreather> no, probably not, just a tongue-in-cheek comment
364 2014-02-10 11:28:01 <sipa> it would not surprise me that some bot doing this is actually out there
365 2014-02-10 11:28:04 <davout> hehe, i suppose some people would find an interest in doing just that
366 2014-02-10 11:28:07 <sipa> there have been many random cases
367 2014-02-10 11:28:21 <davout> sipa: yeah, the profit opportunity is pretty clear
368 2014-02-10 11:28:45 <airbreather> some people just want to see the world burn. or at least, scramble around a bit confused, asking if transactions still work
369 2014-02-10 11:29:13 <Aahzmundus> Stupid since news like this sets back mass adoption a good few months
370 2014-02-10 11:29:17 <davout> airbreather: or crash&buy
371 2014-02-10 11:29:52 <maaku> davout: more charitably, it seems that mtgox was making transactions with incorrect encodings, and it may be that someone was just 'helpfully' fixing these after they became non-standard in 0.8
372 2014-02-10 11:29:59 <maaku> but i don't think we know yet
373 2014-02-10 11:31:04 <davout> maaku: well, as long as they were going through they were valid, remember that the "standard" thing is not in the protocol per se
374 2014-02-10 11:31:22 <jouke> gmaxwell: misinformed journalist, we'll contact them right away
375 2014-02-10 11:31:37 <Plarkplark> jouke: dutch?
376 2014-02-10 11:31:49 <jouke> yes
377 2014-02-10 11:31:50 <Ademan> Trying to get out of the storm... so... regarding scriptSig maleability, are there any other implications for that, or just, again, invalidating the transaction hash?
378 2014-02-10 11:31:50 <thermoman> "As a result the Mtgox wallet believed some coins were available for spending which really had already been spent and it began double spending those inputs"
379 2014-02-10 11:31:51 <Plarkplark> Because the bigger news sites will pick this up asap in NL
380 2014-02-10 11:32:10 <sipa> Ademan: s/invalidating/changing/
381 2014-02-10 11:32:53 <Ademan> sipa: sorry, right
382 2014-02-10 11:33:01 <airbreather> Ademan: any transaction that spends the outputs from the losing txid also becomes invalid once the winner gets a few confirms, but that's as far as I think it goes...
383 2014-02-10 11:33:10 <Ademan> I guess I said invalidating since other things depend on the hash, but really it's just changing
384 2014-02-10 11:33:59 <sipa> Ademan: the problem is the definition of validity here... if you have a double spend or other forms of conflicting transactions... both are valid
385 2014-02-10 11:34:06 <sipa> Ademan: it's just that only one will be accepted
386 2014-02-10 11:35:31 <wallet42> how exaclty can i change the hash of a signed tx?
387 2014-02-10 11:35:41 <gwb3> sipa and gmaxwell - if there is anything we can all do to help support your efforts now, more than ever, please do let us know
388 2014-02-10 11:35:42 <UukGoblin> so having read all this, I've come to the conclusion that there's nothing wrong with bitcoin itself, and that you shouldn't trust unconfirmed transactions, and also that you shouldn't rely on the txid not changing
389 2014-02-10 11:35:51 <airbreather> +1 UukGoblin
390 2014-02-10 11:35:53 <Ademan> wallet42: https://en.bitcoin.it/wiki/Transaction_Malleability
391 2014-02-10 11:36:01 <sipa> UukGoblin: bingo
392 2014-02-10 11:36:01 <wallet42> ademan:thx
393 2014-02-10 11:36:14 <Ademan> wallet42: np, please don't try this at home ;-)
394 2014-02-10 11:37:38 <gwb3> there are two issues now, 1. a technical issue at mt.gox 2. a pr problem for bitcoin
395 2014-02-10 11:37:38 <sipa> gwb3: thanks, but i don't think it's up to us to fix things
396 2014-02-10 11:37:52 <gwb3> sipa: np ;)
397 2014-02-10 11:38:32 <Ademan> gwb3: maybe they were hoping after this nobody would want their bitcoins any more and they would be off the hook for their insolvency ;-)
398 2014-02-10 11:38:43 <UukGoblin> gwb3, well, also probably 3. another technical issue at mtgox with cleaning all the mess up
399 2014-02-10 11:39:16 <gwb3> i will continue to spread positive news items on social media to fight the good fight
400 2014-02-10 11:39:26 <UukGoblin> I don't expect it to be fixed any time sooner than their bank withdrawal problems ;-)
401 2014-02-10 11:40:34 <Plarkplark> Why does he say this
402 2014-02-10 11:40:35 <Plarkplark> The problem we have identified is not limited to MtGox, and affects all transactions where Bitcoins are being sent to a third party. We believe that the changes required for addressing this issue will be positive over the long term for the whole community.
403 2014-02-10 11:40:56 <money> https://www.mtgox.com/press_release_20140210.html The problem we have identified is not limited to MtGox, and affects all transactions where Bitcoins are being sent to a third party. We believe that the changes required for addressing this issue will be positive over the long term for the whole community.
404 2014-02-10 11:41:04 <money> whats that
405 2014-02-10 11:41:11 <money> he sais the whole bitcoin network has a bug
406 2014-02-10 11:41:20 <UukGoblin> no
407 2014-02-10 11:41:24 <sipa> it does not
408 2014-02-10 11:41:27 <money> it's just not onl y him
409 2014-02-10 11:41:31 <UukGoblin> he says that other exchanges might have similar bugs as mtgox
410 2014-02-10 11:41:33 <Ademan> Plarkplark: It's not clear to me why this doesn't affect (unconfirmed transactions) in regular wallets
411 2014-02-10 11:41:37 <money> it does yes read, in black andwhite
412 2014-02-10 11:42:00 <money> don't sweetned this, is it a bitcoin problem or not?
413 2014-02-10 11:42:08 <UukGoblin> money, it is not
414 2014-02-10 11:42:23 <Ademan> ACTION needs to finish reading the source code so he knows how transactions are indexed
415 2014-02-10 11:42:24 <Plarkplark> bitcoind seems uneffected, according to gmaxwell
416 2014-02-10 11:42:30 <money> so why did he write that nonsense if it's nonsense
417 2014-02-10 11:42:42 <Plarkplark> So is this like a "wear your seatbelt" kinda thing. and gox did not listen?
418 2014-02-10 11:43:00 <randy-waterhouse> money: it's an edge case if you are a large target like an exchange doing lots of transactions without confirmations
419 2014-02-10 11:43:03 <Plarkplark> and others _might_ als not be listening to the devs?
420 2014-02-10 11:43:10 <money> gmaxxell should openly disqualify his statements.
421 2014-02-10 11:43:51 <money> but well, that means that devs have to work on scalebility right?
422 2014-02-10 11:43:53 <wallet42> what statement?
423 2014-02-10 11:43:58 <money> so it does have limitations.
424 2014-02-10 11:44:03 <sipa> money: it has nothing to do with scalability
425 2014-02-10 11:44:34 <randy-waterhouse> money: gox-like enterprises have limitations, but we already knew that
426 2014-02-10 11:44:40 <money> what is it then?
427 2014-02-10 11:44:40 <thermoman> If an exchange uses the official bitcoind and accounts incoming BTC to user accounts only if at least 6 confirmations were seen on the network for this specific TXID - is this exchange safe or not?
428 2014-02-10 11:45:10 <sipa> money: bitcoin infrastructure (not the protocol or wallets themselves) assuming that transaction id's are immutable
429 2014-02-10 11:45:31 <money> well so what he says isn't making sense? bitcoind is alright? or do you have to expand it? may other exchanges get into the same problem? btchina, houbi, and other exchanges?
430 2014-02-10 11:46:05 <Plarkplark> money: only if they dont handle tx properly
431 2014-02-10 11:46:16 <maaku> money bitcoind is fine
432 2014-02-10 11:46:17 <money> I see.
433 2014-02-10 11:46:19 <Ademan> thermoman: I believe the issue actually lies on the outgoing side, but yes, I believe there is no problem with sufficiently confirmed transactions
434 2014-02-10 11:46:34 <Plarkplark> maaku: so there was a bugfix years ago for this problem in the official client?
435 2014-02-10 11:46:55 <maaku> Plarkplark: there isn't a problem in the reference client
436 2014-02-10 11:47:02 <wallet42> bitcoind is alright but it currently introduces a trapdor if you dont "get" the possible issues in your local database scheme
437 2014-02-10 11:47:39 <money> well why is mtgox blaming it on the outher external circumstances.... I know mtgox is bad, but there could be a possibility. And doesn't bitcoin produce standard wallets that work perfectly well with the bitcoinds?
438 2014-02-10 11:48:45 <wallet42> well mtgox is right about that this "trapdrop" one may fall trough if you dont pay attention to some edge cases could be closed forever
439 2014-02-10 11:50:06 <money> Bitcoin transactions are subject to a design issue that has been largely ignored, while known to at least a part of the Bitcoin core developers and mentioned on the BitcoinTalk forums. https://www.mtgox.com/press_release_20140210.html <--- he is attacking the system.
440 2014-02-10 11:50:20 <money> "Largely Ignored"
441 2014-02-10 11:50:27 <money> DA NERVE.
442 2014-02-10 11:50:54 <starsoccer> So are the bitcoin devs activily looking for a solution/working on a solution or its not a huge rush
443 2014-02-10 11:50:56 <wallet42> it only affects haevy bitcoin transaction producers, that rely their check "this money was send?" on the incorrect assumptin that a txhash is not malleable
444 2014-02-10 11:51:13 <Plarkplark> starsoccer: solution: use the reference (bitcoind) client. done.
445 2014-02-10 11:51:16 <Ademan> maaku: why isn't this a problem for unconfirmed transactions for all clients?
446 2014-02-10 11:51:22 <starsoccer> Plarkplark, yes i know that lol
447 2014-02-10 11:51:31 <randy-waterhouse> who woulda thought ... the centralised users of decentralised system are having problems?
448 2014-02-10 11:51:32 <Apocalyptic> starsoccer, it's not up to bitcoin devs to work out a sol for mtgox
449 2014-02-10 11:51:36 <starsoccer> i just mean so the devs arent changing the whole protocol for mtgox
450 2014-02-10 11:51:43 <starsoccer> oo i know
451 2014-02-10 11:51:53 <sipa> the first e-mail on the bitcoin-dev mailing about malleability is from me, send on october 20th, 2012
452 2014-02-10 11:51:55 <Plarkplark> If a car is broken, do you fix the road?
453 2014-02-10 11:51:56 <maaku> starsoccer: there is no problem with the protocol or with bitcoind
454 2014-02-10 11:51:56 <starsoccer> just mtgox has an interesting way of blaming others for its problems
455 2014-02-10 11:52:00 <maaku> nothing is broken
456 2014-02-10 11:52:08 <maaku> except mtgox's accounting
457 2014-02-10 11:52:13 <starsoccer> lol
458 2014-02-10 11:52:18 <sipa> maaku: apparently not only theirs
459 2014-02-10 11:52:26 <starsoccer> yes just mtgox trying to push out some blame
460 2014-02-10 11:52:27 <maaku> sipa: true
461 2014-02-10 11:52:27 <wallet42> sipa: what is your take, should the protocol be changed?
462 2014-02-10 11:52:30 <starsoccer> thats what i figured
463 2014-02-10 11:52:39 <sipa> wallet42: no
464 2014-02-10 11:53:05 <Ademan> sipa: why not? Surely having reliable txids even for unconfirmed transactions is *desirable*
465 2014-02-10 11:53:06 <sipa> wallet42: there are some changes that can be made to slowly root out the problems caused by malleability
466 2014-02-10 11:53:07 <wallet42> sipa: so better local implementation is the answer
467 2014-02-10 11:53:28 <maaku> Ademan: any improperly coded wallet application could suffer this problem. i don't know what other clients are vulnerable
468 2014-02-10 11:53:44 <sipa> wallet42: but that will take years, is not a guaranteed fix for every potential issue with it, and is not really the issue here
469 2014-02-10 11:54:04 <sipa> Ademan: right, if we'd design bitcoin from scratch today, we'd make sure malleability was of no concern
470 2014-02-10 11:54:16 <sipa> but there is a huge infrastructure that cannot just be changed
471 2014-02-10 11:54:52 <money> oh
472 2014-02-10 11:55:05 <Ademan> maaku: isn't this a problem for bitcoind too? Unconfirmed transactions' txids may not be what the originating client expects, how could that *not* be a problem?
473 2014-02-10 11:55:10 <starsoccer> sipa so years, like gmaxwell said. thats what i ifigured
474 2014-02-10 11:55:22 <sipa> Ademan: yes, bitcoind's wallet doesn't deal with it particularly well
475 2014-02-10 11:55:23 <maaku> Ademan: because txids are meaningless
476 2014-02-10 11:55:45 <sipa> Ademan: only when you accept unconfirmed transactions, though
477 2014-02-10 11:55:59 <davout> maybe they should be re-labeled to something else than "IDentifier" then :-)
478 2014-02-10 11:56:02 <Plarkplark> I hope the devs come up with a good, short post on what/how/when/who.
479 2014-02-10 11:56:04 <money> so if I get this malleability concept correctly, some otherguy can use up coins, and actually doesn't need to own them?
480 2014-02-10 11:56:07 <maaku> the reference wallet in bitcoind annoyingly doesn't handle mutant transactions very well
481 2014-02-10 11:56:10 <gmaxwell> Your site says it payed a customer in txid X. They call bitching, and the tx is unconfirmed for N weeks. Your support staff looks and indeed txid X is unconfirmed for weeks. ... problem there is that the _only_ safe thing to do is to respend and keep the same inputs. Mallability is irrelevant to the safty in this case. So thats a bit interesting.
482 2014-02-10 11:56:11 <maaku> but you don't lose money because of it
483 2014-02-10 11:56:13 <sipa> maaku: NO
484 2014-02-10 11:56:14 <Plarkplark> Get this finger pointing out of the way.
485 2014-02-10 11:56:14 <sipa> eh
486 2014-02-10 11:56:15 <Ademan> money: no
487 2014-02-10 11:56:16 <sipa> money: NO
488 2014-02-10 11:56:25 <sipa> money: all that can happen is that someone can modify a transaction's txid
489 2014-02-10 11:56:33 <sipa> money: without changing the source or destination of the money
490 2014-02-10 11:56:37 <sipa> money: and without invalidating it
491 2014-02-10 11:56:40 <wallet42> money: no you can cange txid
492 2014-02-10 11:56:43 <Plarkplark> gmaxwell: can they delay the tx for weeks?
493 2014-02-10 11:56:50 <money> ok
494 2014-02-10 11:56:53 <gmaxwell> Plarkplark: no, why are you asking me this again?
495 2014-02-10 11:56:58 <Plarkplark> sorry
496 2014-02-10 11:57:06 <maaku> money: the transaction is *exactly* the same ... just with a different hex id
497 2014-02-10 11:57:21 <money> i see
498 2014-02-10 11:57:42 <wallet42> but if you store in your DB: user_x got paid by TXID
499 2014-02-10 11:57:55 <wallet42> and now there is TXID' in the block
500 2014-02-10 11:58:01 <gmaxwell> Plarkplark: mtgox's delayed transactions are because they were spending already spent coins, and before that because they were producing invalid der encodings, and before that because they were spending immature coins. The existance of mutation doesn't give anyone a way to delay payments that I'm aware of.
501 2014-02-10 11:58:01 <wallet42> the user got his funds
502 2014-02-10 11:58:22 <wallet42> but in your DB the TXID is marked as not included in block
503 2014-02-10 11:58:24 <gmaxwell> maaku: say functionally the same instead of exactly. :P
504 2014-02-10 11:58:31 <maaku> gmaxwell: yes, thank you
505 2014-02-10 11:58:38 <Hawkix> Is there a way to verify ex-post that the immutable hash id were indeed misused by someone?
506 2014-02-10 11:58:44 <Plarkplark> gmaxwell: Ok so the explenation in the press release does not really match what we saw in the blockchain?
507 2014-02-10 11:59:07 <gmaxwell> Plarkplark: which part?
508 2014-02-10 11:59:14 <maaku> Hawkix: yes
509 2014-02-10 11:59:24 <Plarkplark> the "bug"
510 2014-02-10 11:59:38 <Ademan> so is the way to "account" for this correctly to compute your own "id" based on unmaleable portions (a somehow normalized signature and scriptsig + inputs+outputs) ?
511 2014-02-10 11:59:43 <Hawkix> maaku: by searching for additional "padding spam" in the mined transactions?
512 2014-02-10 11:59:58 <gmaxwell> Ademan: sure, thats a way of accounting. Or you track spentness on the basis of which inputs were used.
513 2014-02-10 12:00:24 <maaku> Ademan: that would be an ideal thing to do, yes, although theoretically we don't even know if that is possible
514 2014-02-10 12:00:26 <gmaxwell> 03:56 < gmaxwell> Your site says it payed a customer in txid X. They call bitching, and the tx is unconfirmed for N weeks. Your support staff looks and indeed txid X is unconfirmed for weeks. ... problem there is that the _only_ safe thing to do is to respend and keep the same inputs. Mallability is irrelevant to the safty in this case. So thats a bit interesting.
515 2014-02-10 12:00:26 <gmaxwell> IMO inputs are necessary anyways, see my above example:
516 2014-02-10 12:00:43 <wallet42> is the upcomming "relay double spent" transactions a possibly mitigation
517 2014-02-10 12:00:47 <starsoccer> gmaxwell, so basically mtgox is just trying to push the blame onto you when its their custom software
518 2014-02-10 12:01:01 <wallet42> ?
519 2014-02-10 12:01:10 <gmaxwell> E.g. imagine the tx was just delayed and never mutated. You reissue using different inputs? you're potentially screwed, since the original tx might eventually go through. To be safe you must reuse the same inputs, and then you don't care about mutation.
520 2014-02-10 12:01:35 <gmaxwell> starsoccer: well the world is not as simple as A vs B. Bitcoin has some quirks which make correct usage harder than I wish it were.
521 2014-02-10 12:01:51 <Ademan> makes sense
522 2014-02-10 12:02:22 <starsoccer> gmaxwell, yes, for sure, but i just mean they seem to like to say the bitcoin devs need to fix it rather then we will just adjust our software
523 2014-02-10 12:03:33 <money> We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized. In the meantime, exchanges and wallet services - and any service sending coins directly to third parties - should be extremely careful with anyone claiming their transaction did not go through.
524 2014-02-10 12:03:39 <starsoccer> well hopefully mtgox will attempt to actully fix it
525 2014-02-10 12:03:44 <money> whats that??
526 2014-02-10 12:03:47 <starsoccer> otherwise looks like we will be waiting weeks for mtgox
527 2014-02-10 12:04:02 <Ademan> gox has been dead to me for almost a year now
528 2014-02-10 12:04:03 <money> so the bitcoin devs have to fix that and then they will open bitcoin withdrawals?
529 2014-02-10 12:04:20 <wallet42> money: defn not
530 2014-02-10 12:04:23 <sipa> money: hell no
531 2014-02-10 12:04:27 <gmaxwell> they're going to be wating a long time for that.
532 2014-02-10 12:04:27 <money> Also does this mean that the whole network is currently vulnerable???
533 2014-02-10 12:04:30 <Apocalyptic> money, the bitcoin dev don't have to do shit
534 2014-02-10 12:04:31 <money> well he said it.
535 2014-02-10 12:04:31 <wallet42> money: thay have to fix THEIR implementation
536 2014-02-10 12:04:48 <gmaxwell> money: you were trolling hard in the gox channels earler, please don't bring it here.
537 2014-02-10 12:04:51 <Apocalyptic> so it must be true ?
538 2014-02-10 12:04:53 <puzl> but they can track the mutation through the blockchain, right?
539 2014-02-10 12:05:08 <money> NO I quoting what the guy said from the mtgox.com site.
540 2014-02-10 12:05:15 <maaku> puzl: yes
541 2014-02-10 12:05:15 <puzl> so it should be easy enough for them to fix the problem on their end?
542 2014-02-10 12:05:35 <maaku> puzl: yes again, for some definition of "easy"
543 2014-02-10 12:05:36 <wallet42> puzl: well i dont think its a cakewalk
544 2014-02-10 12:05:42 <gwb3> i think it would be helpful if other exchanges started coming out in defense of bitcoin
545 2014-02-10 12:05:44 <sipa> there are 3 different problems here: malleability as a whole (which we are slowly working towards fixing, but will take years), 2) wallets (like mtgox's) which don't deal well with malleability and 3) other services that rely on a constant txid to track transactions that do not confirm
546 2014-02-10 12:05:53 <money> I'm trying to technically understand this. just a second gmaxwell. He said he took this bug with the bitcoin core developers and will only open bitcoin withdrawals once they fix this bug.
547 2014-02-10 12:05:59 <sipa> it is for 3) that they want a standard solution, and we're working on proposing one
548 2014-02-10 12:06:10 <sipa> however, this is NOT something that will impact the protocol or clients
549 2014-02-10 12:06:11 <gwb3> last week (and even to a degree before that) mt. gox really got dragged through the mud
550 2014-02-10 12:06:15 <puzl> well, for a definition of easy being "all the information is present already" i.e. no protocol change required
551 2014-02-10 12:06:22 <gwb3> their brand certainly tarnished to a degree
552 2014-02-10 12:06:34 <gmaxwell> sipa: well kind of a 4th too, did you see my point about inputs? gox wouldn't have been saved from 'potential' losses by just the elimination of mallibility because they respent without doublespending.
553 2014-02-10 12:06:54 <maaku> money: that statement was factually incorrect as we have described to you above. please read the scrollback
554 2014-02-10 12:06:58 <gwb3> this press release is basically saying, "hey, it's not us, it's bitcoin - good thing we picked up on this, others could be affected"
555 2014-02-10 12:07:04 <money> He also states that users can say they didn't get a tx, by manipulating the bitcoinchain thing. he says that anyone can do it right now, and claim that they didn't get a pay.
556 2014-02-10 12:07:21 <money> ok maaku , I just copy pasted from his site
557 2014-02-10 12:07:32 <money> https://www.mtgox.com/press_release_20140210.html
558 2014-02-10 12:07:44 <Hawkix> can someone SCAN the blockchain to detect all mutated transactions and post stats about the misuse?
559 2014-02-10 12:07:52 <maaku> Hawkix: no
560 2014-02-10 12:07:57 <wallet42> you cannot FIX the "doublespending" problem by respending
561 2014-02-10 12:07:58 <Ademan> Hawkix: not from the blockchain alone
562 2014-02-10 12:08:00 <maaku> because only one of the transactions made it on the chain
563 2014-02-10 12:08:02 <Apocalyptic> Hawkix, that would be their job
564 2014-02-10 12:08:15 <gwb3> exchanges are integral to the sustainability of bitcoin, also confidence in exchanges are integral to continued adoption by merchants and other retailers
565 2014-02-10 12:08:28 <Hawkix> I thought that to change transaction id, one must add some padding to the script, right?
566 2014-02-10 12:08:35 <Ademan> Hawkix: I suppose you could try to listen to all transactions on the network, and see if any mutants of transactions you've seen make it into the blockchain
567 2014-02-10 12:08:35 <gwb3> more retailers are adopting bitcoin each day
568 2014-02-10 12:08:41 <maaku> Hawkix: but if by "someone" you mean mtgox, then yes, they have the necessary info to do that
569 2014-02-10 12:08:44 <wallet42> Hawikix: https://en.bitcoin.it/wiki/Transaction_Malleability
570 2014-02-10 12:09:01 <maaku> or they should if they kept logs of their transactions
571 2014-02-10 12:09:06 <Ademan> Hawkix: Both mutant and original transaction are valid, it's not really possible to tell which is the "original"
572 2014-02-10 12:09:21 <Apocalyptic> (this is clearly off-topic here=
573 2014-02-10 12:09:33 <gwb3> does anyone in here know someone in the community who i can reach out to about marketing strategy coming off this press release?
574 2014-02-10 12:10:02 <gwb3> honestly if other exchanges start coming out against what mt. gox just said i think it will help
575 2014-02-10 12:10:05 <Ademan> Apocalyptic: the nature of the blockchain and protocol are offtopic here?
576 2014-02-10 12:10:15 <Apocalyptic> Ademan, nope, the talk about gox
577 2014-02-10 12:10:22 <money> So what mtgox said is wrong? then? --> this cannot happen: In the meantime, exchanges and wallet services - and any service sending coins directly to third parties - should be extremely careful with anyone claiming their transaction did not go through.
578 2014-02-10 12:10:28 <Ademan> Apocalyptic: ah, sorry
579 2014-02-10 12:10:30 <randy-waterhouse> gwb3: most retailers are using BitPay ... talk to them?
580 2014-02-10 12:10:50 <gwb3> randy-waterhouse: ok
581 2014-02-10 12:11:10 <maaku> money: that part is correct. services should not be checking if transactiosn went through by txid
582 2014-02-10 12:11:30 <Apocalyptic> ^
583 2014-02-10 12:11:36 <money> I see.
584 2014-02-10 12:11:39 <Plarkplark> maaku: cant they just check the receiving address, and wait for 3 or 6 confirms?
585 2014-02-10 12:12:09 <maaku> no, because anybody could send coins to the receiving address
586 2014-02-10 12:12:15 <Apocalyptic> Plarkplark, it's a bit more complicated than that, the guy can claim he's expecting another tx with the same amount
587 2014-02-10 12:12:27 <Apocalyptic> you have to watch for specific inputs there
588 2014-02-10 12:12:33 <Apocalyptic> which can be done
589 2014-02-10 12:12:35 <Plarkplark> Ah. There we go. thanks
590 2014-02-10 12:12:54 <Plarkplark> How do other exchanges handle that?
591 2014-02-10 12:12:56 <maaku> but they can extract the essential skeleton of the transactions (inputs minus the script sigs + outputs) and watch for that
592 2014-02-10 12:12:59 <Plarkplark> Or is that too complicated?
593 2014-02-10 12:13:35 <Plarkplark> if you pull apart he receiving address and check if the balance created contains your inputs, you are ok, right?
594 2014-02-10 12:13:46 <Plarkplark> (if it is confirmed of course)
595 2014-02-10 12:14:22 <money> so what's the way to comfirm that the tx went through ok then?
596 2014-02-10 12:14:48 <Ademan> money: if there's a transaction in the block chain which has the inputs and outputs expected
597 2014-02-10 12:14:54 <randy-waterhouse> I think a lot of folks have lost sight of the fact that bitcoin is a much better settlement/clearing system than it is a payment system
598 2014-02-10 12:15:07 <randy-waterhouse> a la jgarzik
599 2014-02-10 12:15:20 <money> ok
600 2014-02-10 12:15:42 <money> and a software and check for that easy? or does it neeed manual intervention?
601 2014-02-10 12:16:05 <Plarkplark> so Gox was not doing things best-practice. and they got hurt.
602 2014-02-10 12:16:22 <Ademan> randy-waterhouse: I think the distinction is lost on me, then again it's really late/early... what do you mean?
603 2014-02-10 12:16:39 <money> but it's annoying to see them blaming others for their stuff. and confusing too.
604 2014-02-10 12:17:03 <Ademan> money: Software to check the blockchain for your transaction is easy enough.
605 2014-02-10 12:17:16 <money> ok