1 2014-10-27 00:00:16 <justanotheruser> It shouldn't be constrained to the last-received-address paying to the sidechain as I think Iriez was implying when he said 19:41 < Iriez> i was just thinking that zerocash as a sidechain would not improve privacy as when you convert it back to btc it would just go back to the original linked address?
  2 2014-10-27 00:02:52 <sipa> oh
  3 2014-10-27 00:02:55 <sipa> i missed that
  4 2014-10-27 00:02:57 <sipa> sorry
  5 2014-10-27 00:03:13 <sipa> no, the other side gets to specify who can unlock on the original side
  6 2014-10-27 00:06:11 <justanotheruser> I'm excited for sidechains to be OT in -wizards :)
  7 2014-10-27 00:12:18 <Iriez> So, then it CAN improve privacy?
  8 2014-10-27 00:12:42 <Iriez> you could conver to zerocash, and then back to btc, and retain the anonyminity?
  9 2014-10-27 00:13:23 <sipa> well yes, but that's not better than an advanced mixer
 10 2014-10-27 00:13:25 <justanotheruser> Iriez: you are anonymous within that set
 11 2014-10-27 00:13:35 <sipa> zerocash has actual anonimity, while the coins are there
 12 2014-10-27 00:13:43 <Iriez> basically, can you transfer btc to a sidechain, and then on the conversion back to btc have it be untainted towards the original sending address from parent to chain?
 13 2014-10-27 00:14:01 <Iriez> 'advanced mixer' = 3rd party
 14 2014-10-27 00:14:14 <Iriez> i was thinking of a decentralized way to mix coins.
 15 2014-10-27 00:14:21 <sipa> if you send it back to the original sender, you lose all advantage you hoped to gain
 16 2014-10-27 00:14:33 <sipa> at least send it to a new address of yourself (which you should be doing anyway...)
 17 2014-10-27 00:14:56 <Iriez> Yes, but within the proofs does the returning of funds to the parent chain require there to be a demonstratable link between the originating address?
 18 2014-10-27 00:15:22 <Iriez> is the information in the spv proof public, in that one could ascertain the returning funds are linked
 19 2014-10-27 00:15:37 <sipa> no
 20 2014-10-27 00:15:48 <Iriez> then thats super cool.
 21 2014-10-27 00:15:48 <sipa> you would obviously unlock different coins
 22 2014-10-27 00:16:01 <Iriez> (obviously, heh.)
 23 2014-10-27 00:16:05 <Iriez> obvious to you maybe :P
 24 2014-10-27 00:16:22 <sipa> well, otherwise it's sending coins into a mixer, and getting the same coins back
 25 2014-10-27 00:16:30 <sipa> that's not really helpful :p
 26 2014-10-27 00:17:00 <Iriez> yes, im just trying to analyze benefits of zerocash as a alt coin vs zerocash as a sidechain
 27 2014-10-27 00:17:16 <sipa> not needing an exchange
 28 2014-10-27 00:17:17 <justanotheruser> Iriez: it isn't completely known that if you put 1btc in and take 1btc out 10 minutes later that they're yours, but one can guess that they're yours fairly easily
 29 2014-10-27 00:17:34 <Iriez> yes, one could guess, but is there cryptographic proof?
 30 2014-10-27 00:17:43 <Iriez> demonstrable knowledge of taint.
 31 2014-10-27 00:17:48 <justanotheruser> you can construct one yourself
 32 2014-10-27 00:18:02 <justanotheruser> only for your own tx I mean
 33 2014-10-27 00:18:12 <Iriez> construct through circumstancial evidence, or crypto proof?
 34 2014-10-27 00:18:22 <Iriez> just because A sent one and B received one is not proof
 35 2014-10-27 00:18:59 <justanotheruser> Iriez: I am saying only the person transacting those coins can construct a proof
 36 2014-10-27 00:19:05 <Iriez> Ah, okay
 37 2014-10-27 00:19:16 <Iriez> yes, because only they have the keys to publish the info
 38 2014-10-27 00:19:53 <sipa> cryptography isn't relevant; even in bitcoin today nobody can prove that you own coins after sending them to a new address
 39 2014-10-27 00:20:12 <sipa> you could have sent them to yourself or to someone else
 40 2014-10-27 00:20:20 <Iriez> yes, but there's a trail, and that is proof
 41 2014-10-27 00:20:27 <Iriez> im asking if there is _no trail_
 42 2014-10-27 00:20:32 <Iriez> is the taint removed.
 43 2014-10-27 00:20:33 <sipa> there is no trail
 44 2014-10-27 00:20:39 <Iriez> :)
 45 2014-10-27 00:21:18 <Iriez> so then the real risk is that if you send your coisn to the sidechain, the only way you can lose them is if that chain is 51% attacked or you expose your keys somehow
 46 2014-10-27 00:21:31 <sipa> or you're the only one using the sidechain :p
 47 2014-10-27 00:21:46 <Iriez> Yea, but that'd be silly :P
 48 2014-10-27 00:22:22 <sipa> well, if government outlaws the use to the zerocoin sidechain, and the only ones using it will still be outlaws
 49 2014-10-27 00:22:33 <sipa> trail or no trail
 50 2014-10-27 00:22:47 <Iriez> i doubt they could do that (USA). financial privacy is not a crime
 51 2014-10-27 00:23:14 <Iriez> regulators might attempt to prevent it on county or state levels, but federally i doubt it would/could ever happen
 52 2014-10-27 00:23:17 <justanotheruser> Iriez: the thing about outlawing something is that it makes it a crime
 53 2014-10-27 00:23:58 <Iriez> I want to outlaw outlawing, so all outlaws become civilians.
 54 2014-10-27 00:36:27 <helmholtz> Hello all. I'm trying to build bitcoin 0.9.3 from source on ubuntu 12.04 and having trouble. I am getting the following error when running make
 55 2014-10-27 00:36:33 <helmholtz> In file included from util.cpp:71:0: /usr/include/boost/program_options/detail/config_file.hpp: In instantiation of ‘bool boost::program_options::detail::basic_config_file_iterator<charT>::getline(std::string&) [with charT = char; std::string = std::basic_string<char>]’: util.cpp:1437:1:   required from here /usr/include/boost/program_options/detail/config_file.hpp:163:13: error: ‘to_internal’ was not declared in this
 56 2014-10-27 00:36:49 <helmholtz> if anyone can point me in the right direction it would be greatly apprecaited
 57 2014-10-27 02:11:07 <cilo> q
 58 2014-10-27 08:26:13 <Luke-Jr> 
ACTION wonders why the Mac build succeeded with miner_tests missing

 59 2014-10-27 08:50:18 <wumpus> it doesn't test anything
 60 2014-10-27 08:52:52 <sipa> but for the others, it's building that fails
 61 2014-10-27 08:53:01 <sipa> ah, maybe the test isn't even built on osx
 62 2014-10-27 08:55:02 <sipa> wumpus: i'm trying to get libsecp256k1 in a state where i'm fine with it being used for signing in bitcoin core (which shouldn't be security critical, as we'd still use openssl for verifying that what is signed is valid)
 63 2014-10-27 08:57:54 <Luke-Jr> wumpus: surely it should still *build* the tests?
 64 2014-10-27 09:01:30 <wumpus> sipa: okay, makes sense to do that as first step for secp256k1 integration
 65 2014-10-27 09:03:02 <wumpus> Luke-Jr: right, that's what you'd expect - I don't see anything excluding *building* the tests in .travis.yml
 66 2014-10-27 09:03:24 <wumpus> the only effect of RUN_TESTS is that it will run make check
 67 2014-10-27 09:20:21 <Luke-Jr> wumpus: anything I can rebase or otherwise do before I go to sleep, to help get things merged? ;)
 68 2014-10-27 09:22:57 <wumpus> Luke-Jr: #5077?
 69 2014-10-27 09:23:39 <Luke-Jr> k, 1 min
 70 2014-10-27 09:35:46 <Luke-Jr> sipa: wumpus: re leveldb update - does it break downgrading?
 71 2014-10-27 09:35:53 <sipa> Luke-Jr: shouldn't
 72 2014-10-27 09:36:09 <wumpus> Luke-Jr: from my review of the leveldb changes: no , haven't tested though
 73 2014-10-27 09:36:10 <Luke-Jr> I assume someone competent reviewed it for potential problematic fixes?
 74 2014-10-27 09:36:17 <Luke-Jr> k
 75 2014-10-27 09:36:26 <sipa> i went over the changes yes, there's nothing fundamental
 76 2014-10-27 09:36:49 <sipa> going from old to new or new to old will result in the existing bloom filters to be ignored
 77 2014-10-27 09:36:51 <wumpus> it will not recognize the bloom filter type, but that just means it will ignore it
 78 2014-10-27 09:36:56 <wumpus> exacly
 79 2014-10-27 09:37:05 <sipa> so you may see a short performance reduction after upgrade or downgrade
 80 2014-10-27 09:38:42 <wumpus> Luke-Jr: then again - headers-first changes, which are in the same release, can break downgrading
 81 2014-10-27 09:38:50 <Luke-Jr> they can? :o
 82 2014-10-27 09:39:09 <Luke-Jr> how so? :|
 83 2014-10-27 09:39:20 <wumpus> Luke-Jr: see https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md
 84 2014-10-27 09:40:03 <wumpus> both the block files and the index are potentially not backward compatible after syncing with 0.10
 85 2014-10-27 09:40:17 <sipa> if not fully synced, headersfirst can break stuff
 86 2014-10-27 09:40:20 <wumpus> the utxo set should be ok
 87 2014-10-27 09:40:24 <Luke-Jr> "Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards." <-- shouldn't it just reindex? O.o
 88 2014-10-27 09:40:37 <Luke-Jr> and wouldn't it be fine as long as it's synced?
 89 2014-10-27 09:40:45 <wumpus> Luke-Jr: reindex can't cope with out-of-order blocks in 0.9
 90 2014-10-27 09:40:56 <Luke-Jr> why not? O.o
 91 2014-10-27 09:41:04 <wumpus> Luke-Jr: so make a backup
 92 2014-10-27 09:41:08 <Luke-Jr> oh well, can't fix the past I guess.. but strange
 93 2014-10-27 09:42:15 <Luke-Jr> wumpus: 5077 rebased with change requested
 94 2014-10-27 09:43:21 <wumpus> Luke-Jr: I guess you can get quite far with a reindex after downgrade - it will just ignore blocks that it can't accept, so there will be a bit of waste of space, but after that it will just start resyncing
 95 2014-10-27 09:43:41 <Luke-Jr> I would have thought it'd put them in the orphan pool
 96 2014-10-27 09:43:49 <wumpus> no, orphans are network code only
 97 2014-10-27 09:43:52 <sipa> Luke-Jr: and use 25 GB of ram?
 98 2014-10-27 09:43:58 <Luke-Jr> sipa: exactly!
 99 2014-10-27 09:44:05 <sipa> 
ACTION has only 24 GB in his laptop :(

100 2014-10-27 09:44:13 <Luke-Jr> me too
101 2014-10-27 09:44:22 <Luke-Jr> but thankfully, the blockchain is in-order most of the way for me :P
102 2014-10-27 09:44:40 <Luke-Jr> ("me too" being <25 GB; only 16 GB here)
103 2014-10-27 11:12:27 <jtimon> coryfields_ wumpus regarding #5112, should I make the changes proposed or only add the comment?
104 2014-10-27 11:13:30 <wumpus> jtimon: you shouldn't make the changed proposed there
105 2014-10-27 11:13:49 <wumpus> indeed, just add a comment why the order is as it is
106 2014-10-27 11:14:32 <wumpus> coryfields made a mistake in his comment, which he acknowledges later on
107 2014-10-27 11:15:16 <jtimon> thanks, just wanted to be sure
108 2014-10-27 11:17:33 <t7> 24 gig in your laptop :O
109 2014-10-27 11:31:12 <sipa> wumpus: ugh, why does serialize.h need to have a special case for CScript
110 2014-10-27 11:31:30 <sipa> it's pretty ugly that our lowest level headers-only file depends on a core data structure...
111 2014-10-27 11:31:52 <sipa> seems there's not really a solution to that except making CScript not inherit from vector
112 2014-10-27 11:31:59 <sipa> ... which seems like a bad idea anyway
113 2014-10-27 11:32:10 <sipa> you shouldn't extend stl contains
114 2014-10-27 11:32:43 <Luke-Jr> you shouldn't?
115 2014-10-27 11:33:01 <wumpus> right, it would be good to split the script logic between data storage and functions that act on it
116 2014-10-27 11:33:19 <sipa> yes, that too, but that's not what i mean
117 2014-10-27 11:33:35 <sipa> i mean have a CScript that just has a vector as member, rather than extending it
118 2014-10-27 11:33:47 <wumpus> couldn't we move the parts of serialize.h that depend on CScript to where CScript is declared?
119 2014-10-27 11:33:49 <Luke-Jr> wumpus: that's the whole point of classes in C++ ! :P
120 2014-10-27 11:33:51 <jtimon> sipa I assume you prefer composition in this case? Or just CScript to not depend on std::vector at all?
121 2014-10-27 11:34:02 <sipa> jtimon: i mean composition, indeed
122 2014-10-27 11:34:11 <sipa> wumpus: nope
123 2014-10-27 11:34:52 <sipa> wumpus: because script extends vector, and serialize has a special case for vector, you get an ambiguous template error without an explicit case for CScript too
124 2014-10-27 11:35:28 <wumpus> Luke-Jr: no, it's not - the point of classes is to allow abstracting interfaces, there's nothing that forces every single data item to be a self-contained class
125 2014-10-27 11:35:43 <wumpus> sipa: ugh, right
126 2014-10-27 11:36:01 <sipa> jtimon: at some point having a Cscript that does not fix the storage layer at all, which would be nice for example for a CTransaction that just uses a single allocated blob for all scripts and inputs and outputs
127 2014-10-27 11:36:01 <sipa> jtimon: but that's a larger change
128 2014-10-27 11:37:12 <wumpus> Luke-Jr: forcing every script operation to act on a CScript (or std::vector) can force dynamic allocation where it's not needed, ie in cases where the operation could be done in-memory in-place
129 2014-10-27 11:37:59 <Luke-Jr> forced dynamic allocation where it's not needed is kinda what C++ does <.<
130 2014-10-27 11:38:07 <wumpus> on a (start,size) "slice" of memory
131 2014-10-27 11:38:30 <Luke-Jr> sure, we could do it that way, but then it's just C :p
132 2014-10-27 11:38:54 <wumpus> Luke-Jr: there is nothing in c++ forcing you to do that, you can use C++ as a better C (which allows RAII and such)
133 2014-10-27 11:39:09 <Luke-Jr> I know ☺
134 2014-10-27 11:39:34 <jtimon> I was planning on separating the OPs in (inlined?) functions on script/interpreter in a similar way as in https://github.com/jgarzik/bitcoin/commit/78edf5cb8cf65caf38080ac57040469cc9c6957f for p2p messages
135 2014-10-27 11:39:57 <Luke-Jr> just expressing that it feels ugly to separate data store from actions on that data store, in C++ ; if it still makes sense to do it, that's another matter
136 2014-10-27 11:39:59 <jtimon> but I guess that's after the inheritance -> composition change in CScript
137 2014-10-27 11:41:18 <Luke-Jr> otoh, I guess CScript's "data" could just be pointers to other data just as well - maybe that's what you had in mind
138 2014-10-27 11:41:49 <wumpus> Luke-Jr: yes, just a pointer and size
139 2014-10-27 11:44:25 <wumpus> Luke-Jr: leveldb has the leveldb::slice type for this
140 2014-10-27 11:54:24 <jtimon> github says #5100 needs manual rebase but but it doesn't
141 2014-10-27 11:58:59 <b-itcoinssg> Are these still valid instructions for creating and submitting tests  https://github.com/bitcoin/QA/blob/master/TestPlanCreation.md
142 2014-10-27 11:59:10 <b-itcoinssg> or is there a newer versin
143 2014-10-27 11:59:13 <b-itcoinssg> version*
144 2014-10-27 12:00:13 <b-itcoinssg> it doesn't seem to have been updated since jan 2013
145 2014-10-27 12:02:34 <wumpus> b-itcoinssg: yes, still as valid as ever
146 2014-10-27 12:02:58 <wumpus> feel free to submit pulls to that repository if you feel things are out of date
147 2014-10-27 12:03:26 <sipa> heh, i forgot we had that
148 2014-10-27 12:04:49 <b-itcoinssg> ok
149 2014-10-27 12:07:30 <sipa> jtimon: 5100 doesn't merge cleanly here
150 2014-10-27 12:07:53 <sipa> merge conflict in txmempool
151 2014-10-27 12:15:46 <jtimon> sipa, ok, not anymore, I had just rebased on top of d9702bcf Merge pull request #5115
152 2014-10-27 12:23:21 <Adlai> "a chain with more work which does not include the block which created the output" - does this need to include every transaction in the first block(s) of the DMMS, to prove that the output in question was not present?
153 2014-10-27 12:23:45 <Adlai> (from line 208, page 8 of http://www.blockstream.com/sidechains.pdf )
154 2014-10-27 12:25:04 <sipa> Adlai: for a reorg proof it suffices to show that another chain exists, which does not include the claimed block
155 2014-10-27 12:26:24 <Adlai> sipa: couldn't the transaction to the SPV-locked output have made it into a block in the second chain too?
156 2014-10-27 12:26:36 <jtimon> it may actually include the same transaction but i the block doesn't exist in another longesr chain the SPV proof is not valid
157 2014-10-27 12:27:07 <sipa> indeed; the original SPV proof is refuted by the reorg proof; the original sender can always come up with a new SPV proof for the new block, if that does include the transaction too
158 2014-10-27 12:27:57 <sipa> (which is overall way cheaper than needing to give the entire list of txids in the block)
159 2014-10-27 12:30:11 <Adlai> ok, that makes sense. so in a situation where a reorganization happens but there's no double-spend attempt, the entity that provided the now-invalid SPV proof will be incentivized to produce the new proof, to be able to spend in the sidechain?
160 2014-10-27 12:33:42 <Adlai> 
ACTION wonders also whether transferring assets through an atomic swap would be cheaper or not; on one hand, the atomic swap transactions themselves are smaller, and require smaller fees; but liquidity providers could charge for the convenience of not waiting the confirmation and contest periods

161 2014-10-27 12:34:31 <wumpus> it wouldn't necessarily be cheaper, just faster
162 2014-10-27 12:35:01 <Luke-Jr> Adlai: in ideal situations, nobody would bother with a reorg proof for an output that remains valid in both chains
163 2014-10-27 12:35:45 <Luke-Jr> … unless failure to do so would result in the sidechain believing it lost bitcoins …
164 2014-10-27 12:37:26 <jtimon> note that this is applicable to SPV wallets as well, if they receive a longer header chain, now they want new proofs of inclusion for their transaction in the new merkle tree
165 2014-10-27 13:01:47 <Adlai> could a reorg proof be strengthened to a "fraud proof" by including cryptographic proof of a different transaction spending the same input used in the original SPV proof, proving that a double spend was attempted?
166 2014-10-27 13:02:56 <Adlai> the original transaction becomes invalid by having its input(s) spent elsewhere, thus proving exclusion from the reorganized chain
167 2014-10-27 13:04:50 <Luke-Jr> Adlai: what's the point?
168 2014-10-27 13:05:53 <Luke-Jr> Adlai: even if the reorg doesn't double-spend it, you still want to cancel the redemption
169 2014-10-27 13:11:42 <Adlai> fewer proofs in the fraud-free case, an inclusion proof would be considered valid unless an _ex_clusion proof could be produced
170 2014-10-27 13:12:53 <Adlai> although I guess SPV proof -> reorg proof -> new SPV proof is more watertight
171 2014-10-27 13:19:13 <b-itcoinssg> in https://github.com/bitcoin/bitcoin/tree/master/qa/rpc-tests, what does "Bash-based tests, to be ported to Python:" mean? Are you asking someone to do it or preparing people for code that is on its way(i.e already written)?
172 2014-10-27 13:19:31 <sipa> afaik nobody is doing that
173 2014-10-27 13:19:58 <b-itcoinssg> ok, good to hear
174 2014-10-27 13:20:11 <b-itcoinssg> I'll probably start there
175 2014-10-27 13:48:44 <gavinandresen> b-itcoinssg: porting the bash tests to the python test_framework.py style of doing things is an excellent place to start!
176 2014-10-27 13:49:23 <gavinandresen> b-itcoinssg: I started in bash to try to minimize dependencies, but it is just too painful to write tests in bash (too many weird quoting rules to remember, too much weird syntax....)
177 2014-10-27 13:50:21 <b-itcoinssg> gavinandersen: excellent
178 2014-10-27 13:50:23 <b-itcoinssg> will do
179 2014-10-27 14:02:56 <wumpus> yes, bash code is just too fragile, and it becomes a mess if you want robust error handling; and then you have the people that insist on not using bash but some other shell, making things even worse
180 2014-10-27 14:04:27 <helo> 
ACTION insists on using a ruby interpreter to execute the python test framework

181 2014-10-27 14:06:33 <wumpus> helo: yes, phew, let's be happy that ruby and python don't have (usable) language subset that is valid in both and everything becomes restricted to using
182 2014-10-27 14:40:48 <helo> pthere is a language subset between python 2 and python 3 that fits that criteria, but few people restrict themselves to it
183 2014-10-27 14:41:31 <wumpus> yes
184 2014-10-27 14:49:31 <wumpus> maybe for CScript it makes sense to split into multiple concerns a) Building scripts (ScriptBuilder? MutableScript?) b) Holding script data in data structures, this could just be a typedeffed std::vector<unsigned char> c) A read-only script type to pass to IsPayToScriptHash, IsPushOnly, EvalScript and such, the backing does not need to be a std::vector, but can easily be converted from one, like a leveldb::slice
185 2014-10-27 18:09:32 <chmod755> There was an error submitting the translation.   Reload   <- is it just me or is there an issue with Transifex?
186 2014-10-27 18:29:52 <coryfields_> sipa: ping wrt the above cscript complaint
187 2014-10-27 18:37:38 <coryfields_> sipa: i've been working on a storage class that wraps std vector/array, with the intention of creating a "tagged binary storage" concept for common classes. imo it'd help a good bit with modularization, but others may see it as too much abstraction overhead
188 2014-10-27 18:44:55 <extor> coryfields in PHP?
189 2014-10-27 18:45:46 <coryfields_> ?
190 2014-10-27 18:59:06 <extor> Is there any way of doing coding gigs without signing up at a miserable place like guru or freelancer? I'm assuming you have to be 1) Chummy with some well financed operation and 2) Extremely advanced in a narrow niche and/or with 10-20 years of experience turning out quality apps or 3) Willing to code for the "ewwww tier" operations like camwhore sites, spam factories and captcha farms?
191 2014-10-27 18:59:06 <extor> Just looking for people who need some decent coding done
192 2014-10-27 19:04:45 <justanotheruser> extor: if you have experience apply to some bitcoin companies? Theres also getafreelancer. This should probably be discussed in #bitcoin-otc though.
193 2014-10-27 19:11:40 <extor> otc is offtopic?
194 2014-10-27 19:11:57 <justanotheruser> extor: this is a bitcoin development discussion channel
195 2014-10-27 19:15:32 <extor> bitcoin apps are usually quite complex
196 2014-10-27 19:15:37 <extor> and fine tunes
197 2014-10-27 19:15:41 <extor> especially the mining apps
198 2014-10-27 19:18:00 <BlueMatt> wumpus: which of jgarzik's commits were signed with that key?
199 2014-10-27 19:18:35 <BlueMatt> wumpus: his most recent few merges were unsigned
200 2014-10-27 19:24:21 <BlueMatt> someone want to reopen #5028
201 2014-10-27 19:37:39 <wumpus> BlueMatt: a0a8700 135a43d 76bc6cb 309aa76 and quite a few more
202 2014-10-27 19:41:27 <BlueMatt> wumpus: thanks, I just didnt see him signing any recent commits, so I moved on
203 2014-10-27 19:44:33 <BlueMatt> jgarzik: can you use a semi-consistent pgp key?
204 2014-10-27 19:45:03 <BlueMatt> @exmulti (which is the one on bitcoin.org) hasnt even signed @pobox (which you appear to be using to sign commits)
205 2014-10-27 19:45:09 <BlueMatt> also, there is the @bitpay one...
206 2014-10-27 19:48:02 <chmod755> <chmod755> There was an error submitting the translation.   Reload   <- is it just me or is there an issue with Transifex? << repeating myself
207 2014-10-27 20:24:16 <dgenr8> BlueMatt: you're a fast reader ;)
208 2014-10-27 20:24:46 <BlueMatt> dgenr8: skim + relate to existing ideas :p
209 2014-10-27 20:25:45 <dgenr8> your concern is that double-spend information is local, because not relayed?
210 2014-10-27 20:26:20 <BlueMatt> its local, because speed-of-light
211 2014-10-27 20:26:26 <BlueMatt> but also not relayed
212 2014-10-27 20:27:49 <dgenr8> then i'm surprised you aren't bothered that node's clock is also local ;)
213 2014-10-27 20:28:17 <BlueMatt> there is a large margin for error there, which is ok
214 2014-10-27 20:28:31 <BlueMatt> if it werent for that, then, yes, I'd be very bothered
215 2014-10-27 20:29:09 <dgenr8> thanks BlueMatt
216 2014-10-27 20:29:41 <gmaxwell> dgenr8: he's complaining about attacks where you send all competing miners random double spends. all concurrently, then laugh all the way to the bank as they orphan each other. (and worse enjoy the fireworks as all the non-mining users are confused by the network constantly reorging)
217 2014-10-27 20:30:16 <gmaxwell> (and even if they are agressively connecting to everything, there is always some amount of race where you didn't notice quite fast enough.
218 2014-10-27 20:30:19 <gmaxwell> )
219 2014-10-27 20:30:37 <wumpus> chmod755: possible, although I've not heard other complaints about transifex yet
220 2014-10-27 20:32:32 <dgenr8> gmaxwell: i'm impressed that all those miners were able to generate blocks simultaneously
221 2014-10-27 20:34:31 <gmaxwell> dgenr8: I didn't say that had. An abusive party can make nodes widely ignore varrious blocks, this will result in reorgs as other blocks are created later (e.g. the attacker's blocks)
222 2014-10-27 20:36:31 <dgenr8> if I were a miner, I'd avoid the whole mess and not include any double-spends at all (except much older ones)
223 2014-10-27 20:38:18 <gmaxwell> 
ACTION facepalm

224 2014-10-27 20:38:37 <gmaxwell> dgenr8: so you'll include no transactions then?
225 2014-10-27 20:39:55 <gmaxwell> Someday you will understand that the network is not synchronous, and that you will not have any idea that something is a double-spend for some window of time while other people do. ... if it were somehow synchronous there would be no need for mining at all.
226 2014-10-27 20:40:23 <dhill> i have $50 in the bank
227 2014-10-27 20:40:33 <dhill> i write a check for $50 at the store
228 2014-10-27 20:40:43 <dhill> i wriet a second check for $50 at a different store
229 2014-10-27 20:40:47 <dhill> :)
230 2014-10-27 20:41:35 <gmaxwell> (If I was unclear above about including no transactions: The only way to be sure you will not mine something which doesn't exist conflicted elsewhere, known to other parties, is to mine nothing at all)
231 2014-10-27 20:42:20 <dgenr8> That can happen today
232 2014-10-27 20:42:35 <dgenr8> and i don't propose trying to prevent it
233 2014-10-27 20:43:09 <BlueMatt> wumpus: so..what you're saying is...you want to close #2293?
234 2014-10-27 20:43:41 <dgenr8> after 30 seconds, everybody agrees pretty well (and I quantify this).  After 0 seconds, not so much.
235 2014-10-27 20:43:44 <wumpus> BlueMatt: huh, yes that's been fixed with the leveldb upgrade
236 2014-10-27 20:44:07 <BlueMatt> wumpus: :)
237 2014-10-27 23:22:03 <brocktice> Hi all, is there a dedicated trezor channel?