00:00:02adam3us: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:18adam3us:sipa: it would also solve address reuse. new address on each signed payment permission
00:03:42EasyAt:Or, maybe a way to publish a ruleset in the blockchain for acceptable payments to an address
00:04:26EasyAt:Though, by doing so I am giving up my pubkey... I think
00:04:37EasyAt:Well, I can't think of a way not to give it up
00:05:12sipa:adam3us: well, it's exactly what the payment protocol intends to bring back
00:09:27adam3us:sipa: yes.
00:21:42jcrubino:was a rename decided for stealth addresses? I would like to propose "quiet addresses" or "silent address"
00:23:21adam3us:jcrubino: i think we have a winner from jeremy spilman "reusuable address"
00:23:55jcrubino:sounds good
00:23:57gmaxwell:I like reusable address.
00:24:13maaku:very nice
00:25:04adam3us: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:24adam3us:gmaxwell: seems to me there is a big open question about SPV compatibility.
00:25:27jcrubino:so if I send a payemtn from a reusable address to another resuable address does zerocoin still have a use or case?
00:25:28gmaxwell:ugh yea, I really have mixed feelings on the whole feature.
00:25:38sipa:they are not a solution fo everything
00:25:42gmaxwell:adam3us: it's neither SPV compatible or incompatible.
00:26:02sipa:jcrubino: bitcoin doesn't provide anonimity
00:26:13sipa:even with reusable addresses
00:26:17adam3us:gmaxwell: well an spv client doesnt know what to put in its bloom filter absent another channel then shall we say
00:26:35maaku:adam3us: you'd use prefix filters for SPV
00:26:40gmaxwell:adam3us: well it can be specced with the bloombait idea.
00:27:11adam3us:maaku: yeah same thing i guess (my terminology was bloom bait, petertodd prefix) but that has privacy problems
00:27:13gmaxwell:then you can pick your anonymity set tradeoff. But its an extra thing that has to be 'decided' which is lame.
00:27:31maaku:adam3us: well bloom filters in general have privacy problems...
00:27:48adam3us: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:19gmaxwell: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:40adam3us:maaku: and use it multiple times in your potential graph to narrow in on you. privacy leak stats is cumulative
00:28:59gmaxwell: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:12gmaxwell:it's not privacy against powerful forces but its not half bad.
00:29:41adam3us: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:46gmaxwell: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:58adam3us: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:13gmaxwell: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:00gmaxwell: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:02adam3us:gmaxwell: yes maybe a public key versoin of that
00:34:17gmaxwell:the fact that its not public key is what makes it forgable. :)
00:34:42adam3us:gmaxwell: so long as its a fuzzy match...
00:34:56gmaxwell: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:12gmaxwell:yea, thats why I said n-bits. it has to be small enough that searching for forgeries is easy.
00:35:13adam3us:gmaxwell: maybe could allow different query for same data somehow
00:35:19adam3us:gmaxwell: yeah i got that
00:36:35adam3us:gmaxwell: also in the hmac how do u get the key to the sender...
00:36:52gmaxwell: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
00:37:16gmaxwell:adam3us: you put it in the address.
00:37:54adam3us:gmaxwell: yes but then its not a secret, so ah ok its better than a prefix however got you.
00:38:26gmaxwell: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:28adam3us:gmaxwell: already an improvement on prefix, and Jeremy's about to like write an RFC level of "awesomely done"
00:39:09gmaxwell:down side is that someone scanning for you can't precompute anything to index it... prefixes have that nice property.
00:39:26adam3us:gmaxwell: so the other feature we'd like is pecomputation
00:39:41adam3us:gmaxwell: yes
00:41:16adam3us: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:32gmaxwell: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:56gmaxwell: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:14gmaxwell:and they return any transaction where any one of the part^prefix = one of your baits.
00:43:34gmaxwell:e.g. someone doing stats doesn't know which of the token the part is xored with.
00:43:53gmaxwell:obviously some parameter scaling needs to happen to make it sensible, I picked random numbers.
00:44:19gmaxwell:hm. they should probably be 8 bit. in any case, there you go.
00:45:33adam3us:gmaxwell: not bad i think
00:47:36gmaxwell: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:11adam3us:gmaxwell: is that precomputably indexable?
00:48:12gmaxwell: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:26gmaxwell:adam3us: yea with overhead, e.g. you'd put every transaction in N indexes.
00:49:06gmaxwell: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:49gmaxwell: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:52adam3us:gmaxwell: my public key comment was that then it would not be bait recoverable.
00:51:24adam3us:gmaxwell: yes. it seems reasonably good. definitely a couple of increments better than prefix
01:01:48jcrubino:jcrubino has left #bitcoin-wizards
01:33:47phantomcircuit:that reminds me
01:33:51phantomcircuit:nvm
03:05:51andytoshi: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:17andytoshi: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
04:25:27EasyAt:Where is the correct channel to ask about sybil attack mitigation in a decentralized WoT?
04:33:59amiller:EasyAt, maybe you want #bitcoin-wot
04:34:05amiller:but i'd like to hear about it here too
04:43:23EasyAt:amiller: One second, I'd like to state this concisely
05:14:11amiller:gmaxwell, i'm finally starting to realize you're right about snarks
05:14:19amiller:that so far they all require an obnoxious trusted setup
05:18:19maaku:amiller: but it's okay if you trust yourself, right?
05:18:35amiller:no not really
05:18:38gmaxwell: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:31amiller: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:38gmaxwell: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:08amiller:i've sort of not noticed it despite mouthing off about how cool my nonoutsourceable puzzle is based on snark
05:20:19amiller:it's more immediately relevant to zerocoin though
05:20:33amiller:i mean, they're aware of it too
05:20:40maaku: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:00gmaxwell:amiller: http://www.reddit.com/r/ZeroCoin/comments/1uy35p/matthew_green_to_speak_about_new_zerocoin_version/ceo17ut
05:21:02amiller:maaku, creating a SNARK verify key requires someone to have some secrets they are trusted to delete
05:21:16gmaxwell:amiller: A GGPR-12 SNARK.
05:21:16maaku:amiller: yes, see ^^
05:21:36amiller:yes i just got back from that and chatted with him and his student about this
05:21:51maaku: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:56gmaxwell: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:28amiller: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:40gmaxwell:maaku: for _some_ applications it might not matter, for some it would.
05:23:13gmaxwell: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:43gmaxwell: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:41amiller:i see.
05:26:11gmaxwell: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:26gmaxwell:What they're talking about doing in zerocash I think its completely unacceptable.
05:26:46gmaxwell:then again, for that application 20kbyte signatures is probably also unacceptable.
05:27:21amiller:how far do you think they can smear around the anytrust kind of setup
05:27:41gmaxwell:(and for that matter, q-power knoweldge of exponent, bilinear pairing stuff is by itself probably unacceptable)
05:27:54amiller:that was a question someone asked, matt green answered affirmatively, i didn't seek any details
05:28:04gmaxwell:What was?
05:28:14amiller:whether you could distribute the setup among N parties
05:28:21gmaxwell:yea, I think thats half BS
05:28:23amiller:where any of the N parties has to delete their data
05:28:28amiller:okay
05:29:02gmaxwell: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:45gmaxwell:(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:46maaku:gmaxwell: i see
05:30:29gmaxwell: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:44amiller:yeah everything attempted in practice so far has been semi honest
05:30:48amiller:afaik
05:31:25gmaxwell: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:52gmaxwell:You could, in theory, make the CRS with MPC. .. but active secure MPC that looks remotely pratical is a passive MPC + SNARKS.
05:32:58gmaxwell: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:27gmaxwell: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:48gmaxwell:And realistically I think N can't just be 3. Start talking about 30 and thats more interesting.
05:33:51amiller:yeah. i came to that conclusion pretty quickly too
05:34:05amiller:sell tickets to the big setup phase MPC as your fundraiser gimmick!
05:35:24gmaxwell: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:31amiller:david blaine could do one too
05:36:55gmaxwell:the undetectable compromise part is part of what makes this so bad for ZC where it wouldn't be an issue elsewhere.
05:37:03gmaxwell:lots of room for fud.
05:37:40gmaxwell:"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:24gmaxwell:at least if it were detectable you could freeze new spends and deploy another ZK proof system (perhaps a less efficient one)
05:39:07amiller:i learned about a formalism called "covert security" that's weaker but promises detection like that...
05:39:22amiller:but i couldn't find any trace of someone actually getting any cheaper construction that way
05:40:32gmaxwell: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:25gmaxwell:and I think the way the perfect zero knoweldge is achieved it must be that way.
05:42:14gmaxwell:(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:39gmaxwell: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:40amiller: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:05amiller:i don't have any idea what comes next
05:52:02gmaxwell: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:35gmaxwell: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.
08:01:32nsh:gmaxwell, if it helps, didactically, you can compare the security of the CRS model to the security of DUAL_EC_DRBG....
08:06:13gmaxwell:Hm!
08:06:14gmaxwell:point.
09:46:48TD[away]:TD[away] is now known as TD
11:17:16adam3us: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:39adam3us:gmaxwell: (posted this and related on bitcoin-dev)
12:56:56jtimon: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:11jtimon:does anybody have any reference to that?
13:04:02jtimon:hmm, is this it? https://bitcointalk.org/index.php?topic=63365.0
13:04:45jtimon:I'm considering mentioning rumors about it and putting a link on an article about p2p currencies I'm finishing
13:07:31jtimon:I don't know...wasn't coinhunter a scammer?
13:07:52jtimon:"Artforz publicly admitted to creating a GPU miner for litecoin numerous times" any link to this?
13:08:31jtimon:I'll keep searching, just browsing out loud in case anybody can give me some clues or a better link
14:17:40Emcy:hmm apparently GCHQ couldnt crack truecrypt with the password "$ur4ht4ub4h8"
14:17:51Emcy:they had to sling the guy in jail and sweat it out of him
14:18:03Emcy:isnt that a weak password? Is that a bit surprising.
14:18:16adam3us: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:50adam3us: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:31adam3us: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:48Emcy:and yet a skilled cracker with a good custom dictionary and a handful of radeons might
14:20:45adam3us:Emcy: if it was unstretched, for sure; lot of former gpu miners coul crack that with their own cards!
14:21:49Emcy:ok i assume it was truecrypt
14:22:10Emcy:http://www.bbc.co.uk/news/uk-25745989 look hes got a beard so hes probably up to no good!
14:22:52adam3us: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:51Emcy:adam3us isnt it fairly common knowledge that someone was mining LTC rather faster than should have been possible early on
14:23:58tacotime_:I recall artforz had mentioned he implemented it on GPU And it was slower
14:24:40tacotime_: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:21tacotime_: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:23adam3us: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:12tacotime_:You honestly trust something coinhunter said?
14:26:38tacotime_:The guy who has stolen hundreds (probably thousands) of BTC from the community over the past 2 years? ;)
14:26:51adam3us: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:14adam3us:tacotime_: yeah i heard of solid coin by infamy/reputation only wasnt paying attention back then. he's that guy?
14:27:25tacotime_:yeah
14:27:46tacotime_:RealSolid/CoinHunter, same person
14:28:27tacotime_:http://www.openwall.com/lists/crypt-dev/2013/03/21/1
14:28:29adam3us: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:50tacotime_:I'm not sure where mtrlt was updated to the desynchro/TMTO trick though
14:29:06tacotime_:Or if pooler had first picked it up when optimizing his LTC miner
14:30:15adam3us:tacotime_: i think i saw solar designers TMTO experiments, he mustve cross posted to one of the crypto lists
14:30:28tacotime_:yeah
14:31:46tacotime_:mtrlt also ran off with a load if bitcoins after claiming he would implement primecoin miner on gpu
14:32:03adam3us: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:10tacotime_:He did release some really broken source code, but then just fucked off
14:32:52tacotime_:If it's parallelizable, I find it difficult to believe that a GPU won't run faster even if you need memory
14:33:22tacotime_:GPU vRAM bandwidth is always going to be greater than the DDR3 bus on the main board
14:34:01adam3us: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:21tacotime_: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:29tacotime_:mm
14:35:32adam3us: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:01adam3us:tacotime_: 256-bit might be quite ideal for dagger :) its a merkle tree.
14:38:15adam3us: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:23killerstorm:hi. does anyone have an idea when OP_RETURN outputs will be usable on the mainnet?
14:41:04jtimon:adam3us, tacotime_ : that's the problem. The story seems plausible, but solidcoin is not a reputable source...
14:41:51jtimon: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:33jtimon:adam3us, tacotime_ : seems to point out in that direction, if ltc mining was less competitive, it should have been more profitable
14:42:59jtimon:maybe it was just a botnet what caused that
14:44:00adam3us:killerstorm: i am guessing that is a color coin related question ;)
14:46:45killerstorm: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:16killerstorm:also it looks like non-tech people think that use of OP_RETURN makes protocol better and more legitimate :-/
14:48:21jtimon: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:08jtimon: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:54jtimon:killerstorm: yeah, some freicoiners thought it would allow people to use the chain for messaging, files...
14:51:10adam3us:killerstorm: here's some replayed history from a few days back
14:51:22adam3us:(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:22adam3us:(06:42:36 AM) justanotheruser: So will it be standard in .9?
14:51:22adam3us:(06:42:52 AM) Luke-Jr: hopefully not
14:51:38adam3us:(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:38adam3us:(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:49adam3us:(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:49adam3us:(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:03adam3us:(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:04adam3us:(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:34adam3us:killerstorm: (end of few days old discussion paste)
14:54:19jtimon: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:07jtimon:about using the nsequence fields...I don't know, some people want to use it for microtransactions channels
14:55:45jtimon:I think the probable solution is for microtransactions to be directly off-chain, but I don't know...
14:55:57adam3us: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:30adam3us:jtimon: time-stamping at least typically is putting a single hash which is the merkle root of many documents
14:57:08jtimon:adam3us: yeah, I don't think you need to allow more than a single hash after return
14:57:08killerstorm: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:33jtimon:being not in-chain validated, it can be transffered off-chain as well
14:58:09jtimon:p2sh^2 ??
14:58:22killerstorm: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:43adam3us: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:38jtimon:killerstorm oh, this doesn't use replacements https://bitcointalk.org/index.php?topic=244656.0
15:00:49jtimon:I guess nobody has a use for it then
15:03:26jtimon: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:08jtimon:well, that can be replaced with coinswap, which doesn't need nseq iirc
15:08:41adam3us:jtimon: i dont know, others would know better
15:09:19adam3us:jtimon, killerstorm: i think killerstorm implemented atomic swap in is chromawallet (color coin wallet) if i recall the announce
15:10:40jtimon:adam3us but that is atomic swap between colors in the same chain
15:10:59jtimon:the link and coinswap is cross-chain
15:11:05killerstorm:transaction replacements are usable under condition that all miners are honest. this just doesn't make any sense.
15:11:19jtimon:well, coinswap can also be used in the same chain for mixing
15:11:26killerstorm:trading-across-chains doesn't need replacements
15:12:20jtimon:killerstorm: yes, you're completely right, miners should just get the transaction with higher fees when they receive double-spends
15:32:57killerstorm:killerstorm has left #bitcoin-wizards
15:51:32jtimon:I guess we should just remove the seq field in freimarkets...
16:10:34adam3us:jtimon: the seq field was designed for revisable bids?
16:11:00TD:it is designed for mempool replacement
16:11:22TD:basically for high frequency trading between a set of parties (to use satoshis terminology)
16:14:29jtimon: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:10TD:of course there is
16:16:16TD:this kind of nonsense reasoning about game theory is so destructive
16:17:11TD: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:24TD:miners are not thinking only 20 minutes into the future, you know
16:17:52TD: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:19TD: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:30pigeons:the same pool that did double spend?
16:18:41pigeons:or facilitate it i mean
16:19:04TD:other pools have done the same thing in the past
16:19:06TD:deepbit, btc guild etc
16:19:40gmaxwell:deepbit was DDOSed off the network for a week solid when it reached 50% I don't believe it ever regulated itself.
16:21:16gmaxwell: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:53gmaxwell: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:59TD:correctly configured incentives don't magically make better solutions appear though
16:22:07gmaxwell:We agree.
16:22:18gmaxwell:(well you and I at least on that. :) )
16:22:20TD:they exert pressure in the right direction, but someone still has to do all the work to create an actually better situation :)
16:23:27gmaxwell: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:30TD: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:40TD:like, where the block chain becomes a very strong signal that is nonetheless blended with others
16:24:53TD:betcoin took a bet and lost
16:25:08gmaxwell: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:25jtimon:TD: "the value of their money" you assume miners are always at the same time btc speculators, they can just sell them
16:25:53TD: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:59TD:jtimon: for how much?
16:26:14TD:jtimon: all miners are speculators to some degree because they have amortised costs
16:26:17jtimon:like saying "bitcoin can't work because miners have incentive to merge together and then do 51% attacks to double spend" <--
16:26:17jtimon:no, it works because it's easier and more long term for them to just make money out of honest mining
16:26:43gmaxwell:of course if you're able to trust the payer... why even bother with fancy protocols. "Pay me what you owe eventually."
16:26:44TD: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:58TD:well that's what in practice we do already with unconfirmed transactions.
16:27:15TD:the block chain has a sweet spot where it's really useful and appropriate. other times it's not so helpful
16:29:49TD: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:16jtimon: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:51jtimon:when you compare capital, say a pub, a building and a mining rig
16:31:01TD: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:14TD: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:23jtimon:you compare them by capital yield, doesn't matter if you're doing it with your own money or with borrowed money
16:31:59jtimon:if it's your money you don't have more incentiveto accept low yields
16:32:24jtimon:you could lend/invest more profitably somewhere else
16:33:02jtimon:TD: I mean you're assuming too much about miners by assuming they keep the btc for more than 100 blocks
16:33:22TD:my assumption is really just that they care about the price
16:33:26TD:which is pretty basic, yes
16:35:03jtimon: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:46jtimon:anyway, they won't destroy bitcoin by taking the higher fee when receiving double-spends
16:35:58jtimon:with or without seq
16:36:18jtimon:and if seq relies on that, well, then it is not very secure
16:36:49TD:of course they would
16:36:55TD:that would be the absolute worst thing miners could do
16:37:02TD:no unconfirmed transactions? watch the price collapse
16:37:05jtimon:why?
16:37:09TD:many miners would never make back their ASIC investments then
16:37:39jtimon:mhmm
16:38:34jtimon:what satoshi proposed for "unconfirmed transactions" were services that contracted with pools to connect directly with them I think
16:38:58jtimon:it's in the snack machine thread I think
16:39:29TD:no
16:39:44jtimon:killerstorm also says that the high "frequency tunel" use case doesn't need seq
16:39:44TD: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:53TD:and that it could listen for double spends on the network anyway
16:40:15TD:it doesn't need tx replacement as long as the micropayment channel flows in one way direction
16:40:20TD:if you want more flexible arrangements it does.
16:40:30TD:fortunately for many interesting applications, one direction is enough
16:41:22jtimon:TD https://bitcointalk.org/index.php?topic=423.msg3867#msg3867
16:41:40jtimon:"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:54TD:any node can do that. pools didn't even exist back then
16:42:09TD:so he obviously wasn't talking about contracting with pools
16:42:12TD::)
16:42:19jtimon:correct he didn't said pools, just well connected
16:42:32TD:once double spend relaying is done, you won't even need to be very well connected
16:42:37TD:so this is not really a big deal
16:42:46jtimon:maybehe was thinking about mining farms?
16:43:15jtimon:"double spend relaying" I'm not sure that's really secure
16:43:26TD:he said what he was thinking of - a service provider that performed the job of watching for double spends
16:43:29TD:why not?
16:43:43jtimon:if it was secure we wouldn't need PoW
16:43:54TD:i think you're confused
16:44:08TD:double spend alerts tell you that there has been a double spend. it does not tell you which spend will win.
16:44:31jtimon:oh, sorry
16:45:00jtimon:I thought it was some of those proposals to "prvent double spending"
16:45:18jtimon:I think there's even a paper about that
16:45:41TD:no, i said "double spend relaying"
16:45:52jtimon:sorry again
16:45:57TD:np
16:46:04adam3us: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:23jtimon:TD I still think future miners will just mine the highest fee transaction (even with double spend relay)
16:47:44TD:*shrug* and i think you're wrong. guess we're done :-)
16:48:01jtimon:adam3us: preventing fractional reserve? I must have missed something about the proposal...
16:48:29jtimon:TD hehe, yes, well we can detail how each other see the future
16:48:33adam3us: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:07jtimon:TD I think instant transactions won't be in-chain because in-chain transactions will be expensive
16:49:33jtimon:TD in-chain will be used for debt settlement mostly
16:49:34adam3us:jtimon: that assumes we cant make it scale quite a bit more.
16:49:43TD:these conversations are all years old
16:49:46TD:tbh i'm tired of them
16:49:51TD:back in 2010 it was interesting
16:50:46adam3us:petertodd: is the man to wind up for game-theory arguments.
16:51:09jtimon:adam3us I think we can make it scale it more, just not enough to process all the world's transactions
16:51:57jtimon:adam3us which I also predict will be many more in the future
16:51:58adam3us:jtimon: i am not sure. maybe pegged side chains offer another flexibility.
16:53:09jtimon:adam3us: still if each node processes the whole world transactions, there won't be many full nodes
16:53:16jtimon:or miners
16:53:47adam3us:jtimon: think multiple side-chains, maybe shard the transaction set
16:53:55petertodd: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:14jtimon: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:16jtimon:petertood: yeah something like sharding could make me wrong, but I'm unconvinced that's feasible for now
16:55:33jtimon:not that I don't think about that myself
16:55:51petertodd: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:53TD:it's already done: alt coins
16:56:31petertodd:indeed it is, what's interesting is how to better integrate multiple chians into a cohesive whole
16:56:58jtimon:TD altcoins are very wasteful the way they are right now, they're just highly subsidized by seignoriage greed and stupidity
16:57:10TD:the p2p chain-trade thing would seem to be the best way. not that anyone is really exploring it properly
16:57:26TD:jtimon: so they take some of the stupid-load off the bitcoin chain. win :-)
16:57:29petertodd:jtimon: though also I see *no* reason to think you can get fast, let alone instant, consensus requried for retail payments
16:57:51jtimon:just adding more altcoins doesn't scale, not even with merged mining, miners still need to process everything
16:58:20TD: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:29TD:jtimon: then you'd have exchange rates between them. but that's painful.
16:58:36TD:easier to scale the tech, i suspect
16:58:38jtimon: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:58petertodd:TD: ha, for once we're on agreement on scalability (at least on what we should do in the short/medium term)
16:59:11jtimon:TD ok I get your point
16:59:12TD:i'll go out and celebrate tonight :)
16:59:34jtimon:TD but that's assuming no merged mining :(
16:59:56petertodd:TD: and for long-term, we can probably agree that we don't know yet becaues the research hasn't been done :)
17:00:11TD: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:17TD:indeed!
17:00:42jtimon:yeah, maybe I'm just envisioning the worst-case scalability scenario, and still future looks bright
17:00:55petertodd: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:41petertodd: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:28petertodd: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:33adam3us: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:38jtimon:petertodd: I just don't know how you're going to do that
17:02:47petertodd:jtimon: the open research problems are all related to how does security work there
17:03:12jtimon:petertodd: as said some kind of sharding would be very nice
17:03:13petertodd:jtimon: well, I've got some ideas - day before yesterday I outlined one on -wizards
17:03:52jtimon:yeah you half-explained me one, but I was unconvinced
17:04:08petertodd: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:13jtimon:I'm happy that you're thinking about these things though
17:04:35petertodd:adam3us: but as I say, the specifcs are an open question right now
17:04:57adam3us: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:13jtimon:petertodd: one idea I had in mind was partitioning the sequencing itself
17:05:19helo:sharding is sending bitcoin to an unspendable bitcoin addresses to mint altcoin?
17:05:22adam3us: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:41jtimon:but I haven't found a way to make it p2p
17:05:47adam3us:helo: no sharding is generic... just means split up the volume somehow
17:06:04helo:ok
17:06:20adam3us:helo: pegged side-chain involves proof of transfer (you can move the coin back too, not destroyed as such)
17:06:24petertodd: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:52jtimon:helo: like having half transactions in one chain and the other half in another chain
17:07:06jtimon:helo: I meant that for sharding
17:07:52adam3us: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:59petertodd:jtimon: yeah, atomicicity of transactions in sharded systems is a really interesting question
17:08:37petertodd: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:46petertodd:adam3us: *actual
17:08:47jtimon:let me explain how would it work "centralized", maybe you can come up with a way to make that p2p
17:08:55adam3us: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:58jtimon:or someone else
17:09:21petertodd:jtimon: see fidelity bonded banks where the machine readable fraud proofs are what makes it possible to do it p2p
17:09:27jtimon:adam3us: that still requires fat validation miners
17:09:55petertodd:jtimon: no it doesn't, mining is scalable because miners don't have to validate all chains
17:09:59jtimon:petertodd you don't know what I'm going to say yet
17:10:12adam3us: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:52jtimon:petertodd: there was no sharding in adam3us not implausible comment
17:11:19jtimon:"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:21adam3us: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:43adam3us:jtimon: yeah is just a definitional thing. you could consider the 100 side chains 100 shards
17:12:15petertodd: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:40adam3us:petertodd: yes this is a kind of open transactions argument. i buy that as a plausible thing to explore.
17:12:59jtimon: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:41adam3us:jtimon: i was thinking of a use-case of (multiple identical) pegged side-chains as a mechanism for sharding
17:13:57petertodd: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:15petertodd:jtimon: which is why coming up with a backwards-compatible upgrade is actually fairly plausible - ugly, but feasible
17:15:18jtimon:adam3us: but the pegging thing is to solve the "exchange rate" problem TD mentions
17:15:19adam3us: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:50petertodd:adam3us: yup
17:16:02jtimon: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:16adam3us: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:37adam3us: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:06jtimon:adam3us: security firewalled? what in pegcoin makes it more attractive to merge mine than say, devcoin?
17:18:35petertodd: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:38adam3us:jtimon: incentive you mean? ask petertodd he's the incentive / game-theory gur ;P
17:18:56petertodd:adam3us: it's the think with off-chain stuff: it becoming too effective is a huge risk in the long-term!
17:19:46petertodd:adam3us: now that's like, 10 years away long term hopefully, but it's a problem that needs solving eventually
17:19:54adam3us: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:47jtimon:petertodd are you suggesting off-chain technology working nicely and securely is a "huge risk"? what do you mean?
17:21:01adam3us: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:29petertodd: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:39adam3us:jtimon: he's worried about an incentive break down leading to attacks
17:22:04jtimon:adam3us well I ask you because you made the firewall claim, but I'm happy receiving an explanation from anybody
17:22:10petertodd: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:51petertodd: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:12adam3us: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:54jtimon: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:55adam3us:jtimon: /can/can not/. fortunately that seems possible to assure, hence 2-way peg excitement
17:23:55petertodd: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:34petertodd: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:07TD:TD is now known as TD[gone]
17:25:19adam3us: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:30jtimon:petertodd: if an off-chain system has all the properties bitcoin has, why should we fight to maintain a less efficient system?
17:25:38petertodd: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:58petertodd:jtimon: because plausible off-chian tx systems *require* bitcoin to exist under the hood
17:26:08adam3us:jtimon: in this side-chain model bitcoin main is the sole home of reward mining. its the hub at the center.
17:26:15petertodd:jtimon: without bitcoin they don't work
17:26:19jtimon:DRM needs proprietary software, which means we can't trust it
17:26:29jtimon:proprietary soft/hardware
17:26:47petertodd:jtimon: so what? trust isn't a binary thing
17:27:18jtimon:oh, I see "nbecause plausible off-chian tx systems *require* bitcoin to exist under the hood" this is what I was missing
17:27:19petertodd: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:41jtimon:freimarkets private blockchains don't need public chains to work
17:27:45petertodd:and if bitcoin still exists, I can use techniques like fidelity bonds to make cracking the DRM system a lot less attractive
17:27:49adam3us: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:50jtimon:they can just interoperate with them
17:28:06adam3us:jtimon: is it drazan?
17:28:06jtimon:of course they don't have all the properties bitcoin has
17:28:08petertodd:adam3us: indeed, I'm thinking of buying a pair to support him
17:29:01adam3us:jtimon: drazvan https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688
17:29:33adam3us: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:35jtimon:so your concern is that off-chain systems relying on bitcoin are so useful that nobody uses in-chain transactions
17:30:03petertodd: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:05jtimon: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:06adam3us:petertodd: or maybe some trust/certification/ripple stuff sneaks in and mining contribution is reduced
17:32:00jtimon:petertodd I tend to worry more about "too much security" in the chain than about "too little of it"
17:32:00petertodd: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:19adam3us: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:21petertodd:jtimon: "too much" just means you're wasting money - not a big deal.
17:32:42petertodd:jtimon: too little and some malicious 51% attacker destroys the whole system and we're fucked - big deal
17:32:57adam3us:petertodd: but he should do NFC or QR code, not SMS :(
17:32:58petertodd:jtimon: 0.1% to 1% are pretty low numbers that can be ignored as "rounding errors"
17:33:20petertodd:adam3us: isn't that just a software detail? the hardware itself isn't what does SMS
17:33:28adam3us:petertodd: sure
17:33:32jtimon:maybe I'm too hippy or something, too much you're wasting resources, destroying more nature than you need and all that
17:33:59adam3us:petertodd: nfc/qr = network privacy. sms=privacy leak.
17:34:09petertodd: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:38petertodd:jtimon: I mean, hell, I'm sure with credit cards the numbers are about that *per transaction*
17:34:42nsh_:nsh_ is now known as nsh
17:34:42jtimon:well, I'm pretty sure 2PC ripple doesn't waste more resources than it needs
17:34:59petertodd:jtimon: wastes a lot of human brainpower on person-to-person trust relationships
17:35:23jtimon:credit cards need to feed fat cats, thus their high fees, but that's another story
17:35:55petertodd:jtimon: that's a shitty way to talk about the situation and makes you sound like an occupy activist
17:36:07jtimon: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:47petertodd:jtimon: well I think you're dead wrong there :)
17:37:30petertodd: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:44jtimon:whatever, I can say it more correctly but it's just takes longer
17:38:47jtimon:was just laziness
17:38:49jtimon:credit cards are a very unefficient system for multiple reasons, I was talking about efficient systems like @PC Ripple
17:38:49jtimon:2PC
17:38:54jtimon:petertodd: you see I believe in both counterpartyless money and credit monies complementing each other
17:40:02jtimon:to me, people that plainly reject credit as an exchange toold often sound like braindeath cultists goldbugs
17:40:23jtimon:just like people plainly rejecting counterpartyless money and only accepting mutual credit sound like fanatic
17:40:27petertodd: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:30jtimon:that's just to me
17:41:01petertodd:jtimon: "Also, it's gonna be really awkward to turn down Bob because of his gambling problem."
17:41:24jtimon:petertodd: organizing a ntework of mutual credit local currencies is even more work
17:41:36petertodd: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:49petertodd:jtimon: "But I'd rather not bring that up again...."
17:42:18jtimon:I agree that a ripple-like network has harder critical mass problem than bitcoin
17:42:20petertodd:jtimon: Meh, software can do that automatically, and more likely we'll have schemes where the exchange rates don't float.
17:42:54petertodd:jtimon: It's orders of magnitude harder.
17:43:32jtimon:luckily it can start with other currencies like backed currencies, bonds, coupons, shares...
17:44:02petertodd:it's totally irrelevant what currency ripple works on, the problem is the social dynamics of it
17:44:06jtimon:maybe it never goes beyond that, but I think coupons can be more imporant than many expect in the future
17:45:07jtimon: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:01petertodd:*if* people accept it
17:46:21petertodd:if they don't, then you've put a lot of effort into a system that never got used
17:47:51jtimon:mutual credit is widely used right now
17:47:59jtimon:much more than you think
17:48:36jtimon:I just want to give this systems a plattorm to securely inter-operate
17:48:46petertodd: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:42petertodd: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:48jtimon:yeah, b2b, so called "barter networks" (they're really just another currency), coupons, local currencies...
17:50:07jtimon:to interoperate with others
17:50:28jtimon:to be able to pay with your spanish local currency in germany
17:50:45petertodd: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:52petertodd:if fees are low enough, why bother?
17:50:55jtimon:you just need a market path from the spanish local currency to the germany one
17:51:05jtimon:what fees?
17:51:13jtimon:bitcoin fees?
17:51:38petertodd:remember, ripple is all about optimizing who owes who, but why do you care exactly?
17:51:53jtimon:that's what money is all about
17:52:24jtimon:"bitcoin is about who has what, but why do you care?" I don't understand your point
17:52:24petertodd:what money is about doesn't matter for the end-user, they just want to solve a business problem
17:52:59adam3us: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:03jtimon:seriously I don't get your point about not caring
17:53:26jtimon:how would you don't care about who owes you and who you owe too?
17:53:40adam3us: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:29jtimon:petertood: you don't see any value in a ripple network or in credit in general?
17:54:32petertodd: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:43adam3us:jtimon: i think petertodd is still on competition & adoption, his q. why would someone prefer freimarket IOU freicoin over btc
17:54:58petertodd:jtimon: The "meaning" of money means absolutely nothing to either party in that transaction.
17:55:06jtimon:petertodd: people don't want money, people want the stuff they buy with it
17:55:42adam3us:jtimon: its also a value store i guess.
17:55:50jtimon:it's not about preferring, you have your wares that by definition you don't want and want to sell
17:55:56petertodd: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:21jtimon:exactly
17:56:32jtimon:that can be done with "money" or credit
17:56:42petertodd: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:01jtimon:the important stuff is are the icecream and the milk, the rest are just numbers to make that happen
17:57:23petertodd: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:34jtimon:that's the ideal situation in ripple, try to come back to the b2b stage
17:57:52jtimon:you sell icecream in summer
17:58:22jtimon:I go to you and say "do you accept ourtown's local currency for the ice cream"
17:58:42jtimon:you say "no, I prefer bitcoin"
17:58:47jtimon:"ok, ?I don't have bitcoin, keep your icecream"
17:59:23jtimon:if you want milk and you can buy it with both local credit currency and bitcoin, why reject any of the two?
17:59:37petertodd: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:34jtimon:hehe, you remind me to people talking about real businesses and bitcoin a while back...
18:00:44petertodd: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:02jtimon:the magic of ripple is that you will only ever receive the currencies you accept
18:01:26petertodd:...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:38jtimon:and the payer doesn't need to bother about conversions neither: the system does them
18:01:42jtimon:yes, I'm aware
18:01:43petertodd:jtimon: That's not magic at all.
18:01:59jtimon:no, it's not magic
18:01:59jtimon:it's tech
18:02:01petertodd:jtimon: That's the magic of "I price my icecream in dollars."
18:02:08adam3us:petertodd: well i guess bitcoin doesnt do it
18:02:11petertodd:jtimon: You don't need ripple for that
18:02:41adam3us:petertodd: bitpay et al let you though, ok
18:02:51jtimon:you can say "I price my icecream in gbp, I accept btc, bristol pounds or gbp"
18:03:11petertodd: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:14jtimon:I go there with frc and sevillan pumas
18:03:47adam3us: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:50jtimon:I push "pay 1 gbp to this merchant" the system says "want to pay X frc or Y pumas?
18:04:02jtimon:what's the unconvenience?
18:04:45jtimon:petertodd: a ripple network can do what bitpay does!!
18:04:57petertodd: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:26jtimon:no, I said the merchant just accepted 3 currencies, that's 3 credit relationships
18:05:30petertodd: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:03petertodd: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:12jtimon:but the point of the system is unite the infrastructure of the different currencies NOT TO NEED the specialist
18:06:39jtimon:whatever, I don't think I can convince you
18:06:50petertodd:jtimon: Modern economics has realized over and over again that specialists are excellent solutions to most problems.
18:07:17jtimon:so please, answer my previous question "you don't see much value in a ripple network or in credit in general?"
18:07:43petertodd:I see lots of value in credit, because people use credit all the time. Ripple, not much value at all.
18:07:59jtimon:petertodd, argument of authority fallacy, your authority: "modern economics"
18:08:11jtimon:Ripple = credit
18:08:30petertodd:jtimon: No, ripple is a way to manage credit. There are other ways to manage credit.
18:08:41jtimon:it's just the same thing with a more convenient infrastructure
18:08:59petertodd:jtimon: You think it's more convenient, I don't for a whole host of reasons.
18:09:12jtimon:what's the difference between an international payment and a ripple transaction?
18:09:29jtimon:transitive credit, it's the same thing
18:09:49petertodd: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:54jtimon:you know, banks took all that overhead of trusting each other
18:09:59adam3us: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:27petertodd: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:04petertodd: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:06jtimon:I'm saying it won't start with personal credit, but with b2b, local currencies, p2p markets gateways...
18:11:07adam3us:petertodd: i think the notional advantage of ripple.com is that they can cancel out some debts and so reduce the fees
18:11:22jtimon:the small participants can join later
18:11:38petertodd: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:11jtimon:just to be clear, I'm talking about ripple the concept not ripple.com
18:12:12petertodd: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:21adam3us: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:35petertodd:adam3us: ripple.com is an abomination and we shall not refer to it again
18:12:40jtimon:the way you trust in ripple.com is very risky for users
18:12:42adam3us:jtimon: yes. thats why i put ripple.com when i wanted to refer to them
18:12:57jtimon:because it assumes 1 aaaUSD = 1 bbbUSD
18:13:01adam3us:petertodd: hehe the R-word.
18:13:52jtimon:that's not necessarily true in 2PC ripple or freimarkets
18:14:31maaku:jtimon: replacements can be used for microchannel payments (e.g. utility bill)
18:14:43petertodd: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:16petertodd: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:30jtimon:aaaBTC/bbbBTC should be just a market like any other
18:15:44petertodd:jtimon: that's a market with very little depth to it
18:16:08jtimon:that depends on the issuers, aaa and bbb
18:16:58petertodd: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:00jtimon:maaku why a miner should accept seq = 5 over seq = 3 if seq = 3 has a higher fee ?
18:17:17petertodd:jtimon: because TD and Gavin asked nicely
18:18:04jtimon: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:41petertodd:jtimon: if you issued both, they there weren't two separate things
18:18:48jtimon:"jtimon: because TD and Gavin asked nicely" what did they asked?
18:19:08petertodd:the difference between aaaBTC and bbbBTC is that the issuer is differnt, and thus the default risk is different
18:19:20petertodd:jtimon: to not do "selfish" replace-by-fee of course
18:19:21maaku:jtimon: what if they have the same fee?
18:19:35jtimon:whatever system you had in mind to make "1 aaaBTC == 1 bbbBT", it can be simulated with a market
18:19:51maaku:agreed that nseq is dangerous, but just pointing out the (only) application I know of which nseq handles but nothing else does
18:20:02petertodd: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:27jtimon:killerstorm said you can do that use case with multisig
18:20:32maaku:petertodd: true. then is there any other valid use for nseq?
18:20:38maaku:(still catching up to scrollback)
18:20:46petertodd:maaku: to fork alt implementations :P
18:21:12petertodd:maaku: nSeq is also the *only* user-settable field in a txin that is signed by the signature - an unfortunate limitation
18:21:28petertodd:maaku: useful for colored coins, as an example, as nSeq can be the mapping of colored input to output
18:21:48jtimon:killerstorm wants to use the unused nseq to put CC metadata instead of using OP
18:21:57jtimon:OP_RETURN
18:22:10petertodd:jtimon: yeah, I suggested that to him
18:22:18jtimon:but some people are telling them that the field will be re-enabled later
18:22:38jtimon:petertodd: yes, he said so in bitcoinX
18:22:45petertodd:so what? using it that way is compatible with transaction replacement in fact
18:23:09jtimon:he came here to ask about that
18:23:39jtimon:arguing against the security and the use case of nseq
18:23:50petertodd:well, just think about it: if nLockTime=0 and nSeq != max, the tx is final and nSeq irrelevant
18:23:55jtimon:so I concluded we could just remove it in freimarkets
18:23:56petertodd:(to the replacement code)
18:24:41jtimon:I see, so there's no contra at all for using them for CCs
18:25:25petertodd:yup
18:25:38adam3us: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:01petertodd: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:20petertodd:adam3us: lol, distracting me from stealth addresses as it is
18:27:25adam3us: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:22adam3us:petertodd: some stealth discussion on bitcoin-dev.. also did u see gmaxwell idea for a better fuzzy bloom-bait/prefix?
18:29:01jtimon:still, I see no reason to keep them in FM
18:29:05jtimon:adam3us I don't think we were advancing much
18:29:20petertodd:adam3us: remind me again?
18:29:43adam3us:petertodd: he posted it also on bitcoin-dev
18:29:45petertodd:jtimon: it's 4 bytes per txin, meh
18:29:50petertodd:adam3us: one sec
18:31:08jtimon: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:28jtimon:I think we could do it already, but maybe we won't be able to hardfok once again for freimarkets then
18:31:55jtimon:petertodd 4 bytes we won't use. we're hardforking, why not?
18:34:03jtimon:well, when we start MM I think we will approach all big pools
18:34:27petertodd:adam3us: gregories idea doesn't scale as well
18:35:02petertodd: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:35adam3us: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:35petertodd:adam3us: to be efficient, you're going to need 16 lookup table versions for instance
18:36:12petertodd: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:13adam3us:petertodd: yes its not cost free, but its still indexable and the privacy is slightly less bad.
18:36:22petertodd:jtimon: just make sure that a signature can sign stuff in the scriptSig then
18:36:33petertodd:jtimon: there really needs to be a mechanisms to do that
18:37:04petertodd: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:32jtimon:petertodd I don't understand, why is nseq necessary for the signature?
18:38:31petertodd: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:31adam3us: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:48petertodd:jtimon: the OP_RETURN txout solution to that is worse, because it doesn't play well with coinjoin
18:39:06petertodd:adam3us: remember that prefixes are denominated in bits...
18:39:15maaku_:petertodd: we support colored coins explicitly. is there some other reason you'd need data attached to the txin?
18:39:37petertodd:maaku_: upgrading CHECKSIG in a soft-fork is an excellent example
18:39:50maaku_:can you explain?
18:40:06adam3us:petertodd: either bits is enuf to create an anon-set problem, or bits is so small that it doesnt scale
18:40:37petertodd: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:36petertodd: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:50petertodd:maaku_: I can't do that right now because any additional data in the scriptSig is unsigned
18:42:13petertodd:adam3us: fundementally the problem is what's the chance of all these extra indexes getting adopted? I'd say nero-zero
18:42:19adam3us:petertodd: i mean doesnt scale to non-full-nodes
18:42:23petertodd:adam3us: near-zero
18:43:03petertodd: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:38adam3us: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:00jtimon:petertodd I don't understand the use case, probablyit can be made without a new op
18:44:01adam3us:petertodd: your smart phone might care
18:44:05petertodd:adam3us: well hey, this is a much smaller privacy problem then what we have right now
18:44:26adam3us:petertodd: i disagree, its a worse privacy problem. thats my point.
18:44:31petertodd:jtimon: think about it more, it can't
18:45:02petertodd: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:05adam3us: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:37petertodd: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:44adam3us:petertodd: yes. but. as gmaxwell said thats different to putting the privacy leak in the indelible global record
18:46:30petertodd:adam3us: well for instance his analysis re: coinjoin is just wrong
18:46:33adam3us: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:39petertodd:adam3us: that's what I'm trying to do you know...
18:47:41adam3us:petertodd: i think my analysis on bitcoin-dev about the anon-set overlaid on network analysis is correct.
18:48:23petertodd: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:32adam3us: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:16petertodd: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:26petertodd:adam3us: (specifically with a random nTweak value)
18:49:28adam3us:petertodd: well actually it might if non-change is an prefixed reusable addr and change is a one-use adr
18:49:39maaku_:jtimon petertodd: well i think this particular application could be better done wih etotheipi's WITHINPUTVALUE sighash mode
18:49:50petertodd:adam3us: the whole point is that you can't distinguish a prefixed reusable *output* and a change output
18:50:17petertodd:maaku_: yes, but where in the scriptSig do you sign the input value?
18:50:42petertodd:maaku_: again, if the signature covers some of the scriptSig, that's easy
18:50:57adam3us: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:23jtimon:petertodd maaku_ I can't think about it because I don't know what is trying to be done
18:52:11maaku_:jtimon: he's trying to have his signature cover the fee, by signing both the input values and the output values
18:52:40adam3us: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:59petertodd: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:47jtimon:ok, first solution: using joyscript and a load_utxo-family opcode (I know, this is another opcode)
18:54:06maaku_:jtimon: and doesn't work for hostcoin
18:54:15petertodd:jtimon: anyway, just look up what I've written on bitcointalk about OP_CODESEPARATOR
18:54:21maaku_:hrm, well this is actually an interesting question about a more expressive script - sighash will have to be implemented differently
18:54:22adam3us: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:45jtimon:maaku_ to disable covenants you just need to disable load_tx
18:54:45jrmithdobbs:petertodd: OP_CODESEP is just bottom really isn't it?
18:54:54petertodd:jrmithdobbs: ?
18:55:06maaku_:jtimon: ah, reading failure
18:55:34jtimon:maaku_ how so?
18:55:48maaku_:jtimon: you're fine i misread what you said
18:56:11petertodd:adam3us: again, you can't distingish outputs using stealth and ones that aren't
18:56:20jrmithdobbs:petertodd: give me a few and i'll restate ;p
18:56:27adam3us: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:38maaku_: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:51adam3us:petertodd: correct. but that doesnt stop you ruling out a given stealth address.
18:57:48adam3us:petertodd: full node stealth addresses are of course immune as they can have zero prefix.
18:58:21petertodd: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:30adam3us: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:18petertodd: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:20adam3us: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:37gmaxwell:ditto, fwiw.
18:59:57gmaxwell:(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:58petertodd:adam3us: tough, it's a hell of a lot safer than the *actual* alternative people are going to be using
19:00:19adam3us:petertodd: what are they going to be using
19:00:23petertodd:adam3us: don't live in a dream world of users doing what's absolutely optimal vs. "Hey, this works!"
19:00:32adam3us:petertodd: TD is working on HD wallet for bitcoinj.
19:00:34petertodd:adam3us: they're going to re-use addresses left right and center
19:00:41jtimon:maaku_ is there any reason not to make withinput value the default?
19:00:42petertodd:adam3us: that's got nothing to do with it
19:01:04petertodd:adam3us: HD is orthogonal to the problem stealth addrs try to solve
19:01:04gmaxwell: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:13adam3us: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:18maaku_:jtimon: yes, that's been my thinking. just have to be careful about compatability
19:01:40maaku_:petertodd: so you'd want a some sort of code-separator like device for the scriptSig?
19:02:00petertodd: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:08wallet421:wallet421 is now known as wallet42
19:02:24petertodd:adam3us: that's change addr reuse, not payment related
19:02:33execut3:execut3 is now known as shesek
19:02:41petertodd:adam3us: I'm solving the user-payment side of things, and that's a hard problem without bi-directional comms
19:02:50adam3us:petertodd: aslo while you and jeremy spilman are in implemention mode why not focus on full node case?
19:02:57jtimon:valitationScript may serve too, but again I'm missing the practical use case of the problem, small memory nodes?
19:03:00petertodd:adam3us: because that's stupidly limiting
19:03:27petertodd:adam3us: anyway, long-term this prefixing stuff will either end up being common for scalability in general, or bitcoin doesn't scale...
19:04:13petertodd: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:28petertodd:adam3us: did you read my blockchain privacy paper btw?
19:05:14jtimon:I'm not following the stealth addresses discussion in detail, but petertodd are the prefixes needed for sharding?
19:05:21petertodd:jtimon: exactly
19:05:22adam3us: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:55maaku_: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:00adam3us:jtimon: no he's just trying to make addresses recognizable but with some privacy in a bloom subset like sense
19:06:18adam3us:petertodd: blockchain privacy? where was this?
19:06:24enodios:enodios has left #bitcoin-wizards
19:06:41petertodd:adam3us: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html
19:06:45jtimon: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:30petertodd: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:55jtimon: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:37adam3us: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:09petertodd:adam3us: read that paper first...
19:09:18petertodd:adam3us: there is logic to it :P
19:09:56jtimon:petertodd: so it could work even without changing anything, miners could just do it to be able to manage a partition
19:10:36jtimon:petertodd I am understanding what you're saying?
19:10:47jtimon:ma I
19:10:47jtimon:am I
19:10:51jtimon:ug
19:10:52petertodd: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:11petertodd:jtimon: they can do so securely with the committed (U)TXO stuff that's been floating around
19:11:39jtimon:assuming we already have commited utxo
19:11:48jtimon:what's the next step for sharding?
19:12:37petertodd: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:12petertodd:jtimon: well, and make "full" nodes themselves only get tx's from their peers matching the prefixes
19:13:12jtimon:I see, thanks
19:13:31jtimon:wait
19:14:33jtimon:full nodes also select a part of the UXTO, where do the prefixes come in?
19:14:55jtimon:oh, sorry
19:14:56petertodd:jtimon: the prefix is what part they select
19:15:31petertodd: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:41jtimon:the smaller the prefix, the bigger part of the uxto you have
19:15:50petertodd:jtimon: with fraud proofs if anyone finds a problem, everyone can be informed that the block needs to be rejected
19:15:53petertodd:jtimon: exactly
19:17:31adam3us: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:56jtimon:ok, I'm trying to compare it with maaku_'s stateless validation proposal...
19:17:57jtimon:in that one, miners only have the root of the utxo
19:18:37petertodd:jtimon: this *is* his proposal
19:18:44petertodd:jtimon: it's something you can do with it basically
19:19:26jtimon:ey, wait
19:19:28petertodd: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:44adam3us: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:59petertodd:adam3us: yeah exactly
19:21:17petertodd:adam3us: remember, the big issue with bloom is it's not indexable
19:21:35petertodd:adam3us: to query against a bloom filter requires matching against all transactions for every query, which sucks
19:21:50adam3us: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:13adam3us:petertodd: yeah bloom has its issues.
19:22:17petertodd:adam3us: there's nothing speculative about it, electrum does just that, and will add prefix queries soon
19:22:23adam3us:petertodd: maybe there's a third way
19:22:54adam3us:petertodd: speculative in there being full-nodes that focus on some prefixes only.
19:23:01jtimon: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:01jtimon:Are miners also supposed to send the full update proofs to each other like with maaku_'s?
19:23:01jtimon:If so, what do miners hold any of the utxo at all (apart from the root)?
19:23:22petertodd:adam3us: electrum servers *are* an example of a full node serving SPV clients
19:23:27petertodd:adam3us: SPV != bloom you know
19:23:49petertodd:jtimon: in the current design of bitcoin that's not really possible
19:23:51adam3us:petertodd: yes i know, and i agree
19:25:02jtimon:petertodd: which of the two things are not possible?
19:25:45petertodd: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:24petertodd:jtimon: the validate txins referring to utxo they don't have
19:26:29adam3us:petertodd: well bloom results are not committed
19:27:02petertodd:adam3us: I know, and like I said, stealth addrs could be implemented as "match this bloom filter index with this nTweak"
19:27:21adam3us: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:23petertodd:adam3us: but that's not scalable on the index side becuse of all the possible nTweak's
19:27:57jtimon: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:06petertodd: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:27petertodd:jtimon: ah, sorry, yeah, if you adopt that then miners can do that
19:29:05jtimon:that's stateless validation
19:29:39jtimon:it seems better than sharding for miners
19:30:02adam3us: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:10petertodd:jtimon: think about how much bandwidht they're using in that example...
19:30:19jtimon:maybe all the proofs should go hashed in the block
19:30:39petertodd: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:50jtimon:petertodd yes, bandwith is the bottleneck in this case
19:30:53petertodd:adam3us: hell, this has to be a solution with pretyt damn low programmer complexity to have any hope of being adopted
19:31:06jtimon:petertodd but your approach is not secure for miners
19:31:20petertodd:jtimon: wait, the sharding?
19:31:24petertodd:jtimon: forget miners
19:31:25jtimon:yes
19:31:35adam3us: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:48petertodd:jtimon: sharding for miners is a much harder problem then sharding for full-nods that want to serve SPV
19:32:04maaku_:jtimon: i got stateless validation from petertodd
19:32:32petertodd: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:43jtimon:petertodd, full nodes too, but miners are spending money hashing....oh, ok, you're not talking sharded miners
19:32:48petertodd:adam3us: I'm specifically trying to design stealth addresses themselves to be backwards compat upgradable you know.
19:32:54maaku_:or it came out of a discussion between petertodd and gmaxwell, iirc
19:33:01maaku_:here on -wizards
19:33:25jtimon:petertodd I thought you needed prefixes in stealth addresses for sharded mining
19:33:42petertodd: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:01petertodd:jtimon: sharded mining eventually, sharded full nodes soon
19:34:38adam3us: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:39adam3us:petertodd: ie they just jam them into their wallet, and reuse them ad nauseum for plenty of non-bizcard scenarios
19:36:13jtimon: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:14petertodd:adam3us: hey, at least with an upgrade path we only have to convince the wallets incrementally
19:36:43adam3us: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:45petertodd:adam3us: meh, users reuse addrs if you let them
19:36:58petertodd:adam3us: pff, good luck, that's user obnoxious
19:37:17adam3us:petertodd: well the client sw would say "error cant reuse"
19:37:21petertodd: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:38petertodd:adam3us: we can hardly convince wallet authors to not reuse change addrs, give it up
19:37:52petertodd:adam3us: never mind you're risking user funds
19:38:02Luke-Jr:lolwut, someone emailed me a complaint - they don't like me using proper nettiquite on bitcoin-dev
19:38:37adam3us: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:15adam3us:petertodd: it has uses too. double-spending becomes much harder!
19:39:19petertodd: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:24Luke-Jr:you all coming to Miami? :p
19:39:43petertodd:adam3us: I'm saying "How can I offer something to users that they'll actually accept and make things easier?"
19:39:58petertodd:Luke-Jr: nah
19:40:21adam3us:Luke-Jr: someone paying flights? kind of far for a weekend...
19:40:44Luke-Jr:far from where :P
19:40:54adam3us:Luke-Jr: malta (europe)
19:41:01Luke-Jr:ah, yeah that's a bit far
19:41:21jtimon:yeah spain's far too
19:41:45maaku_: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:27petertodd:bbl
19:43:40adam3us: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:49adam3us:maaku_: nice write up
19:47:24adam3us:maaku_: i guess also that interpreter escape would be calamitous if that is not impled!
19:50:24maaku_:adam3us: good, i'll add that
19:58:56jtimon:maaku_ reading now
20:10:34jtimon:maaku_ looks great, nothing comes to mind to add
20:16:56jtimon:very good idea to approach those commmunities
20:17:43jtimon:I guess petertodd still prefers forth and gmaxwell and sipa still prefer the AST
20:19:03jtimon:but it will be interesting to see what those forums think, where are you sending that maaku_?
20:19:25maaku_:the concatenative yahoo group
20:19:29maaku_:also #concatenative
20:19:40jtimon:ughh, yahoo groups...
20:20:13maaku_:[13:59:44] adam3us: really? I think forth is basically ideal.
20:20:44maaku_:I think sipa is the only one interested in a more imparative AST
20:21:16sipa:imperative?
20:21:39sipa:if anything i prefer it is not imperative...
20:21:44jtimon:now they want my phone number...
20:22:14maaku_:jtimon: just sign up for the mailing list, no yahoo account required
20:22:56maaku_:jtimon: i'm not a fan of programming in concatenative languages... yuck, honestly. but this is the textbook case for where they excell
20:24:46maaku_:sipa: very poor choice of words on my part
20:25:43maaku_:but is there any advantage to the system you advocated before over a concatenative, point-free language?
20:26:05maaku_:i tried to think of an example the last time we talked, but couldn't
20:26:39sipa:it's a bit vague to me what that means
20:26:59sipa:i'll look up joy
20:28:51jtimon: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:24sipa:it may be possible to convert joy to an AST of the type i suggested
20:29:43maaku_:well it's loose terminology so i'm not sure what exactly is meant
20:29:47jtimon:and everybody uses the same AST, well, I'm just speculating about his reasoning
20:30:02maaku_:Forth-like language such as Joy have an AST as well
20:30:21sipa:anyway, i like the idea of these types of script to essentially be an expression
20:30:32jtimon: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:50sipa:it has a natural merkleization
20:31:09sipa:is trivial to analyse wrt to execution time
20:31:20maaku_:sipa: http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html
20:31:26maaku_:and http://www.kevinalbrecht.com/code/joy-mirror/j01tut.html
20:31:31maaku_:probably the best introducitons
20:32:18jtimon: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:33maaku_:with a Merklized Joy, you'd consider quotations to be a branch of the AST
20:32:55maaku_:so, for example, an if statement is: pred [true-branch] [false-branch] if
20:32:57sipa:what advantage does joy/... have?
20:33:14maaku_:you can separately merklize the true and false branches
20:33:50jtimon: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:56maaku_:sipa: implementation and type analysis is very simple (unless you f' up the language design)
20:34:38sipa:i don't understand what's ugly about it
20:34:42sipa:it's just an expression
20:34:43jtimon:oh, and then the strong typing thing, but that's cat, no?
20:34:59sipa:it's pretty much the most natural way of writing *simply* conditions i can think of
20:36:30sipa:but maybe we need to actually try to write some actual things in these sorts of languages first
20:38:33sipa:i guess my usage of the word 'AST' is also a bit confusing, as that's just an compiler step
20:39:17maaku_:sipa: you won't find an argument about concatenative languages being better than lambda abstraction or vice versa, because they are equivalent
20:39:38sipa:i'm *certainly* not planning to introduce lambdas
20:40:19sipa: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:22maaku_: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:40sipa:evaluating an expression tree is surely even simpler
20:40:47maaku_:sipa: a concatenative language like Joy has the power of lambda abstraction without those added complexities
20:41:11sipa:maybe i should just write a toy implementation...
20:41:37jcrubino:jcrubino has left #bitcoin-wizards
20:44:28sipa:maaku_: heh, i guess i didn't realize this before
20:44:37sipa:i presume joy is turing complete?
20:45:10sipa:with some recursion primitives, i'm sure it is
20:45:59maaku_:yes
20:46:09sipa:right, i'm not aiming for that
20:47:13sipa: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:24sipa:but i'm unconvinced about the need for that
20:49:25maaku_:well need is a word that carries baggage
20:50:05maaku_: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:21sipa:right, sure
20:50:28maaku_:but "need" encompasses so many tradeoffs I'm not comfortable making yet :)
20:50:29sipa:i'm just talking about a bitcoin script 2
20:50:40sipa:not about anything more ambitious than that
20:53:40andytoshi:maaku_: nice links. i just clued in that 'postfix' the language is named for 'postfix' the notation :P
20:59:11jtimon:I thought joy hadn't recursion because didn't need it
21:00:16sipa:well, the wikipedia article on it has an example with a 'binrec' primitive
21:01:19jtimon: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:16jtimon:I'll keep reading the links, hopefully I'll have a clearer idea after that
21:02:45maaku_:jtimon: it doesn't have recursion in the traditional sense, but it has the equivalent of an 'eval' opcode
21:02:56maaku_:and since code is data, that's enough to build whatever you need
21:03:34maaku_:combinators (like binrec) are just a variety of built-in variants of this idea
21:04:45jtimon:I don't really have a strong opinion on joy vs ast really
21:06:11sipa:i *really* dislike code==data
21:06:15jtimon: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:17sipa:it makes analysis horrible
21:07:31killerstorm:are you discussing new awesome cryptocurrency?
21:07:36jtimon:yeah, I would definitely ask the concatenative guys what they think about using an AST directly and then compile from other language
21:08:16jtimon:killerstorm: new awesome scripting language that among other things, could be used for native colored coins
21:08:39sipa:that requires an OP_EVAL like sturcture :S
21:09:15sipa:which means you cannot possibly analyse without executing...
21:09:15killerstorm:native colored coins can be implemented using OP_CHECKCOLORVERIFY (https://bitcointalk.org/index.php?topic=253385.0)
21:09:27killerstorm:I mean the basic kind.
21:09:37jtimon:although some people don't like the idea of covenants in the hostcoin
21:09:44jtimon:killerstorm, yes, but that's 1 op = 1 use case
21:10:16jtimon:thi, being more generic, would allow many other things
21:11:04jtimon:within freimarkets for example it would allow you to always be able to buy your p2p interest-bearing debt back
21:11:19killerstorm:I'm afraid that implementing anything non-trivial via scripts will result in a huge bloat
21:11:36jtimon:http://0bin.net/paste/kMkgAK+zO2+mTK0E#Lua4/1g5fGVyv44fpRkftnd37RetgnrDrItXAp9FyvA=
21:11:53jtimon:I still think tagged CCs are better
21:12:13maaku_:[13:06:14] it makes analysis horrible
21:12:20maaku_:not with a strong type system
21:12:52maaku_:killerstorm: yeah sortof, a scripting extension/replacement that will probably make it into freimarkets
21:12:52jtimon:I don't even think interest/demurrage bearing assets are possible with them
21:12:54andytoshi:* andytoshi waits as "rustcoin" stops being funny and starts being considered..
21:12:54jtimon:/with/without
21:13:05amiller:wtf is the point of opcheckcolorverify? the color checking operation is massive/exponential/bad
21:13:50sipa:maaku_: well, then code isn't data :)
21:14:03sipa:maaku_: as the type system can determine in advance what is executable
21:14:04maaku_:sipa: not sure i follow
21:14:12killerstorm:amiller: The idea is to add color tags to utxo db. then it is trivia.
21:14:58sipa: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:03maaku_:jtimon: the "common AST" *is* a concatenative language. there's a reason the JVM and .NET intermediate languages are concatenative...
21:15:13maaku_:everything compiles down to that
21:15:26sipa:JVM bytecode language is certainly not an AST
21:15:36amiller:killerstorm, a lot of effort goes into keeping the utxo as small as possible, how do you quantify what change that incurs?
21:15:44maaku_:yes, it's a stack-based language
21:15:45sipa:it's an imperative stack-based language, afaik
21:15:52maaku_:exactly
21:16:33sipa:i need to stop using the word AST, as it's much wider than what i mean
21:16:36jtimon:amillar the point is making CCs SPV-friendly
21:17:01maaku_:killerstorm: the scripts are in the scriptSigs, so they're immediately pruned
21:17:35amiller: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:04jtimon:amiller I advocate for explicit colors
21:19:00amiller: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:53jtimon:if nobody has to store the full utxo, utxo bloating is not that much of a problem
21:20:00maaku_:amiller: this doesn't result in any utxo bloat...
21:20:26amiller:do coins have at most 1 color or something?
21:20:34maaku_:scripts are in the txin, not out
21:20:36killerstorm:amiller: color tag is just a hash of genesis transaction or something like that. ~32 bytes per UTXO won't hurt.
21:20:49maaku_:amiller: yes
21:21:36amiller:ok that sounds pretty nice.
21:21:59amiller: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:03killerstorm:jtimon: there is no difference between OP_CHECKCOLORVERIFY and explicit colors. OP_CHECKCOLORVERIFY can be in scriptSig.
21:22:06amiller:i'd be really interested to see that
21:22:09jtimon: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:09killerstorm:jtimon: I mean I'm not aware of any practical difference.
21:22:12amiller:that sounds pretty great to me
21:22:30amiller:how about a reference impl that deviates minimally from satoshi client?
21:24:09maaku_:amiller: what scheme are you talking about?
21:24:10killerstorm: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:34killerstorm:I've outlined the spec although I'm not sure about some decisions.
21:25:28jtimon:saposhi nasakyoto I think (I can't believe ixcoin is alive, and there's still people who say MM kills altcoins...)
21:29:58jtimon:but yeah, why not use it to experiment
21:30:27jtimon:is already MM, it's in a great position to be used for this things
21:31:42killerstorm:It got new life: new PR/marketing team :)
21:32:01killerstorm:MM means that it is 100% controlled by ghash.io
21:32:18jtimon:killerstorm, how do you implement per-asset interest/demurrage with OP_CHECKCOLOR ?
21:32:34jtimon:only ghash.io merge-mines it?
21:33:32killerstorm: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:51petertodd:killerstorm: +1 wish people realized that earlier
21:39:24warren:http://en.wikipedia.org/wiki/Savitch's_theorem
21:39:54warren:(for those thinking of memory hard to hash but easy to validate PoW, would this theoretical limit apply?)
21:42:30petertodd:I'm not seeing the connection
21:49:35jtimon:I don't see why memory hard is better
21:50:30warren:I didn't say it was.
21:50:36warren:people were discussing it here in past months
21:50:57petertodd: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:13petertodd:jtimon: however, practical memory hard that really is ASIC-hard appears to be a very difficult problem
21:51:51petertodd:jtimon: reasonably easy to do in cases where the work to be done in non-parallizable, but crypto-consensus systems must be parallelizable
22:01:42jtimon:I don't see why ASICs are worse
22:05:49warren:IMHO, mining pool centralization is the real problem, not ASIC's.
22:07:13jtimon:warren, agreed, and I thought that was solved with trustless pools (p2pool, eligious...)
22:07:55petertodd:jtimon: ASICs centralize control in the hands of a very small number of chip fabs
22:08:25maaku_:petertodd: meh, coordinated quality control could mitigate that
22:08:27petertodd:jtimon: and p2pool and getblocktemplate don't "solve" the problem because there's no incentive to use either
22:08:30petertodd:maaku_: huh?
22:08:57maaku_:petertodd: a scanning electron microscope is not hard to get access to
22:09:22petertodd: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:23maaku_:there should be efforts to take asic chips at random from batches and do SEM scans of their circuits
22:09:44maaku_:then anyone with tools can verify that they are not backdoored
22:09:55petertodd: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:25jtimon:can't the operator of a centralized pool cheat you somehow?
22:10:41maaku_:jtimon: out of your shares, yes
22:10:54jtimon:or decide for you what transactions to, say censor?
22:11:02petertodd: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:29maaku_:jtimon: using GBT you can choose your own transactions
22:11:31petertodd: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:51petertodd:maaku_: in theory, in practice pools don't allow that - very high bandwidth cost
22:12:04maaku_:well, eligius does
22:12:05jtimon:maybe centralized operators aren't being as malevolent as they "should"
22:12:20petertodd:maaku_: yes, and eligius is being operated by alturistic people
22:12:50petertodd:jtimon: who cares? what matters is that our security isn't as good if we have to rely on that
22:13:07maaku_:meh, i would say that eligius is operated by knowlegable people/person
22:13:08sipa:it's my theory that if every actor started out as malevolent/selfish/rational, bitcoin would never have worked
22:13:25sipa:it's an experiment in building a system that doesn't need trust in many actors
22:13:32maaku_:as bitcoin matures i expect more pools to act like Luke-Jr
22:13:39sipa:but we'll need to get there step by step
22:13:59jtimon:sipa you're probably right, the start was incredible difficult
22:14:07maaku_:or maybe the causality is reversed - bitcoin will never mature unless more pools act like Eligius does
22:14:18maaku_:either way once it happens, it happens
22:14:31jtimon:I mean, I wasn't around, but...it's surely the hardest part
22:15:46petertodd:sipa: yes, we got incredibly lucky there
22:16:32petertodd:fact of the matter is that relying on alturism is dangerous and subject to sudden changes
22:16:57petertodd:never mind the fact that what were were talking about, ASIC-hardness, has nothing to do with alturism
22:17:04sipa:yup, but removing much it suddenly is equally dangerous
22:17:17petertodd:sipa: what do you mean by "removing" it?
22:17:39petertodd:sipa: no-one is proposing removing anything
22:17:47sipa:oh, i'm not saying that
22:18:04sipa:but if suddenly many people/miners/whatever started acting selfishly, i'm sure it could hurt bitcoin's survival chances
22:18:22sipa:+suddenly
22:18:29petertodd:oh sure, but the fact that it would hurt just shows that bitcoin is poorly designed
22:18:50sipa:i'd say it just isn't evolved enough :)
22:19:15petertodd:heh, equally true statement
22:19:28petertodd:though the ugly thing is changing the design is probably an economic change so...
22:20:40petertodd: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:55jtimon: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:17petertodd:jtimon: what do you mean by trustless mine?
22:21:31jtimon:p2pool, eligious
22:21:33sipa:p2pool/gbt?
22:21:39jtimon:yes
22:21:51petertodd: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:12petertodd:jtimon: my point with trustless mining is that it *costs more* than just pointing your hashing power at ghash.io
22:22:48jtimon:my point now is to apply your same "for the future of the coin" reasoning for miners to use p2pool/gbt
22:22:57petertodd: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:33petertodd:jtimon: that's a very bad comparison - you're comparing the behavior of a large pool to a small hasher
22:24:44jtimon:a large pool is composed of small hashers
22:25:05jtimon:if anything, they should be more stupid in groups, no?
22:25:28petertodd:not at all, think in terms of incentives to defect and do what's better for you, but worse for the group
22:25:44petertodd:IE, I earn more money for less work if I hash at ghash.io
22:26:06petertodd: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:15petertodd:(especially relevant in my advice to mastercoin you know...)
22:26:23jtimon:IE, I earn more money for less work if I MM instead of attacking a "competing" coin
22:26:45petertodd:oh piss off, scale makes the incentives very different
22:26:57sipa:merge mining a tiny currency doesn't gain you anything significant
22:27:04jtimon:your advice to mastercoin was to use your proof of sacrifice design draft?
22:27:40jrmithdobbs:jtimon: you're failing to control for internet assholes
22:27:40jtimon:sipa how much you lose by gbt vs ghash.io ?
22:27:53jrmithdobbs:"Some men just like to watch the world burn."
22:28:08petertodd: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:31jtimon:jrmithdobbs I don't follow
22:28:46petertodd: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:59petertodd:(this is why MSC adopted an encoding scheme where the data looks like valid pubkeys)
22:29:06jrmithdobbs: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:07sipa:bah
22:29:29petertodd:sipa: heh, I think lots of people didn't realize that was so easy...
22:29:39sipa:petertodd: this is a nice example of what i'd call suddenly changing how selfish a particular party acts
22:29:56petertodd:sipa: indeed, and BTC better realize how easy what MSC did is
22:29:57jtimon: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:07jtimon:that's my point, how is difffernt?
22:30:10petertodd:sipa: basing scalability assumptions, esp re: the UTXO set, on "oh, people will play nice" is idiotic
22:30:15Luke-Jr:hmm, I wonder if deploying P2SH^2 might not be as hard as we think
22:30:25petertodd:Luke-Jr: MSC is P2SH^2 proof
22:30:34Luke-Jr:petertodd: I mean real bitcoin
22:30:34jrmithdobbs:petertodd: i think sd proved that already.
22:30:43petertodd:Luke-Jr: "real bitcoin"?
22:31:12petertodd: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:16Luke-Jr:petertodd: I'm not sure what MSC came up for, I'm talking about Bitcoin itself
22:31:18petertodd:jrmithdobbs: no, they stopped
22:31:26Luke-Jr:petertodd: why do I care about that?
22:31:31jtimon:petertodd: I see your point, MM is less secure than MSC, true, but it's also more scalable
22:31:38jrmithdobbs:petertodd: like a year later
22:31:39petertodd:Luke-Jr: oh, I'm assuming you meant P2SH^2 to stop MSC
22:31:41sipa:Luke-Jr: MSC is putting data in bitcoin's chain...
22:31:52Luke-Jr:petertodd: no, P2SH is to stop data spam
22:31:54Luke-Jr:^2*
22:31:57Luke-Jr:sipa: ⁈
22:32:13petertodd: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:29Luke-Jr:petertodd: you can
22:32:33petertodd:Luke-Jr: you can't stop schemes that encode hashes in the UTXO set, and there's lots of usees for that
22:32:40Luke-Jr:scriptSig can require preimages or valid ECDSA sigs too
22:32:56Luke-Jr:petertodd: not really, no
22:32:57petertodd:Luke-Jr: read this: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03524.html
22:33:10petertodd:Luke-Jr: without some pretty drastic changes to the way scripts work you can't
22:33:11sipa:Luke-Jr: then the preimage would be in the blockchain
22:33:36Luke-Jr:sipa: not necessarily
22:33:37petertodd: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:51sipa:Luke-Jr: that would prevent you from validating it afterwards
22:34:03Luke-Jr:I'm assuming the P2SH^2 enforcement is done by miners only
22:34:07petertodd:Luke-Jr: and timestamp/proof-of-publication spam is really handy to a lot of protocols, and bloats the UTXO set even
22:34:18Luke-Jr:and tx relay
22:34:22sipa:Luke-Jr: then it only requires an out-of-chain deal with a miner to put it in anyway
22:34:31Luke-Jr:petertodd: there is no need to bloat the UTXO set
22:34:33petertodd: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:01petertodd: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:17jtimon:what's P2SH^2 please?
22:35:22jtimon:link?
22:35:29Luke-Jr:petertodd: *technically* yes
22:35:47Luke-Jr:jtimon: miners only mining stuff that is proven to be a hash
22:35:54petertodd:jtimon: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01987.html
22:35:57sipa:jtimon: have P2SH-only in the txouts, but to relay a transaction, you must add SHA256(script) to it
22:36:10petertodd:Luke-Jr: yes, and getting a hash into the UTXO set is enough to implement namecoin
22:36:17sipa:jtimon: so you prove that the data in the P2SH output is a real hash of something, and not data
22:36:54Luke-Jr:petertodd: it makes it more expensive
22:37:16petertodd:Luke-Jr: namecoin is already expensive, irrelevant
22:37:36Luke-Jr:the point is to make blockchain bloat more expensive than merged mining
22:37:41petertodd: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:53petertodd:Luke-Jr: that's irrelevant, merge-mining is less secure
22:38:25Luke-Jr:only if you're scamcoining.
22:38:41sipa:i'm not sure what intent has to do with it
22:38:49petertodd:Luke-Jr: sure, which is why I told Mastercoin to stick with the current system!
22:39:21petertodd: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:38Luke-Jr:sipa: if you're just interested in the security, you can do merged mining in a secure way
22:40:36Luke-Jr: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:19petertodd:Luke-Jr: that's not at all true and stop saying that
22:41:38sipa: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:47petertodd: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:53killerstorm: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:54maaku_:petertodd: it's disengenous to say that merged mining is insercure too
22:42:05Luke-Jr:petertodd: only if the attacker 51%s bitcoin as well
22:42:09petertodd:sipa: nothing explicitly of course
22:42:34maaku_:bitcoin-parasitic vs merged mined alt? of course the parasitic option is better
22:42:52petertodd: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:54maaku_:merged mined alt vs non-merged mined alt? that's a different story
22:43:14Luke-Jr:petertodd: no, you may have 51% of blocks, but you cannot reorg it
22:43:22maaku_:killerstorm: depends on the context. colluding to do what?
22:43:28Luke-Jr:petertodd: you'd need to have 51% of *bitcoin* blocks and reorg bitcoin, to reorg the altcoin
22:43:38sipa:short-term-selfish miners will always collude if they can
22:43:53petertodd: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:54maaku_:but in many cases yes, 51% is sufficient to censor the chain, for example
22:44:08Luke-Jr:petertodd: you'd need a longer *bitcoin* chain
22:44:08petertodd:Luke-Jr: mining a block doesn't magically make it available to the world
22:44:12sipa:as it means their 51% becomes 100%
22:44:49petertodd: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:59petertodd:Luke-Jr: was 2a or 2b the valid best block?
22:45:05Luke-Jr:petertodd: altcoin does not have a prevblock header.
22:45:15Luke-Jr:it is ALWAYS tied to the bitcoin chain
22:45:34petertodd:Luke-Jr: yes it does, the prevblock header just happens to skip a few steps
22:45:52Luke-Jr:your scenario is not possible
22:46:11Luke-Jr:if bitcoin block 11 mines alt block 2, then bitcoin block 12 must mine alt block 3
22:46:13petertodd: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:29petertodd:Luke-Jr: remember, this is a merge-mine chain: participation is voluntary
22:47:10sipa:i wasn't aware of the fact that merged-mined chains had no own prevhash
22:47:22sipa:but it seems to make sense
22:47:23Luke-Jr:sipa: the existing ones do, but that's not the system I was talking about
22:47:29Luke-Jr:petertodd: ok, I remember this now.
22:47:33petertodd:sipa: luke's very mistaken...
22:47:39Luke-Jr:petertodd: I forget if I found a solution to that issue or not
22:47:42maaku_:sipa: they do, i think Luke-Jr is describing something novel/different
22:47:47sipa:ok
22:48:30sipa:i'm not sure what the problem is with it that petertodd is describing
22:48:39petertodd: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:51petertodd:Luke-Jr: tl;dr: I'm way ahead of you :P
22:50:03petertodd: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:25petertodd:sipa: OTOH if you're system doesn't have that vulnerability, it's still longest chain wins and your 51% attack vulnerable
22:50:30Luke-Jr:.. unless we softfork bitcoin
22:50:39petertodd:Luke-Jr: sure, but then it's not a merge-mined chian anymore
22:50:45Luke-Jr:petertodd: sure it is
22:50:58petertodd:Luke-Jr: No, you've just made the blocks bigger with a fancy hash commitment.
22:51:09Luke-Jr:bitcoin miners can enforce disclosure of the merged data to some degree
22:51:12petertodd:Luke-Jr: the whole point of merge-mining is that it's *voluntary*
22:51:28Luke-Jr:petertodd: hence the degree limit
22:51:33petertodd:Luke-Jr: yes, and if disclosure is enforced you've just made the blocks bigger and contain extra data
22:51:58sipa:yup, i see the problem
22:52:01Luke-Jr:only bigger for miners
22:52:17petertodd:Luke-Jr: so what? that's the problem we keep trying to solve
22:52:26killerstorm: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:53:12sipa: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:43petertodd:killerstorm: yeah, and the results are ugly, don't accept 1 conf payments for $1million and do irreversable things based on them
22:54:09petertodd:killerstorm: notably it's why tx fees being the only thing paying miners leads to really ugly consequences
22:54:16jtimon:killerstorm exactly, the bigger the transaction the more you have to wait, it's not 6 blocks
22:54:49sipa:the 6 blocks number is based on statistics that assumed a much less centralizing mining landscape in any case
22:54:55petertodd: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:12petertodd:dunno if that project ever went anywhere, but it's an important one
22:55:37killerstorm:I'm afraid it's much worse than you think...
22:56:09Luke-Jr:personally, I don't think merchants want to have to read a paper..
22:56:12petertodd:killerstorm: lots of people forget an attacker might be ripping off multiple people at once for instance
22:56:34petertodd: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:58petertodd: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:16Luke-Jr: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:35petertodd:Luke-Jr: yeah, well, MM isn't necessarily that innovation
22:58:47adam3us:Luke-Jr: that seems like an interesting idea. (merge mine where the bitcoin blocks are valid alt-chain blocks)
22:58:51Luke-Jr:present-day MM style does that just fine, really. the 51% risks aren't really a real concern.
22:59:02petertodd:Luke-Jr: you realize that one of the reasons mastercoin hired me was because they realized they needed someone to study that
22:59:03Luke-Jr:petertodd: MM is what is needed to *enable* that innovation
22:59:15petertodd:Luke-Jr: again, MM fails in a hell of a lot of scenarios
22:59:37adam3us:Luke-Jr: I agree
22:59:49adam3us:petertodd: so lets see if we can improve it
23:00:06petertodd:adam3us: heh, what do you think I'm working on?
23:00:31adam3us:petertodd: judging from the above stego encoding msc into btc? :P
23:00:32killerstorm: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:35killerstorm: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:43killerstorm:Note that X is not used in equation: it can be very low. Like 1 BTC.
23:00:44petertodd: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:58adam3us:petertodd: fair enuf.
23:01:13killerstorm:You can get 25 BTC of a normal reward, or 25.1 BTC of reward + bribe, what do you do?
23:01:20petertodd:adam3us: and remember, knowing that stego encoding is useful, and damn near impossible to stop, is very valuable knowledge for bitcoin too
23:01:28adam3us: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:32killerstorm:All super-rational miners will decide to take bribe. So one only needs, say, 0.6 BTC to buy them all.
23:02:30maaku_:adam3us: I don't think you can call pegging "secure" until you get rid of the SPV trust
23:02:31killerstorm: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:35killerstorm:What am I missing
23:02:48maaku_:and incidentally, i have an ignore bit to the topic until that is done :P
23:03:11petertodd: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:38petertodd: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:45adam3us:petertodd: yeah i already figured out the stego and kept it to myself :)
23:04:00petertodd:adam3us: heh, did you figure out the timelock crypto version of it?
23:04:36petertodd: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:48jtimon: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:01killerstorm: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:07petertodd:jtimon: which is why my job there is more aimed at making *bitcoin* scale
23:05:36killerstorm: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:43petertodd: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:48adam3us: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:19petertodd:adam3us: publishing the key doesn't guarantee consensus though - the idea being the timelock crypto is to be able to guarantee that
23:06:42petertodd: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:02jtimon:ok, then I guess I would just ask you to encourge parasitism over altcoinism more openly, not just over MM
23:07:10killerstorm: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:21petertodd: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:41jtimon:as always, my claim is that MM is better than independent mining
23:07:48adam3us: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:21petertodd: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:03petertodd: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:25adam3us: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:39jtimon:and I don't think "MM is better than independent mining" is the message that people perceive from bitcoin devs
23:10:05petertodd:adam3us: meh, if you were right then peopel would never pollute, but they do
23:10:11andytoshi: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:31petertodd:adam3us: remember, we've got anonymous systems here where social pressure doesn't work very well
23:10:32jtimon: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:38andytoshi:capped total fees per block*
23:11:49petertodd:jtimon: depends on what bitcoin devs your talking about - gavin regularly writes about how alts are stupid and harmful
23:11:51jtimon:andytoshi what for?
23:12:32jtimon:petertodd: I know there's not one voice
23:12:49adam3us: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:53andytoshi:jtimon: to change the miner incentives to accept crap in exchange for high fees
23:13:16adam3us:petertodd: yes but it hasnt failed yet.
23:13:35petertodd:bbl
23:14:00andytoshi: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:14andytoshi:(this is a far future problem for bitcoin ofc since fees are not even 0.05%)
23:14:51jtimon:0.05% of total reward to miner?
23:14:53adam3us:killerstorm: your super-rational miner strategy seems plausible
23:15:19andytoshi:jtimon: yeah. (am i wrong?)
23:15:49jtimon:andytoshi I don't know I'm not sure I understand
23:16:13jtimon:if you hash more than 0.05 in fees in a block you only get 0.05 in fees
23:16:35jtimon:but 0.5 will be less and less as inflation increases
23:16:35andytoshi:jtimon: that's right, and any other fees that transactions had included would simply get burnt
23:16:48adam3us:petertodd: you realize he just made the $25k per block fraud shrink a lot?
23:16:51andytoshi:jtimon: right, as will 1.0 (the block reward)
23:16:57jtimon:I think the reward will be eventually too small
23:17:22jtimon:1.05 will eventually be 0.0000000000000001% of the total supply
23:17:38andytoshi:jtimon: no, currency loss will stop it getting that far i'm sure
23:17:51andytoshi:but i haven't done any detailed analysis to think about how far it will get
23:18:10andytoshi:maybe it will go too low and kill security, i don't know
23:18:34jtimon:oh, I guess you're right, is there any analysis on currency lost? how you do that?
23:19:19andytoshi: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:36adam3us: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:42andytoshi:so perhaps you can import the physical numbers as "percent carelessness" and get a swag
23:20:24adam3us:maaku_: e) 100 block confirmation on spv liquidity transfer on merge mine is still quite secure
23:21:13jtimon:adam3us how is any pegging scheme more secure than non-pegged MM ?
23:21:26andytoshi: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:31adam3us:jtimon: its not
23:21:35andytoshi:no matter how much magic crypto (eg OWAS) you throw at it
23:22:15andytoshi:but otoh with demurrage, measuring the velocity (which is easy) would give you an estimate of supply
23:22:19jtimon:adam3us and how pegging encourages or facilitates innovation?
23:23:13adam3us: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:55adam3us: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:47adam3us: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:11jtimon:I don't quite understand this part "people who are attached to doing things with btc scarcity rather than new scarcity"
23:25:31jtimon:the second sentence seems to apply for both pegged and non-pegged MM
23:26:46adam3us: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:43warren:adam3us: how bad is the TMTO?
23:27:48adam3us:jtimon: i quite like btc scarcity, virtual gold property, capped supply, the supply curve, human policy inflation proof etc.
23:28:11jtimon: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:39jtimon:btc is still scarce no matter how many altcoins you create
23:28:50jtimon:21 M at most
23:28:52adam3us: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:23maaku_: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:38maaku_:it's a non-starter as far as I'm concerned
23:29:41petertodd:adam3us: how did I make what shrink?
23:29:52adam3us:petertodd: what?
23:30:50adam3us: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:13petertodd: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:39petertodd:adam3us: < adam3us> petertodd: you realize he just made the $25k per block fraud shrink a lot?
23:32:09adam3us: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:28petertodd: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:33:15petertodd:adam3us: ah
23:33:25adam3us: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:28petertodd:adam3us: yeah, the low memory verify aspect is pretty neat, same with cuckhoo hashes
23:33:51sipa:cuckoo...
23:34:05petertodd:adam3us: right, and I'm saying that game theoretic makes too many assumptions about what information each miner knows each miner knows
23:34:18petertodd:sipa: rarely do you correct my engrish :P
23:34:41maaku_:adam3us: ok /print/steal/
23:35:09maaku_:i really don't think pegging adds much at all
23:35:25petertodd: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:36maaku_:most of the interesting alt applications ahve to do with issuing new assets
23:35:48adam3us: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:48petertodd:adam3us: timelock crypto could be one such example
23:36:28petertodd:maaku_: those new assets are more useful though if you can make contracts exchanging them for bitcoins
23:36:53jtimon:maaku_ apparently it solves a philoshophical problem related to non-scarce scarcity...
23:37:07maaku_:mmm marginally more useful
23:37:15jtimon:adam3us what's wrong with zerocoin not being pegged to btc ?
23:37:17maaku_:not everyone is convinced bitcoin has the right economics to play that role
23:37:22adam3us: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:21jtimon:+ 1 for MM zerocash, I don'
23:38:33jtimon:t see how non-peggin is a net loss
23:39:37jtimon:I hope they MM, maybe they prefer to be "anti-specialized-hardware"
23:39:39adam3us: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:44jtimon: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:48adam3us: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:36jtimon:so this is all about bitcoin winning the race? that sounds greedy...
23:41:41adam3us: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:56jtimon:what if zerocoin wins, what would the world lose ?
23:42:02jtimon:a nice logo?
23:42:04adam3us:jtimon: hey i missed the first 4yrs 3mo of the race, i'mnot the winner here
23:42:15petertodd: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:35maaku_:adam3us: we are still way, way early in the adoption curve
23:43:57maaku_:most institutional support for bitcoin is using it as a payment network, not for wealth storage
23:43:58adam3us: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:22killerstorm: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:45maaku_:adam3us: if that happened, who would be hurt? people sitting on bitcoins, but not the institutional players
23:44:57maaku_:they make their money (counted in fiat) on activity not market caps
23:45:01adam3us:maaku_: humanity because digital scarcity is a useful thing
23:45:05petertodd:killerstorm: right, but we *can't* assume miners think identically, and neither can those miners
23:45:11jtimon:adam3us this is not logic: if litecoin gets greater than bitcoin, feathercoin will get greater then litecoin
23:45:20justanotheruser: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:21killerstorm: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:24maaku_:meh i don't think that makes sense as an economic argument
23:45:28jtimon:and the two propositions are very unlikely independently
23:45:33adam3us:jtimon: point is it sets a precedent
23:45:50petertodd: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:00jtimon:I think that's likely to happen, but with something better than bitcoin, not litecoin
23:46:12jtimon:bitcoin 2.0 if you like
23:46:22jtimon:and I don't have any problem with that
23:46:26petertodd:justanotheruser: bootstrapping your mediator trust is a damn nightmight
23:46:29petertodd:*nightmare
23:46:34maaku_:adam3us: your argument hinges on the thing overtaking bitcoin being "just another" coin
23:46:42maaku_:i see no rational basis for that ever happening
23:46:46adam3us:petertodd: exodus eh? did u see there was one proposed recently a new alt, like mastercoin except by proof of burn?
23:47:06maaku_:but if something came out genuinely better, the story would be different
23:47:16petertodd:adam3us: yup, last I checked they got like 500 coins
23:48:16adam3us: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:19justanotheruser:petertodd: Any solutions for bootstrapping mediator trust?
23:48:35petertodd:justanotheruser: solve that and you're halfway to making a crypto-currency...
23:48:40adam3us:petertodd: holy moly 500 btc !
23:48:49petertodd:adam3us: probably even more now :/
23:48:56petertodd:adam3us: not much source-code to it either...
23:49:31justanotheruser:petertodd: couldn't you bootstrap your mediator trust by making non-mediator transactions successfully?
23:50:07jtimon:adam3us so since markets are irrational, it is more rational to peg them?
23:50:08adam3us: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:22petertodd:justanotheruser: define "successfully", and for that matter, how are you going to prove they were successful in a mathematical way?
23:50:56adam3us:petertodd: counterparty that was what it was called (the msc-like meta coin with PoB)
23:51:14justanotheruser: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:16maaku_: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:27petertodd:justanotheruser: where's the root of trust?
23:51:32petertodd:adam3us: yeah, counterparty
23:51:57justanotheruser:petertodd: you are the root of trust for yourself
23:52:23adam3us: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:22petertodd:adam3us: https://blockchain.info/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- 1,165 BTC now
23:53:29adam3us: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:38petertodd:adam3us: that's actually more than msc got in dollar value
23:53:40maaku_: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:41adam3us:petertodd: amazing.
23:53:46adam3us:petertodd: i know!
23:54:13maaku_:wait, did people just irrecovably destroy $1MM of coins?
23:54:17petertodd:adam3us: gonan be a lot of disappointed people I suspect...
23:54:21petertodd:maaku_: yup
23:54:22adam3us:maaku_: yes
23:54:23maaku_:w. t. f.
23:54:35justanotheruser:I wish people would use OP_RETURN
23:54:52petertodd:maaku_: based on a few hundred lines of code and a shoddy specification...
23:54:55justanotheruser:seems like it is from "XPC Proof of Burn"
23:55:08adam3us:maaku_: well from their perspective its still a comparable investment as msc they are investing in the future potential of the idea
23:55:26adam3us:maaku_: the only difference being xcp has now no btc to fund development
23:55:28petertodd: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:30maaku_:and yet we've been able to find just 3 people to donate <$1000 to freimarkets :\
23:56:05jrmithdobbs:i don't even want to think about how much the coins i sold at various points would be worth right now
23:56:07adam3us:maaku_: its a sad fact that scammy/grandiose advertising works seemingly in crypto currency space.
23:56:12justanotheruser:petertodd: how were they burnt to an address? No public key can spend them can they?
23:56:59petertodd:justanotheruser: it's a vanity address with like 12 X's in it... rather unlikely they have the sec key
23:57:02adam3us:petertodd: i thought at one point they burnt them to miner until someone pointed out a miner could mint unlimited coins
23:57:10petertodd:adam3us: ha, I know eh
23:57:35petertodd: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:40justanotheruser:petertodd: OP_RETURN?
23:58:14petertodd:justanotheruser: https://blockchain.info/tx/685623401c3f5e9d2eaaf0657a50454e56a270ee7630d409e98d3bc257560098
23:58:44justanotheruser:petertodd: oh, multiple outputs
23:58:57petertodd:justanotheruser: yup
23:59:21justanotheruser:what is the usual reason for their proof of burn?
23:59:35petertodd:justanotheruser: what do you mean?