00:00:02 EasyAt: maybe there could be a separate key for permission to send sig than for spending. (like the chain-code being in an online computer and the private key in the offline) 00:01:18 sipa: it would also solve address reuse. new address on each signed payment permission 00:03:42 Or, maybe a way to publish a ruleset in the blockchain for acceptable payments to an address 00:04:26 Though, by doing so I am giving up my pubkey... I think 00:04:37 Well, I can't think of a way not to give it up 00:05:12 adam3us: well, it's exactly what the payment protocol intends to bring back 00:06:13 TD has quit 00:09:27 sipa: yes. 00:15:39 DougieBot5000 has quit 00:21:42 was a rename decided for stealth addresses? I would like to propose "quiet addresses" or "silent address" 00:23:21 jcrubino: i think we have a winner from jeremy spilman "reusuable address" 00:23:55 sounds good 00:23:57 I like reusable address. 00:24:13 very nice 00:24:50 <_ingsoc> _ingsoc has quit 00:25:04 gmaxwell: yea me too. i am not sure of the level of enthusiasm for this all being a done deal tho "I have high hopes for this feature. The war *against* address reuse may soon be a distant memory." (Jeremy on bitcoin-dev list) 00:25:24 gmaxwell: seems to me there is a big open question about SPV compatibility. 00:25:27 so if I send a payemtn from a reusable address to another resuable address does zerocoin still have a use or case? 00:25:28 ugh yea, I really have mixed feelings on the whole feature. 00:25:38 they are not a solution fo everything 00:25:42 adam3us: it's neither SPV compatible or incompatible. 00:26:02 jcrubino: bitcoin doesn't provide anonimity 00:26:13 even with reusable addresses 00:26:17 gmaxwell: well an spv client doesnt know what to put in its bloom filter absent another channel then shall we say 00:26:35 adam3us: you'd use prefix filters for SPV 00:26:40 adam3us: well it can be specced with the bloombait idea. 00:27:11 maaku: yeah same thing i guess (my terminology was bloom bait, petertodd prefix) but that has privacy problems 00:27:13 then you can pick your anonymity set tradeoff. But its an extra thing that has to be 'decided' which is lame. 00:27:31 adam3us: well bloom filters in general have privacy problems... 00:27:48 gmaxwell: its worse than bloom i think with its apparently small anon-set. because its public to all and the statisitcal analysts will latch on to it 00:28:19 yea, it's worse than bloom, we don't have anything like bloom for it which is as secure in the semi-honest node model. 00:28:40 maaku: and use it multiple times in your potential graph to narrow in on you. privacy leak stats is cumulative 00:28:59 In bloom you're completely private unless you connect to unfriendly nodes (well ignoring that our links aren't encrypted). So thats not terrible _casual_ privacy. 00:29:12 it's not privacy against powerful forces but its not half bad. 00:29:41 gmaxwell: yup and prefix is like permanent global record with cumulative privacy loss effect on stats. as if we didnt have enuf stats build up problems. 00:32:46 so an improvement would be to make the bait hmac(tx_nonce,secret)[n-bits] then you have to hand over a secret to the party you wish to scan for you... but it's not unforgable like handing over the agreement key. 00:32:58 gmaxwell: hmm bit of lateral thinking. giving up on getting much from the reusable address. but other than a bloom bait, what about some kind of randomized fingerprint, that you can illuminate different parts of in a bloom like way with help of the assisting node. created by the sender based on the reusable key 00:33:13 e.g. I could just pick any collection of transactions on the network and search for a secret that makes them part of the same group. 00:34:00 so someone who says "I ran a SPV node and found out adam3us's secret is π and thus these transactions are his" can be challenged with "no way, thes transactions are three different other people with these other secrets" 00:34:02 gmaxwell: yes maybe a public key versoin of that 00:34:17 the fact that its not public key is what makes it forgable. :) 00:34:42 gmaxwell: so long as its a fuzzy match... 00:34:56 basically there exists some secret such that any selection of baits are related, but finding it takes work related to how specific you want to make the matching. 00:35:12 yea, thats why I said n-bits. it has to be small enough that searching for forgeries is easy. 00:35:13 gmaxwell: maybe could allow different query for same data somehow 00:35:19 gmaxwell: yeah i got that 00:36:35 gmaxwell: also in the hmac how do u get the key to the sender... 00:36:45 go1111111 has quit 00:36:52 dunno maybe there is a way of constructing it with a linear code so that the match is always fuzzy but your real transactions will always have a hamming distance < x. and then you ask for all adam3us: you put it in the address. 00:37:54 gmaxwell: yes but then its not a secret, so ah ok its better than a prefix however got you. 00:38:26 yea its just a secret keyed prefix, with a denyable secret, unlike using the derrivation keys for scanning since they aren't denyable. 00:38:28 gmaxwell: already an improvement on prefix, and Jeremy's about to like write an RFC level of "awesomely done" 00:39:09 down side is that someone scanning for you can't precompute anything to index it... prefixes have that nice property. 00:39:26 gmaxwell: so the other feature we'd like is pecomputation 00:39:41 gmaxwell: yes 00:41:16 gmaxwell: ok i am gonna sleep on it (literally, getting late) interesting problem, with quite useful implications if it can be cracked (I mean I share Jeremy's interest, just not his conclusion about it being solved yet!) 00:42:32 well so, H(nonce) and then split into 16 16 bit parts. pick a part at random, and compute part^secret_bait = prefix and put the prefix in the transaction. 00:42:56 When you ask someone untrusted to scan for you you give them a set of secret baits you're insterested in, including a number of bogus ones you really don't care about. 00:43:14 and they return any transaction where any one of the part^prefix = one of your baits. 00:43:34 e.g. someone doing stats doesn't know which of the token the part is xored with. 00:43:53 obviously some parameter scaling needs to happen to make it sensible, I picked random numbers. 00:44:19 hm. they should probably be 8 bit. in any case, there you go. 00:45:33 gmaxwell: not bad i think 00:47:36 in any case, this is a member of an infinite space of related schemes based on locally decodable error correcting codes. Effectively this is a fountain code, effectively, the transaction picks a random high dimensional vector space, and when combined with the prefix the result is a codeword in that space which is always within a certian proximity of your secret bait... and there is a cheap test of proximity. 00:48:07 wallet42 has quit 00:48:11 gmaxwell: is that precomputably indexable? 00:48:12 it's still vulnerable to statstical analysis, in that you can keep intersecting things if you have a prior that they're related until you recover the bait. 00:48:26 adam3us: yea with overhead, e.g. you'd put every transaction in N indexes. 00:49:06 N picked based on how big the vector space is that you're embedding in.. More dimensions means more area covered by a given radius. 00:50:49 e.g. for my 16/32 example you'd be putting each transaction in the index 16 times. But thats okay, I mean, bloom filtering also pulls multiple keys from a transaction. 00:50:52 gmaxwell: my public key comment was that then it would not be bait recoverable. 00:51:24 gmaxwell: yes. it seems reasonably good. definitely a couple of increments better than prefix 01:00:22 spenvo has quit 01:01:48 jcrubino has left #bitcoin-wizards 01:02:18 go1111111 has joined #bitcoin-wizards 01:06:34 wallet42 has joined #bitcoin-wizards 01:15:58 justanotheruser has quit 01:24:43 go1111111 has quit 01:25:22 justanotheruser has joined #bitcoin-wizards 01:25:22 justanotheruser has quit 01:25:22 justanotheruser has joined #bitcoin-wizards 01:27:12 fractastical has quit 01:33:47 that reminds me 01:33:51 nvm 01:41:12 nsh has quit 01:41:26 nsh has joined #bitcoin-wizards 01:48:36 andytoshi has joined #bitcoin-wizards 01:50:38 am42 has quit 01:54:29 wallet42 has quit 01:54:41 spenvo has joined #bitcoin-wizards 02:41:35 jtimon has quit 02:43:58 go1111111 has joined #bitcoin-wizards 03:05:22 mr_burdell has joined #bitcoin-wizards 03:05:51 michagogo|cloud: i have refreshed the windows build, the only change is that it saves the rpcport= setting in cjclient.conf, before that would get overwritten 03:06:17 michagogo|cloud: but i've got the testnet server working properly, it was just permission issues because i git clone'd the mainnet joiner over on my own unix account :P 03:14:45 nanotube has quit 03:21:35 nanotube has joined #bitcoin-wizards 03:27:19 wyager has joined #bitcoin-wizards 03:29:45 justanotheruser has quit 03:39:15 jps has joined #bitcoin-wizards 03:59:05 wyager has quit 03:59:14 justanotheruser has joined #bitcoin-wizards 03:59:14 justanotheruser has quit 03:59:14 justanotheruser has joined #bitcoin-wizards 04:25:27 Where is the correct channel to ask about sybil attack mitigation in a decentralized WoT? 04:27:56 jps has quit 04:33:59 EasyAt, maybe you want #bitcoin-wot 04:34:05 but i'd like to hear about it here too 04:40:51 Doge_Funnie has joined #bitcoin-wizards 04:43:23 amiller: One second, I'd like to state this concisely 04:51:13 spenvo has quit 04:54:15 fractastical has joined #bitcoin-wizards 05:14:11 gmaxwell, i'm finally starting to realize you're right about snarks 05:14:19 that so far they all require an obnoxious trusted setup 05:18:19 amiller: but it's okay if you trust yourself, right? 05:18:35 no not really 05:18:38 amiller: ones that don't are certantly possible (PCP theorem + fiat shamir shows its possible) though they would not be as compact as the GGPR ones, which are just ludicrously compact. 05:19:31 if i wanted to show someone that the bitcoin community has already been pointing this out, would you recommend a forum post of yours? 05:19:38 maaku: if you don't care about public verifyability then you can use a like an interactive protocol. I'm pretty sure that GGPR is still ZK if the CRS was malicious generated. 05:20:08 i've sort of not noticed it despite mouthing off about how cool my nonoutsourceable puzzle is based on snark 05:20:19 it's more immediately relevant to zerocoin though 05:20:33 i mean, they're aware of it too 05:20:40 gmaxwell, I mean hypothetically if the scriptPubKey were the hash of the SNARK verifying key, and the scriptSig were the verifying key and proof (p2sh replacement) 05:21:00 amiller: http://www.reddit.com/r/ZeroCoin/comments/1uy35p/matthew_green_to_speak_about_new_zerocoin_version/ceo17ut 05:21:02 maaku, creating a SNARK verify key requires someone to have some secrets they are trusted to delete 05:21:16 amiller: A GGPR-12 SNARK. 05:21:16 amiller: yes, see ^^ 05:21:36 yes i just got back from that and chatted with him and his student about this 05:21:51 amiller: if that snark is created by you and only used by you, why is it a problem if you have the trapdoor? 05:21:56 amiller: Eli supposidly is also working on a Linear PCP based on some fiat-shamir transform of a locally testable code, but none of the recent papers are about this. 05:22:28 maaku, if that's the case sure, that's just a much different use case than what i have in mind (or what zerocoin/cash has in mind) 05:22:40 maaku: for _some_ applications it might not matter, for some it would. 05:23:13 maaku: "You can spend these coins if you solve my puzzle" "psyche... I just spent them out from under you even though the code said I couldn't because I can create false proofs for this verification key." 05:24:43 amiller: the upside is removing the CRS the downsides are that the proofs are much larger (tens of kilobytes) and the zero-knoweldge is no longer perfect. 05:25:41 i see. 05:26:11 amiller: well I'm glad your koolaid tap on the CRS stuff ran out. I dunno why everyone thinks its so acceptable.. it is in some cases, not others. 05:26:26 What they're talking about doing in zerocash I think its completely unacceptable. 05:26:46 then again, for that application 20kbyte signatures is probably also unacceptable. 05:27:21 how far do you think they can smear around the anytrust kind of setup 05:27:41 (and for that matter, q-power knoweldge of exponent, bilinear pairing stuff is by itself probably unacceptable) 05:27:54 that was a question someone asked, matt green answered affirmatively, i didn't seek any details 05:28:04 What was? 05:28:14 whether you could distribute the setup among N parties 05:28:21 yea, I think thats half BS 05:28:23 where any of the N parties has to delete their data 05:28:28 okay 05:29:02 I don't know of any systems for _active_ secure MPC that don't themselves require a zk-snark, certantly none that are implemented. 05:29:45 (you can take any semi-honest-secure MPC scheme and make it active secure if you make all the players do their work under ZK-proof that they're obeying with the protocol) 05:29:46 gmaxwell: i see 05:30:29 It's possible in theory at least. But what does N need to be? and where is even a beginning of an implementation? even with just three parties it would be the largest MPC task ever attempted. 05:30:44 yeah everything attempted in practice so far has been semi honest 05:30:48 afaik 05:30:50 nsh has quit 05:31:25 Yes, as far as I can tell. And I think we have a chicken and egg problem here. We have almost pratically efficient snarks actually implemented but in the CRS model. 05:31:52 You could, in theory, make the CRS with MPC. .. but active secure MPC that looks remotely pratical is a passive MPC + SNARKS. 05:32:58 and the CRS computation isn't horrible but there is a lot of it ... for zerocoin they're talking about 1.6GByte prover keys (which actually sounded small to me). 05:33:27 So somehow you've got N party active secure MPC and you're going to compute 1.6 gbytes of CRS in it? 05:33:48 And realistically I think N can't just be 3. Start talking about 30 and thats more interesting. 05:33:51 yeah. i came to that conclusion pretty quickly too 05:33:52 justanotheruser1 has joined #bitcoin-wizards 05:34:05 sell tickets to the big setup phase MPC as your fundraiser gimmick! 05:35:24 I mean there are neat things you can do... one of the mpc nodes should be in a faraday cage in a bunker filled with C4. And you should exploide it when the computation is finished. People would pay to see that. :P 05:36:31 david blaine could do one too 05:36:55 the undetectable compromise part is part of what makes this so bad for ZC where it wouldn't be an issue elsewhere. 05:37:03 lots of room for fud. 05:37:27 justanotheruser has quit 05:37:40 "NSA supercomputer cracked the crypto to recover the key whole cloth, and now the US government can print unlimited coins! Prove me wrong!" 05:38:24 at least if it were detectable you could freeze new spends and deploy another ZK proof system (perhaps a less efficient one) 05:39:07 i learned about a formalism called "covert security" that's weaker but promises detection like that... 05:39:22 but i couldn't find any trace of someone actually getting any cheaper construction that way 05:40:32 well the GGPR12 stuff is super brittle to knowing the CRS. Its easier to compute a fake proof than validate a proof if you know the CRS. 05:41:25 and I think the way the perfect zero knoweldge is achieved it must be that way. 05:42:14 (because you can basically show that for any set of passing input group elements some CRS exists thats makes those element a valid proof, regardless of the statement being true or not) 05:44:39 In any case, Iddo has given me the impression that I'm not the only person who's seen the limitations of the CRS model. 05:46:40 RoboTeddy has quit 05:46:40 i've seen some modifications to CRSs to make them more useful and composable but not that get rid of the trusted/private state somehow 05:47:02 justanotheruser1 has quit 05:47:05 i don't have any idea what comes next 05:52:02 amiller: why not post to the http://www.scipr-lab.org/ mailing list and whine about the CRS trust assumptions and ask what they're going to do about them? :P 05:52:35 As I said, I /think/ they're also working on a backend without one. But I don't know anything about it as it's not mentioned in their papers on their tinyram work. 06:04:00 justanotheruser has joined #bitcoin-wizards 06:04:06 justanotheruser has quit 06:04:06 justanotheruser has joined #bitcoin-wizards 06:12:01 mappum has joined #bitcoin-wizards 06:14:18 spenvo has joined #bitcoin-wizards 06:15:47 sneak has joined #bitcoin-wizards 06:17:34 Ursium has quit 06:22:08 RoboTeddy has joined #bitcoin-wizards 06:23:34 RoboTeddy has quit 06:23:52 RoboTeddy has joined #bitcoin-wizards 06:39:23 nessence has quit 06:39:56 nessence has joined #bitcoin-wizards 06:41:02 nessence has quit 06:45:33 nessence has joined #bitcoin-wizards 07:02:14 nsh has joined #bitcoin-wizards 07:05:33 roidster has quit 07:09:13 jgarzik has quit 07:16:08 mappum_ has joined #bitcoin-wizards 07:21:29 mappum_ has quit 07:24:55 mappum_ has joined #bitcoin-wizards 07:28:02 iddo has quit 07:38:31 rdymac has quit 07:39:08 rdymac has joined #bitcoin-wizards 07:43:17 jgarzik has joined #bitcoin-wizards 07:43:17 jgarzik has quit 07:43:17 jgarzik has joined #bitcoin-wizards 07:50:13 mappum_ has quit 08:00:27 go1111111 has quit 08:01:32 gmaxwell, if it helps, didactically, you can compare the security of the CRS model to the security of DUAL_EC_DRBG.... 08:06:13 Hm! 08:06:14 point. 08:17:41 nessence has quit 08:17:58 nessence has joined #bitcoin-wizards 08:43:39 go1111111 has joined #bitcoin-wizards 08:56:59 shesek has joined #bitcoin-wizards 09:17:22 go1111111 has quit 09:33:22 wallet42 has joined #bitcoin-wizards 09:38:03 <_ingsoc> _ingsoc has joined #bitcoin-wizards 09:40:40 stonecoldpat has joined #bitcoin-wizards 09:40:41 fractastical has quit 09:44:35 iddo has joined #bitcoin-wizards 09:46:48 TD[away] is now known as TD 09:50:17 fractastical has joined #bitcoin-wizards 10:01:16 nsh_ has joined #bitcoin-wizards 10:01:31 nsh has quit 10:03:01 nsh_ has quit 10:03:40 CodeShark has quit 10:03:52 nsh_ has joined #bitcoin-wizards 10:04:15 CodeShark has joined #bitcoin-wizards 10:06:04 nsh_ has quit 10:06:50 nsh_ has joined #bitcoin-wizards 10:07:27 hnz has quit 10:12:02 hnz has joined #bitcoin-wizards 10:14:22 orperelman has joined #bitcoin-wizards 10:19:48 mappum_ has joined #bitcoin-wizards 10:20:00 nsh_ has quit 10:42:13 rdymac has quit 10:43:39 rdymac has joined #bitcoin-wizards 10:54:12 justanotheruser has quit 10:56:44 mappum_ has quit 11:08:10 <_ingsoc> _ingsoc has quit 11:10:41 shesek has quit 11:14:22 <_ingsoc> _ingsoc has joined #bitcoin-wizards 11:17:16 gmaxwell: so while i agree that H(nonce)[rand(32)] ^ prefix is an interesting incremental improvement of raw prefix, with an example 8-bit prefix, and [] being byte index, ^=xor, it still publicly allows elimination. ie with probability (255/256)^32=88% it eliminates you as a payee of any given reusable payment. 11:17:39 gmaxwell: (posted this and related on bitcoin-dev) 11:23:55 jtimon has joined #bitcoin-wizards 11:27:41 shesek has joined #bitcoin-wizards 11:30:19 nsh_ has joined #bitcoin-wizards 11:30:20 comboy has joined #bitcoin-wizards 11:33:23 nsh_ has quit 11:35:11 spenvo has quit 11:54:18 shesek has quit 12:04:11 bobke has quit 12:04:19 bobke has joined #bitcoin-wizards 12:07:25 shesek has joined #bitcoin-wizards 12:16:20 nsh_ has joined #bitcoin-wizards 12:16:36 shesek has quit 12:24:46 justanotheruser has joined #bitcoin-wizards 12:28:51 shesek has joined #bitcoin-wizards 12:29:33 justanotheruser has quit 12:43:10 justanotheruser has joined #bitcoin-wizards 12:45:07 <_ingsoc> _ingsoc has quit 12:47:15 Ursium has joined #bitcoin-wizards 12:56:56 somebody claimed here (I don't know if it was you maaku), that some people were suspicious about scrypt being GPU mined from the beginning 12:57:05 nsh_ has quit 12:57:11 does anybody have any reference to that? 12:58:39 Meistarin has joined #bitcoin-wizards 13:04:02 hmm, is this it? https://bitcointalk.org/index.php?topic=63365.0 13:04:45 I'm considering mentioning rumors about it and putting a link on an article about p2p currencies I'm finishing 13:07:31 I don't know...wasn't coinhunter a scammer? 13:07:52 "Artforz publicly admitted to creating a GPU miner for litecoin numerous times" any link to this? 13:08:31 I'll keep searching, just browsing out loud in case anybody can give me some clues or a better link 13:42:16 rdymac has quit 13:43:39 rdymac has joined #bitcoin-wizards 13:46:56 mr_burdell has quit 14:14:58 andytoshi has quit 14:17:40 hmm apparently GCHQ couldnt crack truecrypt with the password "$ur4ht4ub4h8" 14:17:51 they had to sling the guy in jail and sweat it out of him 14:18:03 isnt that a weak password? Is that a bit surprising. 14:18:16 jtimon: ha thats pretty interesting the guys claim seems quite plausible. casts coblee / artforz in a bad light if so. i was before now supposing the failure of scrypt params chosen to be yet another alt param fail on their part. but maybe it was a "fail" ie not real! they designed it that way and exploited it to the max until someone else figured it out 14:18:50 Emcy: yeah i saw that.. my thoughts also, we have nothign to worry about :) combined might of GCHQ cant crack that short/low entropy password.. chortle. 14:19:31 Emcy: what we dont know however is the program used. maybe it has some memory hard stretching or something preventing fpgas or whatever gchq has 14:19:48 and yet a skilled cracker with a good custom dictionary and a handful of radeons might 14:20:45 Emcy: if it was unstretched, for sure; lot of former gpu miners coul crack that with their own cards! 14:21:49 ok i assume it was truecrypt 14:22:10 http://www.bbc.co.uk/news/uk-25745989 look hes got a beard so hes probably up to no good! 14:22:52 jtimon: analogously i was similarly suspicious of dan larimer with his momentum hash and protoshares. that no GPU status fell pretty fast though he fought the claim all the way down 14:23:51 adam3us isnt it fairly common knowledge that someone was mining LTC rather faster than should have been possible early on 14:23:58 I recall artforz had mentioned he implemented it on GPU And it was slower 14:24:40 The algo itself is slower on GPU if you don't use the TMTO trick (only store every other value in the memory pad and look up the others on the fly) 14:25:21 There's a little bit of reason to believe that solar designer and artforz may have been the same person, but I won't eloborate 14:25:23 Emcy: I dont know wasnt paying attention at the time. tacotime_: the thread jtimon posted above says their programmer spent 4hrs and made something 150x faster than artforz claimed best. 14:26:12 You honestly trust something coinhunter said? 14:26:38 The guy who has stolen hundreds (probably thousands) of BTC from the community over the past 2 years? ;) 14:26:51 tacotime_: solar designer is pretty crypto sharp, he posts on cpunks/crypto lists a lot and seems to have clues. seems to me if that is artforz alter ego he'd have the sharps to do a little TMTO 14:27:14 tacotime_: yeah i heard of solid coin by infamy/reputation only wasnt paying attention back then. he's that guy? 14:27:25 yeah 14:27:46 RealSolid/CoinHunter, same person 14:28:27 http://www.openwall.com/lists/crypt-dev/2013/03/21/1 14:28:29 tacotime_: apparently his antics were so stupid/evil/greedy as to remain the subject of lore 3 years later :) thats how i heard about solid coin at all 14:28:50 I'm not sure where mtrlt was updated to the desynchro/TMTO trick though 14:29:06 Or if pooler had first picked it up when optimizing his LTC miner 14:30:15 tacotime_: i think i saw solar designers TMTO experiments, he mustve cross posted to one of the crypto lists 14:30:28 yeah 14:31:46 mtrlt also ran off with a load if bitcoins after claiming he would implement primecoin miner on gpu 14:32:03 tacotime_: it was the same story again with larimer/protoshare/invictus momentum "cpu only" memory hard PoW, someone showed a few weeks into an impressively large VPS rented power driven difficulty ram that it was duh TMTOable and so worked just fine in GPU 14:32:10 He did release some really broken source code, but then just fucked off 14:32:52 If it's parallelizable, I find it difficult to believe that a GPU won't run faster even if you need memory 14:33:22 GPU vRAM bandwidth is always going to be greater than the DDR3 bus on the main board 14:34:01 tacotime_: they tend to need unique memory per mining instance, so momentum aimed for 750MB but then someone TMTO'ed that with bloom filter in place of hash-table. (unreliable but much smaller hash-table) 14:34:21 So when I hear about "dagger" I don't pay much attention either... implement it on GPU and play with it for a couple weeks, otherwise don't say it's hard to run on any single piece of hardware 14:34:29 mm 14:35:32 tacotime_: yes. but GPU ram bus is wider.. like 256-bit, 384-bit etc vs CPU at 64-bit cache line. so that erodes a bit of the throughput. and the access is random and usually like 64-bit word size (or should be for this reaso) 14:36:01 tacotime_: 256-bit might be quite ideal for dagger :) its a merkle tree. 14:36:16 killerstorm has joined #bitcoin-wizards 14:38:03 <_ingsoc> _ingsoc has joined #bitcoin-wizards 14:38:15 tacotime_: the only thing dagger is adding is to use coelho's use of fiat-shamir to make verification faster (and a few more links in the tree to make calculating all merkle steps slightly less skippable) its mostly a tweaked coelho merkle PoW. i mentioned the coelho merkle pow to vitalik its where he got the idea from. 14:40:23 hi. does anyone have an idea when OP_RETURN outputs will be usable on the mainnet? 14:41:04 adam3us, tacotime_ : that's the problem. The story seems plausible, but solidcoin is not a reputable source... 14:41:51 adam3us, tacotime_ : the fact that "you would be making mining bitcoin and selling them for ltc if you really want the ltc" (I read that somewhere) 14:42:33 adam3us, tacotime_ : seems to point out in that direction, if ltc mining was less competitive, it should have been more profitable 14:42:38 mappum has quit 14:42:59 maybe it was just a botnet what caused that 14:44:00 killerstorm: i am guessing that is a color coin related question ;) 14:46:45 adam3us: yep. it's possible to do coloring without it, using otherwise unused nSequence is appealing, but people freak out and ask about OP_RETURN 14:47:16 also it looks like non-tech people think that use of OP_RETURN makes protocol better and more legitimate :-/ 14:48:21 which reminds me...adam3us seems like enabling "joyscript" in all assets, but disabling the ops needed for quines/covenants on the hostcoin would be a good compromise 14:49:08 adam3us: you know I don't share yyour same fears, but we don't know of any use case that requires covenants in the hostcoin 14:49:54 killerstorm: yeah, some freicoiners thought it would allow people to use the chain for messaging, files... 14:51:10 killerstorm: here's some replayed history from a few days back 14:51:22 (06:42:24 AM) justanotheruser: "So, with some reluctance, I recently merged pull request #2738 : “Relay OP_RETURN data TxOut as standard transaction type.”" - gavin andresen 14:51:22 (06:42:36 AM) justanotheruser: So will it be standard in .9? 14:51:22 (06:42:52 AM) Luke-Jr: hopefully not 14:51:38 (06:43:04 AM) gmaxwell: 21:38 < gmaxwell> as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out. 14:51:38 (09:46:35 PM) adam3us: gmaxwell: "as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out." dont object to backing out (say NO to block-chain spam!), but what are they saying missing context? 14:51:43 andytoshi has joined #bitcoin-wizards 14:51:49 (10:37:04 PM) gmaxwell: adam3us: there have been a number of articles about how bitcoin has been "upgraded" to enable "distributed storage" and such horrifying things like that. 14:51:49 (10:40:32 PM) adam3us: gmaxwell: ah yes. its a scary situation indeed. the flip side is there are then people who will stego encode then in multisigs if you dont, and create needless non-compactable TXOs and on. 14:52:03 (10:41:17 PM) gmaxwell: adam3us: thats why I didn't oppose it initially. Though the trade off of people thinking it is a good non-antisocial and supported application is concerning. 14:52:04 (10:41:39 PM) gmaxwell: Esp what happens if abusive use arises and it must be turned back, but there is also non-abusive use? 14:52:34 killerstorm: (end of few days old discussion paste) 14:54:19 I don't see it as such a bad thing, I think timestamping is a legitimate use of the chain, but it's sad how people understand it 14:55:07 about using the nsequence fields...I don't know, some people want to use it for microtransactions channels 14:55:45 I think the probable solution is for microtransactions to be directly off-chain, but I don't know... 14:55:57 jtimon, killerstorm: coloring is lower bandwidth than mastercoin (which sends even bid and meta-messages over the blockchain) but its still in theory non-btc tx bandwidth use. 14:56:30 jtimon: time-stamping at least typically is putting a single hash which is the merkle root of many documents 14:57:08 adam3us: yeah, I don't think you need to allow more than a single hash after return 14:57:08 adam3us: by the way, gmaxwell mentioned that P2SH^2 would make storing data in blockchain impossible, but this is not true, it just makes it more expensive: people can simply 'mine' hashes which have prefixes they need and share data through those prefixes. 14:57:33 being not in-chain validated, it can be transffered off-chain as well 14:58:09 p2sh^2 ?? 14:58:22 jtimon: as far as I know, nSequence is basically dead, it was a bad idea in the first place. It is possible to do same thing (but better!) using multi-signature scripts. 14:58:43 killerstorm: yes this was mentioned somewhere. he viewed it as closer. also there are multiple stego encoding opportunities, eg unused not obviously invalid 1 of 2 multisig addresses etc. but just because you could stego encode with increasingly lower bit rates doesnt make it a good thing :) was talking about this with petertodd in the mastercoin context.. for them they'd as well use a separate merge mined chain IMO 15:00:38 killerstorm oh, this doesn't use replacements https://bitcointalk.org/index.php?topic=244656.0 15:00:49 I guess nobody has a use for it then 15:03:26 adam3us do you know of any proposed use of replacements? https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains this needed it? 15:04:08 well, that can be replaced with coinswap, which doesn't need nseq iirc 15:05:05 jps has joined #bitcoin-wizards 15:08:41 jtimon: i dont know, others would know better 15:09:19 jtimon, killerstorm: i think killerstorm implemented atomic swap in is chromawallet (color coin wallet) if i recall the announce 15:10:40 adam3us but that is atomic swap between colors in the same chain 15:10:59 the link and coinswap is cross-chain 15:11:05 transaction replacements are usable under condition that all miners are honest. this just doesn't make any sense. 15:11:19 well, coinswap can also be used in the same chain for mixing 15:11:26 trading-across-chains doesn't need replacements 15:12:20 killerstorm: yes, you're completely right, miners should just get the transaction with higher fees when they receive double-spends 15:32:57 killerstorm has left #bitcoin-wizards 15:47:43 DougieBot5000 has joined #bitcoin-wizards 15:51:32 I guess we should just remove the seq field in freimarkets... 16:05:31 jps has quit 16:10:34 jtimon: the seq field was designed for revisable bids? 16:11:00 it is designed for mempool replacement 16:11:22 basically for high frequency trading between a set of parties (to use satoshis terminology) 16:14:29 adam3us, TD: yes, but as killerstorm says there's no reason for a miner to accept seq=5 over seq=3 if seq=3 has a hegher fee 16:16:10 of course there is 16:16:16 this kind of nonsense reasoning about game theory is so destructive 16:17:11 the reason is that if useful and compelling apps rely on that functionality, that increases demand for bitcoin and thus the value of their fees and inflationary rewards 16:17:24 miners are not thinking only 20 minutes into the future, you know 16:17:52 it's sort of like saying "bitcoin can't work because miners have incentive to merge together and then do 51% attacks to double spend" 16:18:19 what we actually see is the opposite, where pools throttle themselves if they get too big because to do otherwise would hurt the value of their money 16:18:30 the same pool that did double spend? 16:18:41 or facilitate it i mean 16:19:04 other pools have done the same thing in the past 16:19:06 deepbit, btc guild etc 16:19:40 deepbit was DDOSed off the network for a week solid when it reached 50% I don't believe it ever regulated itself. 16:21:16 I'd like it to be true, but the self regulation is not working well, it's not like 40% is at all okay. Ghash.io stole several hundred btc from betcoin dice when it had just 25% (possible due to betcoin accepting unconfirmed) and then continued to grow to >40% after that. 16:21:53 I dunno about the game theory stuff, I agree it's wankery. But at the same time the observed behaviors are not good either. 16:21:59 correctly configured incentives don't magically make better solutions appear though 16:22:07 We agree. 16:22:18 (well you and I at least on that. :) ) 16:22:20 they exert pressure in the right direction, but someone still has to do all the work to create an actually better situation :) 16:23:27 the concern with things like the nseq in my mind isn't the incentives so much as the vulnerability of it— like betcoin taking unconfimred payments. 16:24:30 we lack tools, documentation and experience to help business do risk analysis. but over time i expect risk analysis to play a bigger and bigger role in bitcoin 16:24:40 like, where the block chain becomes a very strong signal that is nonetheless blended with others 16:24:53 betcoin took a bet and lost 16:25:08 sure, 99.99% of the time it'll be great. But in that remaining 0.01% ... watch out. Attacks aren't random though, at least when non-trivial amountes are involved a probablistic approach doesn't always work well. 16:25:25 TD: "the value of their money" you assume miners are always at the same time btc speculators, they can just sell them 16:25:53 businesses all have to do crazy risk analyses today to accept existing forms of payments, it's not really an alien concept for them. so we'll see. next dice site will have to weigh up the prospect of being double spent, at least until/unless the mining situation improves 16:25:59 jtimon: for how much? 16:26:14 jtimon: all miners are speculators to some degree because they have amortised costs 16:26:17 like saying "bitcoin can't work because miners have incentive to merge together and then do 51% attacks to double spend" <-- 16:26:17 no, it works because it's easier and more long term for them to just make money out of honest mining 16:26:43 of course if you're able to trust the payer... why even bother with fancy protocols. "Pay me what you owe eventually." 16:26:44 jtimon: in theory a miner who has paid off all his hardware and has no electricity/ongoing costs wouldn't care what the price is indeed. but i guess that won't be true for a long time 16:26:58 well that's what in practice we do already with unconfirmed transactions. 16:27:15 the block chain has a sweet spot where it's really useful and appropriate. other times it's not so helpful 16:29:49 though i'm kinda looking forward to the day that people are dropping nitrogen-cooled ASIC farms into the middle of the desert with a solar farm next door 16:30:16 well, don't want to take my description as assuptions, just wanted to pointed out that you're assuming to much about miners but... 16:30:51 when you compare capital, say a pub, a building and a mining rig 16:31:01 we don't know if i'm assuming too much or not because we never got a chance to try. the feature was disabled due to DoS/surface area risks a long time ago. 16:31:14 perhaps one day we'll get a chance. in the absence of a killer app for the feature though, it's a bit hard to justify right now 16:31:23 you compare them by capital yield, doesn't matter if you're doing it with your own money or with borrowed money 16:31:59 if it's your money you don't have more incentiveto accept low yields 16:32:24 you could lend/invest more profitably somewhere else 16:33:02 TD: I mean you're assuming too much about miners by assuming they keep the btc for more than 100 blocks 16:33:22 my assumption is really just that they care about the price 16:33:26 which is pretty basic, yes 16:33:43 jps has joined #bitcoin-wizards 16:35:03 my assumption (another simplification of reality) is that they care about yields and only indirectly about price, I don't know about their preffered unit of account, tend to asume is fiat 16:35:46 anyway, they won't destroy bitcoin by taking the higher fee when receiving double-spends 16:35:58 with or without seq 16:36:18 and if seq relies on that, well, then it is not very secure 16:36:49 of course they would 16:36:55 that would be the absolute worst thing miners could do 16:37:02 no unconfirmed transactions? watch the price collapse 16:37:05 why? 16:37:09 many miners would never make back their ASIC investments then 16:37:39 mhmm 16:38:34 what satoshi proposed for "unconfirmed transactions" were services that contracted with pools to connect directly with them I think 16:38:58 it's in the snack machine thread I think 16:39:29 no 16:39:44 killerstorm also says that the high "frequency tunel" use case doesn't need seq 16:39:44 in the snack machine thread he pointed out merely that the cost of double spending would be higher than the value of the snack 16:39:53 and that it could listen for double spends on the network anyway 16:40:15 it doesn't need tx replacement as long as the micropayment channel flows in one way direction 16:40:20 if you want more flexible arrangements it does. 16:40:30 fortunately for many interesting applications, one direction is enough 16:41:22 TD https://bitcointalk.org/index.php?topic=423.msg3867#msg3867 16:41:40 "No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes." 16:41:54 any node can do that. pools didn't even exist back then 16:42:09 so he obviously wasn't talking about contracting with pools 16:42:12 :) 16:42:19 correct he didn't said pools, just well connected 16:42:32 once double spend relaying is done, you won't even need to be very well connected 16:42:37 so this is not really a big deal 16:42:46 maybehe was thinking about mining farms? 16:43:15 "double spend relaying" I'm not sure that's really secure 16:43:26 he said what he was thinking of - a service provider that performed the job of watching for double spends 16:43:29 why not? 16:43:43 if it was secure we wouldn't need PoW 16:43:54 i think you're confused 16:44:08 double spend alerts tell you that there has been a double spend. it does not tell you which spend will win. 16:44:31 oh, sorry 16:45:00 I thought it was some of those proposals to "prvent double spending" 16:45:18 I think there's even a paper about that 16:45:41 no, i said "double spend relaying" 16:45:52 sorry again 16:45:57 np 16:46:04 so about (2-way) pegged side-chains again. the security insulation from not accepting more coins than moved, is good. but i think to avoid eg fractional reserve building up in the side-chain, i think the SPV proof needs history back to the coin migration? 16:47:23 TD I still think future miners will just mine the highest fee transaction (even with double spend relay) 16:47:44 *shrug* and i think you're wrong. guess we're done :-) 16:48:01 adam3us: preventing fractional reserve? I must have missed something about the proposal... 16:48:29 TD hehe, yes, well we can detail how each other see the future 16:48:33 jtimon: well that is not part of the proposal, i'm thinking of the min requirements to prevent it happening. the code in the side chain is subject to change 16:49:07 TD I think instant transactions won't be in-chain because in-chain transactions will be expensive 16:49:33 TD in-chain will be used for debt settlement mostly 16:49:34 jtimon: that assumes we cant make it scale quite a bit more. 16:49:43 these conversations are all years old 16:49:46 tbh i'm tired of them 16:49:51 back in 2010 it was interesting 16:50:16 enodios has joined #bitcoin-wizards 16:50:46 petertodd: is the man to wind up for game-theory arguments. 16:51:09 adam3us I think we can make it scale it more, just not enough to process all the world's transactions 16:51:57 adam3us which I also predict will be many more in the future 16:51:58 jtimon: i am not sure. maybe pegged side chains offer another flexibility. 16:53:09 adam3us: still if each node processes the whole world transactions, there won't be many full nodes 16:53:16 or miners 16:53:47 jtimon: think multiple side-chains, maybe shard the transaction set 16:53:55 jtimon: the scalability future will be in blockchains that are sharded, and it's feasible to "process the worlds transactions" with such structures 16:54:14 we advocate for private chains, though the most promising scalability improvements can only come from more data being directly exchanged between parties without toughing the chain 16:55:16 petertood: yeah something like sharding could make me wrong, but I'm unconvinced that's feasible for now 16:55:33 not that I don't think about that myself 16:55:51 jtimon: I disagree there, off-chian is a nice safe way to get better scalability, but I think the best is to reduce the consensus "size" required 16:55:53 it's already done: alt coins 16:56:31 indeed it is, what's interesting is how to better integrate multiple chians into a cohesive whole 16:56:58 TD altcoins are very wasteful the way they are right now, they're just highly subsidized by seignoriage greed and stupidity 16:57:10 the p2p chain-trade thing would seem to be the best way. not that anyone is really exploring it properly 16:57:26 jtimon: so they take some of the stupid-load off the bitcoin chain. win :-) 16:57:29 jtimon: though also I see *no* reason to think you can get fast, let alone instant, consensus requried for retail payments 16:57:51 just adding more altcoins doesn't scale, not even with merged mining, miners still need to process everything 16:58:20 jtimon: what i was thinking is that the world could shard into eurocoins, americoins, or by subject (bitcoins for the internet, corpcoins for big corporate payments, etc) 16:58:29 jtimon: then you'd have exchange rates between them. but that's painful. 16:58:36 easier to scale the tech, i suspect 16:58:38 petertood: "reduce the consensus "size"", that's what I meant here " though the most promising scalability improvements can only come from more data being directly exchanged between parties without toughing the chain" 16:58:58 TD: ha, for once we're on agreement on scalability (at least on what we should do in the short/medium term) 16:59:11 TD ok I get your point 16:59:12 i'll go out and celebrate tonight :) 16:59:34 TD but that's assuming no merged mining :( 16:59:56 TD: and for long-term, we can probably agree that we don't know yet becaues the research hasn't been done :) 17:00:11 the scaling issues with bitcoin aren't really mining, they're to do with management of the chain/transaction rates/etc. so merged mined altcoins are fine. 17:00:17 indeed! 17:00:42 yeah, maybe I'm just envisioning the worst-case scalability scenario, and still future looks bright 17:00:55 jtimon: ah, well depends on your definition of "the chain" - I think long-term we can create systems where, very roughly speaking, you have multiple chains where the "timestamping" PoW is all merged, but the proof-of-publication isn't 17:01:41 jtimon: so your tx on *a* blockchain might be subject to consensus by an audience of 10,000 or whatever, but the "audience" timestamping it may be millions 17:02:28 jtimon: and most likely the tech will be such that the more valuable transactions end up paying higher (absolute) fees, and are "seen" by a larger audience 17:02:33 TD: i'm more excited about pegged side-chains (aka alts but with bitcoin price pegging in lieu of new scarcity races) as a building block to explore sharding and other features. then each guy with a crazy idea can go knock himself out on a side chain without creating dust on bitcoin main meta-coin style, and without creating a new tulip coin with scarcity race sales-hook being his "feature" 17:02:38 petertodd: I just don't know how you're going to do that 17:02:47 jtimon: the open research problems are all related to how does security work there 17:03:12 petertodd: as said some kind of sharding would be very nice 17:03:13 jtimon: well, I've got some ideas - day before yesterday I outlined one on -wizards 17:03:52 yeah you half-explained me one, but I was unconvinced 17:04:08 adam3us: yeah, merge-mined sharding w/ pegged value is probably a reasonable way to upgrade bitcoin 1.0 to this kind of technology 17:04:13 I'm happy that you're thinking about these things though 17:04:35 adam3us: but as I say, the specifcs are an open question right now 17:04:57 anyway its not doom & gloom, we're not all out of ideas, maybe petertodd is full of it or maybe he finds the magic formula :) 17:05:13 petertodd: one idea I had in mind was partitioning the sequencing itself 17:05:19 sharding is sending bitcoin to an unspendable bitcoin addresses to mint altcoin? 17:05:22 petertodd: right exactly. so lets build pegged side-chain and let a dozen people and startups go try see if they can figure it out 17:05:41 but I haven't found a way to make it p2p 17:05:47 helo: no sharding is generic... just means split up the volume somehow 17:06:00 jcrubino has joined #bitcoin-wizards 17:06:04 ok 17:06:20 helo: pegged side-chain involves proof of transfer (you can move the coin back too, not destroyed as such) 17:06:24 adam3us: heh, worst comes to worst all my off-chain stuff *does* work just fine subject to the semi-centralization involved, and it has the enormous advantage that implementations of it can fail and won't take down the whole system with it 17:06:52 helo: like having half transactions in one chain and the other half in another chain 17:07:06 helo: I meant that for sharding 17:07:52 petertodd: it is highly likely that at least one person will try to claim solving it via a centralized server. well we have open transactions even :) federated but auditable, and rebuildable from receipts 17:07:59 jtimon: yeah, atomicicity of transactions in sharded systems is a really interesting question 17:08:37 adam3us: yup, my actualy claim to fame in that space is only better systems of auditing and fraud punishment - the idea itself is so simple as to get reinvented constantly 17:08:46 adam3us: *actual 17:08:47 let me explain how would it work "centralized", maybe you can come up with a way to make that p2p 17:08:55 petertodd, jtimon: so pegged side chain, like 100 of them merge mined, coins moved via SPV proof of move or atomic cross chain swap. seems not implausible 17:08:58 or someone else 17:09:21 jtimon: see fidelity bonded banks where the machine readable fraud proofs are what makes it possible to do it p2p 17:09:27 adam3us: that still requires fat validation miners 17:09:55 jtimon: no it doesn't, mining is scalable because miners don't have to validate all chains 17:09:59 petertodd you don't know what I'm going to say yet 17:10:12 jtimon: it merged mined, but maybe some model can be found for mining without having all 100 full tx feed. its not like most mining power right now is even looking at the tx... 17:10:52 petertodd: there was no sharding in adam3us not implausible comment 17:11:19 "pegged side chain, like 100 of them merge mined, coins moved via SPV proof of move or atomic cross chain swap. seems not implausible" 17:11:21 anyway we dont have to solve it today... more worried about how to provably preventing someone sneaking fractional reserve into a side-chain at this moment. 17:11:43 jtimon: yeah is just a definitional thing. you could consider the 100 side chains 100 shards 17:12:15 adam3us: well, like I said above, the trick is to separate timestamping form the proof-of-publication - merge-mined side chains can naturally work that way if they are genuinely merge-mined, as opposed to just a soft-forking change 17:12:40 petertodd: yes this is a kind of open transactions argument. i buy that as a plausible thing to explore. 17:12:59 well, since we don't know how to shard yet and you didn't explicitly mentioned it, I thought you meant we could still scale doing that without sharding 17:13:41 jtimon: i was thinking of a use-case of (multiple identical) pegged side-chains as a mechanism for sharding 17:13:57 jtimon: well, remember my thought example of the tree-like consensus system? if your top node in that tree is the bitcoin blockchain, then the two leaves logically are your merge-mined side-chains 17:14:15 jtimon: which is why coming up with a backwards-compatible upgrade is actually fairly plausible - ugly, but feasible 17:15:18 adam3us: but the pegging thing is to solve the "exchange rate" problem TD mentions 17:15:19 petertodd: its the beauty of pegged side-chain, the side chain (or lots of them, or competing lots of them) can go do experiments while retaining bitcoin main fungibility 17:15:50 adam3us: yup 17:16:02 adam3us: I'm saying I don't know a technical solution for merged mining + sharding in the first place, seem kind of incompatible to me 17:16:16 jtimon: right. but pegged side-chains also form security firewalled experiment zones for interesting things, like sharding, freimarket script extensions, utxo compaction, zerocoins, comitted tx... anything within reason 17:17:37 petertodd: the limitation is oniy i think it has to be not too alien for bitcoin to not be able to consume the side-chains SPV proof of move 17:18:06 adam3us: security firewalled? what in pegcoin makes it more attractive to merge mine than say, devcoin? 17:18:35 adam3us: nah, I'd say the bigger limitation is that long-term PoW security needs to be paid for by fees, and the basic economic model is screwy there and has a high potential of failure 17:18:38 jtimon: incentive you mean? ask petertodd he's the incentive / game-theory gur ;P 17:18:56 adam3us: it's the think with off-chain stuff: it becoming too effective is a huge risk in the long-term! 17:19:46 adam3us: now that's like, 10 years away long term hopefully, but it's a problem that needs solving eventually 17:19:54 petertodd: it seems like the biggest open q about it really. incentives. but its not like that solved in main. $25k/block or $150k/6-block is the price to admission (x the failure rate to build a chain long enough) 17:20:47 petertodd are you suggesting off-chain technology working nicely and securely is a "huge risk"? what do you mean? 17:21:01 petertodd: Maybe its a TD thing. we (humans) want and need this to work, so maybe most honest people will do it and that will carry the day 17:21:29 adam3us: yup, currently my best guess is per-tx PoW schemes (and actually, maybe per *txin* PoW schemes) with anti-pooling stuff and PoW algorithms more resistant to ASIC centralization is what'll work, but those are all -wizard level questions and lots of research to be done 17:21:39 jtimon: he's worried about an incentive break down leading to attacks 17:22:04 adam3us well I ask you because you made the firewall claim, but I'm happy receiving an explanation from anybody 17:22:10 adam3us: in the meantime, honesty and other non-ideal second order effects will help the existing system limp along for a lot longer than it deserves too 17:22:51 jtimon: yes, in the long term the PoW security needs to be paid for, and one of the few reasonable ways to do it is transaction fees, no-txs == no pow security in many very plausible future models 17:23:12 jtimon: the firewall is its not plausible for bitcoin main to consider accepting transfers back from a side chain (2-way peg) unless there is assurance that fraud or security bugs on the side chain can cause holders of bitcoin main coins to be dilluted or lose btc 17:23:36 jps has quit 17:23:54 petertodd: another is demurrage BUT why would you expect not to have any in-chain transactions? off-chain transactions cannot be p2p currencies 17:23:55 jtimon: /can/can not/. fortunately that seems possible to assure, hence 2-way peg excitement 17:23:55 Keep in mind, it's not that I disagree with TD's hope's of people playing nice, it's that if you're depending on that you've got a system with much weaker security guarantees than one that doesn't need honesty. 17:24:34 jtimon: why pay for an on-chian tx when an off-chian one works well enough? it's simple, less demand for on-chian tx's means less fees, and thus less security 17:25:07 TD is now known as TD[gone] 17:25:08 <_ingsoc> _ingsoc has quit 17:25:19 petertodd: yes. i think 51/33% attacks, incentive in btc main, and merge mined alt & sidechains is far from a done thing. r& d community need to figure out the optimal game-theory and protocol strategies 17:25:30 petertodd: if an off-chain system has all the properties bitcoin has, why should we fight to maintain a less efficient system? 17:25:38 jtimon: e.g. suppose fairly secure DRM w/ remote attestation was being shipped to consumers: you can easily turn that into a pretty good off-chain tx system with pretty good security that will get used a lot. That'll take a lot of money away from miners, reducing the security of the underlying system. 17:25:58 jtimon: because plausible off-chian tx systems *require* bitcoin to exist under the hood 17:26:08 jtimon: in this side-chain model bitcoin main is the sole home of reward mining. its the hub at the center. 17:26:15 jtimon: without bitcoin they don't work 17:26:19 DRM needs proprietary software, which means we can't trust it 17:26:29 proprietary soft/hardware 17:26:33 nsh_ has joined #bitcoin-wizards 17:26:47 jtimon: so what? trust isn't a binary thing 17:27:18 oh, I see "nbecause plausible off-chian tx systems *require* bitcoin to exist under the hood" this is what I was missing 17:27:19 jtimon: if I can trust it *enough* I can use it for less valuable payments and save the more expensive on-chian tx's for more valuable stuff 17:27:41 freimarkets private blockchains don't need public chains to work 17:27:45 and if bitcoin still exists, I can use techniques like fidelity bonds to make cracking the DRM system a lot less attractive 17:27:49 petertodd: there's a guy making offline bitcoin stuff using TPM cards that are microsd sized (via encrypted exchange of private keys) some people see to be excited enuf to be making him non-trivial btc onations 17:27:50 they can just interoperate with them 17:28:06 jtimon: is it drazan? 17:28:06 of course they don't have all the properties bitcoin has 17:28:08 adam3us: indeed, I'm thinking of buying a pair to support him 17:29:01 jtimon: drazvan https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688 17:29:33 jtimon: its kind of cool. not secure at the limit, but maybe it works for low value offline tx. its only the users that lose if it goes wrong, nor online btc holders 17:29:35 so your concern is that off-chain systems relying on bitcoin are so useful that nobody uses in-chain transactions 17:30:03 jtimon: doesn't have to be "nobody", just has to be sufficiently less demand for on-chian that total fees doesn't pay for enough security 17:31:05 well, since I'm not against credit, I'm fine if people use other-things-than-bitcoin offline, so these kind of things don't excite me that much, I haven't read the thread yet though 17:31:06 petertodd: or maybe some trust/certification/ripple stuff sneaks in and mining contribution is reduced 17:32:00 petertodd I tend to worry more about "too much security" in the chain than about "too little of it" 17:32:00 my rough guess is something like 0.1% to 1% of the total value of all Bitcoins should go to PoW security per year. Satoshi should have let that happen with either never-ending inflation, or better yet, explicit demurrage. Doing mining that way give a very simple and stable security guarantee, and importantly works regardless of how many on-chain tx's are done. 17:32:19 jtimon: they are bitcoins, just transfered by encrypted exchange of private keys, in the model that the user doesnt know the private key and the TPM microsd card wont give it to them (or moare accurately tries to prevent cloning, you can load and unload them) 17:32:21 jtimon: "too much" just means you're wasting money - not a big deal. 17:32:42 jtimon: too little and some malicious 51% attacker destroys the whole system and we're fucked - big deal 17:32:57 petertodd: but he should do NFC or QR code, not SMS :( 17:32:58 jtimon: 0.1% to 1% are pretty low numbers that can be ignored as "rounding errors" 17:33:20 adam3us: isn't that just a software detail? the hardware itself isn't what does SMS 17:33:28 petertodd: sure 17:33:32 maybe I'm too hippy or something, too much you're wasting resources, destroying more nature than you need and all that 17:33:59 petertodd: nfc/qr = network privacy. sms=privacy leak. 17:34:09 jtimon: well, meh :) I'm sure conventional transaction systems tend to spend at least similar amounts of money per year on security, likely usually much more than that 17:34:23 nsh_ has quit 17:34:23 nsh_ has joined #bitcoin-wizards 17:34:38 jtimon: I mean, hell, I'm sure with credit cards the numbers are about that *per transaction* 17:34:42 nsh_ is now known as nsh 17:34:42 well, I'm pretty sure 2PC ripple doesn't waste more resources than it needs 17:34:59 jtimon: wastes a lot of human brainpower on person-to-person trust relationships 17:35:23 credit cards need to feed fat cats, thus their high fees, but that's another story 17:35:31 jcrubino has quit 17:35:55 jtimon: that's a shitty way to talk about the situation and makes you sound like an occupy activist 17:36:07 petertodd I disagree on that I don't have to think a lot when a friend of mine wants to borrow 10 eur 17:36:47 jtimon: well I think you're dead wrong there :) 17:37:30 more to the point, if you can only borrow 10 eur from each friend, then actually using ripple for any large tx gets tough 17:38:44 whatever, I can say it more correctly but it's just takes longer 17:38:47 was just laziness 17:38:49 credit cards are a very unefficient system for multiple reasons, I was talking about efficient systems like @PC Ripple 17:38:49 2PC 17:38:54 petertodd: you see I believe in both counterpartyless money and credit monies complementing each other 17:40:02 to me, people that plainly reject credit as an exchange toold often sound like braindeath cultists goldbugs 17:40:23 just like people plainly rejecting counterpartyless money and only accepting mutual credit sound like fanatic 17:40:27 jtimon: You see, I belive in "This Bitcoin thing just requires me to install an app on my phone. This ripple things requires me to dick around convincing my friends to extend credit relationships to me and sounds like a shit-load of work." 17:40:30 that's just to me 17:40:50 Ursium has quit 17:41:01 jtimon: "Also, it's gonna be really awkward to turn down Bob because of his gambling problem." 17:41:24 petertodd: organizing a ntework of mutual credit local currencies is even more work 17:41:36 jtimon: "Nice guy, but still hasn't paid me back that $1000 I gave him when he got fired three years ago and needed to pay rent." 17:41:49 jtimon: "But I'd rather not bring that up again...." 17:42:18 I agree that a ripple-like network has harder critical mass problem than bitcoin 17:42:20 jtimon: Meh, software can do that automatically, and more likely we'll have schemes where the exchange rates don't float. 17:42:29 orperelman has quit 17:42:54 jtimon: It's orders of magnitude harder. 17:43:32 luckily it can start with other currencies like backed currencies, bonds, coupons, shares... 17:44:02 it's totally irrelevant what currency ripple works on, the problem is the social dynamics of it 17:44:06 maybe it never goes beyond that, but I think coupons can be more imporant than many expect in the future 17:45:07 if you have a pub and people accept some of your "I owe you a beer at my pub" currency, why wouldn't you do that? 17:46:01 *if* people accept it 17:46:09 espes___ has quit 17:46:19 jcrubino has joined #bitcoin-wizards 17:46:21 if they don't, then you've put a lot of effort into a system that never got used 17:47:33 espes__ has joined #bitcoin-wizards 17:47:51 mutual credit is widely used right now 17:47:59 much more than you think 17:48:36 I just want to give this systems a plattorm to securely inter-operate 17:48:46 I know, it's why I've said before that ripple is much more likely to catch on for b2b transactions given that 30-day-credit relationships are extremely common 17:49:42 but fundementally you have to ask why you would use the ripple *technology* to manage those relationships? if transaction fees are sufficiently low, there isn't necessarily a compelling reason to bother 17:49:48 yeah, b2b, so called "barter networks" (they're really just another currency), coupons, local currencies... 17:50:07 to interoperate with others 17:50:28 to be able to pay with your spanish local currency in germany 17:50:45 well, again, what does ripple bring to the table? the ability to do cut-thru credit relationships, what does that do for you? potentially reduces transaction fees 17:50:52 if fees are low enough, why bother? 17:50:55 you just need a market path from the spanish local currency to the germany one 17:51:05 what fees? 17:51:13 bitcoin fees? 17:51:38 remember, ripple is all about optimizing who owes who, but why do you care exactly? 17:51:53 that's what money is all about 17:52:24 "bitcoin is about who has what, but why do you care?" I don't understand your point 17:52:24 what money is about doesn't matter for the end-user, they just want to solve a business problem 17:52:59 petertodd: freimarket includes real-ripple as a sub-component so freicoins that are IOU based can interop with frecoins that are mined (minus demurrage) 17:53:03 seriously I don't get your point about not caring 17:53:26 how would you don't care about who owes you and who you owe too? 17:53:40 petertodd: i think its a logical and self-consistent system, remains to be seen on adoptions. some of adoption is first to market, network effects etc. 17:54:29 petertood: you don't see any value in a ripple network or in credit in general? 17:54:32 jtimon: because my *business* problem is "I want to make money, and I can make money if I sell icecream, and if my icecream distributor loans me some stock, I'll pay him back and we'll both make money." 17:54:43 jtimon: i think petertodd is still on competition & adoption, his q. why would someone prefer freimarket IOU freicoin over btc 17:54:58 jtimon: The "meaning" of money means absolutely nothing to either party in that transaction. 17:55:06 petertodd: people don't want money, people want the stuff they buy with it 17:55:16 spinza has joined #bitcoin-wizards 17:55:30 K1773R has quit 17:55:30 spin123456 has quit 17:55:30 he1kki has quit 17:55:42 jtimon: its also a value store i guess. 17:55:50 it's not about preferring, you have your wares that by definition you don't want and want to sell 17:55:56 jtimon: and that's the thing, "I'm an icecream mfg, I need milk, now if you farmers give me some milk, I'll give you some money once I sell my icecream" - that's another business relationship 17:56:21 exactly 17:56:32 that can be done with "money" or credit 17:56:42 jtimon: ripple says "hey! this forms a cool graph when we add the customers into a big decentralized distributed database!" and can make those credit relationships magically collapse when the customer buys the icecream or soemthing 17:57:01 the important stuff is are the icecream and the milk, the rest are just numbers to make that happen 17:57:23 jtimon: meanwhile the business say "Who cares? Doing it the old way is plenty efficient and the new way requires a bunch of software and buy-in from a zillion parties." 17:57:32 he1kki has joined #bitcoin-wizards 17:57:34 that's the ideal situation in ripple, try to come back to the b2b stage 17:57:52 you sell icecream in summer 17:58:22 I go to you and say "do you accept ourtown's local currency for the ice cream" 17:58:38 DougieBot5000_ has joined #bitcoin-wizards 17:58:42 you say "no, I prefer bitcoin" 17:58:47 "ok, ?I don't have bitcoin, keep your icecream" 17:59:23 if you want milk and you can buy it with both local credit currency and bitcoin, why reject any of the two? 17:59:37 and that's the problem, any real business will say "Why the hell do I care about these local currencies? Let someone else figure out how to convert FooDollars to and from Bitcoin so we can focus on making icecream, our core competency." 18:00:23 rdymac has quit 18:00:34 hehe, you remind me to people talking about real businesses and bitcoin a while back... 18:00:44 You might not be aware of this, but one of the reasons Net 30 day works is because there exist third party credit rating agencies that specialize in figuring out whether or not your counterparty will pay you back. 18:01:01 K1773R has joined #bitcoin-wizards 18:01:02 the magic of ripple is that you will only ever receive the currencies you accept 18:01:26 ...and when those agencies aren't good enough, the reason why Net 30 day works is because often suppliers have special insights into their customer's businesses, and thus credit worthyness, that is otherwise really hard to get. 18:01:33 DougieBot5000 has quit 18:01:38 and the payer doesn't need to bother about conversions neither: the system does them 18:01:42 yes, I'm aware 18:01:43 jtimon: That's not magic at all. 18:01:53 jps has joined #bitcoin-wizards 18:01:59 no, it's not magic 18:01:59 it's tech 18:02:01 jtimon: That's the magic of "I price my icecream in dollars." 18:02:08 petertodd: well i guess bitcoin doesnt do it 18:02:11 jtimon: You don't need ripple for that 18:02:41 petertodd: bitpay et al let you though, ok 18:02:51 you can say "I price my icecream in gbp, I accept btc, bristol pounds or gbp" 18:03:11 adam3us: Exactly! bitpay, and the exchanges they work with, managed to outsource all that highly specialized work related to figuring out how to convert bitcoins to dollars 18:03:14 I go there with frc and sevillan pumas 18:03:47 petertodd: probably where a difference comes in is its hard to take out btc denominated loans because its volatile and trending up in price. 18:03:50 I push "pay 1 gbp to this merchant" the system says "want to pay X frc or Y pumas? 18:04:02 what's the unconvenience? 18:04:39 rdymac has joined #bitcoin-wizards 18:04:45 petertodd: a ripple network can do what bitpay does!! 18:04:57 jtimon: the unconvenience is that you needed this big ripple thing with a zillion credit relationships for it to work, when the alternative is to let some specialist handle it for you 18:05:26 no, I said the merchant just accepted 3 currencies, that's 3 credit relationships 18:05:30 jtimon: See, if tx fees to and from sevillan pumas are low, then you're customer, or you, can just as easily use that specialist to convert it for you. 18:06:03 jtimon: That's a *low overhead* solution to the problem that doesn't require much adoption to work. Ripple is the exact opposite. 18:06:12 but the point of the system is unite the infrastructure of the different currencies NOT TO NEED the specialist 18:06:39 whatever, I don't think I can convince you 18:06:50 jtimon: Modern economics has realized over and over again that specialists are excellent solutions to most problems. 18:07:17 so please, answer my previous question "you don't see much value in a ripple network or in credit in general?" 18:07:43 I see lots of value in credit, because people use credit all the time. Ripple, not much value at all. 18:07:59 petertodd, argument of authority fallacy, your authority: "modern economics" 18:08:02 orperelman has joined #bitcoin-wizards 18:08:11 Ripple = credit 18:08:30 jtimon: No, ripple is a way to manage credit. There are other ways to manage credit. 18:08:41 it's just the same thing with a more convenient infrastructure 18:08:59 jtimon: You think it's more convenient, I don't for a whole host of reasons. 18:09:12 what's the difference between an international payment and a ripple transaction? 18:09:29 transitive credit, it's the same thing 18:09:49 And the biggest problem with Ripple is the value of it is network effect dependent, so if only a small network of people use it it has very little value. That's a enormous bootstrapping problem on top of all the other problems of it. 18:09:54 you know, banks took all that overhead of trusting each other 18:09:59 jtimon: if u really lend people money in small amounts, often you dont get it back. thats my experience. and lending money to friends & family generally is not a good idea. when something goes wrong it leads to problems. 18:10:27 jtimon: yes, and banks are specialists at that task. Ripple is asking everyone to get in the business of doing that, which goes against the tendency in modern economies to specialise. 18:11:04 adam3us: yup, it's worth noting that Net 30 day credit relationships are declining as businesses become more complex and transactions more convenient. 18:11:04 Ursium has joined #bitcoin-wizards 18:11:06 I'm saying it won't start with personal credit, but with b2b, local currencies, p2p markets gateways... 18:11:07 petertodd: i think the notional advantage of ripple.com is that they can cancel out some debts and so reduce the fees 18:11:22 the small participants can join later 18:11:38 adam3us: yup, which means it's in competition with every solution that reduces fees... and there are a huge number of ways to do that 18:12:11 just to be clear, I'm talking about ripple the concept not ripple.com 18:12:12 jtimon: doesn't work that way, often those small participants are what make the ripple network loops happen that let credit relationships get canceled out - the core thing that ripple does 18:12:21 petertodd: actually ripple.com is very poorly explained online. i am not sure if it also has issued values other than iou values mixing on its network. 18:12:35 adam3us: ripple.com is an abomination and we shall not refer to it again 18:12:40 the way you trust in ripple.com is very risky for users 18:12:42 jtimon: yes. thats why i put ripple.com when i wanted to refer to them 18:12:55 Ursium_ has joined #bitcoin-wizards 18:12:57 because it assumes 1 aaaUSD = 1 bbbUSD 18:13:01 petertodd: hehe the R-word. 18:13:52 that's not necessarily true in 2PC ripple or freimarkets 18:14:31 jtimon: replacements can be used for microchannel payments (e.g. utility bill) 18:14:43 See, fidelity bonded banks are an excellent example of something where ripple can work very well, and one of the reasons that works is because the whole point is to keep tx fees low, 1 aaaBTC == 1 bbbBTC, and all the logic about the trust relationships can be handled in software (talking about the ideal fidelity bonded bank stuff here) 18:15:16 But that's a crazy-specialized example, and the whole concept of fidelity bonded banking is just as likely to get pushed out by other ways of getting low tx fees. 18:15:30 aaaBTC/bbbBTC should be just a market like any other 18:15:44 jtimon: that's a market with very little depth to it 18:15:52 Ursium has quit 18:16:08 that depends on the issuers, aaa and bbb 18:16:58 jtimon: if the issuers are big, then you've got something that looks suspiciously like standard systems and the cancellation advantages of ripple don't apply, if the issues are small, then you've got the network effect problems and it doesn't work 18:17:00 maaku why a miner should accept seq = 5 over seq = 3 if seq = 3 has a higher fee ? 18:17:17 jtimon: because TD and Gavin asked nicely 18:18:04 petertodd: if I'm the issuer of both aaa and bbb I can make that volume infinite no matter how small I am 18:18:19 Ursium_ has quit 18:18:41 jtimon: if you issued both, they there weren't two separate things 18:18:48 "jtimon: because TD and Gavin asked nicely" what did they asked? 18:19:08 the difference between aaaBTC and bbbBTC is that the issuer is differnt, and thus the default risk is different 18:19:20 jtimon: to not do "selfish" replace-by-fee of course 18:19:21 jtimon: what if they have the same fee? 18:19:35 whatever system you had in mind to make "1 aaaBTC == 1 bbbBT", it can be simulated with a market 18:19:51 agreed that nseq is dangerous, but just pointing out the (only) application I know of which nseq handles but nothing else does 18:20:02 maaku: then you want to accept whatever has the lowest orphan risk, which is whatever you think everyone else accepted, modulo the fact that accepting updates uses precious bandwidth so why encourage that? 18:20:21 tacotime_ has quit 18:20:27 killerstorm said you can do that use case with multisig 18:20:32 petertodd: true. then is there any other valid use for nseq? 18:20:38 (still catching up to scrollback) 18:20:46 maaku: to fork alt implementations :P 18:21:12 maaku: nSeq is also the *only* user-settable field in a txin that is signed by the signature - an unfortunate limitation 18:21:28 maaku: useful for colored coins, as an example, as nSeq can be the mapping of colored input to output 18:21:48 killerstorm wants to use the unused nseq to put CC metadata instead of using OP 18:21:57 OP_RETURN 18:22:10 jtimon: yeah, I suggested that to him 18:22:18 but some people are telling them that the field will be re-enabled later 18:22:38 petertodd: yes, he said so in bitcoinX 18:22:45 so what? using it that way is compatible with transaction replacement in fact 18:23:09 he came here to ask about that 18:23:39 arguing against the security and the use case of nseq 18:23:50 well, just think about it: if nLockTime=0 and nSeq != max, the tx is final and nSeq irrelevant 18:23:55 so I concluded we could just remove it in freimarkets 18:23:56 (to the replacement code) 18:24:41 I see, so there's no contra at all for using them for CCs 18:25:25 yup 18:25:38 jtimon, petertodd: are we all done with the sales/system competition-level arguments about freimarket/real-ripple/ripple.com/banking system? so many ore interesting things to talk about... ;) 18:26:01 the real risk is nSeq will be defined to be something else entirely, and there's some possibilities there, but worst comes to worst you can just upgrade the CC software ina "hard-fork" - not a big deal 18:26:20 adam3us: lol, distracting me from stealth addresses as it is 18:27:25 here's one for you... how do you bootstrap mergemine security in a side chain (or an alt in general). find miners to merge mine as a favor before there is fee incentive? 18:28:02 maaku_ has joined #bitcoin-wizards 18:28:22 petertodd: some stealth discussion on bitcoin-dev.. also did u see gmaxwell idea for a better fuzzy bloom-bait/prefix? 18:29:01 still, I see no reason to keep them in FM 18:29:03 maaku has quit 18:29:05 adam3us I don't think we were advancing much 18:29:20 adam3us: remind me again? 18:29:20 nsh has quit 18:29:43 petertodd: he posted it also on bitcoin-dev 18:29:45 jtimon: it's 4 bytes per txin, meh 18:29:50 adam3us: one sec 18:31:08 adam3us: our approach to MM start without it untill we have our own miners, than hardfork for MM and convince Luke-Jr to MM it 18:31:28 I think we could do it already, but maybe we won't be able to hardfok once again for freimarkets then 18:31:55 petertodd 4 bytes we won't use. we're hardforking, why not? 18:34:03 well, when we start MM I think we will approach all big pools 18:34:27 adam3us: gregories idea doesn't scale as well 18:35:02 adam3us: the big advantage of the prefix thing is it's trivially compatible with sharding ideas and so on - note how I talked about putting the ephm pubkey in the txout too 18:35:35 petertodd: nearly. its also indexable just more indexes, and it allows some parameterizable fuzziness. but it also has stat analysis problems nearly as bad as bare prefix 18:35:35 adam3us: to be efficient, you're going to need 16 lookup table versions for instance 18:36:12 adam3us: exactly, and at the same time, how bad is the analysis problem anyway? it's *not* an issue for coinjoin the way people seem to think it is, given the version where the bait goes in the txout 18:36:13 petertodd: yes its not cost free, but its still indexable and the privacy is slightly less bad. 18:36:22 jtimon: just make sure that a signature can sign stuff in the scriptSig then 18:36:33 jtimon: there really needs to be a mechanisms to do that 18:37:04 adam3us: meh, that's not exciting me very much - highly unlikely that version of it will wind up being made into miner committed indexes for instance 18:37:32 petertodd I don't understand, why is nseq necessary for the signature? 18:38:31 jtimon: the point of it in the CC example is that you want to sign something in the txin itself because you have some additional data that needs to be signed, but that data isn't known until the tx is created 18:38:31 petertodd: for example with 1 byte prefix, it cuts your anon-set by 256x. mix in a bit of time correlation, change glomming on input, and any non-trivial use of reusable addr and its a lot worse i think 18:38:48 jtimon: the OP_RETURN txout solution to that is worse, because it doesn't play well with coinjoin 18:39:06 adam3us: remember that prefixes are denominated in bits... 18:39:15 petertodd: we support colored coins explicitly. is there some other reason you'd need data attached to the txin? 18:39:37 maaku_: upgrading CHECKSIG in a soft-fork is an excellent example 18:39:46 nsh has joined #bitcoin-wizards 18:39:50 can you explain? 18:40:06 petertodd: either bits is enuf to create an anon-set problem, or bits is so small that it doesnt scale 18:40:37 adam3us: what makes you think it doesn't scale? I mean, shit, without prefixes the idea works reasonable well with 1MB blocks - there isn't that much data to manage 18:41:36 maaku_: suppose I want to add a signature over the fees paid to CHECKSIG, if I could just make a merkle tree of the txin values, and put that merkle root in the scriptSig, then I could soft-fork that feature in by defining SIGHHASH_CHECKFEE_MERKLE_ROOT 18:41:50 maaku_: I can't do that right now because any additional data in the scriptSig is unsigned 18:42:13 adam3us: fundementally the problem is what's the chance of all these extra indexes getting adopted? I'd say nero-zero 18:42:19 petertodd: i mean doesnt scale to non-full-nodes 18:42:23 adam3us: near-zero 18:43:03 adam3us: no, it's just a bandwidht trade-off, a desktop SPV client isn't gonna care about downloading even all blocks frankly, and 1/8th (say) gets to be more and more reasonable 18:43:38 petertodd: well if u wanna take the 'we cant change shit' stance i guess we hae to take solutions that cause big privacy problems because of that. hmm. 18:44:00 petertodd I don't understand the use case, probablyit can be made without a new op 18:44:01 petertodd: your smart phone might care 18:44:05 adam3us: well hey, this is a much smaller privacy problem then what we have right now 18:44:26 petertodd: i disagree, its a worse privacy problem. thats my point. 18:44:31 jtimon: think about it more, it can't 18:45:02 adam3us: reality is people are going to connect to untrusted SPV nodes, and it's *very* likely that attackers will start (or alredy do) run them for data collection 18:45:05 petertodd: gmaxwell went over this yday and i wrote about it in detail in one of my bitcoin-dev posts. the privacy issues 18:45:37 adam3us: additionally we *need* to solve SPV scalability, and prefix indexes are a big part of that (electrum works that way for a reason) 18:45:44 petertodd: yes. but. as gmaxwell said thats different to putting the privacy leak in the indelible global record 18:46:07 nsh has quit 18:46:30 adam3us: well for instance his analysis re: coinjoin is just wrong 18:46:33 petertodd: yeah but lets at least try do it in a privacy preserving way eh. we can scale things also by doing other scary things. 18:47:39 adam3us: that's what I'm trying to do you know... 18:47:41 petertodd: i think my analysis on bitcoin-dev about the anon-set overlaid on network analysis is correct. 18:48:23 adam3us: my point is, remember what he said about it reducing the anonymity set in CJ? that's just wrong - it doesn't help you distinguish change and non-change for instance 18:48:32 petertodd: ok fair enuf. i am just saying, its worse, not better; depending on your threat model, and i think targetted attack is less dangerous than after the fact global analysis attack 18:49:16 adam3us: as a thought experiment, consider how it'd work if you made the grinding bloom filter compat: that's basically what gmaxwell is proposing 18:49:26 adam3us: (specifically with a random nTweak value) 18:49:28 petertodd: well actually it might if non-change is an prefixed reusable addr and change is a one-use adr 18:49:39 jtimon petertodd: well i think this particular application could be better done wih etotheipi's WITHINPUTVALUE sighash mode 18:49:50 adam3us: the whole point is that you can't distinguish a prefixed reusable *output* and a change output 18:50:17 maaku_: yes, but where in the scriptSig do you sign the input value? 18:50:42 maaku_: again, if the signature covers some of the scriptSig, that's easy 18:50:57 petertodd: i know. but prefixes are unchanging. there lack of presence eliminate some tx from the network analysis. that effect can be cumulative. it might leak more bits of entropy per edge than a coin join with random (possibly malicious join to self parties) adds 18:51:23 petertodd maaku_ I can't think about it because I don't know what is trying to be done 18:52:11 jtimon: he's trying to have his signature cover the fee, by signing both the input values and the output values 18:52:40 petertodd: ( i mean if i know because its public your prefix is FF and i see a coinjoin that doesnt have FF in the output then i know you're not in it with that addr. maybe there's another CJ feeding into the previous and it does have FF in it.) 18:52:59 adam3us: again, you're totally missing my point here. you can't distinguish the output in the prefix-tx, so all you've maanged to do is narrow down who the tx might pay in terms of probabilities (and even worse, you can't rule out stealth addreses with longer, or no, prefixes) 18:53:47 ok, first solution: using joyscript and a load_utxo-family opcode (I know, this is another opcode) 18:54:06 jtimon: and doesn't work for hostcoin 18:54:15 jtimon: anyway, just look up what I've written on bitcointalk about OP_CODESEPARATOR 18:54:21 hrm, well this is actually an interesting question about a more expressive script - sighash will have to be implemented differently 18:54:22 petertodd: ok look at it from a black box perspective. there's 1000 tx going into a cluster of CJ, two inputs have FF on them, two output have FF on them. there are two uers we've noticed who use CJ who have FF, anon-set reduction by factor of 1000 18:54:45 maaku_ to disable covenants you just need to disable load_tx 18:54:45 petertodd: OP_CODESEP is just bottom really isn't it? 18:54:54 jrmithdobbs: ? 18:55:06 jtimon: ah, reading failure 18:55:34 maaku_ how so? 18:55:48 jtimon: you're fine i misread what you said 18:56:11 adam3us: again, you can't distingish outputs using stealth and ones that aren't 18:56:20 petertodd: give me a few and i'll restate ;p 18:56:27 petertodd: i think you said it yourself even "all you've maanged to do is narrow down who the tx might pay in terms of probabilities" right exactly :) it weakens the already fragile anon-set coming from CJ with random parties. there are flood attacks on mixers near and dear to people who analysed mixaster remailers which apply 18:56:38 but about sighash, the issue is that how it determines what script to put in the serialization only really makes sense for a linear language 18:56:51 petertodd: correct. but that doesnt stop you ruling out a given stealth address. 18:57:09 shesek has quit 18:57:11 execut3 has joined #bitcoin-wizards 18:57:48 petertodd: full node stealth addresses are of course immune as they can have zero prefix. 18:58:21 adam3us: look at it this way, I agree with you that there is an info leak, is it enough to say "wait stop! lets not implement this and delay!" no 18:58:30 petertodd: so either you are saying they arent used, or if they are used they decrease anonymity. less than address reuse, but more than one-use address. 18:59:18 adam3us: what gmaxwell proposes is a linear increase in anonymity set size, with a linear increase in peer work because of extra indexes. will that be implemented? I'm not seeing it 18:59:20 petertodd: well it was for me. i figured out the same stuff on bct and thought, hmm no thats not good for privacy, put in bucket of fun but not quite safe things. (other than for full-node use case) 18:59:32 <_ingsoc> _ingsoc has joined #bitcoin-wizards 18:59:37 ditto, fwiw. 18:59:57 (That this idea wasn't new to me— I knew it from bytecoin's thread, but I simply thought it wasn't good enough) 18:59:58 adam3us: tough, it's a hell of a lot safer than the *actual* alternative people are going to be using 19:00:19 petertodd: what are they going to be using 19:00:23 adam3us: don't live in a dream world of users doing what's absolutely optimal vs. "Hey, this works!" 19:00:32 petertodd: TD is working on HD wallet for bitcoinj. 19:00:34 adam3us: they're going to re-use addresses left right and center 19:00:41 maaku_ is there any reason not to make withinput value the default? 19:00:42 adam3us: that's got nothing to do with it 19:01:04 adam3us: HD is orthogonal to the problem stealth addrs try to solve 19:01:04 having your security depend on unknown factors esp including the attacker's statistical prowess... kinda lame and sometimes less secure than no privacy at all. In any case, it's worth at least doing the thought to get the best design within that space we can. 19:01:13 petertodd: i think it has a lot to do with it. most addr reuse is on bitcoinj dependent smart phone wallets i hazard 19:01:18 jtimon: yes, that's been my thinking. just have to be careful about compatability 19:01:40 petertodd: so you'd want a some sort of code-separator like device for the scriptSig? 19:02:00 gmaxwell: I forget if I got around to proposing it, but the wider blockchain data thing that be made more private in exactly the same way as you're proposing by having full-nodes maintain redundent indexes 19:02:07 wallet421 has joined #bitcoin-wizards 19:02:08 wallet42 has quit 19:02:08 wallet421 is now known as wallet42 19:02:08 wallet42 has quit 19:02:08 wallet42 has joined #bitcoin-wizards 19:02:24 adam3us: that's change addr reuse, not payment related 19:02:33 execut3 is now known as shesek 19:02:41 adam3us: I'm solving the user-payment side of things, and that's a hard problem without bi-directional comms 19:02:50 petertodd: aslo while you and jeremy spilman are in implemention mode why not focus on full node case? 19:02:57 valitationScript may serve too, but again I'm missing the practical use case of the problem, small memory nodes? 19:03:00 adam3us: because that's stupidly limiting 19:03:27 adam3us: anyway, long-term this prefixing stuff will either end up being common for scalability in general, or bitcoin doesn't scale... 19:04:13 adam3us: equally, in the near future we're going to see prefix lookups being used for wallet syncronization, so that part of the infrastrucutre is getting implemented 19:04:28 adam3us: did you read my blockchain privacy paper btw? 19:05:02 nsh has joined #bitcoin-wizards 19:05:14 I'm not following the stealth addresses discussion in detail, but petertodd are the prefixes needed for sharding? 19:05:21 jtimon: exactly 19:05:22 petertodd: thats just admitting defeat. i dont think we've necessarily hit a tech wall yet. eg gmaxwell cooked up the fuzzy bloombait in a few mins yesterday. 19:05:55 jtimon: it's an avenue for future expansion of capability, by being able to include stuff in the scriptSig which is covered by a signature 19:06:00 jtimon: no he's just trying to make addresses recognizable but with some privacy in a bloom subset like sense 19:06:18 petertodd: blockchain privacy? where was this? 19:06:24 enodios has left #bitcoin-wizards 19:06:41 adam3us: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html 19:06:45 petertodd then I guess you need to convince people sharding is feasible to make it count as an argument in the stealth address discussion 19:07:30 jtimon: sharding isn't just related to blockchian structure, it also works even in the "big-block" scenario because it lets nodes handle a subset of the blockchain bandwidth 19:07:55 adam3us: I think he uses it for two purposes I don't understand the one you mentioned, but don't bother I still have too much to read from stealth addresses 19:08:37 jtimon: yes like views it as somehow inevitable for sharding maybe.. i dont get that bit either ;) (talking about you third person there petertodd) 19:09:09 adam3us: read that paper first... 19:09:18 adam3us: there is logic to it :P 19:09:56 petertodd: so it could work even without changing anything, miners could just do it to be able to manage a partition 19:10:36 petertodd I am understanding what you're saying? 19:10:47 ma I 19:10:47 am I 19:10:51 ug 19:10:52 jtimon: miners can't mine without the whole blockchain right now, but full-nodes passing around archival data and serving SPV can easily shard and process bandwidth subsets 19:11:11 jtimon: they can do so securely with the committed (U)TXO stuff that's been floating around 19:11:39 assuming we already have commited utxo 19:11:48 what's the next step for sharding? 19:12:37 jtimon: very simple: adversie what prefix of the UTXO space some full node has, and SPV clients connect to full nodes with the data they need 19:13:12 jtimon: well, and make "full" nodes themselves only get tx's from their peers matching the prefixes 19:13:12 I see, thanks 19:13:31 wait 19:13:36 Ursium has joined #bitcoin-wizards 19:14:09 jcrubino has quit 19:14:33 full nodes also select a part of the UXTO, where do the prefixes come in? 19:14:55 oh, sorry 19:14:56 jtimon: the prefix is what part they select 19:15:00 Emcy has quit 19:15:31 jtimon: obviously they're not actually doing full validation here, but you can set things up so that all the blockchain data is "covered" by multiple partial validators 19:15:41 the smaller the prefix, the bigger part of the uxto you have 19:15:50 jtimon: with fraud proofs if anyone finds a problem, everyone can be informed that the block needs to be rejected 19:15:53 jtimon: exactly 19:17:31 petertodd: ok read. i think i skimmed it a bit before (remember the bloom issues you identified.. i asked TD about it early on and he said yes there are a few bugs) 19:17:48 spenvo has joined #bitcoin-wizards 19:17:56 ok, I'm trying to compare it with maaku_'s stateless validation proposal... 19:17:57 in that one, miners only have the root of the utxo 19:18:28 Ursium has quit 19:18:37 jtimon: this *is* his proposal 19:18:44 jtimon: it's something you can do with it basically 19:19:26 ey, wait 19:19:28 adam3us: good, now see my point how this stealth structure fits in very well with where blockchian indexes are going? this is something we can actually get implemented, and solve a lot of real problems very quickly 19:20:44 petertodd: block chain indexes? you mean the above koorde like sharding of data? (nodes store things near to them in some artificial space)? 19:20:59 adam3us: yeah exactly 19:21:17 adam3us: remember, the big issue with bloom is it's not indexable 19:21:35 adam3us: to query against a bloom filter requires matching against all transactions for every query, which sucks 19:21:50 petertodd: i dont quite accept that as a valid design rationale though. 'could shard this way' for a speculative what-if => lets do prefixes even though they have self-admitted linkability problems 19:22:13 petertodd: yeah bloom has its issues. 19:22:17 adam3us: there's nothing speculative about it, electrum does just that, and will add prefix queries soon 19:22:23 petertodd: maybe there's a third way 19:22:54 petertodd: speculative in there being full-nodes that focus on some prefixes only. 19:22:55 Doge_Funnie has quit 19:23:01 petertodd: with your proposal, how miners validate foreign blocks that contain tx that refer to a part of the utxo they don't have? 19:23:01 Are miners also supposed to send the full update proofs to each other like with maaku_'s? 19:23:01 If so, what do miners hold any of the utxo at all (apart from the root)? 19:23:22 adam3us: electrum servers *are* an example of a full node serving SPV clients 19:23:27 adam3us: SPV != bloom you know 19:23:49 jtimon: in the current design of bitcoin that's not really possible 19:23:51 petertodd: yes i know, and i agree 19:25:02 petertodd: which of the two things are not possible? 19:25:45 adam3us: yes, so, the question really is how do you index data such that you can match approximately, with the in-chain data being less approximate then the indexes the SPV-serving nodes have, gmaxwell has a proposal, but again, how would you ever end up with a miner committed index of it? 19:26:24 jtimon: the validate txins referring to utxo they don't have 19:26:29 petertodd: well bloom results are not committed 19:27:02 adam3us: I know, and like I said, stealth addrs could be implemented as "match this bloom filter index with this nTweak" 19:27:21 petertodd: or are they. hmm. i mean can you verify the entire result set from the fuzy bloom query tie into the containing block hash? 19:27:23 adam3us: but that's not scalable on the index side becuse of all the possible nTweak's 19:27:57 petertodd: I think maaku's proposal with updatable trees require clients to send the complete proofs miners need to check validity having only the root of the utxo 19:28:06 adam3us: obviously miners could commit to boom filters, but then you'd run into the problem that to use gmaxwell's solution you have to have them commit to n different versions of the filter 19:28:27 jtimon: ah, sorry, yeah, if you adopt that then miners can do that 19:29:05 that's stateless validation 19:29:39 it seems better than sharding for miners 19:30:02 petertodd: getting sleepy but it seems more like a public key watermarking problem. ie there are people who thought about and may be even have solutions to this problem. i am not sure if they are going to be indexable or not. but we could explore it. if its expensive also maybe there could be fees. 19:30:10 jtimon: think about how much bandwidht they're using in that example... 19:30:19 maybe all the proofs should go hashed in the block 19:30:39 adam3us: it has to be a solution that isn't expensive or this isn't gonna happen and we'll still have address reuse 19:30:50 petertodd yes, bandwith is the bottleneck in this case 19:30:53 adam3us: hell, this has to be a solution with pretyt damn low programmer complexity to have any hope of being adopted 19:31:06 petertodd but your approach is not secure for miners 19:31:20 jtimon: wait, the sharding? 19:31:24 jtimon: forget miners 19:31:25 yes 19:31:35 petertodd: yea yeah. i know the life of a privacy tech crypto guy, people emand the impossible and then turn their noe up when you pull some minor miracle that its not as easy or as cheap as doing something privacy invasive. been there. done that. got the t-shirt 19:31:48 jtimon: sharding for miners is a much harder problem then sharding for full-nods that want to serve SPV 19:32:04 jtimon: i got stateless validation from petertodd 19:32:32 adam3us: exactly, OTOH we've got this stealth addresses proposal that's gotten like three reimplementations in a few days, and we can actually get adopted. Let that process happen and we can *upgrade* it later to be even better. 19:32:43 petertodd, full nodes too, but miners are spending money hashing....oh, ok, you're not talking sharded miners 19:32:48 adam3us: I'm specifically trying to design stealth addresses themselves to be backwards compat upgradable you know. 19:32:54 or it came out of a discussion between petertodd and gmaxwell, iirc 19:33:01 here on -wizards 19:33:25 petertodd I thought you needed prefixes in stealth addresses for sharded mining 19:33:42 adam3us: when we figure out a more clever way of doing prefixes, we can add a field to the stealth addr data that says "Hey! if you know how to handle this, you can also pay me with this fancy index scheme, but otherwise do the old thing." 19:34:01 jtimon: sharded mining eventually, sharded full nodes soon 19:34:38 petertodd: so maybe could it reasonably said that stealth addresses are used only here in the vanity/bizcard kind of use case. or is this going to turn into another 'yeah address reuse, sorry cant persuade user or wallet maker to stop' scenario 19:35:39 petertodd: ie they just jam them into their wallet, and reuse them ad nauseum for plenty of non-bizcard scenarios 19:36:13 petertodd sharded mining is what's hard for me to believe you're near to solve, but sharded full nodes seems a good enough use case to justify prefixes on stealth addresses 19:36:14 adam3us: hey, at least with an upgrade path we only have to convince the wallets incrementally 19:36:43 petertodd: btw i have another solution to address reuse. one-show signatures. (reuse it at your peril, do that and it leaks your private key via simultaneous equation) the tech is very simple to do it too. how about i propose that on bitcoin-dev and draw some diagrams about the advantages of a final solution :) 19:36:45 adam3us: meh, users reuse addrs if you let them 19:36:58 adam3us: pff, good luck, that's user obnoxious 19:37:17 petertodd: well the client sw would say "error cant reuse" 19:37:21 adam3us: that's the kind of thing you build into a new system, not something you do as a *downgrade* to an existing one (form the users perspective) 19:37:38 adam3us: we can hardly convince wallet authors to not reuse change addrs, give it up 19:37:52 adam3us: never mind you're risking user funds 19:38:02 lolwut, someone emailed me a complaint - they don't like me using proper nettiquite on bitcoin-dev 19:38:04 fractastical has quit 19:38:37 petertodd: well i guess i was just going with the flow you know... proposing things that are risky, and using first to implement arguments for my being right :P 19:39:15 petertodd: it has uses too. double-spending becomes much harder! 19:39:19 adam3us: no, you're doing almost the exact opposite to what I'm doing: "I got this idea and lets impose it because it's good, fuck users." 19:39:24 you all coming to Miami? :p 19:39:43 adam3us: I'm saying "How can I offer something to users that they'll actually accept and make things easier?" 19:39:58 Luke-Jr: nah 19:40:21 Luke-Jr: someone paying flights? kind of far for a weekend... 19:40:44 far from where :P 19:40:54 Luke-Jr: malta (europe) 19:41:01 ah, yeah that's a bit far 19:41:21 yeah spain's far too 19:41:45 jtimon (and anyone else) : I'm reaching out to the concatenative language community to see if they have any input for a joyscript. let me knkow if anyting is missing : http://0bin.net/paste/kMkgAK+zO2+mTK0E#Lua4/1g5fGVyv44fpRkftnd37RetgnrDrItXAp9FyvA= 19:43:27 bbl 19:43:40 petertodd: i get that they might accept it and find it easier (they already like reusing addresses because its conceptually simpler) but it cant replace one-use adresses, because other than for full node (0-length prefix) its strictly worse on privacy. i mean the whole thing is about privacy, so you cant say its easy to use or they accept, if it makes privacy worse (for non-static uses) 19:46:49 maaku_: nice write up 19:47:24 maaku_: i guess also that interpreter escape would be calamitous if that is not impled! 19:47:59 <_ingsoc> _ingsoc has quit 19:49:44 <_ingsoc> _ingsoc has joined #bitcoin-wizards 19:50:24 adam3us: good, i'll add that 19:58:56 maaku_ reading now 19:59:36 fractastical has joined #bitcoin-wizards 20:04:35 nsh has quit 20:05:41 nsh has joined #bitcoin-wizards 20:10:34 maaku_ looks great, nothing comes to mind to add 20:16:56 very good idea to approach those commmunities 20:17:21 jcrubino has joined #bitcoin-wizards 20:17:38 killerstorm has joined #bitcoin-wizards 20:17:43 I guess petertodd still prefers forth and gmaxwell and sipa still prefer the AST 20:19:03 but it will be interesting to see what those forums think, where are you sending that maaku_? 20:19:25 the concatenative yahoo group 20:19:29 also #concatenative 20:19:40 ughh, yahoo groups... 20:20:13 [13:59:44] adam3us: really? I think forth is basically ideal. 20:20:44 I think sipa is the only one interested in a more imparative AST 20:20:56 jps has quit 20:21:16 imperative? 20:21:39 if anything i prefer it is not imperative... 20:21:44 now they want my phone number... 20:22:14 jtimon: just sign up for the mailing list, no yahoo account required 20:22:29 jps has joined #bitcoin-wizards 20:22:56 jtimon: i'm not a fan of programming in concatenative languages... yuck, honestly. but this is the textbook case for where they excell 20:23:11 killerstorm has quit 20:24:46 sipa: very poor choice of words on my part 20:25:43 but is there any advantage to the system you advocated before over a concatenative, point-free language? 20:26:05 i tried to think of an example the last time we talked, but couldn't 20:26:39 it's a bit vague to me what that means 20:26:59 i'll look up joy 20:28:51 AST are used in a phase of compilation I think, so sipa's point is I think for maybe having different compilers to the AST (also being a tree, easily merklizable) 20:29:24 it may be possible to convert joy to an AST of the type i suggested 20:29:43 well it's loose terminology so i'm not sure what exactly is meant 20:29:47 and everybody uses the same AST, well, I'm just speculating about his reasoning 20:30:02 Forth-like language such as Joy have an AST as well 20:30:21 anyway, i like the idea of these types of script to essentially be an expression 20:30:32 yes, compile joy to an ast should be possible, maybe you can ask that too "should we use joy or the AST compiled from joy?" 20:30:50 it has a natural merkleization 20:31:09 is trivial to analyse wrt to execution time 20:31:20 sipa: http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html 20:31:26 and http://www.kevinalbrecht.com/code/joy-mirror/j01tut.html 20:31:31 probably the best introducitons 20:32:18 maybe we can even write the scripts in python and compile them to ast, I'm sure the pypy guys have something to build from 20:32:33 with a Merklized Joy, you'd consider quotations to be a branch of the AST 20:32:55 so, for example, an if statement is: pred [true-branch] [false-branch] if 20:32:57 what advantage does joy/... have? 20:33:14 you can separately merklize the true and false branches 20:33:37 kinlo has quit 20:33:50 sipa I think maaku_'s point is that dealing with the AST directly is ugly and joy is a functional lisp-like lang 20:33:56 sipa: implementation and type analysis is very simple (unless you f' up the language design) 20:34:38 i don't understand what's ugly about it 20:34:42 it's just an expression 20:34:43 oh, and then the strong typing thing, but that's cat, no? 20:34:59 it's pretty much the most natural way of writing *simply* conditions i can think of 20:36:30 but maybe we need to actually try to write some actual things in these sorts of languages first 20:38:26 kinlo has joined #bitcoin-wizards 20:38:33 i guess my usage of the word 'AST' is also a bit confusing, as that's just an compiler step 20:39:17 sipa: you won't find an argument about concatenative languages being better than lambda abstraction or vice versa, because they are equivalent 20:39:34 fractastical has quit 20:39:38 i'm *certainly* not planning to introduce lambdas 20:40:19 i'm a big fan of higher-order strongly-typed functional languages, but lambda's would make implementation significantly more difficult, and analysis even more so 20:40:22 but as an intermediate language, stack based concatenative languages are trivially simple to implement in an imperative or JIT interpreter (close to the machine), and do so safely 20:40:40 evaluating an expression tree is surely even simpler 20:40:47 sipa: a concatenative language like Joy has the power of lambda abstraction without those added complexities 20:41:11 maybe i should just write a toy implementation... 20:41:37 jcrubino has left #bitcoin-wizards 20:44:28 maaku_: heh, i guess i didn't realize this before 20:44:37 i presume joy is turing complete? 20:45:10 with some recursion primitives, i'm sure it is 20:45:59 yes 20:46:09 right, i'm not aiming for that 20:47:13 if you need that, a concatenative approach is probably easier to implement than having higher-order functions and lambdas in an expression language 20:47:24 but i'm unconvinced about the need for that 20:49:25 well need is a word that carries baggage 20:50:05 i was recently convinced of the utility of turing complete scripting, which is to say i understand the desire for it and it is worth experimenting with 20:50:21 right, sure 20:50:28 but "need" encompasses so many tradeoffs I'm not comfortable making yet :) 20:50:29 i'm just talking about a bitcoin script 2 20:50:40 not about anything more ambitious than that 20:53:40 maaku_: nice links. i just clued in that 'postfix' the language is named for 'postfix' the notation :P 20:59:11 I thought joy hadn't recursion because didn't need it 21:00:16 well, the wikipedia article on it has an example with a 'binrec' primitive 21:01:19 this sentence is very confusing to me "Combinators in Joy behave much like functionals or higher order functions in other languages, they minimise the need for recursive and non-recursive definitions." 21:02:13 killerstorm has joined #bitcoin-wizards 21:02:16 I'll keep reading the links, hopefully I'll have a clearer idea after that 21:02:45 jtimon: it doesn't have recursion in the traditional sense, but it has the equivalent of an 'eval' opcode 21:02:56 and since code is data, that's enough to build whatever you need 21:03:34 combinators (like binrec) are just a variety of built-in variants of this idea 21:04:45 I don't really have a strong opinion on joy vs ast really 21:06:11 i *really* dislike code==data 21:06:15 maybe allowing everyone to build their own python, lisp, js, C or whatever to AST compiler and letting the AST interpreter itself be the "consensus sensible" part is a better solution 21:06:17 it makes analysis horrible 21:07:31 are you discussing new awesome cryptocurrency? 21:07:36 yeah, I would definitely ask the concatenative guys what they think about using an AST directly and then compile from other language 21:08:16 killerstorm: new awesome scripting language that among other things, could be used for native colored coins 21:08:39 that requires an OP_EVAL like sturcture :S 21:09:15 which means you cannot possibly analyse without executing... 21:09:15 native colored coins can be implemented using OP_CHECKCOLORVERIFY (https://bitcointalk.org/index.php?topic=253385.0) 21:09:27 I mean the basic kind. 21:09:37 although some people don't like the idea of covenants in the hostcoin 21:09:44 killerstorm, yes, but that's 1 op = 1 use case 21:10:16 thi, being more generic, would allow many other things 21:11:04 within freimarkets for example it would allow you to always be able to buy your p2p interest-bearing debt back 21:11:19 I'm afraid that implementing anything non-trivial via scripts will result in a huge bloat 21:11:36 http://0bin.net/paste/kMkgAK+zO2+mTK0E#Lua4/1g5fGVyv44fpRkftnd37RetgnrDrItXAp9FyvA= 21:11:53 I still think tagged CCs are better 21:12:13 [13:06:14] it makes analysis horrible 21:12:20 not with a strong type system 21:12:52 killerstorm: yeah sortof, a scripting extension/replacement that will probably make it into freimarkets 21:12:52 I don't even think interest/demurrage bearing assets are possible with them 21:12:54 * andytoshi waits as "rustcoin" stops being funny and starts being considered.. 21:12:54 /with/without 21:13:05 wtf is the point of opcheckcolorverify? the color checking operation is massive/exponential/bad 21:13:46 <_ingsoc> _ingsoc has quit 21:13:50 maaku_: well, then code isn't data :) 21:14:03 maaku_: as the type system can determine in advance what is executable 21:14:04 sipa: not sure i follow 21:14:11 <_ingsoc> _ingsoc has joined #bitcoin-wizards 21:14:12 amiller: The idea is to add color tags to utxo db. then it is trivia. 21:14:58 maybe you mean something else by code==data than i do... for me it means i can construct a random string/sequence operations/whatever using code, and then execute it 21:15:03 jtimon: the "common AST" *is* a concatenative language. there's a reason the JVM and .NET intermediate languages are concatenative... 21:15:13 everything compiles down to that 21:15:26 JVM bytecode language is certainly not an AST 21:15:36 killerstorm, a lot of effort goes into keeping the utxo as small as possible, how do you quantify what change that incurs? 21:15:44 yes, it's a stack-based language 21:15:45 it's an imperative stack-based language, afaik 21:15:52 exactly 21:16:33 i need to stop using the word AST, as it's much wider than what i mean 21:16:36 amillar the point is making CCs SPV-friendly 21:17:01 killerstorm: the scripts are in the scriptSigs, so they're immediately pruned 21:17:35 jtimon, ok well fair enough, that is indeed a good way to do it, but you probably also need a way of discouraging utxo bloat 21:18:04 amiller I advocate for explicit colors 21:19:00 jtimon, yes i advocate for it too, i just don't see what the solution is for discouraging utxo bloat now that you add a functionality that increases it 21:19:53 if nobody has to store the full utxo, utxo bloating is not that much of a problem 21:20:00 amiller: this doesn't result in any utxo bloat... 21:20:26 do coins have at most 1 color or something? 21:20:34 scripts are in the txin, not out 21:20:36 amiller: color tag is just a hash of genesis transaction or something like that. ~32 bytes per UTXO won't hurt. 21:20:49 amiller: yes 21:21:36 ok that sounds pretty nice. 21:21:59 adding that single op code and that single change to UTXO is by far the simplest way of getting fairly scalable colored coins usage. 21:22:03 jtimon: there is no difference between OP_CHECKCOLORVERIFY and explicit colors. OP_CHECKCOLORVERIFY can be in scriptSig. 21:22:06 i'd be really interested to see that 21:22:09 killerstorm: in fact, in the next version of freimarkets specs, you can save the tag, by ommiting it you mean "the same color as the previous output" 21:22:09 jtimon: I mean I'm not aware of any practical difference. 21:22:12 that sounds pretty great to me 21:22:30 how about a reference impl that deviates minimally from satoshi client? 21:23:21 go1111111 has joined #bitcoin-wizards 21:24:09 amiller: what scheme are you talking about? 21:24:10 Well I've heard iXcoin guys are interested in implementing this, but they lack developers. (Essentially it is just the guy who does the marketing...) 21:24:34 I've outlined the spec although I'm not sure about some decisions. 21:25:28 saposhi nasakyoto I think (I can't believe ixcoin is alive, and there's still people who say MM kills altcoins...) 21:29:58 but yeah, why not use it to experiment 21:30:27 is already MM, it's in a great position to be used for this things 21:31:42 It got new life: new PR/marketing team :) 21:32:01 MM means that it is 100% controlled by ghash.io 21:32:18 killerstorm, how do you implement per-asset interest/demurrage with OP_CHECKCOLOR ? 21:32:34 only ghash.io merge-mines it? 21:33:32 No, ghash.io has 40% of bitcoin hashpower and is mining alt-coins. Since some Bitcoin miners do not do merged mining, this means that ghash.io hash more than 50% of hashpower of Namecoin and IXCoin 21:34:51 killerstorm: +1 wish people realized that earlier 21:37:05 go1111111 has quit 21:39:24 http://en.wikipedia.org/wiki/Savitch's_theorem 21:39:54 (for those thinking of memory hard to hash but easy to validate PoW, would this theoretical limit apply?) 21:42:30 I'm not seeing the connection 21:49:35 I don't see why memory hard is better 21:50:30 I didn't say it was. 21:50:36 people were discussing it here in past months 21:50:57 jtimon: the theory is memory hard targets memory, which is most likely to be an availalbe commodity product and thus escapes the ASIC centralization trap 21:51:13 jtimon: however, practical memory hard that really is ASIC-hard appears to be a very difficult problem 21:51:51 jtimon: reasonably easy to do in cases where the work to be done in non-parallizable, but crypto-consensus systems must be parallelizable 21:59:18 Ursium has joined #bitcoin-wizards 22:01:42 I don't see why ASICs are worse 22:05:49 IMHO, mining pool centralization is the real problem, not ASIC's. 22:07:13 warren, agreed, and I thought that was solved with trustless pools (p2pool, eligious...) 22:07:55 jtimon: ASICs centralize control in the hands of a very small number of chip fabs 22:08:25 petertodd: meh, coordinated quality control could mitigate that 22:08:27 jtimon: and p2pool and getblocktemplate don't "solve" the problem because there's no incentive to use either 22:08:30 maaku_: huh? 22:08:57 petertodd: a scanning electron microscope is not hard to get access to 22:09:04 go1111111 has joined #bitcoin-wizards 22:09:22 jtimon: they *do* help with "non-selfish" actors, but they fall short of the security ideal where bitcoin is secure in the presense of selfish actors 22:09:23 there should be efforts to take asic chips at random from batches and do SEM scans of their circuits 22:09:44 then anyone with tools can verify that they are not backdoored 22:09:55 maaku_: the problem isn't hardware that's bugged, the problem is getting hardware at all - those chip fabs can easily *publicly* control the bitcoin network 22:10:25 can't the operator of a centralized pool cheat you somehow? 22:10:41 jtimon: out of your shares, yes 22:10:54 or decide for you what transactions to, say censor? 22:11:02 jtimon: they can cheat you in lots of ways, that doesn't change the fact that per unit hashing power they'll be more profitable in many scenarios 22:11:29 jtimon: using GBT you can choose your own transactions 22:11:31 jtimon: after all, they might own the hashing power too you know in which case cheating doesn't even come into it - ghash.io owns much of their physical hashing power 22:11:51 maaku_: in theory, in practice pools don't allow that - very high bandwidth cost 22:12:04 well, eligius does 22:12:05 maybe centralized operators aren't being as malevolent as they "should" 22:12:20 maaku_: yes, and eligius is being operated by alturistic people 22:12:50 jtimon: who cares? what matters is that our security isn't as good if we have to rely on that 22:13:07 meh, i would say that eligius is operated by knowlegable people/person 22:13:08 it's my theory that if every actor started out as malevolent/selfish/rational, bitcoin would never have worked 22:13:25 it's an experiment in building a system that doesn't need trust in many actors 22:13:32 as bitcoin matures i expect more pools to act like Luke-Jr 22:13:39 but we'll need to get there step by step 22:13:59 sipa you're probably right, the start was incredible difficult 22:14:07 or maybe the causality is reversed - bitcoin will never mature unless more pools act like Eligius does 22:14:18 either way once it happens, it happens 22:14:31 I mean, I wasn't around, but...it's surely the hardest part 22:15:46 sipa: yes, we got incredibly lucky there 22:16:32 fact of the matter is that relying on alturism is dangerous and subject to sudden changes 22:16:57 never mind the fact that what were were talking about, ASIC-hardness, has nothing to do with alturism 22:17:04 yup, but removing much it suddenly is equally dangerous 22:17:17 sipa: what do you mean by "removing" it? 22:17:39 sipa: no-one is proposing removing anything 22:17:47 oh, i'm not saying that 22:18:04 but if suddenly many people/miners/whatever started acting selfishly, i'm sure it could hurt bitcoin's survival chances 22:18:22 +suddenly 22:18:29 oh sure, but the fact that it would hurt just shows that bitcoin is poorly designed 22:18:50 i'd say it just isn't evolved enough :) 22:19:15 heh, equally true statement 22:19:28 though the ugly thing is changing the design is probably an economic change so... 22:20:40 anyway, as I said about the selfish miner attack, these attacks are real, and we're damn lucky that for now the big players are acting alturisticly, take advantage of that time to study alternatives so we'll have them ready when they're needed 22:20:55 come'on miners have to attack MM chains because "the good of their coin is their good", but they cannot trustless mine because "it is not selfish enough"? 22:21:17 jtimon: what do you mean by trustless mine? 22:21:31 p2pool, eligious 22:21:33 p2pool/gbt? 22:21:39 yes 22:21:51 jtimon: remember, my point re MM attack was that if you have a big pool, then your MM chain is in a dangerous position 22:22:12 jtimon: my point with trustless mining is that it *costs more* than just pointing your hashing power at ghash.io 22:22:48 my point now is to apply your same "for the future of the coin" reasoning for miners to use p2pool/gbt 22:22:57 after all, this all came up with mastercoin when I got hired to analyze what type of blockchian they should use, and the result was "Why use anything less secure?" 22:23:33 jtimon: that's a very bad comparison - you're comparing the behavior of a large pool to a small hasher 22:24:44 a large pool is composed of small hashers 22:25:05 if anything, they should be more stupid in groups, no? 22:25:28 not at all, think in terms of incentives to defect and do what's better for you, but worse for the group 22:25:44 IE, I earn more money for less work if I hash at ghash.io 22:26:06 vs. "I'm a 30% pool and killing off FooCoin is cheap and easy and the public doesn't like it anyway so the PR will be good for me." 22:26:15 (especially relevant in my advice to mastercoin you know...) 22:26:23 IE, I earn more money for less work if I MM instead of attacking a "competing" coin 22:26:45 oh piss off, scale makes the incentives very different 22:26:57 merge mining a tiny currency doesn't gain you anything significant 22:27:04 your advice to mastercoin was to use your proof of sacrifice design draft? 22:27:40 jtimon: you're failing to control for internet assholes 22:27:40 sipa how much you lose by gbt vs ghash.io ? 22:27:53 "Some men just like to watch the world burn." 22:28:08 again, the first time this came up I had a paying contract to tell mastercoin if they should, or shouldn't, stick with putting data in the blockchain. I said the existing design was very secure if you used steganography for anit-censorship, PoW chains were possible to 51% attack, and merge-mine would make 51% trivial by a big pool 22:28:31 jrmithdobbs I don't follow 22:28:46 given that censorship of MSC txs in the blockchain is *way* harder than people realize, obviously I told them some techniques to improve on that and stick with what they had 22:28:59 (this is why MSC adopted an encoding scheme where the data looks like valid pubkeys) 22:29:06 jtimon: just because it is in their economic interest to mergemine instead of attack alt coins doesn't mean that is the decision that will always be made. 22:29:07 bah 22:29:29 sipa: heh, I think lots of people didn't realize that was so easy... 22:29:39 petertodd: this is a nice example of what i'd call suddenly changing how selfish a particular party acts 22:29:56 sipa: indeed, and BTC better realize how easy what MSC did is 22:29:57 jrmithdobbs just because it is in their economic interest to mine at ghash.io instead of using p2pool/gbt doesn't mean that is the decision that will always be made. 22:30:07 that's my point, how is difffernt? 22:30:10 sipa: basing scalability assumptions, esp re: the UTXO set, on "oh, people will play nice" is idiotic 22:30:15 hmm, I wonder if deploying P2SH^2 might not be as hard as we think 22:30:25 Luke-Jr: MSC is P2SH^2 proof 22:30:34 petertodd: I mean real bitcoin 22:30:34 petertodd: i think sd proved that already. 22:30:43 Luke-Jr: "real bitcoin"? 22:31:12 Luke-Jr: I mean, adopting P2SH^2 *doesn't* stop the MSC encoding scheme (well, with the trivial modification to wrap the CHECKMULTISIGs in P2SH txs) 22:31:16 petertodd: I'm not sure what MSC came up for, I'm talking about Bitcoin itself 22:31:18 jrmithdobbs: no, they stopped 22:31:26 petertodd: why do I care about that? 22:31:31 petertodd: I see your point, MM is less secure than MSC, true, but it's also more scalable 22:31:38 petertodd: like a year later 22:31:39 Luke-Jr: oh, I'm assuming you meant P2SH^2 to stop MSC 22:31:41 Luke-Jr: MSC is putting data in bitcoin's chain... 22:31:52 petertodd: no, P2SH is to stop data spam 22:31:54 ^2* 22:31:57 sipa: ⁈ 22:32:13 Luke-Jr: well, that's my point, you can't stop data spam *except* to stop it from getting in the UTXO set, and even that's weak 22:32:29 petertodd: you can 22:32:33 Luke-Jr: you can't stop schemes that encode hashes in the UTXO set, and there's lots of usees for that 22:32:40 scriptSig can require preimages or valid ECDSA sigs too 22:32:56 petertodd: not really, no 22:32:57 Luke-Jr: read this: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03524.html 22:33:10 Luke-Jr: without some pretty drastic changes to the way scripts work you can't 22:33:11 Luke-Jr: then the preimage would be in the blockchain 22:33:36 sipa: not necessarily 22:33:37 Luke-Jr: also, stopping data spam 100% stops you from soft-forking in a lot of potential new features, for instance new signature algorithms 22:33:51 Luke-Jr: that would prevent you from validating it afterwards 22:34:03 I'm assuming the P2SH^2 enforcement is done by miners only 22:34:07 Luke-Jr: and timestamp/proof-of-publication spam is really handy to a lot of protocols, and bloats the UTXO set even 22:34:18 and tx relay 22:34:22 Luke-Jr: then it only requires an out-of-chain deal with a miner to put it in anyway 22:34:31 petertodd: there is no need to bloat the UTXO set 22:34:33 Luke-Jr: e.g. P2SH^2, even gmaxwell's v2.0 version, doesn't stop you from doing namecoin int he UTXO set 22:35:01 Luke-Jr: for many protocols abusing the UTXO set is cheaper and more secure and there's fuck all we can do about it other than ask nicely to stop 22:35:17 what's P2SH^2 please? 22:35:22 link? 22:35:29 petertodd: *technically* yes 22:35:47 jtimon: miners only mining stuff that is proven to be a hash 22:35:54 jtimon: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01987.html 22:35:57 jtimon: have P2SH-only in the txouts, but to relay a transaction, you must add SHA256(script) to it 22:36:10 Luke-Jr: yes, and getting a hash into the UTXO set is enough to implement namecoin 22:36:17 jtimon: so you prove that the data in the P2SH output is a real hash of something, and not data 22:36:54 petertodd: it makes it more expensive 22:37:16 Luke-Jr: namecoin is already expensive, irrelevant 22:37:36 the point is to make blockchain bloat more expensive than merged mining 22:37:41 Luke-Jr: as I told Mastercoin, their transactions are worth a lot more than the least valuable Bitcoin transactions, so they'll be able to outbid those and still get their data in the chain 22:37:53 Luke-Jr: that's irrelevant, merge-mining is less secure 22:38:25 only if you're scamcoining. 22:38:41 i'm not sure what intent has to do with it 22:38:49 Luke-Jr: sure, which is why I told Mastercoin to stick with the current system! 22:39:21 Luke-Jr: After all, what is or isn't a scamcoin is a matter of public opinion, so you're safer assuming people think you are and acting appropriately. 22:39:38 sipa: if you're just interested in the security, you can do merged mining in a secure way 22:40:36 if every Bitcoin block is a valid Altcoin block, and Altcoin uses the same difficulty and requires merged mining, then the worst someone can do is equivalent to not participating 22:41:19 Luke-Jr: that's not at all true and stop saying that 22:41:38 petertodd: totally different subject; if we'd have a system with TXO MMR's... that would require every wallet to remain up-to-date with all blocks, to find operations that affect the path of its unspent outputs to the roots of the range? 22:41:47 Luke-Jr: you've just come up with a system where the block interval is really long if there isn't that much hashing power, that is still vulnerable to 51% attack 22:41:53 I have a question about Bitcoin security: do we need to assume that majority of miners (hashpower-weighted) are not colluding (i.e. making a secrete arrangements) with each other for Bitcoin to be secure? Or do we assume that they are rational and rational miners won't collude? 22:41:54 petertodd: it's disengenous to say that merged mining is insercure too 22:42:05 petertodd: only if the attacker 51%s bitcoin as well 22:42:09 sipa: nothing explicitly of course 22:42:34 bitcoin-parasitic vs merged mined alt? of course the parasitic option is better 22:42:52 Luke-Jr: no, think about it: altcoin is 1% of hashing power, so the block interval is 10min * 100, I can still 51% attack that by mining more blocks than the other miners regardless of the interval 22:42:54 merged mined alt vs non-merged mined alt? that's a different story 22:43:14 petertodd: no, you may have 51% of blocks, but you cannot reorg it 22:43:22 killerstorm: depends on the context. colluding to do what? 22:43:28 petertodd: you'd need to have 51% of *bitcoin* blocks and reorg bitcoin, to reorg the altcoin 22:43:37 shesek has quit 22:43:38 short-term-selfish miners will always collude if they can 22:43:53 Luke-Jr: ah, but if I can't re-org it, and it's a timestamp system, then what happens if I mine a longer chain in secret and reveal it? 22:43:54 but in many cases yes, 51% is sufficient to censor the chain, for example 22:44:08 petertodd: you'd need a longer *bitcoin* chain 22:44:08 Luke-Jr: mining a block doesn't magically make it available to the world 22:44:12 as it means their 51% becomes 100% 22:44:49 Luke-Jr: no, bitcoin block #10 mines altcoin block 1, bitcoin block #11 mines alt block 2a, bitcoin block #12 mines alt block 2b 22:44:59 Luke-Jr: was 2a or 2b the valid best block? 22:45:05 petertodd: altcoin does not have a prevblock header. 22:45:15 it is ALWAYS tied to the bitcoin chain 22:45:34 Luke-Jr: yes it does, the prevblock header just happens to skip a few steps 22:45:52 your scenario is not possible 22:46:11 if bitcoin block 11 mines alt block 2, then bitcoin block 12 must mine alt block 3 22:46:13 Luke-Jr: after all, if the miner of bitcoin block #11 doesn't tell anyone he mined 2a, then how does 2b know that? 22:46:29 Luke-Jr: remember, this is a merge-mine chain: participation is voluntary 22:47:10 i wasn't aware of the fact that merged-mined chains had no own prevhash 22:47:22 but it seems to make sense 22:47:23 sipa: the existing ones do, but that's not the system I was talking about 22:47:29 petertodd: ok, I remember this now. 22:47:33 sipa: luke's very mistaken... 22:47:39 petertodd: I forget if I found a solution to that issue or not 22:47:42 sipa: they do, i think Luke-Jr is describing something novel/different 22:47:47 ok 22:48:30 i'm not sure what the problem is with it that petertodd is describing 22:48:39 Luke-Jr: you realize I've proposed basically the same thing with my zookeyv proposal, and I even took advantage of that by ensuring that proof-of-sacrifice "blocks" in the scheme were always visible in the bitcoin blockchian, so you could know if a 51% attacker was waiting to reveal their attack to the world and outspend them 22:48:51 Luke-Jr: tl;dr: I'm way ahead of you :P 22:50:03 sipa: the problem is that if you tie things as tightly to the bitcoin chain as luke is suggesting, the moment someone mines an alt-coin block but *doesn't* publish it you're screwed because all alt-coin clients can see the block header commitment, but dont have the data to go along with it 22:50:25 sipa: OTOH if you're system doesn't have that vulnerability, it's still longest chain wins and your 51% attack vulnerable 22:50:30 .. unless we softfork bitcoin 22:50:39 Luke-Jr: sure, but then it's not a merge-mined chian anymore 22:50:45 petertodd: sure it is 22:50:58 Luke-Jr: No, you've just made the blocks bigger with a fancy hash commitment. 22:51:09 bitcoin miners can enforce disclosure of the merged data to some degree 22:51:12 Luke-Jr: the whole point of merge-mining is that it's *voluntary* 22:51:28 petertodd: hence the degree limit 22:51:33 Luke-Jr: yes, and if disclosure is enforced you've just made the blocks bigger and contain extra data 22:51:58 yup, i see the problem 22:52:01 only bigger for miners 22:52:17 Luke-Jr: so what? that's the problem we keep trying to solve 22:52:26 OK, let's formulate in a different way: is there a game-theoretic research of Bitcoin? Particularly, double-spend-via-a-bribe attack: somebody wants to double-spend a large amount of money and will pay miners a bribe to help him to do that. 22:52:45 shesek has joined #bitcoin-wizards 22:53:12 killerstorm: yup, will work for large amounts; you just need to have enough confirmations that reverting it costs more than what one might pay a miner to revert it :) 22:53:43 killerstorm: yeah, and the results are ugly, don't accept 1 conf payments for $1million and do irreversable things based on them 22:54:09 killerstorm: notably it's why tx fees being the only thing paying miners leads to really ugly consequences 22:54:16 killerstorm exactly, the bigger the transaction the more you have to wait, it's not 6 blocks 22:54:49 the 6 blocks number is based on statistics that assumed a much less centralizing mining landscape in any case 22:54:55 FWIW peter from the bitfoin foundation asked me last summer if I or someone else would be willing to do some research to make up a whitepaper and similar tools to advice merchants on exactly that issue. 22:55:12 dunno if that project ever went anywhere, but it's an important one 22:55:37 I'm afraid it's much worse than you think... 22:55:37 justanotheruser has quit 22:55:37 justanotheruser has joined #bitcoin-wizards 22:56:09 personally, I don't think merchants want to have to read a paper.. 22:56:12 killerstorm: lots of people forget an attacker might be ripping off multiple people at once for instance 22:56:34 Luke-Jr: indeed, which is why peter's vanesses idea was to eventually create some calculators for said merchants to do the thinking for them 22:56:58 Luke-Jr: Like, input in the value of the tx and spit out how long they needed to wait. (subject to certain assumptions about the attacker) 22:58:16 petertodd: re MM, the problem we need to solve is not forcing people to store data against their will, but also enable innovation beyond Bitcoin taking advantage of the same securing hashpower 22:58:35 Luke-Jr: yeah, well, MM isn't necessarily that innovation 22:58:47 Luke-Jr: that seems like an interesting idea. (merge mine where the bitcoin blocks are valid alt-chain blocks) 22:58:51 present-day MM style does that just fine, really. the 51% risks aren't really a real concern. 22:59:02 Luke-Jr: you realize that one of the reasons mastercoin hired me was because they realized they needed someone to study that 22:59:03 petertodd: MM is what is needed to *enable* that innovation 22:59:15 Luke-Jr: again, MM fails in a hell of a lot of scenarios 22:59:37 Luke-Jr: I agree 22:59:49 petertodd: so lets see if we can improve it 23:00:06 adam3us: heh, what do you think I'm working on? 23:00:31 petertodd: judging from the above stego encoding msc into btc? :P 23:00:32 Well, here's what I'm thinking about: Suppose we have 100 independent miners each having an equally powerful mining rig (thus one of them solves the next block with equal opportunity). Block reward is 25 BTC, normal tx fees are negligible. Somebody sends a transaction with Y BTC in it. Gets 6 confirmations. Then publishes a transaction which pays X BTC to fees. What happens next, super-rational miners realize that all super-rational miners will tr 23:00:35 y to do a reorganization. Only 6 miners are NOT interested in reorganization, thus we'll have 94 miners working on a fork. 23:00:43 Note that X is not used in equation: it can be very low. Like 1 BTC. 23:00:44 adam3us: in the mean time, my advice *without* those theoretical - and maybe impossible - improvements is that stego encoding has a hell of a lot of advantages 23:00:58 petertodd: fair enuf. 23:01:13 You can get 25 BTC of a normal reward, or 25.1 BTC of reward + bribe, what do you do? 23:01:20 adam3us: and remember, knowing that stego encoding is useful, and damn near impossible to stop, is very valuable knowledge for bitcoin too 23:01:28 petertodd: yes i think however that its a bit of a dead end. it much more attractive to have secure pegged side-chains or unpegged alt-chains for innovation 23:01:32 All super-rational miners will decide to take bribe. So one only needs, say, 0.6 BTC to buy them all. 23:02:30 adam3us: I don't think you can call pegging "secure" until you get rid of the SPV trust 23:02:31 Which basically means that if miners are super-rational and there are many of them, we should just pack and go, it doesn't work. 23:02:35 What am I missing 23:02:48 and incidentally, i have an ignore bit to the topic until that is done :P 23:03:11 adam3us: it's a "dead end" only because I've shown that you don't need to go any further with the theory; I solved the problem modulo invasive censorship like whitelists, or P2SH^2 v2.0 - and that isn't very likely to get implemented 23:03:38 killerstorm: 0.6BTC isn't enough because the work done to get all that reward is done and there's a valuble return 23:03:45 petertodd: yeah i already figured out the stego and kept it to myself :) 23:04:00 adam3us: heh, did you figure out the timelock crypto version of it? 23:04:36 killerstorm: for the miners if they don't reorg and keep trucking they get to keep the block rewards that are already there 23:04:48 petertodd parasitism is more secure and unstoppable, fine, who cares? it doesn't scale MSC can't do the things willet wants atscale with parasitism, at some point you will have to tell him that 23:05:01 Well, first miners to win a block will pay 0.5 BTC to OP_TRUE, script, second will pay 0.4 BTC and so on. Each one will collect only 0.1 extra BTC, but it is nice and shiny. 23:05:07 jtimon: which is why my job there is more aimed at making *bitcoin* scale 23:05:36 All super-rational miners think in the same way, so they will find a strategy which rewards everybody who are working on the fork. 23:05:43 jtimon: (we're all lucky they have enough cash around and pr to consider to do things that may not be stricly economically rational) 23:05:48 petertodd: no, but better. just publish the key. i think you do not need consensus on the key because consensus is reached on the ciphertext and its non-malleable. same argument s committed-tx 23:06:19 adam3us: publishing the key doesn't guarantee consensus though - the idea being the timelock crypto is to be able to guarantee that 23:06:42 adam3us: e.g. if the key doesn't get published, and is uncrackable, you'll never know for sure if one isn't waiting to be published 23:07:02 ok, then I guess I would just ask you to encourge parasitism over altcoinism more openly, not just over MM 23:07:10 petertodd: I think you're missing that 6 miners will get rewards through chain which appeared earlier, and 94 miners will get reward through a fork. Basically, 94% of hashpower will work on forking chain in these conditions. 23:07:21 killerstorm: ok, I see your point, but the problem is there's no way for those super-rational selfish miners to know they're all working on the same fork, and if they aren't, then defection makes sense 23:07:41 as always, my claim is that MM is better than independent mining 23:07:48 petertodd: no i mean dead end like focusing all energy ontop of bitcoin may saturate bitcoin tx throughput and hit its scaling limits, and damage crypto currencies generally. i think there is better scope for innovation if we can focus on uncoupling innovation (btc denominated with pegged side-chain and other with mm alt-chain) 23:08:21 adam3us: that's a nice concern, but for the individual alt-coin thing they're incentive is still to defect and do what's best for them individually 23:09:03 adam3us: simple example: I want to timestamp a document. Why do I care about the "bitcoin environment" when I just want to easily timestamp something and my desire not to lose the timestamp is worth more than the tx fee to bloat the UTXO set? 23:09:25 petertodd: yes but even selfishly there is interest to succeed. mking bitcoin fail and going down with it is not useful to either the meta-coin nor bitcoin 23:09:39 and I don't think "MM is better than independent mining" is the message that people perceive from bitcoin devs 23:10:05 adam3us: meh, if you were right then peopel would never pollute, but they do 23:10:11 petertodd: it might be interesting to think about an alt with a fixed 1-coin reward, and which capped miner fees at, say, 0.05 coins (and the rest would be destroyed) 23:10:31 adam3us: remember, we've got anonymous systems here where social pressure doesn't work very well 23:10:32 people somehow perceive that "all experts prefer scrypt and quark, it's just that bitcoin is not going to hardfork on that now" 23:10:38 capped total fees per block* 23:11:49 jtimon: depends on what bitcoin devs your talking about - gavin regularly writes about how alts are stupid and harmful 23:11:51 andytoshi what for? 23:12:32 petertodd: I know there's not one voice 23:12:49 maaku_: SPV proofs and pegged sidechain. yes. the issue is that you dont really want to rely on as part of the protocol expecting bitcoin validators to follow the side-chain traffic or vice versa 23:12:53 jtimon: to change the miner incentives to accept crap in exchange for high fees 23:13:16 petertodd: yes but it hasnt failed yet. 23:13:35 bbl 23:14:00 jtimon: this would also reduce the potential for fee extortion, since with fees capped at 5% of income there'd be lots of people who simply don't care 23:14:14 (this is a far future problem for bitcoin ofc since fees are not even 0.05%) 23:14:51 0.05% of total reward to miner? 23:14:53 killerstorm: your super-rational miner strategy seems plausible 23:15:19 jtimon: yeah. (am i wrong?) 23:15:49 andytoshi I don't know I'm not sure I understand 23:16:13 if you hash more than 0.05 in fees in a block you only get 0.05 in fees 23:16:35 but 0.5 will be less and less as inflation increases 23:16:35 jtimon: that's right, and any other fees that transactions had included would simply get burnt 23:16:48 petertodd: you realize he just made the $25k per block fraud shrink a lot? 23:16:51 jtimon: right, as will 1.0 (the block reward) 23:16:57 I think the reward will be eventually too small 23:17:22 1.05 will eventually be 0.0000000000000001% of the total supply 23:17:38 jtimon: no, currency loss will stop it getting that far i'm sure 23:17:51 but i haven't done any detailed analysis to think about how far it will get 23:18:10 maybe it will go too low and kill security, i don't know 23:18:34 oh, I guess you're right, is there any analysis on currency lost? how you do that? 23:19:19 jtimon: it's hard to say, numbers exist for physical currency destruction, but that's obviously possible to measure, while cryptocurrency numbers are not 23:19:19 nsh has quit 23:19:36 maaku_: however there are some factors. a) bitcoin is still security firewalled (it wont accept coins that didnt come from its chain), b) individual users/miners may choose to full validate; c) atomic swap is the much more frequently used method and that can be full validated; d) spv proven transfer back is liquidity event for imbalanced in demand, and a little bloated. 23:19:42 so perhaps you can import the physical numbers as "percent carelessness" and get a swag 23:20:24 maaku_: e) 100 block confirmation on spv liquidity transfer on merge mine is still quite secure 23:21:13 adam3us how is any pegging scheme more secure than non-pegged MM ? 23:21:26 jtimon: in the absense of demurrage, i don't think it's possible since people can store physical keying material, and that's identical to the network to a lost coin 23:21:31 jtimon: its not 23:21:35 no matter how much magic crypto (eg OWAS) you throw at it 23:22:15 but otoh with demurrage, measuring the velocity (which is easy) would give you an estimate of supply 23:22:19 adam3us and how pegging encourages or facilitates innovation? 23:23:13 warren: u know re mem hard complexity limits, dan larimer/bitshare/invictus momentum hash (birthday) does actually kind of work and is very fast to verify (modulo a non-catastrophic TMTO) would be interesting to see if the TMTO could be fixed. see also google for cuckoo hash proof of work 23:23:55 jtimon: it allows people who are attached to doing things with btc scarcity rather than new scarcity to do so on a different chain and make changes and features that suit their use case. 23:24:13 nsh has joined #bitcoin-wizards 23:24:47 jtimon: (rather than for example arguing that bitcoin main should incorporate their changes which imposes dev cost and security risk for btc main and so would tend to be rejected or progress slowly and conservatively) 23:25:11 I don't quite understand this part "people who are attached to doing things with btc scarcity rather than new scarcity" 23:25:31 the second sentence seems to apply for both pegged and non-pegged MM 23:26:46 jtimon: well if they dont care about using btc currency they can do a MM alt-chain with its own distribution params or auxilliary distribution PoW already 23:27:43 adam3us: how bad is the TMTO? 23:27:48 jtimon: i quite like btc scarcity, virtual gold property, capped supply, the supply curve, human policy inflation proof etc. 23:28:11 what if they do care, and want to experiment but just don't want pegged-MM's inferior security? say they're zerocoin 23:28:39 btc is still scarce no matter how many altcoins you create 23:28:50 21 M at most 23:28:52 warren: bad enough that some guy claimed $5000 "break the PoW" bounty for demonstrating it would run on a GPU when they thought it would take 750MB per instance. 23:29:23 adam3us: 100 block wait is not secure. all you need is one global consensus bug and people can start printing money before it is resolved 23:29:38 it's a non-starter as far as I'm concerned 23:29:41 adam3us: how did I make what shrink? 23:29:52 petertodd: what? 23:30:50 maaku_: they cant print money from btc main perspective, because the SPV proofs have to track back to specific previously moved coins, and that will be allowed only once per moved coin. 23:31:06 nsh has quit 23:31:13 adam3us: momentum (birthday) hashes may work from a theoretical point of view, but like I've said before, from a practical asic hard point of view they don't because they can be implemented with highly specialized content addressable memory techniques 23:31:18 nsh has joined #bitcoin-wizards 23:31:39 adam3us: < adam3us> petertodd: you realize he just made the $25k per block fraud shrink a lot? 23:32:09 petertodd: yeah. i agree with you. came to same conclusion - i guess we talked about that a while back. (asic vs memhard). just curious about the design of them to be memory low verify 23:32:28 adam3us: as for cuckhoo hashes as far as I can tell where they fail is they are parallizable, and an optimal implementation would be some crazy distributed routing layer ontop of some ram 23:32:28 nsh has quit 23:33:15 adam3us: ah 23:33:25 petertodd: ah yes. killerstorm was talking about a super-pragmatic or such miner greed where they could be bribed by paying $25k+10c if game theoretically they knew most of the other miners might do the same thing 23:33:28 adam3us: yeah, the low memory verify aspect is pretty neat, same with cuckhoo hashes 23:33:51 cuckoo... 23:34:05 adam3us: right, and I'm saying that game theoretic makes too many assumptions about what information each miner knows each miner knows 23:34:18 sipa: rarely do you correct my engrish :P 23:34:41 adam3us: ok /print/steal/ 23:35:09 i really don't think pegging adds much at all 23:35:25 adam3us: see, what *is* interesting about cuckoo hashes is that the memory *latency* hard part of them looks pretty solid, so in situations where you need a pow and it's not parallelizable, they work great 23:35:36 most of the interesting alt applications ahve to do with issuing new assets 23:35:48 jtimon: "what if they do care, and want to experiment but just don't want pegged-MM's inferior security? say they're zerocoin"well its a good example, but it kind of illustrates my point. green et al seemed to think bitcoin would adopt their protocol. when it turned out people didnt like the bloat, they were disppointed. with pegged side chain they could've gone and done it themselves 23:35:48 adam3us: timelock crypto could be one such example 23:36:28 maaku_: those new assets are more useful though if you can make contracts exchanging them for bitcoins 23:36:53 maaku_ apparently it solves a philoshophical problem related to non-scarce scarcity... 23:37:07 mmm marginally more useful 23:37:15 adam3us what's wrong with zerocoin not being pegged to btc ? 23:37:17 not everyone is convinced bitcoin has the right economics to play that role 23:37:22 jtimon: again with the zerocoin example now with zerocash, they took tht lesson and they're talking about making a zerocash alt coin. so thts a net loss, probably some bitcoin users would like to be able to get zerocash anonymity for their bitcoin, but with a floating rate and an alt the zerocash might not be much fun to use, nor very secure. merge mine would be good step either way 23:38:21 + 1 for MM zerocash, I don' 23:38:33 t see how non-peggin is a net loss 23:39:37 I hope they MM, maybe they prefer to be "anti-specialized-hardware" 23:39:39 jtimon: not centrally motivating ("philoshophical problem related to non-scarce scarcity.") i agree issued assets are the most useful thing to make smart-contracts interesting. 23:40:44 again, I don't see the loss of zercoin and bitcoin floating: they're different currencies with different properties, why should they have the same price? 23:40:48 jtimon: but i think bitcoin is also the most interesting digital scarcity, basically because it got there first, and has the most merchant integration, intrinsic (transactional) value etc, but thats history - its here now, the investors took real risks early to bootstap it and the supply curve is tapering, and its the most secure. 23:41:36 so this is all about bitcoin winning the race? that sounds greedy... 23:41:41 jtimon: so given an interest in smart-contracts, issued assets, and bitcoins it seems natural to me that you'd want to be able to do in-chain contracts between those 3 types of things 23:41:56 what if zerocoin wins, what would the world lose ? 23:42:02 a nice logo? 23:42:04 jtimon: hey i missed the first 4yrs 3mo of the race, i'mnot the winner here 23:42:15 adam3us: re: digital scarcity, so what would you think of a alt-coin using my demurrange + balanced mining ideas for zero inflation, where to get said coins you had to prove a bitcoin sacrifice? that maintains scarcity I would argue, even if where the coins go has different economic structure 23:43:35 adam3us: we are still way, way early in the adoption curve 23:43:57 most institutional support for bitcoin is using it as a payment network, not for wealth storage 23:43:58 jtimon: well if that were the only risk, i'd say go for it, lets see who wins in the market. but i think the outcome could be worse. see what if litecoin overtkes bitcoin or gets clsoe... the bitcoin price plummets? give it a few month and litecoin notice feathercoin is gaining fast, do that a couple of times and the even concept of digital scarcity could be irrepairably damaged, it might go in the history bookss like a digital tulip. 23:44:22 petertodd: Well, I don't know much about game theory, but here's how it might work in practice: suppose somebody makes a patched version of bitcoind which implements this kind of a strategy, let's call him a-bitcoind. Miner Bob can see that if everybody upgrades to a-bitcoind, but he doesn't, then his payouts will be lower. If we assume that miners think identically, they will either all upgrade to a-bitcoind, or keep using bitcoind. 23:44:45 adam3us: if that happened, who would be hurt? people sitting on bitcoins, but not the institutional players 23:44:57 they make their money (counted in fiat) on activity not market caps 23:45:01 maaku_: humanity because digital scarcity is a useful thing 23:45:05 killerstorm: right, but we *can't* assume miners think identically, and neither can those miners 23:45:11 adam3us this is not logic: if litecoin gets greater than bitcoin, feathercoin will get greater then litecoin 23:45:20 Proposal for distributed storage without polluting the blockchain in a few sentences: There is a web of trust to choose mediators trusted mutually between the uploader and the host. The uploader send the file to the hosters and the mediators after making a tx that gives a small amount to the hoster given that either the uploader signs it, or M of N mediators sign it. The mediators take hash(random nonce0,file), hash(random 23:45:21 petertodd: and, again, in practice, a-bitcoind might leave a certain mark in coinbase transaction which identifies it. but I'm not sure if we can use it in game-theoretic model as that mark can lie. 23:45:24 meh i don't think that makes sense as an economic argument 23:45:28 and the two propositions are very unlikely independently 23:45:33 jtimon: point is it sets a precedent 23:45:50 killerstorm: you can make mechanisms for those miners to *co-ordinate* their actions, e.g. soft-fork majority upgrade mechanism, but when you're talking about delibrate re-orgs that's much tricker 23:46:00 I think that's likely to happen, but with something better than bitcoin, not litecoin 23:46:12 bitcoin 2.0 if you like 23:46:22 and I don't have any problem with that 23:46:26 justanotheruser: bootstrapping your mediator trust is a damn nightmight 23:46:29 *nightmare 23:46:34 adam3us: your argument hinges on the thing overtaking bitcoin being "just another" coin 23:46:42 i see no rational basis for that ever happening 23:46:46 petertodd: exodus eh? did u see there was one proposed recently a new alt, like mastercoin except by proof of burn? 23:47:06 but if something came out genuinely better, the story would be different 23:47:16 adam3us: yup, last I checked they got like 500 coins 23:48:16 jtimon: markets doing work based on propositional logic, but by herd behavior and economic decisions and a large port of psychology and emotive reaction of individuals 23:48:19 petertodd: Any solutions for bootstrapping mediator trust? 23:48:35 justanotheruser: solve that and you're halfway to making a crypto-currency... 23:48:40 petertodd: holy moly 500 btc ! 23:48:49 adam3us: probably even more now :/ 23:48:56 adam3us: not much source-code to it either... 23:49:31 petertodd: couldn't you bootstrap your mediator trust by making non-mediator transactions successfully? 23:50:07 adam3us so since markets are irrational, it is more rational to peg them? 23:50:08 maaku_: yes litecoin & ftc are currently not plausible to overtake, but warren does try to do innovation, and maybe eg if btc-china had started pushing ltc while it was 60% of market volume (charlie & bobby lee being brothers) or some new feature is added to litecoin (say zerocash).. who knows 23:50:22 justanotheruser: define "successfully", and for that matter, how are you going to prove they were successful in a mathematical way? 23:50:56 petertodd: counterparty that was what it was called (the msc-like meta coin with PoB) 23:51:14 petertodd: I don't understand what you mean. It is a web of trust like bitcoin-otc. Success is defined by trusted people trusting you. 23:51:16 adam3us: again, if warren turns litecoin into a genuine improvement over bitcoin, then there is no reason the world need collapse if it overtakes bitcoin 23:51:27 justanotheruser: where's the root of trust? 23:51:32 adam3us: yeah, counterparty 23:51:57 petertodd: you are the root of trust for yourself 23:52:23 jtimon: the peg is just a firewall mechanism between two versions of what would be by intent the same coin. it could be applied to any alt-coin. 23:53:22 adam3us: https://blockchain.info/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- 1,165 BTC now 23:53:29 maaku_: i think that would be challenge. i am not sure how people would react. maybe they just take it as competition and say great the new better bitcoin 23:53:38 adam3us: that's actually more than msc got in dollar value 23:53:40 adam3us: it is a cool concept. it has applications if it could be made safe enough to deploy, which it is not yet. but i don't thik it does everything you think it does 23:53:41 petertodd: amazing. 23:53:46 petertodd: i know! 23:54:13 wait, did people just irrecovably destroy $1MM of coins? 23:54:17 adam3us: gonan be a lot of disappointed people I suspect... 23:54:21 maaku_: yup 23:54:22 maaku_: yes 23:54:23 w. t. f. 23:54:35 I wish people would use OP_RETURN 23:54:52 maaku_: based on a few hundred lines of code and a shoddy specification... 23:54:55 seems like it is from "XPC Proof of Burn" 23:55:08 maaku_: well from their perspective its still a comparable investment as msc they are investing in the future potential of the idea 23:55:26 maaku_: the only difference being xcp has now no btc to fund development 23:55:28 justanotheruser: heh, original counterparty burn tx's used OP_RETURN to embed a *message* and the coins were still burnt to a address 23:55:30 and yet we've been able to find just 3 people to donate <$1000 to freimarkets :\ 23:56:05 i don't even want to think about how much the coins i sold at various points would be worth right now 23:56:07 maaku_: its a sad fact that scammy/grandiose advertising works seemingly in crypto currency space. 23:56:07 andytoshi has quit 23:56:12 petertodd: how were they burnt to an address? No public key can spend them can they? 23:56:59 justanotheruser: it's a vanity address with like 12 X's in it... rather unlikely they have the sec key 23:57:02 petertodd: i thought at one point they burnt them to miner until someone pointed out a miner could mint unlimited coins 23:57:10 adam3us: ha, I know eh 23:57:35 adam3us: someone mentioned my announce/commit scheme at one point, but as I said to them, using an address has a lot of advantages re: advertising 23:57:40 petertodd: OP_RETURN? 23:58:14 justanotheruser: https://blockchain.info/tx/685623401c3f5e9d2eaaf0657a50454e56a270ee7630d409e98d3bc257560098 23:58:44 petertodd: oh, multiple outputs 23:58:57 justanotheruser: yup 23:59:21 what is the usual reason for their proof of burn? 23:59:35 justanotheruser: what do you mean?