1 2014-09-03 00:05:37 <jgarzik> Luke-Jr, "makes more sense" depends on your perspective
  2 2014-09-03 00:05:45 <jgarzik> Luke-Jr, built-in miner is all I use for testnet
  3 2014-09-03 00:12:05 <iamsatoshi> My fellow disciples, I have arisen from the ashes
  4 2014-09-03 00:18:50 <imton> after months away from bitcoin development, did someone finally created a decentralized/escrow exchange?
  5 2014-09-03 00:21:48 <gmaxwell> 2/kb iamsatoshi
  6 2014-09-03 00:37:20 <phantomcircuit> imton, decentralization and escrow are kind of at odds
  7 2014-09-03 00:37:30 <phantomcircuit> it's at best an open market for escrow services
  8 2014-09-03 00:38:14 <imton> ok, does it exists?
  9 2014-09-03 00:42:40 <phantomcircuit> imton, openbazaar does exist, how safe/sane it is ... well that's another question entirely
 10 2014-09-03 00:53:13 <GandalfGreyHat> Howdy, I'm looking for a way to verify someone owns an address via a website easily without requiring them to make an account.
 11 2014-09-03 00:54:05 <GandalfGreyHat> I understand there's a way to sign messages with your private key somehow, but is there a way that a verification check can be made on said messages via automatic means or a script?
 12 2014-09-03 00:56:23 <GandalfGreyHat> Actually, my idea is dumb, I just figured out a way I can do what I'm trying to do without the need for that.
 13 2014-09-03 00:57:16 <GandalfGreyHat> Would it be better for me to require users always send from the same send address or have a way for users to make accounts on the site? If I'm trying to make it as easy as possible to tie isolated transactions back to one individual?
 14 2014-09-03 03:53:11 <phantomcircuit> gmaxwell, does the pull tester build windows binaries?
 15 2014-09-03 03:53:19 <phantomcircuit> BlueMatt, ^?
 16 2014-09-03 03:53:29 <Luke-Jr> phantomcircuit: pretty sure yes
 17 2014-09-03 03:53:36 <Luke-Jr> phantomcircuit: usually it has a download link for those even
 18 2014-09-03 03:53:44 <BlueMatt> phantomcircuit: yes, it did
 19 2014-09-03 03:54:10 <Luke-Jr> BlueMatt: past tense?
 20 2014-09-03 03:55:24 <BlueMatt> well, it used to do lots of things, but its been borked for a long time and its being phased out because it sucks....
 21 2014-09-03 04:03:53 <phantomcircuit> BlueMatt, is the bitcoind.exe here http://jenkins.bluematt.me/pull-tester/p4790_7838ae88a9a66b84621f5d3076d1cf194178ba45/out/
 22 2014-09-03 04:04:00 <phantomcircuit> actually a build of #4790 ?
 23 2014-09-03 04:04:08 <BlueMatt> if its linked from the pull, yes
 24 2014-09-03 04:04:19 <phantomcircuit> ok
 25 2014-09-03 04:14:59 <phantomcircuit> BlueMatt, er why is it 90MB
 26 2014-09-03 04:16:29 <BlueMatt> strip difference?
 27 2014-09-03 04:17:01 <phantomcircuit> BlueMatt, also it crashes when run from cmd.exe on windows 8.1
 28 2014-09-03 04:22:45 <BlueMatt> phantomcircuit: that sucks
 29 2014-09-03 04:22:59 <BlueMatt> phantomcircuit: again, unsupported, unupdated in much time, probably broken in many ways
 30 2014-09-03 04:23:38 <BlueMatt> phantomcircuit: cfields is working on getting the builds from travis to be downloadable
 31 2014-09-03 04:27:47 <phantomcircuit> BlueMatt, i assume building for windows is now only supported in gitian or something?
 32 2014-09-03 04:29:31 <BlueMatt> phantomcircuit: no, its only supported in mingw
 33 2014-09-03 04:29:38 <BlueMatt> ./configure figures it out properly
 34 2014-09-03 05:30:00 <lechuga_> let's say im writing my own bitcoin node and releasing it open source
 35 2014-09-03 05:30:36 <lechuga_> what's the best license that i can have in terms of personal protection from litigation while at the same time promoting maximum liability-free usage?
 36 2014-09-03 05:30:48 <lechuga_> personal/organizational
 37 2014-09-03 05:33:11 <poutine> whatever license you feel is best
 38 2014-09-03 05:33:27 <poutine> for legal advice, see a lawyer
 39 2014-09-03 05:36:56 <justanotheruser> lechuga_: MIT
 40 2014-09-03 05:36:59 <justanotheruser> probably
 41 2014-09-03 05:37:43 <justanotheruser> though, you should look into the problems with altclients, mainly netsplit https://bitcointalk.org/index.php?topic=260595.0
 42 2014-09-03 05:38:24 <dgenr8> what keeps a joker from constantly broadcasting every unconfirmed tx he has ever seen, trying to grow mempools?
 43 2014-09-03 05:38:46 <justanotheruser> dgenr8: #bitcoin
 44 2014-09-03 05:38:47 <phantomcircuit> dgenr8, whatever policy the peers implement
 45 2014-09-03 05:40:10 <dgenr8> i guess i'm suprised not to have seen this, or seen it described happening in the wild
 46 2014-09-03 05:40:41 <justanotheruser> dgenr8: well the peers you're connected to must not have a policy that allows spam
 47 2014-09-03 05:41:03 <justanotheruser> which is probably because they are running a vanilla reference client
 48 2014-09-03 05:41:40 <lechuga_> dgenr8: it would get rejected from every immediate node
 49 2014-09-03 05:41:46 <lechuga_> so it wouldnt propagate
 50 2014-09-03 05:41:52 <lechuga_> and would fill no mempools afaict
 51 2014-09-03 05:42:14 <dgenr8> reference client collects a great deal of non-confirming crud in 2 months http://mempool.info
 52 2014-09-03 05:43:22 <justanotheruser> dgenr8: seems to only have a handful of tx per day from more than 3 days ago
 53 2014-09-03 05:43:49 <lechuga_> how would he relay enough to grow the mempool to a material size if it wont exceed the utxo set size anyway
 54 2014-09-03 05:44:10 <lechuga_> he (sic attacker)
 55 2014-09-03 05:44:11 <dgenr8> good point
 56 2014-09-03 05:44:56 <justanotheruser> lechuga_: he's saying relaying unconfirmed tx anyways, so the unconfirmed tx might be spending unconfirmed tx or doublespending since we are already allowing spam
 57 2014-09-03 05:46:09 <lechuga_> that's true unconfirmed spends could still propagate but how would doublespends be allowed in the mempool
 58 2014-09-03 05:46:27 <dgenr8> orphans are at least limited
 59 2014-09-03 05:46:55 <justanotheruser> lechuga_: we are imagining a world where spamming is possible, right
 60 2014-09-03 05:47:07 <justanotheruser> anyways, replace by fee would make that possible at a cost
 61 2014-09-03 05:47:39 <lechuga_> yeah
 62 2014-09-03 05:49:09 <dgenr8> justanotheruser: which spam protection are you thinking of?
 63 2014-09-03 05:49:36 <lechuga_> justanotheruser: thx re: btctalk link
 64 2014-09-03 05:49:38 <justanotheruser> dgenr8: not allowing people to send tx about without a cost?
 65 2014-09-03 05:49:53 <lechuga_> also remarkably apropos
 66 2014-09-03 05:50:13 <justanotheruser> dgenr8: or at least not allowing too many free tx to be sent at a time
 67 2014-09-03 05:52:33 <dgenr8> so an upper bound may be (utxo size + orphan limit) per node
 68 2014-09-03 05:53:18 <justanotheruser> you can make spam much bigger than the utxo if there is no spam prevention
 69 2014-09-03 05:53:53 <justanotheruser> for example, if there was no spam prevention, I could make a 900kb tx with a 100 byte output
 70 2014-09-03 05:54:06 <justanotheruser> so maybe multiply the utxo by 9000
 71 2014-09-03 05:54:42 <dgenr8> yes, i just meant in terms of # of txes.
 72 2014-09-03 05:55:20 <justanotheruser> if you have the spam prevention of preventing doublespends and "softspends" (some coredevs don't like that word for reasons I forget) then yes
 73 2014-09-03 05:58:17 <justanotheruser> certainly isn't ideal to let the mempool be 10000 times the size of the utxo
 74 2014-09-03 05:59:40 <dgenr8> gathering up unsuccessful spends will only work against as small fraction of utxo though
 75 2014-09-03 06:00:14 <justanotheruser> unsuccessful spends?
 76 2014-09-03 06:02:36 <dgenr8> non-confirming spends observed, remembered, and rebroadcast.   otherwise attacker needs to manufacture his own utxos at a cost
 77 2014-09-03 06:03:26 <lechuga_> justanotheruser: this thread seems kind of ridiculous
 78 2014-09-03 06:03:44 <lechuga_> none is ever supposed to write an alternate implementation?
 79 2014-09-03 06:03:47 <lechuga_> noone*
 80 2014-09-03 06:04:14 <sipa> justanotheruser: what is a 'softspend'? I have never heard that word, I think.
 81 2014-09-03 06:04:20 <lechuga_> on the grounds that they cant possibly get it right
 82 2014-09-03 06:04:31 <lechuga_> wasnt bitcoind designed to be a reference implementation
 83 2014-09-03 06:04:36 <justanotheruser> lechuga_: was talking to a few people yesterday about this. Seems the consensus is they should use satoshi consensus code if they make an alt-client
 84 2014-09-03 06:04:52 <lechuga_> im for that, which would need to incldue a modular script runner
 85 2014-09-03 06:04:59 <justanotheruser> sipa: the way I've heard it use is spending an unconfirmed tx
 86 2014-09-03 06:05:01 <sipa> lechuga_: working on it!
 87 2014-09-03 06:05:05 <lechuga_> nice
 88 2014-09-03 06:06:09 <sipa> well, not me specifically, but there was an earlier PR to add a libbitcoinscript.so/dll build output with a stable API, that can validate scripts
 89 2014-09-03 06:06:27 <lechuga_> that was matt's wasnt it
 90 2014-09-03 06:06:30 <sipa> indeed
 91 2014-09-03 06:06:42 <lechuga_> well i'd immediately adopt it
 92 2014-09-03 06:06:49 <sipa> consensus is more than just scripts, but it's certainly the part that's easiest to get wrong
 93 2014-09-03 06:06:58 <lechuga_> nod
 94 2014-09-03 06:08:08 <sipa> the PR is closed now because of some refactorings to go in first, but i hope to see it again soon
 95 2014-09-03 06:13:58 <lechuga_> if alt-impls ran matt's tool and PT did something useful like add tests to it when he finds alt-impl forks the landscape would be a bit more friendly no?
 96 2014-09-03 06:14:32 <lechuga_> at least more accomodating of a more heterogeneous network
 97 2014-09-03 06:14:33 <sipa> eventually, i suppose
 98 2014-09-03 06:14:42 <lechuga_> which should fundamentally be more healthy
 99 2014-09-03 06:15:06 <sipa> but we're unlikely to randomly run into many of the potential consensus-splitting behaviours
100 2014-09-03 06:15:20 <sipa> as they are most likely things noboby ever considered
101 2014-09-03 06:15:25 <sipa> judging from previous experiences
102 2014-09-03 06:15:39 <lechuga_> if we write tests for known methods it's at least a start at a comprehensive regression suite
103 2014-09-03 06:15:55 <sipa> fair enough; i couldn't hurt
104 2014-09-03 06:16:00 <sipa> *it
105 2014-09-03 06:16:56 <sipa> but consensus systems are strange... it's true that a more heterogenous network is more healthy in that failure of one implementation means less impact
106 2014-09-03 06:17:28 <lechuga_> it's a complex system but i dont think it' insurmountably so. altho look at sendmail's history.
107 2014-09-03 06:17:30 <sipa> but on the other hand, N implementations means O(N^2) different ways in which they could fail to interact with eachother
108 2014-09-03 06:17:35 <lechuga_> lol
109 2014-09-03 06:17:39 <lechuga_> gp
110 2014-09-03 06:17:57 <lechuga_> but on that basis we'd all be using IE
111 2014-09-03 06:17:59 <midnightmagic> plus new versions..
112 2014-09-03 06:18:14 <sipa> lechuga_: me using a different browser has never threatended the internet; just myself
113 2014-09-03 06:18:31 <justanotheruser> sipa: isn't that O(MN)?
114 2014-09-03 06:18:34 <lechuga_> well akamai and google dont use apache for everything either
115 2014-09-03 06:18:34 <midnightmagic> IE doesn't notice if you write a netscape that can't parse IE javascript
116 2014-09-03 06:18:50 <justanotheruser> M being the number of operations needed to evaluate tx and blocks?
117 2014-09-03 06:19:09 <sipa> justanotheruser: no, i mean the interaction between implementation A and implementation B can fail
118 2014-09-03 06:19:20 <justanotheruser> sipa: in one of M ways
119 2014-09-03 06:19:33 <sipa> if there are N self-consistent implementations, there are O(N^2) potential different interactions
120 2014-09-03 06:19:47 <sipa> sure, add some constants; this is all handwavy anyway
121 2014-09-03 06:20:01 <poutine> Is there a formal process for approving something like this: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05675.html
122 2014-09-03 06:20:12 <poutine> It's gavin's proposal to relax nonstandard limits on p2sh transactions
123 2014-09-03 06:20:19 <sipa> poutine: already done
124 2014-09-03 06:20:21 <justanotheruser> sipa: you're right
125 2014-09-03 06:20:36 <poutine> sipa, I cannot send nonstandard tx as p2sh and get it relayed without finding a miner
126 2014-09-03 06:20:51 <poutine> the IsStandard() checks apply to the serialized p2sh script
127 2014-09-03 06:20:56 <sipa> poutine: because it's not in a release, but git master follows the rules outlined by gavin there
128 2014-09-03 06:21:25 <poutine> 
ACTION double checks but is on master

129 2014-09-03 06:22:30 <poutine> sipa, https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L595-L598
130 2014-09-03 06:23:12 <sipa> poutine: outputs have to be standard...
131 2014-09-03 06:23:42 <sipa> but in P2SH, the output only contains the script hash
132 2014-09-03 06:23:47 <poutine> sipa, the proposal is to allow nonstandard txouts
133 2014-09-03 06:23:48 <sipa> which is always standard
134 2014-09-03 06:23:59 <sipa> no, the proposal is to allow nonstandard redeemscripts
135 2014-09-03 06:24:39 <poutine> How could you tell a nonstandard from standard p2sh.. the hashes would not be the same
136 2014-09-03 06:24:47 <sipa> you can't
137 2014-09-03 06:24:54 <sipa> the code you're referring to is irrelevant for p2sh
138 2014-09-03 06:25:17 <poutine> c8b86e0dcfe3a1dd48c99ee4b5ddf6172a552303e7f338d49124e060caf62d09
139 2014-09-03 06:25:37 <poutine> That's a P2SH tx I made with a nonstandard out, I could relay the HASH160 <hash> OP_EQUAL without help
140 2014-09-03 06:25:42 <blah> hye
141 2014-09-03 06:25:46 <poutine> but the redemption had to be specially mined
142 2014-09-03 06:26:05 <sipa> poutine: yes, as there is no miner yet running the 0.10 code...
143 2014-09-03 06:26:27 <sipa> or the rest of the network, for that matter, to relay it to miners
144 2014-09-03 06:27:54 <poutine> I guess I understand, I just am not sure why that code I just pointed to in master is NOT going against gavin's propsal there
145 2014-09-03 06:28:12 <sipa> do you understand the difference between scriptPubKey and redeemscript?
146 2014-09-03 06:29:09 <poutine> I understand what a scriptPubKey is, and what a scriptSig is
147 2014-09-03 06:29:25 <sipa> scriptPubKey is the script as it exists, _literally_ in the txout
148 2014-09-03 06:29:40 <sipa> in the case of P2SH, the scriptPubKey is HASH160 <hash> OP_EQUAL
149 2014-09-03 06:29:49 <sipa> _that_ must be standard
150 2014-09-03 06:29:58 <poutine> Ok
151 2014-09-03 06:30:02 <poutine> I understand now
152 2014-09-03 06:30:13 <sipa> it does not know or care what the redeemscript referred to by the p2sh hash is
153 2014-09-03 06:30:35 <sipa> however, there is separate code for doing standardness tests on inputs
154 2014-09-03 06:30:47 <poutine> It's just I compile master, and while I have not compiled in maybe the last month, the redemption with the nonstandard redeem was rejected
155 2014-09-03 06:30:48 <sipa> which in the case of P2SH does apply some checks in addition
156 2014-09-03 06:30:52 <poutine> because the serialized script was nonstandard
157 2014-09-03 06:31:13 <poutine> but I trust you know what you're talking about so I will research more
158 2014-09-03 06:31:51 <poutine> I also understand the miner situation with 0.10, but this is my mempool I'm talking about
159 2014-09-03 06:31:56 <sipa> i see
160 2014-09-03 06:32:13 <sipa> maybe it was from before the p2sh relaxing patch was merged?
161 2014-09-03 06:32:25 <poutine> perhaps, I will research more, thanks for explaining
162 2014-09-03 06:32:41 <sipa> also, still not every script will be allowed
163 2014-09-03 06:32:51 <sipa> in particular, there are still size and sigop constraints
164 2014-09-03 06:36:15 <BlueMatt> cfields: are we not statically linking qt anymore?
165 2014-09-03 06:36:19 <BlueMatt> (in releases)
166 2014-09-03 06:37:31 <cfields> BlueMatt: depends on the OS, and which bitcoin version
167 2014-09-03 06:37:48 <BlueMatt> the linux builds linked from bitcoin.org
168 2014-09-03 06:37:53 <BlueMatt> in the latest versions
169 2014-09-03 06:37:58 <cfields> windows is always static. osx will be when the gitian descriptors merge goes in. linux are all dynamic
170 2014-09-03 06:38:05 <BlueMatt> wat?
171 2014-09-03 06:38:12 <BlueMatt> when did we switch to dynamic qt on linux?
172 2014-09-03 06:38:26 <BlueMatt> or anything dynamic on linux
173 2014-09-03 06:39:32 <cfields> been that way as long as i've been around, afaik
174 2014-09-03 06:48:50 <BlueMatt> naaa, everything was 100% static before autotools
175 2014-09-03 06:49:16 <BlueMatt> not because its right, of course, but because its practical, and prevents dumb crap like https://github.com/bitcoin/bitcoin/issues/4799#issuecomment-53978821
176 2014-09-03 06:51:17 <cfields> BlueMatt: wouldn't have been that, i've argued (and PR'd) static qt several times
177 2014-09-03 06:51:25 <cfields> but there are several good reasons not to
178 2014-09-03 06:53:00 <cfields> BlueMatt: bitcoin builds/links fine against static/dynamic qt4/qt5. all that matters is how gitian is setup to build it
179 2014-09-03 06:53:15 <BlueMatt> hmm, well we had to be static in the wx era as we were using an unsupported version, and I know before autotools gitian was static
180 2014-09-03 06:53:24 <BlueMatt> ie the RELEASE flag was STATIC=1
181 2014-09-03 06:53:31 <BlueMatt> which static'd everything
182 2014-09-03 06:53:55 <cfields> but that was when the .pro was used as well
183 2014-09-03 06:54:20 <cfields> so it still would've depended on how qt itself was built
184 2014-09-03 06:55:17 <cfields> maybe you're right, i dunno. "since i've been around" pretty much lines up with the autotools change :)
185 2014-09-03 07:01:30 <BlueMatt> is that the only thing we dynamically link for release?
186 2014-09-03 07:02:58 <cfields> yes
187 2014-09-03 07:03:11 <BlueMatt> why is it special?
188 2014-09-03 07:03:12 <cfields> well, and glibc/libstdc++
189 2014-09-03 07:03:16 <BlueMatt> sure, sure
190 2014-09-03 07:03:41 <cfields> because qt uses plugins to integrate with desktop managers
191 2014-09-03 07:05:43 <cfields> BlueMatt: see https://github.com/bitcoin/bitcoin/pull/4727
192 2014-09-03 07:06:10 <cfields> it was originally static qt5, but moved back to qt4 after discussion there
193 2014-09-03 07:06:28 <BlueMatt> indeed, though was there any need to go before 4.8?
194 2014-09-03 07:06:52 <BlueMatt> does 4.8 use the same plugin model?
195 2014-09-03 07:06:56 <cfields> yea, debian/redhat/centos/tails/etc
196 2014-09-03 07:07:07 <BlueMatt> hmm?
197 2014-09-03 07:07:21 <BlueMatt> you mean for dynamic, is there any reason to go before 4.8 static?
198 2014-09-03 07:08:23 <cfields> 4.x static wouldn't be any benefit. either 4.x shared for most compat, or 5.x static to drop the dependency and upgrade
199 2014-09-03 07:09:57 <BlueMatt> it would be, then we wouldnt have to touch 4.6 or the issues there
200 2014-09-03 07:10:06 <BlueMatt> we could use an actually up-to-date version
201 2014-09-03 07:10:58 <cfields> 4.x static doesn't allow for plugins, maybe that's where we're losing eachother?
202 2014-09-03 07:12:03 <BlueMatt> is there any use for plugins?
203 2014-09-03 07:12:26 <cfields> see the link above, wumpus linked some images
204 2014-09-03 07:12:30 <BlueMatt> I mean afaict, the difference is 5.X uses magical plugins to make things work, 4.X doesnt
205 2014-09-03 07:12:38 <BlueMatt> yea, I thought it worked on 4.X static?
206 2014-09-03 07:12:55 <wumpus> 4.x static has no benefits
207 2014-09-03 07:13:03 <wumpus> no it doesn't, it doesn't work for any static qt
208 2014-09-03 07:13:08 <BlueMatt> ahhh, ok
209 2014-09-03 07:13:08 <cfields> no, static qt disables plugin support, it assumes you build it exactly how you want users to se it
210 2014-09-03 07:13:10 <BlueMatt> thats the disconnect
211 2014-09-03 07:13:26 <BlueMatt> 4.X static clearly has benifits over using an os-provided 4.6.OLD_AND_BROKEN
212 2014-09-03 07:13:42 <BlueMatt> but, ok
213 2014-09-03 07:13:48 <wumpus> old, not broken
214 2014-09-03 07:14:06 <cfields> BlueMatt:  in that case, 5.x static is the way to go. 4.x static really doesn't make sense to target
215 2014-09-03 07:14:25 <wumpus> cfields: right
216 2014-09-03 07:15:18 <BlueMatt> cfields: sure, I was under the impression 4.X didnt have plugin things at all and the idea of plugins to make things work with your os was a 5.X thing
217 2014-09-03 07:16:29 <wumpus> yes, in 4.x it was normal for distros to just hack Qt into pieces instead of providing plugins :-) that doesn't help the static case, tho
218 2014-09-03 07:16:30 <cfields> BlueMatt: nope. ubuntu (and others i'm sure) started patching it in in 4.x, it was fully mainlined in 5.2 iirc.
219 2014-09-03 07:17:14 <cfields> er... 5.3
220 2014-09-03 07:18:54 <wumpus> anyhow there is no ideal solution for the qt problem on linux
221 2014-09-03 07:19:28 <cfields> wumpus: i swear i didn't bring it up :)
222 2014-09-03 07:20:17 <wumpus> but indeed, the choice is betweens 4.old dynamic or 5.newest static
223 2014-09-03 07:24:45 <BlueMatt> ok, ok, sorry to bring it back up
224 2014-09-03 07:32:49 <cfields> BlueMatt: np, was just joking with wumpus because we discussed it earlier
225 2014-09-03 07:52:52 <BlueMatt> I may get the cake for pull which touched the most files with #4830
226 2014-09-03 07:53:16 <extor> Inspirational, http://www.norvig.com/21-days.html
227 2014-09-03 09:18:50 <btcdrak> Has anyone see this oddity? http://www.reddit.com/r/Bitcoin/comments/2fbtb8/im_running_couple_of_full_nodes_and_noticed_a/
228 2014-09-03 09:46:31 <wumpus> I don't understand why we have a MilliSleep(50) in StopNode
229 2014-09-03 09:49:48 <sipa> haha
230 2014-09-03 09:50:26 <wumpus> bitcoind sleeps too much, it should at least get as little sleep as I do
231 2014-09-03 09:51:25 <sipa> wumpus: i have a branch that doesn't keep spent-and-never-written entries in the coinscache... extrapolating it should he able to do a full reindex with ~1.5G of memory, with nothing written to disk
232 2014-09-03 09:52:09 <wumpus> sipa: nice!
233 2014-09-03 09:52:49 <sipa> testing now
234 2014-09-03 09:54:13 <wumpus> BlueMatt: I don't mind changing from one MIT license to another, but do we really have to touch every damn file :p
235 2014-09-03 09:54:28 <BlueMatt> wumpus: im not changing the license, actually
236 2014-09-03 09:54:40 <BlueMatt> wumpus: I'm making the headers match the license
237 2014-09-03 09:55:08 <wumpus> hmm... but what is the real license, the one in the header or the one in the global copying file
238 2014-09-03 09:55:11 <BlueMatt> (and I dont feel comfortable going the other way because it gets less restrictive, so I'd want to ask /everyone/)
239 2014-09-03 09:55:30 <BlueMatt> I suggest it doesnt matter as long as one is clearly strictly more restrictive
240 2014-09-03 09:55:39 <BlueMatt> and expat it, it simply adds an extra clause that x11 does not have
241 2014-09-03 09:55:50 <wumpus> but why a more restrictive license? what clause?
242 2014-09-03 09:56:20 <BlueMatt> oops, wait...
243 2014-09-03 09:56:55 <BlueMatt> yea, I had it backwards
244 2014-09-03 09:56:59 <wumpus> let's switch to LGPL while we're at it *ducks*
245 2014-09-03 09:58:53 <wumpus> at least the README.md could be updated to *what* MIT license, I personally never knew there was more than one
246 2014-09-03 10:00:11 <kdomanski> wumpus: I think the names of those licenses are very non-formal
247 2014-09-03 10:00:48 <Arnavion> Could just use APL 2.0 and get copyright assignment for free
248 2014-09-03 10:04:05 <sipa> wumpus: i once got lectured by RMS about which MIT licenses existed, when trying to explain which one we used in bitcoin...
249 2014-09-03 10:04:21 <wumpus> at least the consensus code should be licensed under the most free license possible
250 2014-09-03 10:04:50 <wumpus> sipa: oh!
251 2014-09-03 10:05:10 <BlueMatt> ok...sooo. Our headers say "MIT/X11" which refers to the license in our COPYING file EXCEPT for an additional clause which is included in the X11 license:
252 2014-09-03 10:05:11 <BlueMatt> "Except as contained in this notice, the name(s) of the above copyright holders shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization."
253 2014-09-03 10:05:55 <BlueMatt> additionally, the specific license used in X11 refers explicitly to X Consortium
254 2014-09-03 10:06:19 <BlueMatt> the clause quoted above is from wikipedia, which replaces "X Consortium" with "name(s) of the above copyright holders"
255 2014-09-03 10:06:55 <BlueMatt> however, in the expat license's main block, "THE X CONSORTIUM" is replaced with "AUTHORS OR COPYRIGHT HOLDERS"
256 2014-09-03 10:07:05 <BlueMatt> which I think is more consistent since we dont name all authors
257 2014-09-03 10:07:24 <BlueMatt> thus, for consistency, I propose we add the following clause to the COPYING file:
258 2014-09-03 10:07:29 <BlueMatt> "+
259 2014-09-03 10:07:29 <BlueMatt> +Except as contained in this notice, the name of the authors or copyright
260 2014-09-03 10:07:29 <BlueMatt> +from the authors or copyright holders.
261 2014-09-03 10:07:29 <BlueMatt> +holders shall not be used in advertising or otherwise to promote the sale,
262 2014-09-03 10:07:29 <BlueMatt> +use or other dealings in this Software without prior written authorization
263 2014-09-03 10:07:30 <BlueMatt> "
264 2014-09-03 10:08:05 <wumpus> cfields: as for the macosx sdk, can't we (ab)use their cache to store that on travis itself?
265 2014-09-03 10:08:48 <wumpus> BlueMatt: would make sense
266 2014-09-03 10:09:42 <wumpus> BlueMatt: I'm not opposed to adding that clause, and in practice we've already been licsensing our code under it so ..
267 2014-09-03 10:10:28 <BlueMatt> wumpus: https://github.com/bitcoin/bitcoin/pull/4832
268 2014-09-03 10:11:28 <BlueMatt> actually
269 2014-09-03 10:11:33 <wumpus> btcdrak: there appears to be at least one party experimenting with opening multiple connections per node, not sure for what purpose
270 2014-09-03 10:12:01 <btcdrak> wumpus, but with 1.6TB of data?
271 2014-09-03 10:12:04 <BlueMatt> ok
272 2014-09-03 10:12:52 <wumpus> btcdrak: if they're requesting data it's probably real nodes
273 2014-09-03 10:13:15 <wumpus> none of the sniffer nodes is actually interested in blocks, they just listen for invs
274 2014-09-03 11:19:57 <sipa> wumpus: it's closer to 2GB, but does seem to work :)
275 2014-09-03 11:21:49 <wumpus> sipa: well that the ccoinscache entries take up more memory than expected we already knew :)
276 2014-09-03 11:22:38 <sipa> the earlier number was an extrapolation; must be that later transactions are larger on average
277 2014-09-03 11:23:13 <wumpus> they certainly are
278 2014-09-03 11:23:55 <sipa> and dumping everything to leveldb at the end made it spike to 2.7
279 2014-09-03 11:26:47 <wumpus> heh
280 2014-09-03 11:26:57 <wumpus> one big batch
281 2014-09-03 11:27:11 <sipa> yes, one batch of the entire UTXO set :)
282 2014-09-03 11:34:15 <wumpus> does anyone perhaps know if there is any tool on linux to support generating 'stub' libraries, ie shared libraries that can be used to link against (w/ a certain interface provided by a real library) but don't contain the actual code
283 2014-09-03 11:34:49 <sipa> 
ACTION looks in cfields' direction

284 2014-09-03 11:35:04 <wumpus> I've already asked him :)
285 2014-09-03 11:41:00 <hearn> wumpus: yes
286 2014-09-03 11:41:24 <hearn> wumpus: i wrote one years ago. it may be bitrotted but it basically allowed you to use regular code as if it was linking against a library directly, but the library was actually loaded via dlopen
287 2014-09-03 11:41:41 <hearn> you could test for presence of symbols before invoking them, control what happened if a stub was invoked etc
288 2014-09-03 11:42:08 <hearn> does that sound like what you want?
289 2014-09-03 11:43:24 <hearn> 
ACTION tries to find it

290 2014-09-03 11:44:25 <wumpus> hearn: hmm it's in the same direction, but not exactly... what I need is a way to generate a dummy library from a map file basically. This map file is, in turn, generated either from an existing .so library or in the same build process. The resulting library can only be used to link against and does not provide any functionality
291 2014-09-03 11:45:24 <hearn> i think you could just use it and not load the underlying library, perhaps. though i think the tool tries to load the underlying lib by default.
292 2014-09-03 11:45:36 <hearn> well, anyway, it's here: http://listaller.tenstral.net/docs/relaytool-howto.html
293 2014-09-03 11:45:38 <hearn> https://gitorious.org/listaller/autopackage-legacy/source/179c382bd30682ed1e525bd1494ead0ce42abbe8:apbuild/relaytool
294 2014-09-03 11:46:10 <hearn> i have absolutely no clue if it still works on modern linuxes. as you can see the first version is about a decade old, though it was apparently updated up until 2007
295 2014-09-03 11:50:41 <wumpus> thanks' I'll take a look
296 2014-09-03 11:51:27 <hearn> what's the goal?
297 2014-09-03 11:56:53 <wumpus> well the idea would be to link against a certain well-defined interface, instead of local libraries, for compatibilty with different distributions
298 2014-09-03 11:57:45 <hearn> that's what relaytool was designed to help solve. about a decade ago i was working on the problem of distributing binaries to linux users
299 2014-09-03 11:57:47 <wumpus> (without having to build those versions of the libraries, or copying them from a running system)
300 2014-09-03 11:57:58 <hearn> version skew in the libraries, what's available, what's not etc, binary compatibility problems with glibc
301 2014-09-03 11:58:04 <hearn> i wrote solutions for lots of them
302 2014-09-03 11:58:27 <hearn> you can say "only load the symbols used in these files", for example.
303 2014-09-03 11:58:47 <hearn> of course you still have a bit of manual work. if some linux users have feature X and others don't, well, you need to be able to fall back gracefully at runtime no matter what
304 2014-09-03 11:59:14 <wumpus> currently we just build all the libraries, which is ok for small libraries, but has some overhead for a monster like qt
305 2014-09-03 11:59:33 <hearn> you mean build in gitian?
306 2014-09-03 12:00:05 <wumpus> yes, for example
307 2014-09-03 12:00:14 <hearn> generally it should "just work" without any special hacks, unless the header files of the library magically rewrite your code to "upgrade it". GTK and glibc were always terrible for that. this is where the "you must compile on the oldest distro you care about" black magic came from
308 2014-09-03 12:01:16 <hearn> for C++ it can be difficult to do this though because you end up linking against pieces of data and not just functions. relaytool has some support for this but i can't remember how well it worked.
309 2014-09-03 12:01:23 <hearn> i'd just copy the libraries
310 2014-09-03 12:01:39 <wumpus> well, we do that right now, but I was hoping there would be a way to avoid this
311 2014-09-03 12:02:22 <wumpus> indeed, it would also have to handle pieces of data, not just functions (although the content of the data itself doesn't matter because it's never used)
312 2014-09-03 12:03:06 <hearn> *shrug* probably not worth the effort. the binaries aren't that big, are they? copying them should not be a big deal. stripping the code from the ABI definition seems like a lot of work for little gain. for relaytool it was worth it because we wanted the same binary to adapt gracefully to different distro and library versions.
313 2014-09-03 12:03:22 <hearn> but if there won't be any runtime adaptation and it's just about compile times, i'd just go with binary copies
314 2014-09-03 12:03:51 <wumpus> well we can't copy the binary, everything has to be built from source... the intermediate binaries are cached, but it's some overhead just to have an interface
315 2014-09-03 12:04:22 <hearn> they have to be built from source, why? you can hard-code the library hashes, right
316 2014-09-03 12:04:34 <wumpus> right, I had hoped there was just some obscure option to objcopy to do this
317 2014-09-03 12:05:15 <wumpus> if it involves reviving ancient code it's indeed not worth it, was asking just in case, I don't want to spend much time on it
318 2014-09-03 12:05:32 <hearn> ok
319 2014-09-03 12:05:49 <hearn> in theory relaytool should still work, the ELF ABI is a stable standard. but i haven't tried it
320 2014-09-03 12:05:54 <hearn> (lately)
321 2014-09-03 12:06:31 <wumpus> the oracle compiler dues support it :p http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter2-22.html
322 2014-09-03 12:08:31 <hearn> right, solaris
323 2014-09-03 12:08:57 <hearn> is this impacting your productivity? i thought gitian builds were only made at release time. perhaps the foundation can set up a compile farm
324 2014-09-03 12:09:32 <sipa> ideally, we're able to test all supported platforms exactly as they would be at release
325 2014-09-03 12:09:50 <sipa> otherwise you encounter things like using some old GCC compiler unsupported feature way too late
326 2014-09-03 12:10:32 <wumpus> hearn: well both gitian and the travis tester (will) use the new depends mechanism
327 2014-09-03 12:11:18 <hearn> oh,travis is going to be compiling qt over and over? that's suboptimal
328 2014-09-03 12:11:28 <wumpus> hearn: so this is something called every few minutes, not just before releases (though the stub libraries wouldn't impact the median build times, as said, intermediate libraries are cached)
329 2014-09-03 12:11:49 <wumpus> no, it's actually caching it (just like it would have to when statically linking)
330 2014-09-03 12:12:07 <hearn> ok
331 2014-09-03 12:12:25 <wumpus> I'm just interested in it
332 2014-09-03 12:13:22 <hearn> relaytool is a pretty funny piece of code. it's a bash script that generates a C file which has inline assembly stubs.
333 2014-09-03 12:13:25 <hearn> :)
334 2014-09-03 12:13:29 <hearn> it was nice to use though!
335 2014-09-03 12:16:11 <wumpus> well sure it has to generate something that can be compiled back to a library, so a C file with inline assembly stubs makes sense
336 2014-09-03 12:17:21 <wumpus> that's closest to a working solution you'll get with GNU tools, with LLVM it could be solved more elegantly by generating bytecode and compiling that to a library directly
337 2014-09-03 12:19:53 <hearn> yeah. i so do not miss screwing around with c/c++ toolchains ....
338 2014-09-03 12:21:33 <wumpus> well of course it'd be possible to write the ELF library directly, there's no need to generate any code just symbols, not rocket science but pretty masochistic
339 2014-09-03 12:21:58 <hearn> as a veteran of working directly with ELF, yes masochistic is definitely the right word to use :)
340 2014-09-03 12:23:05 <hearn> https://github.com/wine-mirror/wine/blob/master/loader/preloader.c
341 2014-09-03 12:23:05 <hearn> i wrote the first version of this program (it was rewritten later but worked in substantially the same way)
342 2014-09-03 12:23:17 <hearn> probably the nastiest bit of ELF/address space/linker hacking i've ever seen
343 2014-09-03 12:27:48 <wumpus> "The goal of this program is to be a workaround for exec-shield, as used by the Linux kernel distributed with Fedora Core and other distros." hah, the most torturous code works around voluntarily added restrictions
344 2014-09-03 12:29:07 <hearn> yeah that was fun
345 2014-09-03 12:29:15 <hearn> i remember hacking on it on a transatlantic flight
346 2014-09-03 12:29:21 <hearn> running notepad would fail like one time in three
347 2014-09-03 12:29:28 <hearn> non-deterministic program startup yay!
348 2014-09-03 12:53:18 <wumpus> LOL https://github.com/bitcoin/bitcoin/pull/4833#issuecomment-54290819
349 2014-09-03 12:54:39 <sipa> let's have a look at git blame
350 2014-09-03 12:55:09 <wumpus> sometimes I'm not sure I want to work on bitcoin's codebase anymore :)
351 2014-09-03 12:56:23 <wumpus> don't blame gavinandresen, he just changed the Sleep to MilliSleep :p
352 2014-09-03 12:56:36 <sipa> i know
353 2014-09-03 12:56:42 <sipa> the sleep was put there by s_nakamoto
354 2014-09-03 12:56:45 <sipa> that bastard
355 2014-09-03 12:56:46 <wumpus> ooohhh
356 2014-09-03 13:00:38 <wumpus> there used to be logic above there to wait for threads to exit, I guess it was part of that
357 2014-09-03 13:00:52 <sipa> yup
358 2014-09-03 13:04:56 <sipa> loi, the million bitcoin question
359 2014-09-03 13:06:15 <sipa> jgarzik: not an expert, but i believe a license restriction is allowed by MIT; you're basically making a derived work with a more restrictive but compatible license
360 2014-09-03 13:06:46 <sipa> jgarzik: while, assuming the implied license was the more restrictive version, loosening would require acknowledgement from copyright holders
361 2014-09-03 13:07:37 <jgarzik> sipa, mixing two things
362 2014-09-03 13:08:00 <jgarzik> sipa, I can incorporate MIT code in my GPL project.  That is fine according to license, going to a more restrictive project.
363 2014-09-03 13:08:20 <jgarzik> sipa, Changing the same code's license is a bit different
364 2014-09-03 13:09:14 <sipa> ok, that's possible
365 2014-09-03 13:10:01 <jgarzik> sipa, BlueMatt's PR looks like a license change according to all my experience with Red Hat lawyers and copyright.  We had a lot of these issues in the kernel, making sure included code (often MIT etc.) was properly copyrighted, and going through the arduous process of contacting authors if not.
366 2014-09-03 13:11:20 <jgarzik> usually it was the old-BSD with advertising clause that needed changing to a better license without advertising clause.  Can't just relicense BSD code, as permissive a license as it is.
367 2014-09-03 13:17:03 <wumpus> so the advertising clause, innocent as it looks, is a problem?
368 2014-09-03 13:22:30 <jgarzik> wumpus, changing the license is a problem, regardless of the text
369 2014-09-03 13:22:44 <jgarzik> wumpus, and it -is- a license change in that PR
370 2014-09-03 13:23:12 <wumpus> the license is completely unclear though
371 2014-09-03 13:23:45 <sipa> wait, where does the more restrictive version come from then?
372 2014-09-03 13:24:20 <sipa> if the source files, the COPYING file, and the linked license text are identical?
373 2014-09-03 13:24:29 <wumpus> good question, where does the MIT/X11 text come from
374 2014-09-03 13:24:31 <jgarzik> sipa, from BlueMatt's brain :)
375 2014-09-03 13:24:55 <wumpus> eh not only, all the source files mention MIT/X11 in their header
376 2014-09-03 13:24:59 <jgarzik> wumpus, clear or unclear makes no difference from the perspective of "is it a license change?  if yes, we must get permission from copyright holders" etc.
377 2014-09-03 13:25:01 <wumpus> his first pull was to change those around
378 2014-09-03 13:25:20 <wumpus> maybe that was the better choice
379 2014-09-03 13:25:31 <jgarzik> it sounds like people are getting confused by labels
380 2014-09-03 13:25:35 <wumpus> https://github.com/bitcoin/bitcoin/pull/4830
381 2014-09-03 13:26:22 <jgarzik> The license _text_ in COPYING and link matches
382 2014-09-03 13:26:39 <jgarzik> If people want to bike shed over licensing _naming_, feel free.  I vote we call it the "nam-shub license."
383 2014-09-03 13:26:57 <wumpus> I don't want to bike-shed about this at all
384 2014-09-03 13:27:13 <sipa> ah, each file said it was MIT/X11, while the COPYING text and linked text were MIT/Expat?
385 2014-09-03 13:27:47 <wumpus> if it's fine as it is I'd prefer to keep it as it is, it was just like it looked like an inconsistency...
386 2014-09-03 13:28:08 <wumpus> sipa: yes
387 2014-09-03 13:28:17 <jgarzik> wumpus, sipa, No.  "Expat" adds a clause, and is a license change.
388 2014-09-03 13:28:28 <jgarzik> if it adds a clause, it's not the same license.
389 2014-09-03 13:28:34 <sipa> jgarzik: yes, not arguing with that
390 2014-09-03 13:28:47 <wumpus> Expat adds a clause? I thought X11 does?
391 2014-09-03 13:28:49 <sipa> just trying to see where the idea came from that there were 2 different licenses in the first place
392 2014-09-03 13:28:52 <wumpus> ok, never mind, I'll keep out of this
393 2014-09-03 13:29:14 <sipa> and it seems it's just because each file says "Licensed under MIT/X11"
394 2014-09-03 13:29:28 <jgarzik> sipa, yes
395 2014-09-03 13:29:37 <sipa> so, not BlueMatt's brain
396 2014-09-03 13:30:04 <sipa> anyway, i have no idea about legal value of these
397 2014-09-03 13:30:09 <sipa> but i wouldn't just dismiss it :)
398 2014-09-03 13:30:27 <jgarzik> sipa, wumpus: The only viable fix AFAICS is simply removing the "/X11" string from each file.
399 2014-09-03 13:30:52 <sipa> people may argue that that is a license change too
400 2014-09-03 13:30:56 <wumpus> so you do admit something is wrong
401 2014-09-03 13:31:21 <sipa> but IANAL, and i agree that it's likely that the link and COPYING text has more legal value than the name of license in files
402 2014-09-03 13:31:22 <jgarzik> sipa, They would be wrong.  The license _text_ has always been the same, both in COPYING and at the link.
403 2014-09-03 13:31:35 <wumpus> agree on that
404 2014-09-03 13:32:08 <sipa> jgarzik: no offence, but i'm not sure if i'm just going to trust your legal opinion here
405 2014-09-03 13:32:21 <jgarzik> wumpus, Sure...  I agree that "MIT/X11" is not correct...  IMO it's bike-shedding over license name.  We can call it any name we want.
406 2014-09-03 13:32:52 <jgarzik> sipa, That's fine.   We can go that route.
407 2014-09-03 13:32:58 <wumpus> but it makes sense that the actual terms are what matter here, otherwise you could just look up anyone who calls their license a certain name...
408 2014-09-03 13:33:02 <jgarzik> sipa, Any change should be approved by a lawyer, then.
409 2014-09-03 13:33:13 <wumpus> and COPYING, as well as that link never changed
410 2014-09-03 13:34:04 <jgarzik> sipa, IME over past 15 years of copyright battles, every single time you change the license TEXT you must get permission from all the authors holding copyright.
411 2014-09-03 13:34:11 <jgarzik> sipa, BlueMatt's pull changed the license text.
412 2014-09-03 13:34:14 <sipa> jgarzik: not arguing with that
413 2014-09-03 13:34:40 <sipa> jgarzik: but i wonder whether doing the opposite (changing the "MIT/X11") wouldn't require that too
414 2014-09-03 13:35:15 <sipa> not saying that's likely - i agree that the actual text probably takes precedence
415 2014-09-03 13:35:57 <wumpus> the MIT/X11 header was already in the very first commit, it was not added later
416 2014-09-03 13:36:33 <wumpus> COPYING was called license.txt back then, but contents were the same
417 2014-09-03 13:36:49 <wumpus> so this conflict always existed and we just propagated it to more files...
418 2014-09-03 13:37:01 <sipa> yup
419 2014-09-03 13:38:54 <jgarzik> I really challenge you to find a lawyer that thinks the title of a contract takes precedence over the terms...
420 2014-09-03 13:39:50 <wumpus> and we can be sure it is a mistake as the terms of MIT/X11 were never in the repository, or even referred to
421 2014-09-03 13:57:08 <wumpus> in any case for new code and new files I want them MIT licensed (matching the COPYING file)
422 2014-09-03 14:03:24 <wumpus> though I'd already assume that is the intention of every contributor
423 2014-09-03 14:04:03 <Luke-Jr> pretty sure "Expat" is just a Debian-specific way to say "MIT" because whoever imported the license didn't realise it was generic
424 2014-09-03 14:04:54 <Luke-Jr> not sure why we'd want to adopt Debian's really-a-bug naming over the obvious/clear/sensible name used by everyone else
425 2014-09-03 14:05:09 <wumpus> well - MIT is fine, the problem is the /X11
426 2014-09-03 14:06:33 <wumpus> and at least according to BlueMatt, MIT/X11 has an extra clause, although I cannot find that anywhere
427 2014-09-03 14:06:45 <wumpus> some people also call the MIT license the X11 license
428 2014-09-03 14:07:02 <wumpus> to add to confusion
429 2014-09-03 14:07:18 <Luke-Jr> the X11 license ends with "Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. X Window System is a trademark of X Consortium, Inc." *outside* the list of terms/clauses
430 2014-09-03 14:07:26 <Luke-Jr> otherwise it is word-for-word identical
431 2014-09-03 14:08:31 <Luke-Jr> so, the terms are the same, just the X11 project had an additional clarification in the file that it didn't apply to their trademark
432 2014-09-03 14:08:40 <wumpus> so it is clear that Satoshi thought MIT and X11 licenses were the same thing, so he mentions both in the file headers
433 2014-09-03 14:09:19 <Luke-Jr> there are actually 2 versions of the MIT license, the earlier one being GPL-incompatible and different from X11 license; but listing both seems clear he meant the newer one
434 2014-09-03 14:10:27 <wumpus> that message "Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium" wouldn't make sense in our case anyway
435 2014-09-03 14:10:37 <Luke-Jr> right
436 2014-09-03 14:11:03 <wumpus> so anyhow, this is a storm in a glass of water, nothing is harmed by calling it MIT/X11
437 2014-09-03 14:11:30 <wumpus> although for new files I'd prefer if it was just called MIT, to not propagate Satoshi's confusion on the subject
438 2014-09-03 14:11:31 <Luke-Jr> IMO nothing is harmed, correct
439 2014-09-03 14:11:49 <Luke-Jr> really it only matters when/if someone tries it in court
440 2014-09-03 14:11:55 <Luke-Jr> which frankly, is never going to happen
441 2014-09-03 14:12:34 <Luke-Jr> and if it did, I have little doubt the court would see the "MIT/X11" to refer to the terms in the X11/MITv2 licenses
442 2014-09-03 14:12:35 <earlz> Satoshi is going to come back, cash out all his bitcoins and sue everyone using it ROFL
443 2014-09-03 14:12:58 <Luke-Jr> earlz: you can't win lawsuit unles the terms were violated and you convince a court of that
444 2014-09-03 14:13:16 <Luke-Jr> earlz: the only way to violate this license is to strip the copyright notice
445 2014-09-03 14:13:34 <Eliel> Luke-Jr: you could also try distributing just binaries :P
446 2014-09-03 14:13:36 <earlz> some altcoins strip out copyright notice by lazy renaming heh
447 2014-09-03 14:13:43 <Luke-Jr> Eliel: that's allowed
448 2014-09-03 14:13:51 <Eliel> oh right, it wasn't GPL
449 2014-09-03 14:15:36 <earlz> is there a channel for the speculations on Satoshi? lol
450 2014-09-03 14:16:04 <sipa> #whereonearthissatoshinakamoto
451 2014-09-03 14:17:39 <earlz> it'd be awesome if Satoshi proved he wasn't dead and that he didn't do it to get rich or whatever by spending all his bitcoins to an unspendable transaction
452 2014-09-03 14:18:04 <timothy> earlz: lol
453 2014-09-03 14:18:39 <earlz> I think in reality though, the keys to that wallet are gone
454 2014-09-03 14:18:52 <wumpus> please move to #bitcoin
455 2014-09-03 14:18:54 <sipa> earlz: #bitcoin
456 2014-09-03 14:19:00 <earlz> lol ok ok. enough tangent
457 2014-09-03 14:21:22 <jgarzik> <wumpus> and at least according to BlueMatt, MIT/X11 has an extra clause, although I cannot find that anywhere
458 2014-09-03 14:21:38 <jgarzik> wumpus, BlueMatt's wikipedia link highlights the extra clause
459 2014-09-03 14:21:47 <wumpus> jgarzik: yes, Luke-Jr mentions what was added below, but it's not really a clause
460 2014-09-03 14:27:06 <wumpus> just a clarification about using a trademark, which has no relation whatsoever on bitcoin
461 2014-09-03 14:33:04 <jgarzik> wumpus, no that's not what BlueMatt's wikipedia link says
462 2014-09-03 14:34:01 <jgarzik> wumpus, See http://en.wikipedia.org/wiki/MIT_License#Various_versions
463 2014-09-03 14:38:50 <dabura667> sipa: https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json
464 2014-09-03 14:38:57 <dabura667> sipa: thanks for the help last night
465 2014-09-03 14:41:56 <wumpus> jgarzik: it's just that I don't 100% trust wikipedia
466 2014-09-03 14:45:35 <wumpus> thinking about it, I certainly don't want to switch to a more restrictive license based on hearsay
467 2014-09-03 15:02:45 <justanot1eruser> Is there any scheme that could be employed so bitcoin could survive locally in the event that the internet is partitioned?
468 2014-09-03 15:03:17 <petertodd> justanot1eruser: yes, ham radio, (very fast) passenger pigeons, etc.
469 2014-09-03 15:03:51 <justanot1eruser> petertodd: so the answer isn't to get it to work partitioned, but to unpartition
470 2014-09-03 15:04:10 <epscy> i was just going to say, it isn't partitioned anymore in that case
471 2014-09-03 15:04:18 <justanot1eruser> intuitively it seems to me that there wouldn't be a way to get it to work partitioned
472 2014-09-03 15:04:24 <epscy> justanot1eruser: i think the answer is no
473 2014-09-03 15:04:26 <petertodd> justanot1eruser: yup, bitcoin absolutely depends on global consensus; there's no alternative to that
474 2014-09-03 15:05:07 <petertodd> justanot1eruser: even schemes that appear to partition the blockchain, treechains, sharding, whatever, don't work in the face of physical partitioning
475 2014-09-03 15:05:16 <hearn> justanot1eruser: it could survive as two separate currencies with each side being worth less
476 2014-09-03 15:05:32 <justanot1eruser> hearn: I think only one of the sides would be worth less
477 2014-09-03 15:05:43 <hearn> depends if you could spend your coins on both sides or not
478 2014-09-03 15:05:45 <epscy> hearn: wouldn't unpartitioning then screw things up?
479 2014-09-03 15:06:07 <hearn> yes they'd be unmergable at that point. but i suspect a large fork would eventually become unresolvable even if the partition went away
480 2014-09-03 15:06:15 <justanot1eruser> hearn: and on the weaker side, there is no point to mining since your blocks will just get reorged out
481 2014-09-03 15:06:18 <hearn> right
482 2014-09-03 15:06:37 <hearn> at that point it'd make sense for the island dwellers to deliberately hard-fork themselves out of the consensus for good
483 2014-09-03 15:06:52 <petertodd> it's not practically possible to have both sides stay partitioned geographically, as there's no way to prevent miners in the wrong place from mining the coin
484 2014-09-03 15:07:02 <justanot1eruser> I was hoping there was some idea maybe involving proof of being in that location based on some computation based on light speed
485 2014-09-03 15:07:42 <petertodd> justanot1eruser: yeah, I had that one, the problem is it relies on a trusted, centralized, third party to perform that speed of light measurement
486 2014-09-03 15:07:44 <epscy> hearn: i mean, it seems like a situation that wouldn't last for very long, difficult to imagine not knowing you are partitioned, and if txes could get reversed upon unpartitioning who will accept payment?
487 2014-09-03 15:08:00 <hearn> only double spends would get reversed
488 2014-09-03 15:08:29 <hearn> depending on the circumstances, you might be able to muddle through with just threatening double spenders with big sticks, for example. not really sustainable or ideal but for short term partitions ....
489 2014-09-03 15:08:44 <wumpus> and transactions based on coinsbases of blocks that don't make it
490 2014-09-03 15:09:01 <hearn> yeah
491 2014-09-03 15:09:17 <petertodd> wumpus: and anyonecanspend transactions, or anything using SIGHASH_ANYONECANPAY, or...
492 2014-09-03 15:10:12 <wumpus> petertodd: yes it's not pretty
493 2014-09-03 15:10:44 <wumpus> it is clear that partitioning should be avoided, luckily there are many ways to do that
494 2014-09-03 15:11:04 <sipa> well, in case of a big partitioning, and both sides disagree about which side should be accepted, there is of course an easy solution: declare war!
495 2014-09-03 15:11:18 <petertodd> indeed, having less miner centralization, even just more distributed pools w/o real management-level decentralization, is a big improvement in reliability
496 2014-09-03 15:11:48 <wumpus> sipa: hah, proof-of-agression
497 2014-09-03 15:12:22 <sipa> proof-of-victory, i guess :)
498 2014-09-03 15:13:30 <petertodd> sipa: note how schemes using client-side validation at one level decrease the chance of a partition - the proof-of-publication record is less likely to fail as there are far fewer validity rules to disagree on - on the other hand coming to consensus about what validity rules are correct to resolve the fork may be more difficult socially
499 2014-09-03 15:14:25 <petertodd> sipa: or in essense, client-side validation *takes away* the ability to "declare war" on rules you don't like by out-mining the other side
500 2014-09-03 15:14:50 <hearn> we might be going to witness the first partition thanks to china, i guess
501 2014-09-03 15:14:57 <hearn> 
ACTION expected them to split the network years ago, surprised it didn't quite happen yet

502 2014-09-03 15:15:15 <petertodd> china doesn't try to block satphones, among other things...
503 2014-09-03 15:16:03 <petertodd> that said, if we increase the blocksize the available defenses against partitions quickly become useless
504 2014-09-03 15:16:39 <sipa> does china block carrier pigeons?
505 2014-09-03 15:16:54 <petertodd> sipa: yes, they're hungry and eat them
506 2014-09-03 15:16:59 <sipa> eww
507 2014-09-03 15:17:19 <petertodd> sipa: only because of horrendous pollution...
508 2014-09-03 15:25:35 <wumpus> well as long as they don't (generally) block http it's easy enough
509 2014-09-03 15:27:52 <petertodd> china's firewall still operates on a blacklist model; north korea's firewall operates via whitelisting. getting blockchain data in NK is probably pretty much infeasible
510 2014-09-03 15:28:17 <petertodd> (modulo non-internet obviously)
511 2014-09-03 15:28:36 <hearn> wumpus: no, why
512 2014-09-03 15:28:46 <hearn> wumpus: great firewall measures entropy and does connection resets on connections that last too long and look encrypted
513 2014-09-03 15:28:51 <hearn> block chain looks encrypted, entropy-wise ....
514 2014-09-03 15:28:51 <wumpus> oh sure, but if you turn the country into NK I'm sure people have other things to worry about, like food getting in...
515 2014-09-03 15:29:13 <hearn> basically they try and allow "web like things" that aren't on their blacklist but block vpns and the like
516 2014-09-03 15:29:41 <hearn> if they decide to crack down on bitcoin there, then there is no fix. we just shrug and say ok china, buhbye
517 2014-09-03 15:29:44 <petertodd> hearn: easy to turn the blockchain into not entropy looking things, human readable text, images, etc. - tor has various plugins that do that
518 2014-09-03 15:30:07 <hearn> yes and it hasn't really helped them, has it
519 2014-09-03 15:30:42 <petertodd> hearn: tor's issues in china is introducing new users; technically knowledable users with friends outside china have an easy time getting past the firewall
520 2014-09-03 15:30:49 <wumpus> hearn: there are a lot of things that look like lots of entropy, such as compressed files, they can't block all of them
521 2014-09-03 15:31:05 <hearn> heh
522 2014-09-03 15:31:07 <hearn> have you ever been to china?
523 2014-09-03 15:31:12 <hearn> western internet there is practically unusable.
524 2014-09-03 15:31:27 <hearn> they can do whatever they like to it really because most chinese are not going outside the firewall anyway
525 2014-09-03 15:32:00 <petertodd> I've talked to actual tor devs about this... china has huge numbers of succesful tor users, the issue is making it friendly enough for new users, esp. technically unsophisticated ones
526 2014-09-03 15:32:12 <hearn> this must be some new definition of "huge" i haven't encountered before.
527 2014-09-03 15:32:22 <timothy> tor browser is friendly for anybody
528 2014-09-03 15:32:58 <petertodd> of course, all this works only because china's policy towards the internet is that using Tor, etc. is essentially *legal*, so individual users aren't worried about getting caught all that much; I'd be scared to try the same in North Korea
529 2014-09-03 15:33:00 <hearn> usage wise tor gets kicked in the teeth by commercial VPN services. they're a lot friendlier and easier to use, even though the most popular one puts adverts into unencrypted web pages ....
530 2014-09-03 15:33:52 <petertodd> hearn: you mean in china or in general?
531 2014-09-03 15:33:56 <hearn> in general
532 2014-09-03 15:34:12 <hearn> china might even be the opposite, i don't remember any country specific stats that i've seen (i mean outside the tor metrics page)
533 2014-09-03 15:34:32 <wumpus> well if commercial VPN providers work, why not use them...
534 2014-09-03 15:34:51 <timothy> wumpus: you can't know if somebody is sniffing :)
535 2014-09-03 15:35:02 <hearn> most users don't care
536 2014-09-03 15:35:10 <hearn> they just want to reach youtube or twitter or whatever site their asshole government blocked
537 2014-09-03 15:35:17 <hearn> they don't care if the usa or us companies can spy on their traffic.
538 2014-09-03 15:35:17 <timothy> most users use 1234 as password
539 2014-09-03 15:35:19 <wumpus> timothy: well, same if you use the unencrypted web over tor...
540 2014-09-03 15:35:30 <petertodd> right, and VPN services have significantly reduced privacy properties, the Tor devs know exactly why those VPN services are user friendly and aren't willing to make the compromises necesary to get to that level of usability. relations between Tor and VPN services are pretty good - mullvad was at the same Tor meeting I was at two months ago for instance
541 2014-09-03 15:35:34 <timothy> yes, but you can't know WHO is using this connection
542 2014-09-03 15:35:42 <hearn> yes indeed.
543 2014-09-03 15:35:48 <hearn> they have decided not to compete in that space.
544 2014-09-03 15:36:44 <petertodd> Tor's funding is aimed at a higher security level than VPN, so it's not surprising they haven't decided to "compete"
545 2014-09-03 15:37:36 <petertodd> anyway, they're still looking at ways to integrate Tor, VPN's, Bitcoin etc. to make  traffic analysis of everything more difficult
546 2014-09-03 15:40:28 <petertodd> for instance, mullvad had a fascinating idea of operating for-pay Tor/VPN entry nodes, paid for via bitcoin, and then allowing anyone to sell their internet access to act as those introduction points. in particular, install the mullvad client and the default would be you'd sell incoming bandwidth. the chinese firewall relies on identifying introduction points and blacklisting them, so when everyone is selling access that blacklisting becomes much ...
547 2014-09-03 15:40:34 <petertodd> ... more difficult, esp. with steganographic hiding of the traffic
548 2014-09-03 15:44:18 <hearn> nah. not gonna happen, china can beat anything like that trivially. they are already auto-probing and blocking tor. google ran a project that had the right idea. let friends coordinate over sites that are too big to block (ignoring china for a moment) and use their friends internet connections via a chat client. from the pov of dpi it looks like video chat.
549 2014-09-03 15:44:33 <hearn> this is good enough for turkey, iran, etc
550 2014-09-03 15:44:39 <hearn> (the uk ....)
551 2014-09-03 15:45:39 <wumpus> encoding it over video chat is a good idea too
552 2014-09-03 15:45:44 <petertodd> that's exactly the kind of thing mullvad is working on, with an added incentive of money
553 2014-09-03 15:46:40 <petertodd> anyway, china is limited by the problem that their economic productivity is going down because of all this internet blocking. obviously they could block everything north korea style if they wanted too, but they have to strike a balance.
554 2014-09-03 15:47:09 <hearn> yeah, realistically i don't think decentralisation helps here. you want as much centralisation as possible, to ensure that censors have to cause massive collatoral damage to try and stop the tunnels. google, microsoft, maybe facebook have enough weight to pull it off. individuals don't, really.
555 2014-09-03 15:47:30 <hearn> right. china will probably have to relax things a bit in the coming decades. they're already doing so in the shenzen free trade zone
556 2014-09-03 15:48:41 <petertodd> s/you want as much centralisation as possible/you want as much participation as possible/ <- FTFY
557 2014-09-03 15:50:10 <petertodd> china's massive brain drain to more free countries is an existential threat to the country
558 2014-09-03 15:50:41 <wumpus> that assumes that the big players will want to cooporate with something like this in the first place, they may have enough weight to pull it off, but generally they just work with the countries they operate in
559 2014-09-03 15:52:01 <petertodd> wumpus: "they" assumes those companies are monoliths - google is a great example of how the same company can both aid and hinder censorship in different departments
560 2014-09-03 15:52:09 <hearn> yeah it's a tightrope walk. push too hard and the whole company gets blocked.
561 2014-09-03 15:52:36 <wumpus> what incentive would google have to provide something like tor access?
562 2014-09-03 15:52:37 <hearn> but for example, in iran, when we started encrypting all gmail connections they tried to block gmail entirely. that lasted a few days and then they gave up and restored access. too much pain
563 2014-09-03 15:53:01 <petertodd> it's a prisoners dilemma situation that legislation would help - force all western companies to participate, so at least they aren't being put at a disadvantage relative to their western competitors
564 2014-09-03 15:54:00 <hearn> tor access? none. something like tor is toxic to large companies, too much reputational damage. but as i said they explored smaller lighter weight ways to get through national firewalls, using social connections etc. well it was handed off to some university iirc, some kind of joint collaboration, but most of it was done in house. not sure what happened to it.
565 2014-09-03 15:54:02 <wumpus> petertodd: agreed, they are far from monolithic, but in the end it's the money at the top making the decisions, and government make good customers
566 2014-09-03 15:54:12 <hearn> or rather google explored. dunno about facebook.
567 2014-09-03 15:54:50 <petertodd> wumpus: yup, of course, that line of thinking can also extend to "cut china's fiber lines" - obvious reasons why it's hard to get the political will to implement it
568 2014-09-03 15:54:57 <hearn> anything that boils down to beating firewalls is very politically problematic of course in the west as well. lots of places want to filter traffic and get upset if they can't. that's why it took a long time to go SSL-by-default on web search
569 2014-09-03 15:55:10 <hearn> they tried several times and were forced to back down each time
570 2014-09-03 15:55:52 <hearn> i think now they have a service that lets non-ssl access be requested by subnet or something. can't remember the details. people can request to get their networks unencrypted, iirc. been a while since i looked at it though.
571 2014-09-03 16:00:06 <hearn> what's the best way to figure out why i'm getting a 500 from bitcoin rpc? -debug=rpc prints nothing
572 2014-09-03 16:00:19 <jgarzik> petertodd, indeed, Torcoin tries to accomplish similar goals as this mullvad idea
573 2014-09-03 16:00:29 <jgarzik> petertodd, laudable goal, sustainable overlay network
574 2014-09-03 16:00:51 <jgarzik> "generation 1" P2P networks are all DoS-able, sybil-able, 100% volunteer.  Gen-2 networks will be sustainable.
575 2014-09-03 16:00:55 <jgarzik> bitcoin is 1.5
576 2014-09-03 16:00:57 <jgarzik> maybe 1.2
577 2014-09-03 16:17:01 <wumpus> jgarzik: what's torcoin?
578 2014-09-03 16:17:23 <timothy> just another spamcoin?
579 2014-09-03 16:18:09 <super3> uh there are two torcoins
580 2014-09-03 16:18:26 <super3> one is a scam coin, the other is very legit https://www.petsymposium.org/2014/papers/Ghosh.pdf