1 2014-08-25 00:32:26 <petertodd> elichai2: I can spare five
  2 2014-08-25 00:42:29 <justanotheruser> petertodd: can I PM you a quick non-technical question?
  3 2014-08-25 01:00:20 <skinnkavaj> Mike Hearn for president (not really lol)
  4 2014-08-25 01:00:21 <skinnkavaj> http://blog.vinumeris.com/2014/07/02/vinumeris-and-olivier-janssens-team-up/
  5 2014-08-25 01:20:51 <gmaxwell> BlueMatt: have you been tracking blocks that predict poorly with your relay tool at all?  So far the worst I've seen are 000000000000000012feb790a9ef2e01d50299c47e8a1fccad488306a2c26c63 113/490  00000000000000001c5b4fd3a8ae6150f5a8c0e869ece137307cae59a8dd83b8 324/1024 00000000000000001f9e4d8b0e9ae8d5a45f9d8f3afd249bc1b451ac9b556389  540/1702 00000000000000001767e1658e78c2f0c9e58e3737292b34295d149822f59bb4 797/2097
  6 2014-08-25 01:35:12 <BlueMatt> gmaxwell: no, it has been without love quite a bit recently as I was spending my time on whitepaper review and pull review
  7 2014-08-25 01:35:30 <BlueMatt> gmaxwell: I'm planning on doing some more monitoring in the coming week
  8 2014-08-25 01:36:33 <BlueMatt> gmaxwell: are any of those right after a restart/disconnect?
  9 2014-08-25 01:38:32 <gmaxwell> no, I excluded ones that were.
 10 2014-08-25 01:38:54 <gmaxwell> (there was one span where apparently preforwarding wasn't working— as it was 0/N for quite a few blocks)
 11 2014-08-25 01:39:34 <BlueMatt> yes, that has happened once or twice
 12 2014-08-25 01:39:37 <BlueMatt> (node crashed)
 13 2014-08-25 01:39:42 <BlueMatt> shouldnt happen again
 14 2014-08-25 01:54:18 <zoroastre> gmaxwell, do you think zeroMQ could be used as a replacement for boost.asio in a new implementation?
 15 2014-08-25 01:55:41 <Luke-Jr> zoroastre: totally different thing
 16 2014-08-25 01:55:57 <phantomcircuit> zoroastre, also no
 17 2014-08-25 01:56:26 <zoroastre> damn
 18 2014-08-25 02:01:17 <phantomcircuit> gmaxwell, probably just needs a more extensive listening network
 19 2014-08-25 02:02:31 <gmaxwell> phantomcircuit: has nothing to do with that, the preforwarding is filtered via a node (otherwise it's trivial to dos attack) so most of the non-forwarded transactions were ones the node didn't like.
 20 2014-08-25 02:04:32 <phantomcircuit> gmaxwell, oh
 21 2014-08-25 02:04:52 <phantomcircuit> well then the node probably needs to be reconfigured to forward more loosely
 22 2014-08-25 02:09:36 <gmaxwell> phantomcircuit: sure perhaps, though the defaults are already pretty dos-attack vulnerable. But this is what makes it interesting to look at the exceptions.
 23 2014-08-25 02:10:26 <BlueMatt> phantomcircuit: it does need that, but I'm working on it
 24 2014-08-25 02:10:35 <BlueMatt> (and it can only get better :) )
 25 2014-08-25 02:10:40 <gmaxwell> an obvious thing to do would be to have a queue determinstically ordered by a unified priority/fee metric, and just forward at a constant rate limited speed of e.g. 4x the peak long term data rate. according to whatever is in the queue.
 26 2014-08-25 02:11:11 <gmaxwell> then the node's acceptance policy could be made permissive without further opening up the door to flooding attacks.
 27 2014-08-25 02:11:56 <BlueMatt> gmaxwell: patches welcome
 28 2014-08-25 02:12:32 <BlueMatt> I'm happy enough with the prerelay stuff for now, I'm focusing on getting block sources signed up and making sure the performance is where it should be
 29 2014-08-25 02:25:12 <gmaxwell> BlueMatt: Is there a reason I'm missing that you're just not sending indexes instead of txids for the non-missing transactions?
 30 2014-08-25 02:25:44 <BlueMatt> gmaxwell: hmm?
 31 2014-08-25 02:27:02 <BlueMatt> gmaxwell: oh, you mean like index-in-cache?
 32 2014-08-25 02:27:41 <gmaxwell> Yes.
 33 2014-08-25 02:28:08 <gmaxwell> As in— two bytes (reserve one value to be an escape for out of cache) instead of 32.
 34 2014-08-25 05:32:48 <arowser> identify tiange
 35 2014-08-25 08:28:25 <Genitrust> if inputs total 0.5 BTC, and outputs total 0.4999 BTC, does that mean that a transaction fee of 0.0001 BTC was applied?
 36 2014-08-25 08:29:23 <sipa> yes
 37 2014-08-25 08:34:57 <rfreeman_w> that reminds me of that 27 BTC fee guy.  that will teach'em to use testnet
 38 2014-08-25 08:56:20 <GMP> did we just witnessed 90min block ?
 39 2014-08-25 08:57:28 <Jouke> so?
 40 2014-08-25 08:57:43 <Jouke> Welcome to Bitcoin.
 41 2014-08-25 08:57:46 <sipa> ;;tblb 5400
 42 2014-08-25 08:57:48 <gribble> The expected time between blocks taking 1 hour, 30 minutes, and 0 seconds to generate is 15 weeks, 2 days, 2 hours, 15 minutes, and 10 seconds
 43 2014-08-25 08:58:06 <GMP> extremely rare!
 44 2014-08-25 08:58:13 <sipa> happens a few times a year
 45 2014-08-25 08:59:30 <Genitrust> sipa: thanks:)
 46 2014-08-25 09:00:09 <Genitrust> wasn't there a block that took like 8 hours?
 47 2014-08-25 09:00:27 <Genitrust> or was that just 1 hour? -.- damn my memory
 48 2014-08-25 09:01:35 <sipa> not in recent history
 49 2014-08-25 09:02:36 <sipa> in the first year (2009) thete eveb were day-long blocks, but that's not a fair comparison as hashing speed was below difficulty 1 level
 50 2014-08-25 09:05:08 <GMP> simple math question: if avg block time is 10 min, is average confirmation time 5 min?
 51 2014-08-25 09:06:47 <sipa> no, 10 minutes
 52 2014-08-25 09:06:48 <Genitrust> GMP no, average block time is 10 min, meaning a transaction (if included in a block) gets "confirmed" again when included in another block
 53 2014-08-25 09:06:56 <sipa> it's a poisson process
 54 2014-08-25 09:06:59 <Genitrust> sooo...as sipa said, 10 minutes
 55 2014-08-25 09:07:05 <Genitrust> poisson?
 56 2014-08-25 09:07:24 <sipa> so the expected time to the next block is always the same (it is memoryless)
 57 2014-08-25 09:07:58 <sipa> look it up on wikipedia
 58 2014-08-25 09:08:10 <Genitrust> sipa: memoryless as in, does not remember when the last block was solved?
 59 2014-08-25 09:08:15 <sipa> indeed
 60 2014-08-25 09:08:28 <sipa> every second has the same chance of finding a block or not
 61 2014-08-25 09:08:41 <btcdrak> rfreeman_w there seems to be one of those every few weeks...
 62 2014-08-25 09:08:45 <sipa> regardless of whether one was just foumd
 63 2014-08-25 09:09:07 <sipa> btcdrak: what is your use case for getutxos?
 64 2014-08-25 09:09:45 <btcdrak> (because insight-api is terribly unreliable and buggy).
 65 2014-08-25 09:10:02 <sipa> you can use getutxos RPC...
 66 2014-08-25 09:10:28 <sipa> *getutxo
 67 2014-08-25 09:11:12 <btcdrak> sipa: I didnt realise there is an RPC call for that? I thought that's what 4007 was about.
 68 2014-08-25 09:12:12 <sipa> 4007 is about indexing it by address
 69 2014-08-25 09:12:19 <sipa> that's not what i am asking about
 70 2014-08-25 09:12:34 <sipa> i wondered what use case you have for the getutxos P2P message
 71 2014-08-25 09:12:50 <sipa> which does the same as the already-existing getutxo RPC
 72 2014-08-25 09:13:05 <sipa> (4351)
 73 2014-08-25 09:13:59 <Genitrust> let me guess, the opposite of a "spent output" is one that... well... was never spent. (as in, coins are just sittin in there waiting to be used!)
 74 2014-08-25 09:14:00 <Genitrust> ...right?
 75 2014-08-25 09:14:15 <sipa> Genitrust: #bitcoin please
 76 2014-08-25 09:14:26 <Genitrust> awww this isn't dev chat? :(
 77 2014-08-25 09:14:33 <Genitrust> my bad, i guess that is more protocol specific... sorry!
 78 2014-08-25 09:14:50 <sipa> no, it's the most basic concept of how bitcoin functions
 79 2014-08-25 09:15:01 <Genitrust> well, was it right? :(
 80 2014-08-25 09:15:57 <sipa> btcdrak: you were asking on 4351 when it would get merged... so i wonder what you need it for
 81 2014-08-25 09:17:04 <Genitrust> sipa heya if you're bored, you could always just give an easy yes/no ;D
 82 2014-08-25 09:17:32 <sipa> i'll answer on #bitcoin
 83 2014-08-25 09:17:44 <btcdrak> sipa: I dont particularly like 4351, seems like it should only be available via RPC, but it's an immediate bandaid for us since there is no way to get utxo by address from bitcoin RPC and insight-api is not production ready.
 84 2014-08-25 09:18:01 <sipa> btcdrak: 4351 does not give you that!
 85 2014-08-25 09:18:18 <sipa> it does exactly the same as the existing getutxo RPC, only over P2P
 86 2014-08-25 09:19:25 <btcdrak> sipa: I am confused. There is no getutxo RPC call atm...
 87 2014-08-25 09:19:40 <btcdrak> 
ACTION thinks he needs more coffee

 88 2014-08-25 09:20:06 <sipa> oh, it's called gettxout, sorry
 89 2014-08-25 09:20:48 <btcdrak> sipa: today I learned... ^.^
 90 2014-08-25 09:20:51 <Genitrust> 
ACTION also thinks btcdrak needs more coffee

 91 2014-08-25 09:21:09 <sipa> but gettxout also does not work by address
 92 2014-08-25 09:21:16 <BlueMatt> wumpus: ok, when you get a chance, squash #4748 and I'll verify the c/p and ack
 93 2014-08-25 09:21:22 <sipa> as such an index simply does not exist
 94 2014-08-25 09:21:55 <btcdrak> sipa: hence #4007
 95 2014-08-25 09:22:04 <sipa> btcdrak: yes, no problem with 4007
 96 2014-08-25 09:22:10 <sipa> i do have a problem with 4351
 97 2014-08-25 09:23:07 <sipa> (except that i'd prefer 4007 to be an external tool rather than more functionality in bitcoind, but i understand the use case)
 98 2014-08-25 09:23:09 <wumpus> BlueMatt: yes, also did the renames
 99 2014-08-25 09:23:36 <btcdrak> sipa: then I made a mistake. I also dont like it but given there were so many ACKs already, I figured it was going to get merged regardless frankly... I didnt realise there was an RPC for this already.
100 2014-08-25 09:23:37 <wumpus> pushed
101 2014-08-25 09:23:54 <BlueMatt> wumpus: damn you, I was gonna go to bed after the next block!
102 2014-08-25 09:24:23 <wumpus> btcdrak: hah, that's the perfect illustration of why we have too much functionality in bitcoind already
103 2014-08-25 09:24:41 <wumpus> people not even realizing something already exists
104 2014-08-25 09:24:55 <btcdrak> wumpus: yes, I feel a bit stupid frankly.
105 2014-08-25 09:27:22 <btcdrak> sipa: I think the ability to query utxo by address is a basic functionality. Having to spin up something like insight-api just to query UTXO by address is a pretty major undertaking when the data is sitting right there in bitcoind.
106 2014-08-25 09:27:57 <sipa> i understand the practical concern
107 2014-08-25 09:28:00 <btcdrak> insight-api requires full node + about 30GB of it's own data and the best part of a day to import.
108 2014-08-25 09:28:24 <sipa> but it's not like the data is "right there" in bitcoind
109 2014-08-25 09:28:46 <sipa> the by-address utxo index would be larger than the utxo set itself i believe
110 2014-08-25 09:29:35 <rfreeman_w> hello, hi Sillopotatis
111 2014-08-25 09:29:40 <rfreeman_w> oh hi sipa  :)
112 2014-08-25 09:30:31 <rfreeman_w> I have a general question that came up on ##c++ and while coding some altcoin, that might be of interest to bitcoin too
113 2014-08-25 09:30:50 <rfreeman_w> what do you think of using safe, signaling integral types, that guarantee to abort program in case of arithmetic over/under flow
114 2014-08-25 09:31:40 <rfreeman_w> at worst they can be written just as a class that does proper asserts on all operators,  but possibly they could be on many platforms implemented better using CPU signaling (just a new idea, not researched it yet)
115 2014-08-25 09:32:38 <rfreeman_w> they could be used everywhere across the code, so in any even unexpeteced place we would get program abort instead of silently continuing with logically incorrect value
116 2014-08-25 09:34:36 <sipa> that makes sense for some types i guess
117 2014-08-25 09:38:02 <wumpus> what do you think of using safe, signaling integral types, that guarantee to abort program in case of arithmetic over/under flow <- that should be the future
118 2014-08-25 09:38:50 <wumpus> not sure how well it fits into c++, but it's one of the changes to how programming languages work that would kill entire classes of bugs
119 2014-08-25 09:39:14 <sipa> right, i would love efficient types int32_strict_t and int_mod32bit_t
120 2014-08-25 09:39:39 <sipa> where the former one really represents natural numbers, and fails when going out of bounds
121 2014-08-25 09:40:44 <BlueMatt> Block built with 726 bytes on the wire
122 2014-08-25 09:40:47 <rfreeman_w> sipa, yeap my thought exactly :) I will be researching this options this week; Apparently CERN did some cool work on this area if you would like to research it too
123 2014-08-25 09:40:47 <wumpus> right
124 2014-08-25 09:40:55 <BlueMatt> not bad for an 80kB block
125 2014-08-25 09:41:23 <rfreeman_w> thoughts gathered so far:       apparently some platforms can be configured to signal on integer overflow, resulting in SIGFPE and FPE_INTOVF_TRAP      -ftrapv on gcc   -fsanitize=integer           https://www.youtube.com/watch?v=hgeErnYxAUw&list=UU5e__RG9K3cHrPotPABnrwg
126 2014-08-25 09:42:19 <wumpus> rfreeman_w: that will only work for the signed integers though, not unsigned integers and size_t and such
127 2014-08-25 09:43:07 <wumpus> but yes it's a step in the right direction, as signed ints are already implicitly forbidden to overflow in C
128 2014-08-25 09:43:32 <sipa> eh?
129 2014-08-25 09:43:58 <petertodd> justanotheruser: sure, although email might be better
130 2014-08-25 09:44:41 <wumpus> overflow in signed integers results in 'undefined behavior', so trapping is an acceptable thing to do
131 2014-08-25 09:44:52 <rfreeman_w> wumpus, are you sure
132 2014-08-25 09:45:11 <rfreeman_w> wumpus, we just had that discussion on ##c++ and standard says both (Afair) are defined, as U2 type
133 2014-08-25 09:45:37 <wumpus> rfreeman_w: sure about what?
134 2014-08-25 09:46:29 <rfreeman_w> <Adrinael> TIL C11 defines intN_t types to be two's complement representation     <Adrinael> C11 7.20.1.1          <Adrinael> unsigned overflow is not UB    <Adrinael> 3.9.1/4
135 2014-08-25 09:46:39 <petertodd> gmaxwell: oh, scorched-earth is your idea? I thought it was jdillon's
136 2014-08-25 09:46:41 <rfreeman_w> Adrinael is my hero next to Satoshi
137 2014-08-25 09:47:12 <wumpus> how does that conflict with what I said? *unsigned* overflow is indeed defined
138 2014-08-25 09:49:18 <wumpus> I was clearly talking about signed overflow
139 2014-08-25 09:51:26 <rfreeman_w> ah allright
140 2014-08-25 09:52:07 <petertodd> gmaxwell: that said, I think the ANYONECANPAY version is superior to the CPFP version... and I still can't take credit for that either: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
141 2014-08-25 09:52:37 <wumpus> so we'd only need  strict and modNbit variants of the unsigned types
142 2014-08-25 09:54:08 <btcdrak> sipa: I think the size doesnt matter if it's like txindex and configurable. If you need it, you can use it else off by defualt.
143 2014-08-25 09:54:37 <sipa> btcdrak: size doesn't matter; conplexity does
144 2014-08-25 09:55:03 <sipa> as in: i would prefer to keep non-essential things out of bitcoind
145 2014-08-25 09:55:04 <btcdrak> :-P
146 2014-08-25 09:55:28 <wumpus> bitcoin core is meant a minimal software to maintain the infrastructure, it shouldn't gain all kinds of extra indexes however useful
147 2014-08-25 09:56:15 <wumpus> it would be nice if bitcoind had interfaces to implement that kind of functionality in a modular way without having to patch around, though
148 2014-08-25 09:56:26 <btcdrak> sipa: dunno, seems like a pretty glaring problem we need to build complex external apps just to do something simple. utxo query is essential for wallet 3rd party implementations
149 2014-08-25 09:57:22 <wumpus> btcdrak: as I said, that's an interface problem, smashing everyting into bitcoind is not the solution
150 2014-08-25 09:58:22 <wumpus> what we need is a *general* interface that makes things such as address and utxo indexes posibble without integrating all that code into bitcoind
151 2014-08-25 09:58:33 <btcdrak> wumpus: this is not "everything" this is a pretty basic requirement. it is what allows you to build wallets.
152 2014-08-25 09:58:41 <wumpus> no special casing for everything
153 2014-08-25 09:58:55 <wumpus> no, it is not a basic requirement, not for bitcoind at least
154 2014-08-25 09:59:08 <wumpus> bitcoind doesn't care about building wallets, it is a node implementation
155 2014-08-25 09:59:52 <wumpus> for building wallets you'd likely start from some SPV library like bitcoinj
156 2014-08-25 10:00:05 <btcdrak> wumpus but sure, bitcoin core could be a bit more modular. But isnt that what's happening by separating out things slowly like  -cli, -tx, separating wallet and daemon and gui in the compile process etc.
157 2014-08-25 10:01:21 <wumpus> btcdrak: yes, it's a move in the same direction
158 2014-08-25 10:01:37 <wumpus> btcdrak: except that this would involve designing an API
159 2014-08-25 10:01:56 <wumpus> and exporting a library or such
160 2014-08-25 10:02:43 <btcdrak> wumpus in the long term it would be awesome if you could build plugins that interface with bitcoind. as you say it would need to expose some interfaces for that.
161 2014-08-25 10:03:41 <wumpus> that's what we need... and that's why I'm going to stop merging 'please handle this special case too', as it only delays a thorough and general solution
162 2014-08-25 10:07:05 <wumpus> there's nothing long term about it, someone just needs to do it
163 2014-08-25 10:08:55 <wumpus> ie, define some signals and slots, and subscribe to them at some point at initialization
164 2014-08-25 10:11:38 <wumpus> "This new format is suitable for researchers performing lots of raw block processing, and bitcoind users importing via "-reindex". The reindex import method is superior to bootstrap.dat."
165 2014-08-25 10:11:49 <wumpus> that's interesting, never thought of using -reindex to bootstrap
166 2014-08-25 10:16:29 <wumpus> it makes a lot of sense, I can't think of any case where a bootstrap.dat would be preferable
167 2014-08-25 10:19:16 <BlueMatt> gmaxwell: to answer your question from earlier, because the cache code hadnt been written when the wire protocol was being written
168 2014-08-25 10:20:14 <BlueMatt> gmaxwell: anyway, fixed now (you might see some spikes after restarts earlier tonight, also go update)
169 2014-08-25 10:55:18 <michagogo> wumpus: did you see https://github.com/bitcoin/gitian.sigs/pull/53?
170 2014-08-25 10:55:27 <wumpus> michagogo: probably not
171 2014-08-25 10:55:40 <michagogo> Looks like a match to me
172 2014-08-25 10:56:07 <wumpus> whether it's a match or not, gitian sigs should be merged, done :)
173 2014-08-25 10:57:16 <wumpus> for some reason I don't get emails when someone submits a pull there
174 2014-08-25 10:59:12 <wumpus> all match
175 2014-08-25 11:00:06 <wumpus> hm, https://github.com/bitcoin/gitian.sigs README.md shouldn't contain  an outdated extract from the release process
176 2014-08-25 11:00:20 <wumpus> let's make it just a reference
177 2014-08-25 13:19:13 <wumpus> sigh...
178 2014-08-25 13:19:28 <wumpus> "I will not NAK this change" is not a NAK @jgarzik
179 2014-08-25 13:20:19 <jgarzik> Yes that obviously changed with new info...
180 2014-08-25 13:20:26 <wumpus> what new info?
181 2014-08-25 13:20:29 <sipa> that discussion about abusing it as fileserver was more recent
182 2014-08-25 13:20:30 <wumpus> what is so obvious here?
183 2014-08-25 13:21:11 <sipa> people assumed that it would just query spentness or not, it seems
184 2014-08-25 13:21:22 <sipa> not actually fetching full txout content
185 2014-08-25 13:21:45 <hearn_> sigh
186 2014-08-25 13:22:04 <hearn> although i did make a nice writeup with the patch, and wrote a BIP, and the code is only one screen long
187 2014-08-25 13:22:13 <wumpus> so, back to changing the BIP, back to changing the code?
188 2014-08-25 13:22:16 <hearn> no
189 2014-08-25 13:22:21 <wumpus> why didn't anyone post that in the issue?
190 2014-08-25 13:22:30 <hearn> the objection makes no sense
191 2014-08-25 13:23:00 <hearn> as i explained both to gregory (who actually replied on the BIP thread but then claims he didn't know what it did), and on the github thread just now
192 2014-08-25 13:23:01 <wumpus> as I saw it there were no strong objections, only "it could be used insecurely"
193 2014-08-25 13:24:43 <sipa> i think part of the problem is that things that are disliked get less reviee
194 2014-08-25 13:24:46 <sipa> *review
195 2014-08-25 13:26:18 <wumpus> so, is there a real risk that this will get people to use the UTXO set as a file server?
196 2014-08-25 13:26:39 <hearn> wumpus: i put an explanation of why the answer is "no" on the pull request
197 2014-08-25 13:26:53 <wumpus> hearn: I read that, but I'd like to hear from the people that claim this in the first place too
198 2014-08-25 13:29:08 <wumpus> anyhow... when there is a critical problem with an issue post that in the issue, i usually try to read all that is said in this channel but I must have missed that part and feel really stupid about it now...
199 2014-08-25 13:30:45 <hearn> wumpus: i missed it too
200 2014-08-25 13:30:51 <wumpus> I just cannot do my job this way
201 2014-08-25 13:31:03 <hearn> agreed, such things are better discussed on the mailing list
202 2014-08-25 13:33:35 <hearn> sipa: i think that's generous .... there as >120 posts of "review" (if we want to call it that). i'm feeling somewhat frustrated that a significant fraction of the feedback on both the pull request and the bip thread was from people who clearly did not read anything i wrote, but developed strong opinions about it anyway. e.g. gregory asked for something to be mentioned in the BIP that was already there. it's not even a long document.
203 2014-08-25 13:34:09 <hearn> i'm not sure how to forge consensus in such a situation
204 2014-08-25 13:34:10 <sipa> yes, i agree, and i'm guilty too
205 2014-08-25 13:34:44 <hearn> anyway
206 2014-08-25 13:34:55 <hearn> lighthouse beta is in a week :)
207 2014-08-25 13:35:00 <sipa> but part is that people don't feel responsible to keep track of everything... and mostly focus on what they like to see happen
208 2014-08-25 13:35:18 <hearn> so i'm looking forward to getting this project out and real world testing. we can start to get real data.
209 2014-08-25 13:35:38 <hearn> yes well this is always an issue in any project, but especially one with lots of volunteers. i guess there's not much that can be done about it.
210 2014-08-25 13:35:53 <hearn> we all just have to digitally hold hands and sing kumbayah every so often :)
211 2014-08-25 13:35:58 <jgarzik> At this moment, I'm modifying blkscan.c to get real numbers
212 2014-08-25 13:36:02 <jgarzik> on txouts and sizes
213 2014-08-25 13:36:14 <jgarzik> 36 bytes for 36 bytes is obviously a handwave
214 2014-08-25 13:36:48 <hearn> i didn't say that. you get more than 36 bytes back. a single key is 32 bytes, so with a multisig output that's still spendable you upload 36 bytes and get back 32*however many keys are not real, probably 2 if it's a standard output
215 2014-08-25 13:36:58 <hearn> if it's not standard, well, then you can do all sorts of things ...
216 2014-08-25 13:37:39 <sipa> after the previous discussion, i realized that txout data and spentness data are totally separate pieces of information
217 2014-08-25 13:37:42 <hearn> even so, it's way less efficient than just saying "grab every tx with this 4-byte sequence between block heights X and Y"
218 2014-08-25 13:37:47 <sipa> one is provable and immutable
219 2014-08-25 13:38:01 <sipa> the other is completely unauthenticated and is independent of the othet
220 2014-08-25 13:38:16 <sipa> it seems to me that lighthouse really only needs spentness
221 2014-08-25 13:38:58 <sipa> by requiring peers to give you the actual outout (which you already know), they can't lie about unspentness
222 2014-08-25 13:39:07 <sipa> but they can always lie about spentness
223 2014-08-25 13:39:14 <hearn> lighthouse checks signatures to ensure if you submit a pledge, it's actually spendable
224 2014-08-25 13:39:27 <hearn> that is, you are not submitting pledges for other people's outputs
225 2014-08-25 13:40:27 <hearn> anyway, bitcoin has always been usable as a file server. people have done it a little bit, but it still keeps on trucking and in reality these file transactions are not common. of all the problems we have, dumb people trying to turn bitcoin into a new FTP is pretty low down the list, thank goodness
226 2014-08-25 13:40:45 <hearn> if bitcoin core had an "extract file" feature it'd be a lot worse, of course
227 2014-08-25 13:41:17 <hearn> but for as long as you have to distribute some special app to download stuff in the block chain, and for as long as it sucks harder than just using a real file transfer protocol, this sort of thing will just be individuals experimenting and messing around.
228 2014-08-25 13:41:18 <wumpus> yes I suppose it's equally possible to abuse the bloom filtering to give you parts of a file
229 2014-08-25 13:41:50 <wumpus> although storing in the utxo set is particularly bad of course
230 2014-08-25 13:41:51 <hearn> well or just "getblocks". we're theorising about people who don't care about efficiency here. so they could just download the whole block and throw the irrelevant parts away.
231 2014-08-25 13:42:15 <jgarzik> wumpus, right... and giving direct fetch access to the UTXO set changes that incentive-to-store a bit
232 2014-08-25 13:42:33 <sipa> but blocks can be thrown away
233 2014-08-25 13:42:36 <sipa> the utxo set cannot
234 2014-08-25 13:42:39 <hearn> so can unspendable UTXOs.
235 2014-08-25 13:42:51 <jgarzik> hearn, people have already stored files -- and the python scripts to upload and download -- in unspendable utxos
236 2014-08-25 13:42:56 <sipa> so people with an incentive to store data there will not use unspendable utxos
237 2014-08-25 13:42:59 <hearn> you don't even need consensus. if you can prove they're unspendable, because the keys are actually strings or whatever, you can just delete them. don't even need a consensus change.
238 2014-08-25 13:43:23 <hearn> jgarzik: yeah, but we're not worried about "occasional individual who is messing around". we worry about trends that could significantly harm bitcoin as a financial platform.
239 2014-08-25 13:43:24 <jgarzik> hearn, I wouldn't mind doing that, but it's hueristics
240 2014-08-25 13:43:44 <jgarzik> hearn, as stated the upload script is embedded in the chain, and it appears multiple parties have used it
241 2014-08-25 13:44:16 <jgarzik> 112203 multisig
242 2014-08-25 13:44:16 <jgarzik> 120490193 txout
243 2014-08-25 13:44:16 <jgarzik> 24 op_drop
244 2014-08-25 13:44:16 <jgarzik> 317001 block
245 2014-08-25 13:44:16 <jgarzik> 45129151 tx
246 2014-08-25 13:44:16 <jgarzik> 4542 op_return
247 2014-08-25 13:44:18 <jgarzik> 0 pubkey
248 2014-08-25 13:44:20 <jgarzik> 119407368 pubkeyhash
249 2014-08-25 13:44:20 <wumpus> that's a cat and mouse game I'm afraid, then they just encode the strings with a known key so they're not recognizable as such, or encode audio data instead of strings :p
250 2014-08-25 13:44:22 <jgarzik> 58837 scripthash
251 2014-08-25 13:44:24 <jgarzik> 907209 unknown
252 2014-08-25 13:44:25 <hearn> zero pubkey?
253 2014-08-25 13:44:26 <jgarzik> stats for 317,001 blocks (height 317000)
254 2014-08-25 13:44:39 <hearn> you mean zero OP_CHECKSIG outputs? that must be a bug surely
255 2014-08-25 13:44:39 <jgarzik> hearn, lumped into "unknown" at present
256 2014-08-25 13:44:42 <hearn> oh
257 2014-08-25 13:45:17 <sipa> it's always possible to store data in not-provably-but-unspendable outputs
258 2014-08-25 13:45:29 <hearn> wumpus: well the point of putting files somewhere is so they can be retrieved. so obviously someone must know there's a file there. if you're going to send a file to just one person, may as well just encrypt it and send it directly. the block chain buys you nothing. people who put stuff there want it to be widely available.
259 2014-08-25 13:45:49 <rfreeman_w> sipa, you can even stenograph data over spendable valid transactions I bet
260 2014-08-25 13:46:01 <hearn> sipa: if someone can retrieve the data at all, they can prove to others that it's a file.
261 2014-08-25 13:46:03 <jgarzik> rfreeman_w, sure with msig
262 2014-08-25 13:46:03 <sipa> yes, but transactiins are not queryable
263 2014-08-25 13:46:08 <hearn> even if it's encrypted.
264 2014-08-25 13:46:10 <rfreeman_w> (wasting more space)
265 2014-08-25 13:46:30 <sipa> storing in the blockchain is one thing, but that incentive is significantly reduced by pruning
266 2014-08-25 13:46:36 <hearn> the "proof" is then you just run the program that is supposed to fetch this file and watch what outputs it decodes. check what the program does -> now you know those outputs are data, even if encrypted.
267 2014-08-25 13:46:39 <sipa> storing in the utxo set is forever
268 2014-08-25 13:46:53 <rfreeman_w> I think we can not stop people that want to do this, we could just profit maybe from heaving them finance miners
269 2014-08-25 13:47:04 <hearn> sipa: well, there are two cases right
270 2014-08-25 13:47:24 <hearn> sipa: in one case all the keys in the output are files. in that case the output is unspendable, but core doesn't know that automatically. however it can be told, e.g. via an rpc or external tool.
271 2014-08-25 13:47:36 <hearn> sipa: in another case at least one key is real. but then the outputs can be spent and they are no more forever than any other output is.
272 2014-08-25 13:47:55 <hearn> sipa: plus then you're back to distributing/uploading half of what you download, which is sort of nonsensical
273 2014-08-25 13:48:21 <hearn> you didn't really solve any problem for yourself, you still have this giant keyfile (std::vector<COutPoint>) to distribute.
274 2014-08-25 13:48:52 <sipa> nobody pays for usage of the utxo set
275 2014-08-25 13:48:58 <wumpus> rfreeman_w: the problem is that every validating node has to store the utxo set forever, it can't be pruned like the block chain, so financing just miners will not provide the right incentive
276 2014-08-25 13:48:59 <sipa> people pay for blockchain space
277 2014-08-25 13:49:23 <hearn> the utxo set *can* be pruned, of unspendable outputs.
278 2014-08-25 13:49:37 <sipa> so one will use non-unspendable ones
279 2014-08-25 13:49:45 <hearn> heck it can be pruned of spendable outputs too if there is strong enough consensus.
280 2014-08-25 13:49:48 <sipa> which do not cost morr
281 2014-08-25 13:49:58 <sipa> +more
282 2014-08-25 13:50:06 <hearn> sipa: they cost more in the sense that you upload more data (the getutxo queries) to get less data back.
283 2014-08-25 13:50:34 <sipa> ...
284 2014-08-25 13:50:44 <hearn> i mean, if we abandon all pretense that we're dealing with a sane adversary here then yes people can do all kinds of stupid things with bitcoin. they can just throw money away for no reason at all or put outputs that request someone to solve their maths homework or whatever.
285 2014-08-25 13:51:15 <hearn> assuming someone actually wants a usable file transfer protocol, having a "url" that's ~half the size of the file itself is not very useful
286 2014-08-25 13:52:08 <hearn> i'm afraid i cannot design software that can never be abused by insane/irrational people. i bet nobody else can either. in practice we weigh up the risks and try to avoid systems that are attractive to abuse by sane rational people, and that's about the best we can do.
287 2014-08-25 14:36:07 <cfields> wumpus: if you're ok to merge the travis PR, i can plan to give it my attention today if anything acts up
288 2014-08-25 14:42:24 <dionyziz> What is the expected block generation time for testnet?
289 2014-08-25 14:45:04 <jgarzik_> dionyziz, same as mainnet, with one exception:  if 20 mins goes by without a block, you may mine one.
290 2014-08-25 14:46:34 <dionyziz> jgarzik_: ok! thank you :)
291 2014-08-25 15:18:20 <netg_> 72
292 2014-08-25 18:17:45 <alfacent> Can you please say a bit about Reorganize() function in the original version? What was it substitued with in later versions?
293 2014-08-25 18:26:41 <jonasbits> What do you think about this "turtle" icon to indicate 0 incoming connections http://i.imgur.com/bFr1TYo.png and the commit https://github.com/jonasbits/bitcoin/commit/8f77845ea810e048c794d1755ba05555b81213a1
294 2014-08-25 18:29:35 <gmaxwell> jonasbits: it's misleading, to americans the turtle would imply that this configuration was slow.
295 2014-08-25 18:29:40 <jgarzik> alfacent, look around ConnectBlock(), DisconnectBlock() and friends
296 2014-08-25 18:29:51 <gmaxwell> I wouldn't be surprised if a turtle has entirely different meanings in other cultures though.
297 2014-08-25 18:30:16 <jgarzik> I'm sure it's a sexual innuendo somewhere, in some niche community ;p
298 2014-08-25 18:30:33 <jgarzik> "I turtled him again last night!"
299 2014-08-25 18:31:08 <jrick> turtles are a delicacy in china
300 2014-08-25 18:33:48 <alfacent> jgarzik: cheers!
301 2014-08-25 18:36:17 <Luke-Jr> jrick: I have a turtle in my yard I'd love to try, but stupid America prohibits killing it
302 2014-08-25 18:38:44 <l337> hi, is there a php script in the open that redirects the user once the balance of a bitcoin addy is non-null (i.e. when there's an incoming transaction)
303 2014-08-25 18:40:29 <blast_> its unlikely theres one that serves JUST that specific functino, but im sure theres one that provides that as a subset of its other functionality
304 2014-08-25 18:41:17 <blast_> quickest best bet ould be sendfing blockchian.info a query
305 2014-08-25 18:42:02 <blast_> or if your using a bitcoin deamon to send rpc too
306 2014-08-25 18:42:06 <blast_> ILl write one for you if you buy me lunch ;D
307 2014-08-25 18:42:23 <blast_> Chipotle burrito bowl + chips and guac 11$
308 2014-08-25 18:42:55 <blast_> 0.0218 BTC
309 2014-08-25 18:43:16 <sipa> not here please
310 2014-08-25 18:43:39 <l337> where's my lunch ticket????
311 2014-08-25 18:45:19 <blast_> ill setup a chan specifically for btc-chiptole exchange ;D
312 2014-08-25 18:46:32 <Luke-Jr> l337: hopefully not, that sounds like a poorly designed system
313 2014-08-25 18:47:44 <Luke-Jr> classic case of "tell us what you want to do, not how you think you should do it"
314 2014-08-25 18:49:13 <gmaxwell> facepalm: https://bitcointalk.org/index.php?topic=756580.0
315 2014-08-25 18:51:07 <jgarzik> gmaxwell, but.. but.. they were password-protected keys!
316 2014-08-25 18:51:08 <jgarzik> ;p
317 2014-08-25 18:52:52 <blast_> so you mean I shouldnt be generating all my private keys from the seed word 'password' ?
318 2014-08-25 18:53:34 <blast_> Thats the lolz of some of these better then carbon-clone altcoins like Node
319 2014-08-25 18:54:02 <blast_> all your keys are generated off your 'password' but its just a 10 character pass.... I've seen some sites using 5 words or 10 words, but 10 chars the amount of overlap will be insane
320 2014-08-25 18:54:03 <Luke-Jr> sigh
321 2014-08-25 19:01:08 <blast_> ^   ^  bitcat
322 2014-08-25 19:01:08 <blast_> >'o'< does not approve
323 2014-08-25 19:09:18 <Luke-Jr> 
ACTION wonders how easy it would be to take advantage of QR codes' error correction to make a counterfeit address that looks similar to the real one in hopes the owner doesn't notice

324 2014-08-25 19:09:27 <gmaxwell> Luke-Jr: I like the person whos brainwallet was just stolen arguing with you that they're secure.
325 2014-08-25 19:09:40 <Luke-Jr> gmaxwell: lol, I didn't even notice it was the same person
326 2014-08-25 19:10:18 <gmaxwell> I did a double-take.
327 2014-08-25 19:10:37 <gmaxwell> Luke-Jr: you don't even need to do that, change the QR but leave the printed address showing the expected one.
328 2014-08-25 19:10:43 <Luke-Jr> heh
329 2014-08-25 19:11:17 <Luke-Jr> I'm almost glad these idiots get robbed. Except for the criminal getting the bitcoins. :p
330 2014-08-25 19:12:08 <Luke-Jr> 
ACTION ponders if it would be legal/moral to have a bot bruteforcing weak keys and discarding them as fees

331 2014-08-25 19:14:20 <jgarzik> theft+destruction of property?
332 2014-08-25 19:14:53 <jgarzik> have the bot send coins to /dev/null
333 2014-08-25 19:14:56 <jgarzik> j/k
334 2014-08-25 19:15:28 <blast_> eh it depends, when people are just being too lazy to take in the information its kind of their own fault, but there are more and more people trying to get into cryptos that are pretty computer illterate when it comes to anything other than a point and click gui
335 2014-08-25 19:15:29 <Luke-Jr> well, maybe it can be argued that weak keys is equivalent to leaving your property in the middle of a public street ;P
336 2014-08-25 19:15:49 <blast_> I feel like its more leaving your car unlcoked with alot of stuff inside in a major city
337 2014-08-25 19:16:25 <Luke-Jr> blast_: consider that there may be no clear owner of the bitcoins in this case - maybe the "thief" is just using the same address for donations
338 2014-08-25 19:16:36 <blast_> a good possibility
339 2014-08-25 19:16:40 <jgarzik> steal from the foolish and give to the burn
340 2014-08-25 19:16:58 <helo> if you were to grab the stereo and leave a note saying "someone's going to steal your stereo if you leave your car unlocked, so i took it to keep it safe. call me at xxx-xxx-xxxx and i'll give it to you."
341 2014-08-25 19:17:13 <Luke-Jr> helo: then you'd have to give it back :p
342 2014-08-25 19:18:02 <helo> you'd have to get a signmessage from the person that sent the bitcoin to that address to say "i gave my bitcoin to this guy, he is the right owner"
343 2014-08-25 19:18:39 <helo> at least some chance of recovery, versus none if a criminal takes it
344 2014-08-25 19:19:11 <Luke-Jr> helo: signmessage is not useful for that
345 2014-08-25 19:19:19 <Luke-Jr> you sign as receipient, not as sender
346 2014-08-25 19:19:32 <Luke-Jr> we don't have a standard for sender-signed messages
347 2014-08-25 19:20:08 <Luke-Jr> (I'm not sure it's clear there is a safe way to do so either)
348 2014-08-25 19:20:20 <helo> i suppose there isn't a straightforward (or always applicable) method
349 2014-08-25 19:20:45 <helo> e.g. if it was a coinjoin send
350 2014-08-25 19:55:38 <jonasbits> gmaxwell: i agree that the turtle is not a good choice, maybe a parasite (tick) is closer to the freeloader nature of listen=0, this i how it could look http://imgur.com/zffI0Fu
351 2014-08-25 19:57:08 <Luke-Jr> looks like a bug/error to me
352 2014-08-25 19:57:21 <Luke-Jr> brick wall might imply firewall
353 2014-08-25 19:57:26 <Luke-Jr> red brick*
354 2014-08-25 19:57:29 <gmaxwell> A node which is listen=0 is not a parasite, it doesn't contribute sockets to the network but it contributes in other ways.
355 2014-08-25 19:58:29 <jonasbits> helo: i have a slow adsl connection
356 2014-08-25 20:03:53 <jonasbits> gmaxwell: allright, turtle and parasite is not a good choice, brick wall is only good to indicate firewall, i would want something to let me know that listen=0 is active.
357 2014-08-25 20:06:07 <gmaxwell> http://awomanscomfort.com/images/monkeys/hear_no_evil.gif
358 2014-08-25 20:06:27 <jrick> haha
359 2014-08-25 20:06:48 <jonasbits> helo: im contemplating using maxconnections=12 instead of listen=0, but listen=0 is a simpler setting to understand for a average person
360 2014-08-25 20:11:34 <helo> if someone has listen=0 set, they probably don't need to be notified of it. it may mostly confuse the majority seeing it, who will fall in the later category (firewalled)
361 2014-08-25 20:15:25 <jonasbits> helo: yes i agree, but when Settings->Options->Network have a tick to set listen=0 or maxconnections=, then this could be something to consider
362 2014-08-25 20:19:33 <Luke-Jr> jonasbits: maybe don't show the icon if listen=0
363 2014-08-25 20:19:54 <Luke-Jr> ie, only show it if no inbound connections, listen=1 (and some time has passed?)
364 2014-08-25 20:23:29 <jonasbits> Luke-Jr: to indicate to the user that "maybe your upnp port forward was removed, take action if you want"
365 2014-08-25 20:24:25 <Luke-Jr> jonasbits: if they have listen=0, they don't have a upnp port forward
366 2014-08-25 20:25:57 <jonasbits> Luke-Jr: yeah sure, i was trying to play around with the idea not to show the icon if listen=0
367 2014-08-25 20:38:40 <michagogo> What about the way Bitmessage does it?
368 2014-08-25 20:38:58 <michagogo> You get a red dot with no (or only a few) outgoing connections
369 2014-08-25 20:39:06 <michagogo> A yellow dot if you have several outgoing
370 2014-08-25 20:39:12 <michagogo> And green with one or more incoming
371 2014-08-25 20:39:20 <michagogo> (with a mouse-over tooltip)
372 2014-08-25 20:39:35 <jonasbits> michagogo: that is good tought
373 2014-08-25 20:39:57 <gmaxwell> michagogo: you mean how it alreadt works?
374 2014-08-25 20:40:09 <michagogo> gmaxwell: hm?
375 2014-08-25 20:40:23 <gmaxwell> it has a little set of bars that follow criteria just like you described.
376 2014-08-25 20:40:28 <michagogo> We don't have something indicating if there are any incoming connections, do we?
377 2014-08-25 20:40:47 <jonasbits> gmaxwell: yeah, i didnt think about that,
378 2014-08-25 20:40:58 <gmaxwell> michagogo: we do, effectively.
379 2014-08-25 20:41:05 <michagogo> gmaxwell: How so?
380 2014-08-25 20:41:18 <sipa> <=8 vs >8
381 2014-08-25 20:41:29 <gmaxwell> michagogo: the bars cannot show full without incoming connections due to how the thresholds are set.
382 2014-08-25 20:41:33 <michagogo> Ahhh
383 2014-08-25 20:42:02 <michagogo> So the only thing missing is telling the user specifically that topping out at 8 means no incoming
384 2014-08-25 20:42:14 <jonasbits> so maybe maxconnections=8 is better then listen=0?
385 2014-08-25 20:42:36 <gmaxwell> better for what?
386 2014-08-25 20:42:51 <sipa> it is effectively identical, as soon as you have 8 outgoing connections
387 2014-08-25 20:42:52 <jonasbits> for me, with my slow adsl connection
388 2014-08-25 20:43:35 <gribble> The operation succeeded.
389 2014-08-25 20:43:35 <michagogo> ;;later tell jgarzik 2 things about the new bootstrap format... 1) You (or someone?) mentioned the possibility of adding a partial reindex option, to reindex only the position of blocks on disk. 2) Does the new linearize create an empty file with the next number when it's done? Both of those things, IMHO, should be there before switching the torrents over,
390 2014-08-25 20:43:35 <michagogo> to allow seeding in place
391 2014-08-25 20:44:31 <sipa> why the empty next file?
392 2014-08-25 20:45:00 <sipa> ah, you want it to continue there? that won't work; bitcoin core appends in the first file it has space in
393 2014-08-25 20:45:09 <michagogo> oh
394 2014-08-25 20:45:16 <sipa> i guess that means you must guarantee that all files have a minimum size too
395 2014-08-25 20:45:22 <michagogo> So that means that even the current format won't work
396 2014-08-25 20:45:29 <sipa> or it may start appending to old files again
397 2014-08-25 20:45:42 <michagogo> Okay, that's weird
398 2014-08-25 20:45:51 <michagogo> I would not expect that at all
399 2014-08-25 20:45:53 <sipa> let me check the code
400 2014-08-25 20:46:23 <gribble> The operation succeeded.
401 2014-08-25 20:46:23 <michagogo> ;;later tell jgarzik ...to allow seeding in place.
402 2014-08-25 20:46:30 <elichai2> petertodd, here?
403 2014-08-25 20:48:00 <sipa> michagogo: it does remember the last block file number in the index
404 2014-08-25 20:48:19 <sipa> and during reindex it iterates through all files, so perhaps that's enough
405 2014-08-25 20:48:53 <michagogo> And would it pick up an empty file and count that as the last block file?
406 2014-08-25 20:49:04 <michagogo> Or is it "the last file number that had a block"?
407 2014-08-25 20:49:24 <gmaxwell> michagogo: ugh. please take whatever time you'd spend trying to make seeding in place work and put it into testing headers first.
408 2014-08-25 20:49:52 <gmaxwell> Trying to make the torrent seed in place is super kludgy, isn't going to benefit more than a few people, and will be a PITA to maintain.
409 2014-08-25 20:50:42 <michagogo> Anyway, at this point I really should go to bed... it's 10 to midnight, and I need to be up early tomorrow
410 2014-08-25 20:50:45 <michagogo> so, goodnight
411 2014-08-25 20:51:47 <sipa> michagogo: it stores the last file that has a block it seems
412 2014-08-25 20:52:16 <sipa> gmaxwell: feel like having a look at secp256k1 #54 ?
413 2014-08-25 20:55:16 <Luke-Jr> sipa: +#define DEBUG_CHECK(cond) do { (cond); } while(0)
414 2014-08-25 20:55:26 <Luke-Jr> sipa: how is that different from #define DEBUG_CHECK(cond) cond
415 2014-08-25 20:55:28 <Luke-Jr> ?
416 2014-08-25 20:58:30 <sipa> it probably isn't!
417 2014-08-25 20:59:18 <sipa> there's a difference, but it would be pretty weird to matter: you shouldn't be able to write: x = DEBUG_CHECK(y)
418 2014-08-25 21:00:39 <Luke-Jr> sipa: aha, thanks
419 2014-08-25 21:02:35 <l337> what am I doing wrong? :( -> http://pastebin.com/YUU0CJV6
420 2014-08-25 21:04:28 <sipa> l337: this is not PHP 101
421 2014-08-25 21:10:19 <jintelletec> lookign for anyone who can help with a remote project. Need a strong C++,C++11 and crypto experience
422 2014-08-25 21:14:00 <hearn> jintelletec: i think there's a bitcoin jobs board somewhere. i can't remember what it's called there
423 2014-08-25 21:15:36 <blast_> isnt there a bitcoin jobs irc chan too
424 2014-08-25 21:21:09 <elichai2> petertodd, even was here in the past few days?
425 2014-08-25 21:22:06 <btcdrak> elichai2 he was here several hours ago
426 2014-08-25 21:24:12 <elichai2> btcdrak, why do i aways miss him :X
427 2014-08-25 21:24:21 <sipa> wrong timezone?
428 2014-08-25 21:24:30 <sipa> btw, you can also ping people in PM...
429 2014-08-25 21:24:36 <btcdrak> elichai2 remember he's in Canada...
430 2014-08-25 21:24:55 <btcdrak> or email
431 2014-08-25 21:25:11 <elichai2> yeah, this is why i'm getting in this hour(12 am here) and not in my regular hours lol
432 2014-08-25 21:25:21 <elichai2> btcdrak, i just need some help with one of his toold
433 2014-08-25 21:25:23 <elichai2> *tools
434 2014-08-25 21:25:38 <elichai2> (it's not really working as it supposed to be)
435 2014-08-25 21:26:31 <btcdrak> if I were you I'd email... I see you message here a few times a day lol.
436 2014-08-25 21:28:08 <elichai2> btcdrak, yeah lol
437 2014-08-25 22:27:18 <BlueMatt> who was the crazy chinese miner who fit all their blocks in a single udp packet?
438 2014-08-25 22:37:15 <poutine> https://github.com/syscoin/syscoin/blob/master/src/script.cpp#L628-637 <- OP_TUCK is listed as taking x1, and x2, and resulting in x2, x1, x2, which is incorrect as far as I can tell, isn't it just resulting in x1, x2, x2?
439 2014-08-25 22:37:18 <poutine> Oops
440 2014-08-25 22:37:22 <poutine> excuse the shitcoin link
441 2014-08-25 22:37:40 <poutine> https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L636-L644
442 2014-08-25 22:40:02 <sipa> the comment looks correct to me
443 2014-08-25 22:40:20 <sipa> it takes the top element, and inserts it before the element before it
444 2014-08-25 22:40:39 <l337_> can someone please tell me what I'm doing wrong? -> http://pastebin.com/raw.php?i=rJN30Yq6
445 2014-08-25 22:40:54 <l337_> it always shows me "your balance=0"
446 2014-08-25 22:41:13 <l337_> never the "nothing in teh wallet"
447 2014-08-25 22:41:28 <poutine> l337_, learn the difference between assignment and comparison operators
448 2014-08-25 22:41:32 <sipa> l337_: again, this is not PHP 101
449 2014-08-25 22:41:36 <poutine> also realize that PHP issues != bitcoin dev issues
450 2014-08-25 22:41:37 <gmaxwell> l337_: ah, I see where you're going wrong: asking bc.i and/or questions in this channel. You also misspelled the.
451 2014-08-25 22:42:31 <poutine> sipa, It looks like it grabs the stack #2 element, and inserts it after the #2 element
452 2014-08-25 22:42:45 <poutine> in which case, the result (since not popped) would be x1, x2, x2
453 2014-08-25 22:43:18 <sipa> x1 x2 x3 x4 is the stack
454 2014-08-25 22:43:24 <sipa> stacktop(-1) takes x4
455 2014-08-25 22:43:48 <sipa> inserts it at the position of end-2, which is the position of x3
456 2014-08-25 22:43:54 <sipa> shifting the rest forward
457 2014-08-25 22:43:57 <gmaxwell> It's like end for an iterator, it's past the end.