1 2013-10-30 00:01:56 <aupiff> sipa: yep that worked. thanks. how does bitcoind get around that dependency, exactly?
2 2013-10-30 00:02:14 <sipa> hmm?
3 2013-10-30 00:02:22 <sipa> release binaries always use 4.8
4 2013-10-30 00:02:48 <sipa> asnusing a different bdb means your wallet files become incompatible
5 2013-10-30 00:03:12 <aupiff> sipa: ah, that makes sense.
6 2013-10-30 00:08:42 <warren> petertodd: omg, how did you send me 18k dust!?
7 2013-10-30 00:12:58 <phantomcircuit> 00:08:59
8 2013-10-30 00:13:01 <phantomcircuit> 00:06:56
9 2013-10-30 00:13:11 <phantomcircuit> interesting
10 2013-10-30 00:16:52 <warren> petertodd: I'm forced to abandon this wallet, it takes like 30 minutes to send a tx
11 2013-10-30 00:21:39 <phantomcircuit> warren, just pull the private keys that dont have spam associated with them out
12 2013-10-30 00:24:59 <warren> phantomcircuit: he sent all spam =)
13 2013-10-30 00:48:17 <BlueMatt> hmm...does anyone remember if leveldb is impossibly slow in wine or if its on native windows too?
14 2013-10-30 00:48:24 <BlueMatt> ACTION seems to recall there being some strange wine interaction here
15 2013-10-30 00:49:02 <BlueMatt> or...does someone wanna run the new BitcoindComparisonTool again bitcoin on native windows for me to test?
16 2013-10-30 01:49:36 <warren> well... my fault, found some kind of conflict between coin control and watchonlly
17 2013-10-30 01:56:47 <Luke-Jr> http://news.yahoo.com/norwegian-man-buys-flat-forgotten-24-bitcoin-investment-174651722.html
18 2013-10-30 02:57:08 <tunage> I am looking to get into bitcoin dev, I have background in ASM. where is a good place to look for aspects to consider when selecting microcontrollers and application design techniques? anything like that around?
19 2013-10-30 02:58:20 <maaku> tunage: maybe you'd be interested in the various hardware wallet projects?
20 2013-10-30 02:59:22 <Luke-Jr> dunno, asm isn't usually a good idea for much of anything anymore
21 2013-10-30 02:59:26 <tunage> maaku hardware wallet? is that acis?
22 2013-10-30 02:59:43 <Luke-Jr> I'd certainly be writing hardware wallet stuff in C
23 2013-10-30 02:59:54 <Luke-Jr> considering what's at stake
24 2013-10-30 02:59:59 <Luke-Jr> tunage: which asm do you know?
25 2013-10-30 03:00:31 <tunage> Luke-Jr I can spin it off the register faster that anyone I know. :) there is a lot more to it than that I am sure though.
26 2013-10-30 03:00:44 <tunage> Luke-Jr nasm and masm
27 2013-10-30 03:00:47 <Luke-Jr> tunage: spin what off the register?
28 2013-10-30 03:00:57 <Luke-Jr> tunage: I don't mean syntax, I mean architecture
29 2013-10-30 03:01:07 <Luke-Jr> MIPS or ARM?
30 2013-10-30 03:01:40 <tunage> Luke-Jr I am used to the x86 but have tinkered with a couple of Pics too.
31 2013-10-30 03:02:26 <Luke-Jr> ACTION can't see much use of x86 asm at this point
32 2013-10-30 03:02:32 <Luke-Jr> maybe sipa's libsecpthing
33 2013-10-30 03:02:39 <Luke-Jr> you could review and audit it..
34 2013-10-30 03:03:00 <Luke-Jr> https://github.com/sipa/secp256k1
35 2013-10-30 03:03:35 <tunage> Luke-Jr I am going to have to learn a whole new architecture, I am sure of this. This is why I am trying to get started in the right direction.
36 2013-10-30 03:04:07 <Luke-Jr> tunage: really, assembly has little use in most things today :/
37 2013-10-30 03:04:11 <tunage> I am maturing from calculators. :)
38 2013-10-30 03:04:32 <Luke-Jr> secp256k1 is the only thing I can think of that would benefit from assembly, and sipa already wrote it (but again, more eyes are needed to review it!)
39 2013-10-30 03:04:35 <tunage> I know c++ but asm is for speed.
40 2013-10-30 03:04:58 <Luke-Jr> tunage: usually code readability is far far more important than microoptimisation
41 2013-10-30 03:05:01 <tunage> once you understand exactly what you are working with. :/
42 2013-10-30 03:05:37 <Luke-Jr> sipa's secp256k1 seems to work well, but we're not using it yet due to lack of peer review
43 2013-10-30 03:05:50 <Luke-Jr> since it's such an important part of the protocol, it has to be 100% perfect
44 2013-10-30 03:06:09 <Luke-Jr> so I think if you can look over it and make sure it's correct, that would be very helpful
45 2013-10-30 03:06:51 <tunage> all pure C I have worked with C.
46 2013-10-30 03:07:17 <Luke-Jr> sipa's secp256k1 is mainly asm ;)
47 2013-10-30 03:07:46 <tunage> Luke-Jr I have worked with the IP stack some in C++, I have an idea of what to expect there.
48 2013-10-30 03:08:23 <Luke-Jr> tunage: Bitcoin isn't like any other software before; unless you've worked with *Bitcoin*, you don't know what to expect until you do
49 2013-10-30 03:09:17 <tunage> Luke-Jr I know, I am getting ready to buckle down. The concept is very attractive.
50 2013-10-30 03:09:21 <Luke-Jr> I need to rephrase what I stated earlier
51 2013-10-30 03:09:31 <Luke-Jr> it's not 100% perfection that Bitcoin needs in this code
52 2013-10-30 03:09:43 <Luke-Jr> it's 100% identical results as the current OpenSSL behaviour
53 2013-10-30 03:09:47 <Luke-Jr> bug-for-bug
54 2013-10-30 03:09:54 <tunage> what architecture is secp256k1 optimize/ported for?
55 2013-10-30 03:09:57 <Apocalyptic> hum
56 2013-10-30 03:10:02 <Luke-Jr> tunage: mainly x86_64
57 2013-10-30 03:10:12 <Luke-Jr> there is also assembly for x86_32, but it isn't optimised right now
58 2013-10-30 03:10:55 <tunage> very interesting
59 2013-10-30 03:21:17 <tunage> Luke-Jr is there a known lag between algorithm calculation and transmission to the IP stack? or is all of the 'burn' in the math?
60 2013-10-30 03:22:25 <tunage> and is elliptic curve the fastest or just the most stable at this time?
61 2013-10-30 03:24:18 <maaku> tunage? elliptic curve the algorithm, not the implementation
62 2013-10-30 03:25:13 <tunage> maaku yes. it's the meat and potatoes
63 2013-10-30 03:26:41 <maaku> do you mean why was ecdsa chosen in 2009? because it has small keys and efficient validation
64 2013-10-30 03:26:59 <tunage> but microcontroller doesn't have a lot of room for bs, curious if software such as watchdogs are known process killers, etc.
65 2013-10-30 03:27:02 <maaku> but it's a moot point now - bitcoin uses ecdsa. you can't change that without breaking compatability
66 2013-10-30 03:27:39 <maaku> ok, so you need something beefier to do validation
67 2013-10-30 03:27:58 <tunage> maaku oh, that's right, or you would break the math... didn't think about that.
68 2013-10-30 03:31:00 <Luke-Jr> maaku: there is a faster EC curve than we use though
69 2013-10-30 03:31:32 <maaku> Luke-Jr: in 2009?
70 2013-10-30 03:31:43 <Luke-Jr> maaku: AFAIK none of this stuff is created, just discovered ;)
71 2013-10-30 03:32:21 <maaku> heh, true
72 2013-10-30 03:33:09 <Luke-Jr> looks like it was discovered in 2007
73 2013-10-30 03:34:05 <tunage> so your chip frequency is literally the determaining factor for calculation that algorithm. You're basically bouncing the results of the ASM function into the IP stack? in a nutshell?
74 2013-10-30 03:34:44 <Luke-Jr> â¦
75 2013-10-30 03:34:55 <Luke-Jr> tunage: IP isn't part of Bitcoin, beyond a mere transport
76 2013-10-30 03:35:26 <Luke-Jr> I'd say there's about zero chance of anyone accepting asm in the IP code
77 2013-10-30 03:36:58 <tunage> Luke-Jr layer 2/1 it comes in handy.
78 2013-10-30 03:37:28 <Luke-Jr> nothing in Bitcoin cares about that layer
79 2013-10-30 03:39:08 <maaku> tunage: I suggest reading the bitcoin source tree, and seeing what interests you.
80 2013-10-30 03:40:35 <tunage> is it a protocol or a socket connection bitcoin uses to transport the results?
81 2013-10-30 03:43:25 <Luke-Jr> ⦠both
82 2013-10-30 03:43:43 <tunage> what kind of an API does bitcoin have?
83 2013-10-30 03:44:04 <Luke-Jr> none, bitcoin is a protocol, not software
84 2013-10-30 03:44:13 <Luke-Jr> bitcoin*d* has a JSON-RPC interface
85 2013-10-30 03:44:23 <Luke-Jr> other node software might have other interfaces
86 2013-10-30 03:47:14 <tunage> Luke-Jr I'm confused how the results authenticate and deliver to the block chain?
87 2013-10-30 03:47:38 <Luke-Jr> tunage: results of what?
88 2013-10-30 03:47:46 <Luke-Jr> tunage: every node validates the results itself
89 2013-10-30 03:47:55 <Luke-Jr> the blockchain is abstract
90 2013-10-30 03:47:55 <tunage> https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm
91 2013-10-30 03:48:31 <Luke-Jr> tunage: every node implementing the bitcoin protocol validates every ECDSA signature
92 2013-10-30 03:56:09 <tunage> bitcoin has qt? qt graphics?
93 2013-10-30 03:59:52 <tunage> is the /qt /dir where bitcoin manages the block chain?
94 2013-10-30 05:16:50 <Temper> what is the best way to programmically interface with the bitcoin network?
95 2013-10-30 05:28:24 <Temper> anyone here program c#
96 2013-10-30 05:28:46 <Temper> i am trying to make a program that can send or recieve bitcoin with multiple wallets.. any hints?
97 2013-10-30 05:32:09 <warren> sipa: https://bitcointalk.org/index.php?topic=320695.0 I removed Watch Only for now. Despite my adjustment to AvailableCoins() something else went haywire in coin selection when combined with Coin Control. I'll look at it again later.
98 2013-10-30 05:32:41 <warren> petertodd: you may want to upgrade your EC2 bitcoind to this new build. It still has disablewallet.
99 2013-10-30 05:34:21 <Temper> does anyone know: how often does the bitcoin network change code?
100 2013-10-30 05:34:38 <warren> Temper: that is not a simple question
101 2013-10-30 05:34:53 <Temper> hahah with bitcoin nothing EVER IS!
102 2013-10-30 05:34:54 <Temper> lol
103 2013-10-30 05:35:43 <Temper> let me try putting it this way. If i ran the bitcoind on my computer, never shutdown the program, updateded it etc, how long would it effectively run on the network?
104 2013-10-30 05:36:03 <pigeons> we don't know
105 2013-10-30 05:36:13 <Temper> lol
106 2013-10-30 05:36:28 <Temper> ok.. lets say a week later they make a change to the bitcoind code
107 2013-10-30 05:36:39 <Temper> does that mean my client is bumped off?
108 2013-10-30 05:37:25 <pigeons> depends on the kind of change, it is possible for a certain kind of change to cause everyone who updates to it to start following a different fork than your old node
109 2013-10-30 05:38:00 <Temper> so the network basically diverges?
110 2013-10-30 05:38:25 <pigeons> these things are rare, and coordinated and planned and announced in advance if possible
111 2013-10-30 05:38:40 <Temper> ok.. so how many have there been in the last year?
112 2013-10-30 05:38:46 <Temper> [ballpark]
113 2013-10-30 05:38:54 <Temper> 1,2,10,100?
114 2013-10-30 05:39:12 <pigeons> well even with those, its not easy to tell if your old node would be affected or not
115 2013-10-30 05:39:20 <Temper> lol..
116 2013-10-30 05:39:41 <Temper> does bitcoind support apis with multiple wallets?
117 2013-10-30 05:40:53 <Temper> maybe i should try this..
118 2013-10-30 05:41:03 <Temper> I was looking at implementing a website with https://code.google.com/p/bitcoinj/
119 2013-10-30 05:41:30 <Temper> but then I read: Be warned: This software is at an early development stage. You still need to patch it to achieve many use cases and you must have a good understanding of the Bitcoin protocol. If you lose money you have only yourself to blame!
120 2013-10-30 05:41:46 <Temper> i understand they don't want liability
121 2013-10-30 05:42:07 <Temper> but is this saying that the project is not ready for production?
122 2013-10-30 05:42:20 <Temper> or is that just standard disclaimer stuff
123 2013-10-30 05:43:51 <Temper> i guess what i am saying is interfacing with the bitcoind the way to go?
124 2013-10-30 05:44:18 <Temper> is there a tip jar i am supposed to tip for answers :)
125 2013-10-30 06:31:49 <petertodd> warren: python-bitcoinlib is my favorite tool for mischief :)
126 2013-10-30 06:32:56 <warren> petertodd: i'm missing context
127 2013-10-30 06:33:08 <warren> petertodd: did you break bitcoin-ruby again?
128 2013-10-30 06:33:12 <petertodd> warren: dust
129 2013-10-30 06:33:18 <warren> oh
130 2013-10-30 06:33:23 <petertodd> warren: when did it break?
131 2013-10-30 06:33:29 <warren> didn't
132 2013-10-30 06:33:51 <petertodd> warren: I spent half an hour a week or so ago auditing it and found something like three or four forking bugs :/
133 2013-10-30 06:34:06 <warren> petertodd: the super slow wallet helped expose a serious problem when coin control and watchonly were combined, I don't know what's going on. had to remove watchonly for now.
134 2013-10-30 06:34:30 <warren> petertodd: please upgrade your EC2 node to OMG2
135 2013-10-30 06:34:41 <petertodd> heh, you know, this dust business is probably a possible DoS attack against p2pool too...
136 2013-10-30 06:34:52 <warren> how so?
137 2013-10-30 06:35:12 <petertodd> my bitcoin node crashed when the dust-containning block got mined
138 2013-10-30 06:35:49 <warren> isn't that concerning for the entire network?
139 2013-10-30 06:36:04 <petertodd> yes
140 2013-10-30 06:36:32 <petertodd> though it's only something that happens if it's your wallet that is being updated, not in general
141 2013-10-30 09:14:07 <warren> petertodd: you know, litecoin's mininput patch would make me immune to your spam attack
142 2013-10-30 09:14:22 <petertodd> warren: yup
143 2013-10-30 09:14:59 <petertodd> mininput isn't a bad idea IMO, although people worry about the UTXO bloating of it, on the other hand, it discourages a lot of behavior too
144 2013-10-30 09:15:41 <warren> mininput + dust expiration would work quite nicely, especially with your MMR resurrection thing
145 2013-10-30 09:16:25 <petertodd> note though, it doesn't discourage dust de-anonymization attacks much, as the attacker wants you to spend the dust, so they'll send profitable to spend dust
146 2013-10-30 09:16:34 <petertodd> yup
147 2013-10-30 09:16:46 <melvster> can a previous block have a later timestamp than a next block?
148 2013-10-30 09:16:53 <petertodd> melvster: yes
149 2013-10-30 09:16:58 <melvster> O_o
150 2013-10-30 09:17:04 <stonecoldpat> +how?
151 2013-10-30 09:17:23 <petertodd> melvster: if that wasn't possible, then everyone woul dhave to have the exact same notion of time as everyone else, which is infeasible
152 2013-10-30 09:17:34 <melvster> but look at this
153 2013-10-30 09:17:35 <melvster> http://blockexplorer.com/block/0000000000000004ad57e9f06642286946c23e5f5b031767dc567c37917437bc
154 2013-10-30 09:17:44 <melvster> 2013-10-26 18:33:07
155 2013-10-30 09:17:47 <melvster> previous block
156 2013-10-30 09:17:48 <petertodd> melvster: timestamps are only needed to scale PoW difficulty after all, they do *not* need to be very accurate at all
157 2013-10-30 09:17:56 <melvster> 2013-10-26 18:34:22
158 2013-10-30 09:18:03 <melvster> that's 85 seconds
159 2013-10-30 09:18:46 <petertodd> melvster: as I said, you don't need accurate timestamps, therefore it's good engineering to place no strict demands on them
160 2013-10-30 09:18:51 <melvster> so how much can they vary?
161 2013-10-30 09:19:02 <warren> sipa: when you're around I can explain the trouble I had with coin control + watchonly.
162 2013-10-30 09:19:06 <warren> They work fine independently.
163 2013-10-30 09:19:13 <melvster> in practice
164 2013-10-30 09:19:22 <melvster> can they be like hours apart?
165 2013-10-30 09:19:25 <petertodd> melvster: a block is considered valid if the timestamp is no more than two hours in the future, and no earlier than the median of the last 11 blocks. (IIRC)
166 2013-10-30 09:19:35 <melvster> wow thanks
167 2013-10-30 09:20:00 <melvster> so like a 4 hour range wow
168 2013-10-30 09:20:08 <petertodd> as say, if you placed tighter demands on it you'd get failures when people didn't set their clocks right, and that's very bad
169 2013-10-30 09:20:12 <petertodd> melvster: roughly yeah
170 2013-10-30 09:20:29 <melvster> i better start indexing height
171 2013-10-30 09:20:41 <melvster> thanks
172 2013-10-30 09:20:44 <petertodd> np
173 2013-10-30 09:24:22 <warren> https://bitcointalk.org/index.php?topic=320695.msg3436889#msg3436889 <--- something early in 0.9 re-broke this, and a later patch in master fixed it, although I don't know which one.
174 2013-10-30 09:25:18 <warren> and I have no mac so I can't test it easily
175 2013-10-30 09:27:19 <petertodd> I have no GUI so I can't test it easily :P
176 2013-10-30 09:28:13 <warren> I hope I'm not unduly annoying people with this branch.
177 2013-10-30 09:28:42 <warren> I already did a ton of work to test a hybrid of 0.8 and 0.9, so might as well push it out there to expose people to more bugs.
178 2013-10-30 09:28:51 <petertodd> pff, sounds like you've already found some interesting bugs that needed finding
179 2013-10-30 09:29:14 <warren> The watchonly + coincontrol issue is weird...
180 2013-10-30 09:29:38 <warren> https://github.com/litecoin-project/bitcoinomg/commits/bitcoin-omg-0.8
181 2013-10-30 09:30:29 <warren> https://github.com/litecoin-project/bitcoinomg/commit/8ebd9b64a8974d2fbc47fffdef5dbd72d3860a37 Here's the simplest glue I could think of to filter out the watchonly outputs from coincontroldialog selection. The CC display showed an expected tx size and fee, everything looks correct when you click Send.
182 2013-10-30 09:30:47 <warren> then it crunches the CPU forever, and eventually claims the Transation is too large.
183 2013-10-30 09:31:07 <warren> a ~9990 byte transaction according to CC
184 2013-10-30 09:31:40 <warren> sending a transaction without CC selection similarly screws up
185 2013-10-30 09:32:23 <warren> a 2000 byte transaction wanted a fee that was several times bigger than what CC expected
186 2013-10-30 09:34:15 <petertodd> huh, wonder how many O(n^ugly) algorithms are at play there
187 2013-10-30 09:34:54 <warren> petertodd: it's more like O(ugly^n)
188 2013-10-30 09:35:34 <petertodd> lol
189 2013-10-30 09:36:01 <warren> ceteris paribus, CC works quite well, just slow as heck
190 2013-10-30 09:37:20 <warren> petertodd: your 18k spam made CC crunch for 30 minutes
191 2013-10-30 09:37:27 <petertodd> lol
192 2013-10-30 09:38:16 <petertodd> this is why for opentimestamps my coin selection code was "pick n inputs, lowest first" followed by "if that fails, pick highest first until done"
193 2013-10-30 09:38:34 <petertodd> not exactly optimal though...
194 2013-10-30 09:39:46 <warren> 1) make it work 2) <foo> 3) optimize it
195 2013-10-30 09:39:52 <warren> <foo> = mininput patch
196 2013-10-30 09:40:30 <petertodd> well, ideally mininput shouldn't be needed
197 2013-10-30 09:40:57 <warren> mininput was an expedient way to bring a network back from death
198 2013-10-30 09:41:42 <warren> petertodd: they were dealing with milllions of satoshi spam, not 18k
199 2013-10-30 09:42:35 <petertodd> wallet software should be able to deal with millions of utxo spam as well. The only limiting factor should be disk space on the wallet.
200 2013-10-30 09:43:46 <warren> yep ... just confirmed watchonly on its own works just fine
201 2013-10-30 09:44:06 <warren> CC, with CC dialog selection disabled fucks up with watchonly
202 2013-10-30 09:45:34 <warren> it messes up even with zero watchonly addresses
203 2013-10-30 09:48:20 <HaltingState> I worked out a 2 factor wallet proticol that allows 3rd party to hold wallet and prevents your bitcoin from being stolen either by the third party or by adversary, even if computer you are running on is compromised (rootkit/trojan) etc
204 2013-10-30 09:48:54 <HaltingState> i am writing library now for ECC that will work on arduino duo;anyone know of a C/C++ repo for that or should I just gut opensll?
205 2013-10-30 09:49:21 <warren> err, you probably want a simpler library
206 2013-10-30 09:49:33 <warren> libsecp256k1
207 2013-10-30 09:49:39 <HaltingState> the python ECC implementation is really nice, but its not C
208 2013-10-30 09:49:55 <warren> libsecp256k1 is C
209 2013-10-30 09:50:36 <HaltingState> https://github.com/sipa/secp256k1
210 2013-10-30 09:50:39 <HaltingState> this one?
211 2013-10-30 09:50:44 <warren> yeah
212 2013-10-30 09:50:56 <warren> it seems to work, although we're too afraid to use it in production
213 2013-10-30 09:51:19 <HaltingState> ecc is tricky, expecially signatures, seem to leak keys
214 2013-10-30 09:51:48 <HaltingState> openssl is not perfect either, expecially for people with older versions on system
215 2013-10-30 09:52:30 <HaltingState> i will look at gutting openssl ecc and if its not too much work, might be worth doing
216 2013-10-30 09:52:57 <HaltingState> it removes the openssl dependency and its "safe"
217 2013-10-30 09:53:34 <warren> I've gutted openssl before
218 2013-10-30 09:54:13 <HaltingState> how was it?
219 2013-10-30 09:54:52 <HaltingState> are you worried about the openssl dependency at all and bugs (etc random number generator in older version etc, may leak keys when signing with ecc etc?)
220 2013-10-30 09:56:36 <warren> worried about abandonware
221 2013-10-30 09:56:49 <warren> libsecp256k1 will eventually be the in-bitcoin EC library
222 2013-10-30 09:59:14 <stonecoldpat> im guessing the only information needed for a new block is the merkle tree root, previous tx? and they just need to discover the nounce?
223 2013-10-30 10:01:59 <HaltingState> warren, canonical encodings ^_^ finally; really did not like that you could take signature and create another valid signature
224 2013-10-30 10:04:20 <HaltingState> one of the brilliant things about bitcoin is that the pubkeys are not published until first transaction for address, so even if ECC is broken, if you dont reuse addresses it does not matter
225 2013-10-30 10:05:24 <HaltingState> satoshi managed to find trade off between hashes and crypto signatures that resists complete failure of the crypto
226 2013-10-30 10:24:08 <melvster> stonecoldplat: you need timestamp and difficulty as well
227 2013-10-30 10:25:09 <TD> good morning
228 2013-10-30 10:40:01 <HaltingState> warren, does field implementation matter?
229 2013-10-30 10:40:16 <HaltingState> 10x26, vs 5x52 vs 5x64?
230 2013-10-30 11:11:40 <JyZyXEL> how are people able to put messages into transactions?
231 2013-10-30 11:12:39 <pigeons> JyZyXEL: do you have an example
232 2013-10-30 11:12:50 <JyZyXEL> yeah, the FBI address
233 2013-10-30 11:12:56 <JyZyXEL> its full of ads
234 2013-10-30 11:13:36 <pigeons> i think you're thinking of the messages that the site blockchain.info uses, they aren't a part of the bitcoin protocol, just exist in the website's database
235 2013-10-30 11:13:44 <sipa> Luke-Jr: huh? libsecp256k1 only has assembly for x86_64
236 2013-10-30 11:13:56 <sipa> Luke-Jr: and it's only a very small part that is asm
237 2013-10-30 11:14:49 <sipa> pigeons: indeed
238 2013-10-30 11:16:42 <JyZyXEL> oh, i guess they let you leave a public message if you can prove you own the transaction
239 2013-10-30 11:27:35 <melvster> are we sure this formula is correct? https://en.bitcoin.it/wiki/Difficulty
240 2013-10-30 11:27:45 <melvster> in particular 2**(8*(0x1b - 3))
241 2013-10-30 11:27:55 <melvster> i keep being out by a factor of 8
242 2013-10-30 11:28:40 <melvster> oh no, im out by a factor of 2
243 2013-10-30 11:28:43 <melvster> grr
244 2013-10-30 11:30:15 <melvster> the closest I can find using this calculation is
245 2013-10-30 11:30:16 <melvster> Computed hash OK
246 2013-10-30 11:30:17 <melvster> 000000000000000a25c350f265534b54eda3d09bfc9efd305193266a3fcf3498
247 2013-10-30 11:30:17 <melvster> 00000000000000190afc00000000000000000000000000000000000000000000
248 2013-10-30 11:30:17 <melvster> Checking Target is Bigger than computed hash OK
249 2013-10-30 11:30:29 <melvster> always half the target at most
250 2013-10-30 11:31:58 <melvster> unless its related to *double* hashes
251 2013-10-30 11:32:05 <melvster> so maybe i should half the target
252 2013-10-30 11:32:17 <melvster> that must be it ...
253 2013-10-30 11:33:56 <melvster> ah ha! http://blockexplorer.com/q/hextarget
254 2013-10-30 11:34:17 <melvster> yes that's half my value
255 2013-10-30 11:34:31 <sipa> melvster: hashes always refers to double-sha256
256 2013-10-30 11:34:37 <melvster> hmmm
257 2013-10-30 11:34:47 <sipa> bitcoin never uses individual sha256 operations inside the consensus mechanism
258 2013-10-30 11:35:31 <melvster> sipa: the wiki page must be wrong then
259 2013-10-30 11:35:44 <melvster> because the current nbits is : 190afc85 [85fc0a19]
260 2013-10-30 11:36:03 <melvster> and 19 is 25 in decimal
261 2013-10-30 11:36:41 <melvster> 25 - 3 = 22
262 2013-10-30 11:36:46 <sipa> so 0xfc0a19 * 256^(0x19 - 0x1b)
263 2013-10-30 11:36:58 <sipa> eh
264 2013-10-30 11:37:01 <sipa> so 0xfc0a19 * 256^(0x19 - 3)
265 2013-10-30 11:37:37 <melvster> which is 16^44
266 2013-10-30 11:37:41 <melvster> ie 44 0's
267 2013-10-30 11:37:50 <sipa> yes
268 2013-10-30 11:37:57 <melvster> oh wait
269 2013-10-30 11:38:07 <melvster> ahhh
270 2013-10-30 11:38:11 <melvster> i see my mistake
271 2013-10-30 11:38:36 <melvster> wrong substr
272 2013-10-30 11:39:17 <melvster> im getting used this this littlendian bigendian coverstions
273 2013-10-30 11:39:30 <melvster> perfect
274 2013-10-30 11:39:31 <melvster> 000000000000000a25c350f265534b54eda3d09bfc9efd305193266a3fcf3498
275 2013-10-30 11:39:31 <melvster> 000000000000000afc8500000000000000000000000000000000000000000000
276 2013-10-30 11:39:31 <melvster> Checking Target is Bigger than computed hash OK
277 2013-10-30 11:39:31 <melvster> Computed hash OK
278 2013-10-30 11:40:49 <arioBarzan> http://blockexplorer.com/q/hextarget
279 2013-10-30 11:41:28 <melvster> got it thanks
280 2013-10-30 11:53:08 <melvster> what exactly is the 'coinbase' in : http://blockexplorer.com/rawtx/01c2981233a6ca5de0abfcb0895e5631900cc4377fb90930ac7abd4cdd350918
281 2013-10-30 11:53:36 <melvster> the transaction and coinbase wiki pages are a bit confusing
282 2013-10-30 11:53:55 <melvster> coinbase is what generates new coins? but can be arbitrary?
283 2013-10-30 11:58:54 <kinlo> coinbase used to be arbitrary data, to be used as a second nonce
284 2013-10-30 11:59:19 <melvster> oic
285 2013-10-30 11:59:30 <melvster> kinlo: and now?
286 2013-10-30 11:59:36 <melvster> why would you want a second nonce?
287 2013-10-30 11:59:37 <kinlo> but since version 2, there is a mandatory field containing the block height
288 2013-10-30 11:59:59 <kinlo> so it becomes impossible to have 2 transactions with the same transaction id
289 2013-10-30 12:00:46 <melvster> kinlo: why is it bad to have two tx with the same id?
290 2013-10-30 12:00:59 <kinlo> coz transactions are uniquely identified by their id
291 2013-10-30 12:01:26 <melvster> but i mean why is it bad to have the same unique tx in two blocks?
292 2013-10-30 12:01:40 <melvster> eg i could pay someone 1 bit now and 1 tomorrow
293 2013-10-30 12:01:46 <melvster> does it cause a problem?
294 2013-10-30 12:04:20 <kinlo> yes, the bitcoin client assumes they are unique
295 2013-10-30 12:04:44 <kinlo> I'm not entirely sure, but I believe one transaction becomes unspendeable, so you're basicly losing the coins in it
296 2013-10-30 12:05:30 <kinlo> this is a corner case, which is basicly never foreseen and therefore you must look at "how does the reference implementation do it"
297 2013-10-30 12:05:52 <kinlo> the specs assume these tx id's are always unique
298 2013-10-30 12:07:30 <melvster> ah ok thx
299 2013-10-30 12:07:54 <melvster> kinlo: so today what is the coinbase? is it always the same or random?
300 2013-10-30 12:10:32 <kinlo> it's first the block height, then "data"
301 2013-10-30 12:10:40 <kinlo> the data is basicly the extranonce
302 2013-10-30 12:11:27 <kinlo> which is required to find the solution to the block - so it is not just "random", the pools make sure it contains different data for each miner so they don't do the same work
303 2013-10-30 12:11:50 <kinlo> and since there is a lot of room in extra nonce, pools do put some other data in it too
304 2013-10-30 12:12:07 <kinlo> sometimes a signature or a comment
305 2013-10-30 12:12:52 <kinlo> but the coinbase is also "abused" for merged mining, where an altcoin uses the same hashing power as bitcoin
306 2013-10-30 12:14:39 <melvster> ahhhh
307 2013-10-30 12:14:39 <melvster> thx
308 2013-10-30 12:18:05 <sipa> melvster: the coinbase either refers to the first transaction in a block (the one that creates outputs without real inputs), or to the scriptSig inside that transaction
309 2013-10-30 12:18:21 <melvster> thx
310 2013-10-30 12:18:35 <sipa> the data in the coinbase transaction's scriptSig is almost random, as it's not used to input things from anywhere
311 2013-10-30 12:18:50 <sipa> it's required to be between 2 and 100 bytes, and must start with a push of the block's height
312 2013-10-30 12:19:14 <sipa> also, identical transactions refers to bitwise identical transactions; not just transactions with the same effect
313 2013-10-30 12:54:47 <radiator> hi
314 2013-10-30 12:55:30 <radiator> guys - Im wondering, to get the current balance of a BTC address, its necessary to parse all the previous transactions to that addressâ¦. right???
315 2013-10-30 12:58:31 <lianj> address balance == sum( all unspent outputs to that address )
316 2013-10-30 12:59:08 <shesek> radiator, its necessary to check all the transaction to that address, and all the transactions from that address (to check how much of the incoming transactions was already spent)
317 2013-10-30 13:03:10 <sipa> depending on what data source
318 2013-10-30 13:03:30 <sipa> if you're starting from the UTXO set, it suffices to just count all coins assigned to that address
319 2013-10-30 13:03:57 <sipa> if you're starting from the blockchain, you need to find all transactions crediting the address, and all transactions consuming one of the coins credited to it before
320 2013-10-30 13:11:22 <radiator> alright guys, thanks for answering that :D
321 2013-10-30 14:44:14 <BlueMatt> TD: ping
322 2013-10-30 14:44:28 <TD> hi
323 2013-10-30 14:44:58 <Evilmax> ;;blocks
324 2013-10-30 14:44:59 <gribble> 266900
325 2013-10-30 14:45:10 <BlueMatt> TD: how many changes did you make to my nonetty branch before you squashed it+rebased it?
326 2013-10-30 14:45:23 <BlueMatt> ACTION has made a few changes since while working through dnsseed stuff
327 2013-10-30 14:46:46 <TD> none, iirc
328 2013-10-30 14:47:13 <BlueMatt> ok, so if I rebase mine and then lose your commit no work should be lost?
329 2013-10-30 14:48:33 <TD> right. i only squashed+rebased for review purposes
330 2013-10-30 15:13:44 <BlueMatt> TD: can you pick the top 2 commits from my master branch?
331 2013-10-30 15:21:15 <TD> huh. it appears the JVM learned how to spot circular deadlocks at some point
332 2013-10-30 15:21:18 <TD> even without guava's help
333 2013-10-30 15:22:15 <TD> oh, i see. one of the locks is a synchronized statement. this is in the payment channels code. grr
334 2013-10-30 15:22:49 <TD> BlueMatt: yes. i will grab those soon
335 2013-10-30 15:29:45 <BlueMatt> TD: I believe most debug tools have been able to do that as long as the lock actually appears
336 2013-10-30 15:29:55 <BlueMatt> s/lock/deadlock/
337 2013-10-30 15:30:08 <TD> right, if you ask the jvm to dump all stacks, then it will do the calculation
338 2013-10-30 15:30:28 <TD> do the methods on PaymentChannelClientConnection really need to be synchronized?
339 2013-10-30 15:33:37 <BlueMatt> TD: umm...well considering they're all literally one line and call into methods that immediately lock, probably not so much
340 2013-10-30 15:33:47 <BlueMatt> TD: but considering that I see no reason why that could deadlock?
341 2013-10-30 15:33:50 <TD> that's what i was thinking
342 2013-10-30 15:34:14 <TD> http://pastebin.com/F7rg08QS
343 2013-10-30 15:34:24 <BlueMatt> git-wizards: is there a way to get rebase to ignore whitespace changes when merging and be smart instead of considering the whole damn thing a conflict?
344 2013-10-30 15:34:24 <TD> http://pastebin.com/raw.php?i=F7rg08QS
345 2013-10-30 15:34:31 <BlueMatt> some kind of rebase/cherry-pick -b
346 2013-10-30 15:34:54 <TD> junit is pretty stack hungry
347 2013-10-30 15:35:08 <BlueMatt> very
348 2013-10-30 15:37:17 <TD> http://pastebin.com/raw.php?i=MZApQ24M
349 2013-10-30 15:37:17 <TD> oops, this one is more informative
350 2013-10-30 15:37:48 <TD> i think the combination of explicit cycle detecting locks and synchronized statements is problematic. it can't properly describe the deadlock
351 2013-10-30 15:37:53 <TD> even though it knows there is one and why
352 2013-10-30 15:38:58 <TD> basically it inverts ProtobufParser and PaymentChannelClient.
353 2013-10-30 15:39:01 <BlueMatt> TD: I assume if you remove the synchronzied statements you would still get that deadlock, no?
354 2013-10-30 15:39:12 <TD> yeah sorry the *Connection thing is a red herring
355 2013-10-30 15:39:22 <TD> the actual problem is ProtobufParser.
356 2013-10-30 15:39:26 <BlueMatt> anyway, thats an easy fix, just send the message to the server outside the main lock and add another lock for that
357 2013-10-30 15:39:36 <BlueMatt> or split the read/write lock in the parserw
358 2013-10-30 15:39:40 <BlueMatt> which is probably better
359 2013-10-30 15:40:19 <TD> well i need to make the locking consistent in this part of the code and document the ordering. it should always use cycle detecting locks, never synchronized, and the ordering should always be Parser > Client
360 2013-10-30 15:40:21 <TD> i think
361 2013-10-30 15:41:20 <BlueMatt> Parser > Client for receive messages, Client > Parser for send
362 2013-10-30 15:41:29 <BlueMatt> need two locks then, but that makes sense anyway
363 2013-10-30 15:44:02 <TD> no, we shouldn't ever have situations like that
364 2013-10-30 15:44:08 <TD> it's just far too confusing and this code is already confusing enough as it is
365 2013-10-30 15:44:42 <TD> AFAICT the only state that's being accessed is the writeTarget pointer
366 2013-10-30 15:44:44 <TD> (on send)
367 2013-10-30 15:45:19 <TD> so it can just be read atomically and used without locking
368 2013-10-30 15:46:11 <BlueMatt> well, ok in that case maybe its not needed, but the writetarget will need the same level of complexity
369 2013-10-30 15:48:04 <TD> how the writeTarget manages locking is up to the implementor, some of which won't be using the pre-built classes anyway.
370 2013-10-30 15:48:15 <BlueMatt> fair enough
371 2013-10-30 15:48:38 <TD> but really there should be no locks held on the sending path. otherwise we do end up with these inversions and it's just so hard to untangle
372 2013-10-30 15:49:05 <BlueMatt> you're gonna have to if you fill up the send buffer java manages for you, you're gonna end up needing your own additional one
373 2013-10-30 15:49:46 <TD> and when would that happen?
374 2013-10-30 15:50:10 <melvster> Quite an interesting article: "Choosing the right elliptic curve" http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
375 2013-10-30 15:50:20 <BlueMatt> if you send a bunch of messages in a row?
376 2013-10-30 15:50:49 <TD> we shouldn't be adding any additional buffering on top of what the kernel provides, anyway.
377 2013-10-30 15:52:22 <BlueMatt> then you still get the same problem because you lock until the buffer space frees up
378 2013-10-30 15:53:14 <TD> i.e. until the data is sent or the connection is dropped.
379 2013-10-30 15:53:49 <melvster> TD: I can confirm that the bitcoin wallet on ubunutu touch mobile phone uses bitcoinj and I've successfully sent coins to it :)
380 2013-10-30 15:53:53 <TD> anyway, we *need* to simplify this code no matter what. if that means dropping some features then so be it. the current level of complexity in this part isn't sustainable, as evidenced by the fact that it still has bugs.
381 2013-10-30 15:54:05 <TD> melvster: ubuntu touch mobile? ok, cool .... what's the name of the wallet?
382 2013-10-30 15:55:07 <melvster> TD: just do a search in apps for 'bitcoin' ... the wallet is called bitcoin-app, it's in the store https://bugs.launchpad.net/bitcoin-app still some work to do ...
383 2013-10-30 15:55:21 <TD> and i thought andreas picked a generic name with "bitcoin wallet"
384 2013-10-30 15:55:23 <TD> bitcoin app? ye gods
385 2013-10-30 15:55:35 <TD> ok "bitcoin touch", slightly better
386 2013-10-30 15:56:03 <melvster> the operating system is "ubuntu touch"
387 2013-10-30 15:56:06 <melvster> it's quite good actually
388 2013-10-30 15:56:47 <TD> huh. the UI is based on Qt, and it uses JNI to talk to bitcoinj?
389 2013-10-30 15:56:57 <TD> i wish i had time to finish off the auto-binding work
390 2013-10-30 15:56:58 <melvster> TD: yeah ... i didnt design it ...
391 2013-10-30 15:57:32 <TD> well right now that's the most obvious way to use the library from native code
392 2013-10-30 15:57:39 <TD> (my solution - don't use native code :-)
393 2013-10-30 15:57:43 <TD> but there are better ways
394 2013-10-30 15:58:02 <melvster> if you have any comments/tips feel free to add comment or you can mail sam ( sam@sambull.org )
395 2013-10-30 15:58:14 <TD> as long as he's on the announcement list (and ideally dev list) then i have no comments right now
396 2013-10-30 15:58:42 <melvster> ok cool
397 2013-10-30 15:58:49 <TD> seems like he's not though
398 2013-10-30 15:59:14 <TD> nor is the guy he is working with ....
399 2013-10-30 15:59:16 <TD> :(
400 2013-10-30 15:59:31 <Belxjander> bitcoin MLs?
401 2013-10-30 15:59:46 <TD> if he's using bitcoinj, he needs to be on the bitcoinj mailing lists
402 2013-10-30 16:00:16 <melvster> ill let them know!
403 2013-10-30 16:04:20 <BlueMatt> TD: Ill take a look after I finish rebasing nonetty
404 2013-10-30 16:05:45 <TD> i think it may be due to a change i introduced actually
405 2013-10-30 16:05:47 <TD> i'm adding a PAYMENT_ACK message
406 2013-10-30 16:06:02 <TD> the stack traces don't make this obvious but it seems likely to be related.
407 2013-10-30 16:06:09 <TD> possibly this is a unit-test specific inversion
408 2013-10-30 16:06:12 <TD> i will investigate
409 2013-10-30 16:06:50 <BlueMatt> TD: stop breaking my code
410 2013-10-30 16:06:58 <TD> :)
411 2013-10-30 16:07:10 <TD> it needs to be free of inversions anyway
412 2013-10-30 16:08:22 <BlueMatt> Im surprised the inversion-checking locks didnt catch it though
413 2013-10-30 16:08:33 <TD> well not all the objects are using them
414 2013-10-30 16:08:36 <TD> so that would be why :)
415 2013-10-30 16:08:43 <BlueMatt> though those synchronized methods should be removed so that it forces the checking locks to do the work
416 2013-10-30 16:08:53 <TD> yeah. synchronized is fine on leaf objects.
417 2013-10-30 16:08:55 <TD> anyway, bbiab
418 2013-10-30 16:34:58 <gmaxwell> wumpus: https://bitcointalk.org/index.php?topic=279249.msg3443288#msg3443288
419 2013-10-30 16:36:39 <wumpus> yes, I'm a bit late to the party :)
420 2013-10-30 16:37:08 <gmaxwell> Well, we have poor communications flow in Bitcoin land. :)
421 2013-10-30 16:37:54 <sipa> It shouldn't surprise anyone that a broadcast communication system is inefficient :p
422 2013-10-30 16:39:11 <Musk> wumpus late to the party then you should drink little and stay mostly sober after all we are the designated drivers right ? xD
423 2013-10-30 16:40:10 <Musk> Basicly what serve someone to have lots of BTC if after all they get lost on bad investments :3
424 2013-10-30 16:40:11 <wumpus> gmaxwell: but that would only work for merging multiple outputs of your own into a sendmany, indeed locally, I wonder how we could do multiplayer coinjoin
425 2013-10-30 16:41:07 <gmaxwell> wumpus: well the idea there is that the interface is the same. E.g. you queue, and then in the background a multiplayer coinjoin could happen with no further _interface_ impact. (but obviously a lot of additional protocol stuff to find the other players)
426 2013-10-30 16:41:30 <gmaxwell> wumpus: I was responding to your " once we figure out how a user friendly interface for this could work"
427 2013-10-30 16:41:34 <gmaxwell> :)
428 2013-10-30 16:41:34 <wumpus> gmaxwell: ahh, right, yes agreed
429 2013-10-30 16:42:16 <gmaxwell> wumpus: the hard part about the actual protocol for it is setting up the introductions... e.g. finding the other players.
430 2013-10-30 16:42:19 <wumpus> 'queue transaction' with a timeout, and a way to show that a transaction is queued (instead of sent to the network) would be enough user interface
431 2013-10-30 16:42:46 <wumpus> yes, the coordination, I wonder how much interactivity would be needed
432 2013-10-30 16:43:02 <stonecoldpat> at the moment - is it possible to determine if a block is confirmed was by a pool? (at the protocol level without external information, im assuming no, but just to verify)
433 2013-10-30 16:43:05 <wumpus> would you coinjoin with random people, or with people you know
434 2013-10-30 16:43:15 <gmaxwell> wumpus: yea, and would be kinda useful immediately since it could merge local transactions even without the CJ stuff.
435 2013-10-30 16:43:44 <gmaxwell> wumpus: different tradeoffs there, with random people possibly allows more usage, but runs the risk that all the people are the same person.
436 2013-10-30 16:43:45 <wumpus> would someone open a "coinjoin server" and get other people to join
437 2013-10-30 16:44:08 <wumpus> right, so that choice has to be made by the user as well
438 2013-10-30 16:44:45 <gmaxwell> wumpus: one way we could support it is make it just work by connecting to a CJ server (e.g. over tor). And there is a preference for what CJ server to use.
439 2013-10-30 16:45:01 <gmaxwell> And so you could pick what kind of CJ properties you get by picking the CJ server.
440 2013-10-30 16:45:08 <wumpus> sounds good
441 2013-10-30 16:45:26 <gmaxwell> This could be done without any server at all.. e.g. with the broadcast network, but would make the protocol a lot more complicated.
442 2013-10-30 16:45:48 <gmaxwell> vs having a server coordinate the activity is pretty straight forward.
443 2013-10-30 16:46:03 <wumpus> that would be even better but could be added later
444 2013-10-30 16:48:49 <gmaxwell> yea, esp since I think the w/ the queue idea the interface wouldn't change.. it's still just queued transactions and you have some settings to control how queued transactions are processed.
445 2013-10-30 16:49:04 <wumpus> as servers cannot steal your coins, there isn't much of a trust threshold, and when connecting through TOR they can't log/leak your IP either
446 2013-10-30 16:49:12 <helo> gmaxwell: are there yet any cj server implementations?
447 2013-10-30 16:50:06 <gmaxwell> wumpus: the risks from the server are: dos attacks (e.g. they could fail to work), and that they could only connect you with sybils.
448 2013-10-30 16:50:45 <gmaxwell> wumpus: mostly I think of this as a nearly free way to increase privacy for everyone, not a hard core anonymity thing, so the fact that there is some sybil risk isn't an enormous deal.
449 2013-10-30 16:51:35 <wumpus> yes, they could ignore your transaction, but such servers would fall out favor quickly
450 2013-10-30 16:53:02 <gmaxwell> a side effect: I've been thinking for a while that it would be good to have some mode where the software ran normally but always announced new transactions via tor in order to defeat people spying for txn... this would achieve that as a side effect. (you'd just ask the meeting point server to do the announce)
451 2013-10-30 16:53:03 <wumpus> the sybil attack sounds a bit more far-fetched; putting everyone in a coinjoin with only sybils would give a lot of overhead for them
452 2013-10-30 16:53:50 <gmaxwell> wumpus: well, I dunno that its _that_ much more far fetched than the people who connect to every possible node in order to collect IPs for transactions, and we have an existance proof there. :)
453 2013-10-30 16:54:12 <gmaxwell> still: important to be frank about limitations, but the fact that limitations exist isn't a reason to not use something.
454 2013-10-30 16:54:19 <wumpus> of course, they could also do it to only specific targets
455 2013-10-30 16:54:47 <gmaxwell> wumpus: yea, "if someone tries to join an {interesting address}, pretend to be the other players"
456 2013-10-30 16:55:12 <gmaxwell> though even still: it's never less private than not using it.
457 2013-10-30 16:55:38 <wumpus> right, it's never worse; even if the server gains information that way, casual people checking the block chain don't
458 2013-10-30 17:04:50 <gmaxwell> wumpus: also, if it uses the chaum blinding techinque (maaku has a partial implementation of a CJ server that does) then the server doesn't learn whos output is whos (unless it replaces all other parties with sybs)
459 2013-10-30 17:06:57 <darsie> Does the tx fee influence how a normal tx spreads in the bitcoin net?
460 2013-10-30 17:08:46 <gmaxwell> darsie: a little, in that if it's too low (relative to size and priority) most peers won't relay at all. In the future it may have more relay impact.
461 2013-10-30 17:09:49 <darsie> k
462 2013-10-30 17:11:18 <darsie> I just talked to mtgox. tx from them sometimes take quite long until they show up on blockchain.info. They increased the fee from 0.0005 to 0.005 btc. I told them, they could come here for help.
463 2013-10-30 17:12:42 <darsie> tx from my btcoin-qt are most always very quick with 0.0001 btc fee. I think, their problem is somewhere else.
464 2013-10-30 17:13:33 <darsie> What's the tx format used when measuring tx size?
465 2013-10-30 17:13:44 <lianj> raw/binary
466 2013-10-30 17:14:11 <gmaxwell> darsie: a month or so ago they were paying people with immature coins.
467 2013-10-30 17:14:13 <darsie> Would that be hex->binary?
468 2013-10-30 17:14:22 <gmaxwell> I advised them of this. I'm not sure that they understood.
469 2013-10-30 17:14:37 <gmaxwell> As in newly generated coins with <100 confirms.
470 2013-10-30 17:14:57 <gmaxwell> darsie: can you check to see if this was the case in the transactions you're concerned about? (e.g. are they still doing it?)
471 2013-10-30 17:15:22 <darsie> Well, the case we had today didn't have a fee, IIRC.
472 2013-10-30 17:15:23 <gmaxwell> IOW when it shows up on BCI can you check to see if one of the inputs was freshly generated approx. 100 blocks ago?
473 2013-10-30 17:15:37 <gmaxwell> yea, well not having a fee shouldn't be a problem if they meet the priority rules in any case.
474 2013-10-30 17:15:56 <darsie> I'll see ...
475 2013-10-30 17:17:07 <maaku> Eligius found a block 19 minutes ago, and they have a deal for tx inclusion..
476 2013-10-30 17:17:45 <darsie> gmaxwell: I think its this tx: https://blockchain.info/tx/55b5d56b763f6eb27a234defe1f313c273ec244487e960237686906aee826c30
477 2013-10-30 17:18:42 <darsie> I'm not sure how to best check the age/priority.
478 2013-10-30 17:19:41 <darsie> gmaxwell: They have a page showing tx that didn't show up on the net for 2h: https://data.mtgox.com/api/0/bitcoin_tx.php
479 2013-10-30 17:20:11 <gmaxwell> darsie: yes, mtgox = fuckups.
480 2013-10-30 17:20:18 <gmaxwell> also, bc.i = fuckups.
481 2013-10-30 17:20:38 <darsie> You mean, they can't get it right?
482 2013-10-30 17:20:43 <BlueMatt> generally, bitcoin websites = fuckups
483 2013-10-30 17:20:54 <gmaxwell> in that transaction the 1MAv44YHbeh9mt3tHUdxDqG7J8acjA9byh input is a p2pool coinbase output which only has 77 confirms.
484 2013-10-30 17:21:09 <BlueMatt> they invest more time in getting their sites to work than they do on bitcoin minutia
485 2013-10-30 17:21:15 <gmaxwell> That transaction is invalid.
486 2013-10-30 17:21:24 <BlueMatt> where bitcoin minutia is also incredibly important, obviously
487 2013-10-30 17:21:47 <maaku> invalid for the next couple of hours at least
488 2013-10-30 17:21:54 <maaku> you'll just have to wait a little longer for your coins
489 2013-10-30 17:21:58 <gmaxwell> yea.
490 2013-10-30 17:22:25 <darsie> When trying to rebroadcast mtgox tx, some are rejected by bitcoind.
491 2013-10-30 17:23:02 <maaku> darsie: because some of the inputs are coinbase transactions < 100 confirms old
492 2013-10-30 17:23:54 <darsie> That's someone elses tx. But I had troubled tx myself, which is very annoying when I have a buyer sitting next to me and I can't give him back the money cause the btc will eventually arrive.
493 2013-10-30 17:24:34 <darsie> maaku: bitcoind will reject a tx just because the inputs are too young?
494 2013-10-30 17:24:39 <maaku> darsie: yes
495 2013-10-30 17:24:48 <maaku> just for coinbase inputs
496 2013-10-30 17:24:51 <gmaxwell> darsie: it is a special rule for newly generated coins.
497 2013-10-30 17:24:59 <maaku> because if there is a reorg, those inputs will not follow
498 2013-10-30 17:25:00 <gmaxwell> It's a requirement of the bitcoin protocol.
499 2013-10-30 17:25:03 <darsie> But I can send coins I received just after one confirm. ohh.
500 2013-10-30 17:25:37 <darsie> I don't (need to) understand that.
501 2013-10-30 17:26:15 <maaku> what's happening is that people are using a mt.gox receiving address for their miner payments
502 2013-10-30 17:26:39 <darsie> Coinbase? Is that just another exchange? Why treat them specially ... in the btc protocol?
503 2013-10-30 17:26:53 <gmaxwell> which is fine, and mtgox has its own custom wallet codeâ which is fine. But the wallet code is flawed and doesn't obey the bitcoin rules in this respect, which is not fine.
504 2013-10-30 17:27:05 <gmaxwell> ACTION groans