09:05:18hobana.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:18hobana.freenode.net:Users on #bitcoin-wizards: andy-logbot Guyver2 Dr-G3 moa weex_ hktud0 CodeShark SDCDev prodatalab grandmaster justanotheruser RoboTedd_ jaekwon_ HaltingState TheSeven Emcy_ epscy damethos nanotube d1ggy_ dgenr8 gavinandresen dc17523be3 koeppelmann cryptowest rusty melvster hashtag DougieBot5000 fanquake p15_ tromp zooko cluckj Starduster bramc go1111111 flower_ shesek binaryatrocity waxwing spinza MoALTz andytoshi hashtag_ antgreen bliljerk101 pukie amincd luktgf
09:05:18hobana.freenode.net:Users on #bitcoin-wizards: embicoin GAit luny tromp__ wizkid057 starsoccer xabbix comboy nsh Taek PRab arubi adlai iddo EasyAt maaku LarsLarsen Logicwax Quanttek Pan0ram1x c0rw1n helo null_radix bosma PaulCapestany sipa btcdrak NikolaiToryzin huseby s1w bepo nuke1989 Visheate crescendo livegnik asoltys_ optimator gribble fluffypony Meeh cursive yoleaux dansmith_btc ebfull [d__d] berndj Luke-Jr morcos nickler jgarzik Fistful_of_Coins dardasaba sl01 isis gwillen
09:05:19hobana.freenode.net:Users on #bitcoin-wizards: stonecoldpat BlueMatt face airbreather delll_ dasource espes__ GreenIsMyPepper bedeho smooth phantomcircuit ajweiss sdaftuar coryfields Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo forrestv Muis cfields platinuum sneak Oizopower BananaLotus Keefe catlasshrugged JonTitor petertodd kanzure eric mappum jbenet wiz grubles midnightmagic heath gnusha warren gmaxwell Adrian_G Iriez lechuga_ dignork kinlo jessepollak ahmed_
09:05:19hobana.freenode.net:Users on #bitcoin-wizards: Graet ryan-c Eliel veox amiller warptangent indolering K1773R TD-Linux leakypat CryptOprah Apocalyptic guruvan Anduck paperbot fenn harrow a5m0 SubCreative d9b4bef9 DoctorBTC mr_burdell NeatBasis Hunger- davout Alanius brand0 @ChanServ throughnothing btc___ HM2 azariah MRL-Relay otoburb hguux__ so phedny roasbeef BrainOverfl0w wumpus jcorgan jaromil bbrittain
13:15:40jdvs:it's difficult for me to determine if omnicoin is based on the bitcoin blockchain or another blockchain, does anyone know the answer to this?
13:17:12fluffypony:jdvs: it's forked from Bitcoin, so undoubtedly yes
13:21:12fluffypony:forked from an old version of Bitcoin too, like 0.8-ish
14:55:56LTD_:LTD_ has left #bitcoin-wizards
16:57:34prodatalab_:prodatalab_ is now known as prodatalab
17:57:01maaku:GreenIsMyPepper: where does SIGHASH_NORMALIZED get the normalized transaction IDs from?
18:06:41bramc:A question I keep meaning to ask: If there are a bunch of utxos all of which can be unlocked with the same key, can they all be accumulated together with a single transaction which has a single signature?
18:08:29zooko`:zooko` is now known as zooko
18:08:58sipa:no, you need a signature per input
18:09:14sipa:in theory it would be possible to allow them to be combined
18:09:22sipa:but it would require a more complex design
18:09:28sipa:and it would encourage key reuse
18:13:45Eliel:yep, not going to happen because of that last part.
18:18:29nsh:sipa, can you sketch the more complex design?
18:23:50maaku:nsh: i'm not sure sipa was referencing an actual design so much as commenting that bitcoin transaction format is not expressive enough to represent 'one signature covering multiple inputs'
18:23:59nsh:right
18:24:20nsh:but you might have a sidechain that is, conceivably?
18:27:34maaku:sure, maybe, but why would you want to?
18:29:57nsh:maaku, good question
18:30:22nsh:i don't presume to be able to guess bramc's thinking
18:30:44nsh:some kind of consolidation / defragmentation maybe
18:32:29bramc:nsh, It's useful for reducing transaction fees by making transactions smaller (at least in the future, when such things are correlated) and yes I'm thinking of it for cleaning up dust, or at least change-making
18:32:58nsh:right
18:33:03bramc:There's no real anonymity lost by sending a bunch of outputs to the same key if they're all going to be consolidated together anyway.
18:33:21nsh:i mooted at some point a kind of sweeper service that's funded from mining subsidies somehow
18:33:26nsh:but it was very woolly thinking
18:34:17bramc:There isn't a very good change-making service out there right now. Cryptoshuffle might be one but I haven't read that paper yet.
18:35:55bramc:I mean, cryptoshuffle might be a proposal for one, I don't believe anyone claims to be running such a service.
18:36:21nsh:* nsh nods
18:37:29bramc:It would be nice if there was a bitcoin wallet which had a 'make change' button which cleaned up the dust and unlinked all the utxos through a centralized service which specialized in that
18:37:46bramc:It's unclear how much demand there might be for such a beast though.
18:40:17bramc:But working on the design of that centralized service would be fun
18:40:53nsh:what would the trust implications be?
18:41:22nsh:(better than using bc.i obviously, but non-zero presumably)
18:42:19bramc:nsh, Not all that much if you use simultaneous transfer properly, a little bit of threat that the centralized service could re-link your unlinked transactions, or if they screw it up could reveal information about your business with them and hence who you are
18:43:22bramc:At one point in this channel we had a discussion about the algorithms for picking which utxos to combine/split when making a payment from a wallet. The upshot was basically 'we do this, but have no coherent intellectual basis for arguing that other algorithms are better or worse'
18:43:40nsh:right
18:45:10bramc:After thinking about it a bunch, my conclusion is that what you really should do is make payments by taking the smallest coin you have bigger than the target and splitting it in two, and move the extra into your dust pile, along with all received transactions, and when the amount of dust gets too much go use the change-making service
18:45:34bramc:There's a potential natural monopoly with the change-making service, because the bigger the pool the better the unlinking
18:47:09nsh:to greater the extent to which the input-choice algorithm is deterministic, the greater the ability to link transactions
18:47:51nsh:if you coupled with lossy mechanisms like coin-join that could be mitigated
18:48:07bramc:Sort of, randomization can open you up to attacks as well, where lots of small transactions are more likely to give away your identity
18:48:14nsh:right, yup
18:48:18nsh:randomness can be just as pernicious
18:48:40nsh:just less intuitively :/
18:48:42bramc:The unlinking service I'm talking about would basically be a massive better version of coin-join
18:49:00nsh:ah right. that's favorable imho
18:49:27nsh:but as i understand it, the complexity of coin-join grows as you scale it up to more users
18:49:34bramc:It seems like a potentially good business, and fun to work on, but I'm busy working on other stuff
18:49:37nsh:* nsh nods
18:51:09bramc:It gets a lot easier if you have a centralized service and trust the centralized service to throw out their data eventually. The idea is that you do a coinswap with the service for all of your utxos, where they give you back somewhat better formed change by consolidating some of the dust they got from other people
18:52:10nsh:right. you can certainly increase the transparency and auditability to some 'trustworthy' threshold (again, certainly compared to e.g. bc.i)
18:52:16nsh:but proving the destruction of information is basically impossible
18:52:31nsh:that's the problem with trusted set-up (common reference string) schemes too
18:52:33bramc:The service needs a certain amount of working capital, and some algorithms for deciding which utxos to consolidate together when. That's the fun part.
18:52:44nsh:* nsh nods
18:52:54bramc:Dumb question: what are you referencing by bc.i?
18:53:11nsh:because lots of people just trust these guys with their wallet keys, as i understand it
18:53:18nsh:and that is really not too warranted from experience
18:53:33nsh:i'm just picking on them because i'm too lazy to think of other examples though
18:53:37nsh:oh, blockchain.info
18:53:38nsh:sorry
18:54:03bramc:Yeah trusting with wallet keys is totally cringeworthy. It calls into question whether you can get customers by doing things like change-making securely
18:54:17nsh:* nsh nods
18:54:38bramc:It could be that any such change-making service would wind up mostly servicing the relatively small number of vendors who are mostly receiving payments rather than sending them
18:54:39nsh:cultivating the right degree and the right kind of paranoia in the general public is a hard problem
18:54:47nsh:* nsh nods
18:55:24bramc:Although that would of course still be a very real business
18:57:01nsh:aye
19:03:12bramc:Making it truly decentralized is an interesting academic challenge but probably vastly less secure than using a centralized service
19:03:33nsh:i'm not sure i follow
19:04:13nsh:centralization generally concentrates the negative consequences of insecurity
19:04:28nsh:in exchange for lower complexity or better synchronicity
19:06:07bramc:If you try to make a truly decentralized change-making service, there are a lot more potential attacks where the participants mess with whoever they happen to be interacting with
19:09:23nsh:ah, i see
19:09:58nsh:yeah i guess you have more leeway to leverage human psychology/error in a decentralized solution that involves cluefulness
19:11:26bramc:It isn't just psychology. There are potential connection flooding attacks and selective leaving and tagging when you're participating in a decentralized system
19:15:58nsh:that too, aye
19:16:34nsh:you have to be very careful delegating security properties to unexamined assumptions about network connectivity
19:16:44nsh:this is a common way to screw up
19:18:16nsh:s/delegating...to/making contingent...on/
19:22:59bramc:Given what a huge improvement the centralized system would be over what exists today, it's more compelling to make that. There's also less of a business in making the decentralized thing. But if anybody comes up with interesting designs on the decentralized thing I'd love to see them.
19:23:06sipa:bramc: i think it's a pretty bad idea to have a design that makes loss of privacy cheaper; if you don't reuse keus (which you should for privacy reasons), this optimization does not gain you anything anyway
19:27:31bramc:sipa, fair enough
19:43:49adam3us:anyone interested in cryptonote / ring sig crypto? i think you can ~halve the signature size by using section 5.1 from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.363.3431&rep=rep1&type=pdf
19:45:43nsh:neat
19:51:16andytoshi:adam3us: cool, this is actually quite different from the van saberhagen scheme
19:51:37andytoshi:so i can't just copy the key image over. but probably i can come up with something analogous
19:53:33andytoshi:hopefully i'll have time for brainteasers later this weekend to do it, if you haven't. (anyone else who wants to give it a shot is welcome to PM me for advice -- i'm 75% sure it's just "straightforward algebra" and does not require math/crypto experience)
19:54:30adam3us:andytoshi: i think its close enough. if you look at the g^s*y^c that is basically L
19:54:43adam3us:so compute R also and put that also into each hash
19:55:27bramc:There tends to be a fairly firm separation between crypto primitive work and using the primitives to make protocols. The former is mostly math, the latter is mostly 'crypto'
19:55:33andytoshi:oh, yeah, i see...but if R is in there you lose the space savings right?
19:55:50adam3us:and i think you're done (add I to the signature, add R=H(y)^s*I^c to the verification step)
19:55:58adam3us:(and convert to EC basis)
19:56:42adam3us:andytoshi: no because R is computed
19:57:22adam3us:andytoshi: the sig includes I now, and you can compute the rest…. H(y)^s*I^c
19:58:29andytoshi:ok, that seems correct, i'm not confident of security because the van saberhagen scheme has a second set of challenges and i worry they are necessary (and will imply that you need bigger sigs)
19:58:33bramc:This all sounds like fun. I'm stuck in monte carlo land.
19:58:43andytoshi:but i just need to write it out
20:00:05adam3us:andytoshi: i have the cryptonote paper here. it includes c_i and q_i which are analogous c_i and s_i here.
20:01:01adam3us:andytoshi: i was trying to figure out how to do this trick (towards my hobby of trying to find a fixed size ring sig for all of utxo ha ha) and found this paper with the magic formula- they did what i was trying to do.
20:01:44adam3us:andytoshi: so that takes it form O(2n+c) to O(n+c) only the pesky O(n) to get rid of :)
20:05:07andytoshi:adam3us: "analogous" is a stretch, they require sum{c_i} = H(...) so they can program all but one of the c_i's, whereas in this paper the c_i's are all hashes and all-but-one are programmed by chaining into each other, which is enough difference to confuse my intuition
20:05:17andytoshi:but i see what you're saying now, i think that you're right
20:10:18andytoshi:it's surprising to me that s doesn't even need to change, it's as though c_i = d_i in the van saberhagen scheme
20:12:41andytoshi:oh never mind, there is no d_i in the saberhagen scheme, i am looking at my own notes which do something else (combining signatures iirc)
20:12:45adam3us:andytoshi: i think the actual challenge requirement is that they depend on the commitments (g^s*y^c) such that you can forge at most n-1 of them and need one private key. the c values are arbitrary and could come from a CPRNG
20:14:40andytoshi:adam3us: right ... doing it by sum is the "obvious" way, this chaining thing is entirely new to me ... does the space savings come from this change somehow?
20:16:30andytoshi:ah, i think so, doing it by sum requires that you have a new equation for each new thing you wanna prove the DL of (in this case, the key image I = H(y)^x as well as y = g^x), else you have fewer equations than unknown and are not forced
20:16:46andytoshi:whereas you can put as many things as you want into a single hash challenge and it'll force them all at once
20:16:52andytoshi:very slick
20:17:13adam3us:andytoshi: yes you only need to send c1, the rest is computed by recurrence. so then the sig becomes c1,s1,…,sn instead of c1,…,cn,s1,…,sn
20:22:47andytoshi:ok, i understand. the space savings is simply because the recurrence avoids the need to send every c_i. (what i was saying explained how we avoid having both L_i's and R_i's, which are not sent but computed in verification; the paper you posted has only e_i's, so there's also a 50% speedup)
20:31:02andytoshi:this is really cool, this "ring of hash commitments" is totally out of left field to me
20:39:31andytoshi:for constant-size sigs, i wonder if you can do something like: replace the s_i's with a single sum of c_i^i*x_i, then [magic magic] this reduces to "given g^x, g^(x^2), ..., g^(x^q) determine g^(x^{q+1})" which is a standard and imo safe assumption (called q-diffie-hellman iirc)
21:03:02adam3us:andytoshi: i know scribbles on paper here in similar directions. the hard part is to correct it so you dont disclose which signature was the one with known private key. if it can be made to work its practically useful for bitcoin.
21:04:49adam3us:andytoshi: the issue is one of the s_i values is computed as \alpha-c_i*x_i (where x_i is the private key from y_i = g^x_i)
21:10:24andytoshi:the other s_i's are random, i wonder if we can deterministically generate them from each other (with an arbitrary one being programmable) with something like an "invertible permutation hash"
21:11:21andytoshi:lol, is there anything wrong with just doing s_i = s_0 + i actually?
21:21:11andytoshi:or what if all the s_i's are the same?
21:24:31adam3us:andytoshi: i did try s_{k+1} = E( s_k ) which implies s_{k-1} = D( s_k ) etc however you still arrive back at the problem that either you make the one you can fix coincide with the c_k you are calculating and divulge which is the real private key)
21:27:37andytoshi:i don't see why, the one you fix is blinded by α which is not revealed
21:32:52andytoshi:oh derp i see, you cannot actually have all the s_i's constant because you need to know c_k (which depends on s_{k-1}) before you compute s_k
22:30:13Eliel:if you wanted to help people learn bitcoin better, you'd first need to create a compact but easily understandable materials and then persuade the most popular wallets to include or at least link to it.
22:34:50nsh:you mean documentation?
22:36:19nsh:it's useful to appreciate how the curve might look when you graph the amount of information required to understand something well enough to do it right against the distribution of people who would benefit by using it
22:36:34nsh:i suspect the decay is quite sharp
22:37:09nsh:you can only package things and make them accessible to a certain degree, after that it's just a case of how much a given person is willing to eat the morsels
22:37:31nsh:if you want a wide franchise, you can't expect there to be a large meal of lore to swallow
22:37:43nsh:even if you make it into a yummy fruit smoothie
22:37:43bramc:Given that journalists sometimes write laudatory 'bitcoin is the future' articles while clearly not even understanding what it does and how, I don't think lack of documentation is the problem.
22:37:55nsh:journalism is the problem :)
22:38:01nsh:no, that's glib :)
22:38:38bliljerk101:what's the bitcoin-wizards channel for?
22:39:31bramc:bliljerk101, For discussing advanced topics and potential new development outside of the day to day of bitcoin development
22:39:54nsh:discussion of the theory and future developments of the technology of the blockchain and its associated/peripheral things
22:40:20nsh:and sometimes, within reason, other topics that might be of interest to the demographic that would usually discuss such thing
22:43:17bliljerk101:i see. i wasn't sure since i don't see much useful discussion going on in here
22:43:45bramc:bliljerk101, You can see past discussion in the archives on bitcoin.ninja
22:44:01nsh:thank goodness you intervened, bliljerk101 :)
22:44:12bramc:It frequently gets deep into arcane and technical discussions
22:48:50prodatalab_:prodatalab_ is now known as prodatalab
22:56:31bliljerk101:bramc thanks. nsh thanks for adding merit to my previous statement
22:56:46nsh:* nsh nods
23:54:39zooko:phantomcircuit, maaku: Ah! Psychology! Now that is an argument I can admit might be true, although I have a hard time judging if it is true.
23:55:34phantomcircuit:zooko, it's pretty obvious that it's different
23:56:05phantomcircuit:there's a reason the irs collects taxes through withholding and tax collectors
23:56:28maaku:zooko: the psychological argument is real
23:56:39maaku:the other argument is from sticky prices
23:57:21maaku:inflation allows those closest to the source of money to unevenly profit from the inflation
23:57:25zooko:To me sticky prices are another expression of psychology.
23:57:37zooko:Or of inaccurate or limited mental models of the players.
23:57:41maaku:well, in the sense that economics is really a social science
23:58:07zooko:bbiab