| 00:10:04 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 00:17:28 | andytoshi: | gmaxwell: here's a neat fact: you can do a BRS sig spending two of N outputs by just adding together the sigs and publishing both key images; verifiers add the key images together before verifying as usual |
| 00:17:45 | andytoshi: | this preserves correctness but not security, since obviously any pair of key images which sums to the same thing will verify |
| 00:18:16 | andytoshi: | (think it's still unforgeable, but it's definitely no longer linkable) |
| 00:23:30 | gmaxwell: | I hadn't thought through that before but it doesn't surprise me. |
| 00:24:54 | andytoshi: | there is a curvepoint->curvepoint hash that, if you replace with the identity (which you can do without breaking BRS, but it does break anonymity of the stealth addresses that monero uses, so you maybe shouldn't do it), and you know both secret keys, you can produce a ringsig that'll validate with both key images |
| 00:25:35 | [nsh]: | hash? |
| 00:26:32 | andytoshi: | [nsh]: there are two hash functions in bytecoin ring signatures, a "real" one used the same way as in any other sig scheme (and is modeled after a random oracle), and one that was used for compression in the ringsig scheme that they modified to get BRS... |
| 00:26:58 | andytoshi: | ...but is no longer needed since the pubkeys are the same size as the key images, and has no required cryptographic properties |
| 00:27:33 | andytoshi: | except that, if you just use the identity, the resulting sigs have some algebraic structure which, when combined with monero-style stealth addresses, breaks their anonymity (but does not break it if you don't do the stealth address thing) |
| 00:28:31 | [nsh]: | hmm |
| 00:28:50 | gmaxwell: | what happens if you just replace it with addition with a random point for which the discrete log is unknown. |
| 00:29:49 | andytoshi: | still broken, what you do to attack is produce a stealth-address with two ephemeral keys that you know, then subtract them |
| 00:30:13 | andytoshi: | so any linear relation will let you identify the target's signatures as being the same |
| 00:30:46 | gmaxwell: | ah, gotcha. well okay, it only breaks it for the prior payer but not random third parties. |
| 00:30:54 | andytoshi: | correct |
| 00:31:04 | gmaxwell: | maybe unfortunately surprising but not totally busted at least. |
| 00:32:21 | andytoshi: | yeah. fwiw i haven't thought about the interactions of stealth addresses with our output-blinding scheme, maybe we don't want/need them.. |
| 00:33:46 | andytoshi: | i'm not clear on what they're accomplishing in monero tbh |
| 00:37:19 | kanzure: | "Asymmetric transactions in p2p systems create the possibility of asymmetry of interest. [...] This is mitigated by shared history, where every peer keeps records about all of the interactions that occur in the system, regardless of whether he was directly involved in them or not." |
| 00:37:24 | kanzure: | from http://diyhpl.us/~bryan/papers2/incentives/Robust%20incentive%20techniques%20for%20peer-to-peer%20networks.pdf |
| 00:37:48 | kanzure: | not very convinced that shared history eliminates those asymmetries completely |
| 00:47:56 | andytoshi: | kk, a BRS sig for a ring of size n involves publishing 2n numbers along with the key image ... i think i can do a BRS sig spending m outputs by publishing (m+1)n numbers along with the m key images |
| 00:48:04 | andytoshi: | where verification is also linear growth in m |
| 00:49:39 | gmaxwell: | hm. thats interesting especially in concert with the value commitments. |
| 00:50:57 | [nsh]: | how might commitments be used in this context? |
| 00:51:03 | andytoshi: | it's interactive setup (as always you have to agree on the nonce sum before setting up, and in BRS this implies also agreeing on the ring), but i think the common case is you own all the outputs anyway |
| 00:51:56 | andytoshi: | s/before setting up/before signing/ |
| 00:53:49 | gmaxwell: | [nsh]: well normally a transaction will spend a couple inputs, say 5. and each will have its own ring of (say) size 4. so that 5 * 2*4 plus one key image per, so 5 images, so 45 values. andytoshi seems to think it works with only (5+1)*4 + 5 = 29... so a fair savings. |
| 00:54:13 | gmaxwell: | The reason the value commitmens come into it is that its the prereq for putting coins of different values into one anonymity set. |
| 00:54:33 | [nsh]: | ah |
| 00:55:09 | gmaxwell: | bleh, actually the value reveal means you can't actually join across value groups, never mind.. still it's more efficient if you spend multiple coins of the same value at least. |
| 00:55:33 | [nsh]: | * [nsh] nods |
| 00:55:41 | andytoshi: | yeah :/ i realized that as soon as you answered [nsh], shitty |
| 00:56:39 | andytoshi: | roughly what it is is: in BRS you have two sets of nonces, {r_i} and {c_i} where the r_i's look random and the c_i's have to sum to H(m, {L_i}, {R_i}) where L_i and R_i are nonces ... what i'm doing is combining multiple sigs by tweaking the L_i's and R_i's, then the r_i's are the sum of what they would be for individual sigs (the savings are here) |
| 00:57:13 | andytoshi: | then you have {c_i} which have to sum to H(m, {L_i}, {R_i}, I1), {d_i} which sum to H(m, {L_i}, {R_i}, I2), {e_i} which sum to H(m, {L_i}, {R_i}, I3), etc |
| 00:57:23 | andytoshi: | the notation is pretty gnarly :} |
| 00:57:28 | gmaxwell: | meh, from an information theoretic view an additional point would probably be all that would be required to show that two two images you provided were in particular subsets but I dunno if there is an obvious way to lay that out. |
| 00:58:02 | [nsh]: | but you could do a social ritual like coinswap were people prepare a bunch of different value coins into a set of [whatever the current convenient] canonical-valued ones for later use? |
| 00:58:19 | andytoshi: | gmaxwell: you are suggesting that my scheme does not work? |
| 00:58:41 | gmaxwell: | andytoshi: no, no, I'm saying that to make it work across values you need to remove a degree of freedom. |
| 00:59:17 | andytoshi: | ok :) i'm 80% confident this is secure as regular BRS, i'd be pretty dismayed if you saw a flaw just from my vague comments |
| 00:59:26 | gmaxwell: | e.g. you'd want to have two images and show that image 1 is from the first half of keys and image 2 is from the second half. |
| 00:59:57 | andytoshi: | you can do that definitely, but that's roughly the same as just concatenating two signatures |
| 00:59:59 | gmaxwell: | andytoshi: nah, before you explained it I had an idea what you were saying. |
| 01:00:36 | andytoshi: | yeah, it's the second most obvious thing after just adding them (but as i mentioned above that breaks linkability){ |
| 01:00:37 | gmaxwell: | [nsh]: sure existing BRS altcoins do some handling of different values to try to reduce the number of distinct values in the system. Its a little ugly though and is one of the things that results in lower privacy in practice than in theory. |
| 01:00:48 | [nsh]: | * [nsh] nods |
| 01:01:02 | [nsh]: | just wondered if you could treat it as a community janitorial problem in some relatively privacy-benign manner |
| 01:01:36 | [nsh]: | like how old notes are cycled out of circulation |
| 01:02:30 | gmaxwell: | so far the bitcoin ecosystem doesn't seem to have a good track record for successful janitorial handling, alas. |
| 01:02:49 | [nsh]: | fair point |
| 01:05:39 | andytoshi: | anyway what brought this up was i was reading https://download.wpsoftware.net/bitcoin/wizards/2014-06-22.html because i couldn't remember gmaxwell's hash-based OWAS scheme, and my comment there at 18:02 was « idk, my next steps are (a) can we ringsign with two keys in one signature (so spending two outputs and combining their anonymity sets), (b) can we do k-of-n threshold signatures like this the |
| 01:05:42 | andytoshi: | way you can with schnorr-sigs (so multisig outputs are undectectable and can be in each others' anonymity sets) » |
| 01:05:44 | andytoshi: | we've done both :D |
| 01:07:43 | gmaxwell: | I'm not sure what to call the hash based owas. I suspect there are a whole family of interesting private protocols in that class. |
| 01:08:04 | gmaxwell: | Did you find the scheme description? |
| 01:08:12 | andytoshi: | it's the very first line of that log |
| 01:08:49 | andytoshi: | agreed we need a name, it's imo a really important idea |
| 01:09:53 | gmaxwell: | it's a similar kind of security argument to those ecash proposals where singing twice reals your private key and this is something you care about. |
| 01:10:21 | gmaxwell: | ... excep that in our case there is actually a pretty good reason you'd care about being caught. :) |
| 01:10:25 | andytoshi: | well, here it's roughly "if you cheat we'll take your block subsidy away" |
| 01:11:48 | gmaxwell: | I subsiquently came up with a slight improvement. The nonce used for blinding should be encrypted in the output too, so that the reciever also knows it. (or in some way derrived in a way that both the sender and reciever will know) |
| 01:12:12 | gmaxwell: | This way more parties have the ability to prove fraud (though it does link the payment for the reciever) |
| 01:12:13 | andytoshi: | ah, good idea |
| 01:13:38 | andytoshi: | another thing i noticed was that unlinking the inputs and outputs like this lets the miners put them in separate merkle trees |
| 01:14:03 | andytoshi: | which is nice for pruning |
| 01:14:46 | gmaxwell: | Thats actually true even without the unlinking... even usefully so if the transactions themselves are tree structured, so you could still prove parts of transactions where you've pruned the rest. |
| 01:15:04 | andytoshi: | i think this is a concrete example of your "privacy => less data => efficiency" observation |
| 01:15:15 | gmaxwell: | which is one of the reasons I'd prefer transactions being tree structured, I'd generally like to be able to eliminate old signatures. |
| 01:15:17 | andytoshi: | is it true without unlinking? otherwise you need to somehow indicate which inputs go to which outputs |
| 01:15:37 | gmaxwell: | andytoshi: you do, but you can, it's just some amount of extra data. |
| 01:16:04 | andytoshi: | yeah, i'm saying we can drop that extra data, so there's an efficiency improvement to the unlinking |
| 01:16:11 | gmaxwell: | yep it's true. |
| 01:17:19 | andytoshi: | so there's a general observation here ... for any data that isn't relevant to all parties, maybe we can just blind it and introduce fraud proofs, and get some snarklike efficiency gains |
| 01:19:12 | gmaxwell: | so the general fraud proof approach falls down because maybe there is _no one_ that has the required data to produce the fraud proof. |
| 01:19:38 | gmaxwell: | But that doesn't apply here because the sender(/reciever) have it, at a minimum... and failing to provide it hurts them. |
| 01:21:05 | andytoshi: | the reason the sender must have it is that it's in the signature....so we couldn't do e.g. script evaluation like this because checking the signature is a script evaluation |
| 01:21:36 | wallet421: | wallet421 is now known as wallet42 |
| 01:22:07 | andytoshi: | i can't think of anything else to hide that works, but something to keep in mind in any case |
| 01:27:10 | gmaxwell: | well on the signature part, there is a scheme that Felton and some of his students were talking about; where they you assert you've signed correctly, and put up some coins with your claim. Maybe the protocol stops there. Otherwise, someone can assert the signature was invalid (and put up more coins, including enough to pay the tx fee to reveal the whole signature), and then you must provide the whole signature. If you do, you get ... |
| 01:27:17 | gmaxwell: | ... their coins and your payment goes through. If you fail, the refuting party gets the coins you put up. |
| 01:28:43 | gmaxwell: | it's sort of a more elaborate version of the semi-interactive SPV stuff I decribed in the coinwittness thread. Of course, it has the same/worse censorship risks. |
| 01:29:50 | gmaxwell: | I think in most cases where it would be useful, the coinswap compression (or, better, a MAST version of it) where if both players are honest the transfer just becomes a 2of2 multisig is strictly superior. |
| 01:31:02 | kanzure: | a proof of "they cheated on whatever" unlocking some escrowed payment is a nice idea |
| 01:31:11 | kanzure: | s/cheated/fraudulated |
| 01:31:20 | kanzure: | ah, fraud proof |
| 01:32:49 | gmaxwell: | well there its kind of reversed and in doing so it solves the "but what if their claim is such nonsense that everyone is stuck in disproving a negative land" ... so it's "I do this!" "I know you cheated but can't efficiently prove it, so I'll put up a bounty that pays enough that _you_ can prove your honesty if you're really honest.. and otherwise collect your escrowed coins" |
| 01:34:30 | kanzure: | who is collecting? the single party, or a pool of original participants that have now been (provably) frauded? |
| 01:35:14 | gmaxwell: | The additional notion here is that you have some quieting period for this all to settle, so no one has been defrauded... the proof cancels the fradulent move. |
| 01:36:06 | gmaxwell: | compensating people for successful fraud is harder than it seems, in particular it's hard to prevent 'double spending' of your bond. ... e.g. you put up a 1btc bond but then do 1000 0.5 BTC fradulent actions. :) |
| 01:36:24 | gmaxwell: | so at least fraud proofs against double spending are not very effective. |
| 02:37:41 | kanzure: | andytoshi: maybe also https://github.com/bitcoin/bitcoin/commit/d6eb259953699f5bea208ff41a0967d8ea513a70 |
| 02:39:18 | Luke-Jr: | kanzure: fwiw, we decided against that for Eligius today |
| 02:40:01 | Luke-Jr: | the incentives are too unclear |
| 02:40:30 | kanzure: | do you have piles of contributions for something like bitcoin-incentives.tex? |
| 02:40:53 | Luke-Jr: | ? |
| 02:41:01 | andytoshi: | "too unclear" is what i'd say about that too :) |
| 02:41:04 | kanzure: | Luke-Jr: https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex |
| 02:41:15 | andytoshi: | Luke-Jr: kanzure is working on a document to describe the economic components of bitcoin's design |
| 02:41:25 | Luke-Jr: | i c |
| 02:41:26 | kanzure: | i don't know if it's economic |
| 02:41:43 | kanzure: | oh wait, i guess anything slightly related to bitcoin ends up being economic now |
| 02:43:12 | Luke-Jr: | kanzure: http://0bin.net/paste/WjtznKCCqrsN3Hjm#QVLE6Sx3pEHkIv9uIR4OYEGuPVqqdpmSCsQZjaa+q-J |
| 02:43:31 | andytoshi: | kanzure: well, "incentive" to us means "economics" because this is an academic channel.. |
| 02:44:20 | kanzure: | Luke-Jr: thanks |
| 02:44:30 | kanzure: | andytoshi: i am still looking for the right definition of incentive actually. |
| 02:46:52 | Luke-Jr: | wtf, is there seriously YET ANOTHER BASH security update? |
| 02:53:10 | andytoshi: | iirc there was the initial broken one, the "unofficial" one that worked (but disabled too much?) and now a third "real" one |
| 02:57:59 | gwillen: | there have been more than that |
| 02:58:13 | gwillen: | there were at least two broken official updates |
| 02:58:29 | kanzure: | andytoshi: i think incentive is overloaded at this point, heh |
| 03:00:20 | andytoshi: | kanzure: hmm, maybe this word has been used at lesswrong? i'll bet they need a similar concept there |
| 03:00:27 | andytoshi: | and have spent millions of manhours discussing it |
| 03:00:45 | kanzure: | i doubt it, lesswrong has an extremely narrow focus, and complex systems are disgusting to them |
| 03:01:15 | gmaxwell: | kanzure: you mean you're not an all knowing AI that will only give me a million dollars if I won't accept it?!? |
| 03:01:38 | andytoshi: | (i use mine to heat my home in the winter) |
| 03:01:42 | kanzure: | many have suspected that i am an ai http://heybryan.org/mac.html |
| 03:02:02 | gwillen: | I don't see what's unusual about the word 'incentive' here, unless I'm missing some details of what it's being used for |
| 03:02:11 | gwillen: | it seems to be the same 'incentive' as in the standard phrase 'incentive-compatible' |
| 03:02:12 | kanzure: | gwillen: documenting various bitcoin incentives |
| 03:02:19 | gwillen: | * gwillen nods |
| 03:02:50 | kanzure: | there's some folk-like knowledge about incentive-compatibility, but it is not as explicit as it could be |
| 03:03:00 | andytoshi: | how about "there is incentive to X if there is an opportunity cost to not doing X" |
| 03:04:39 | gmaxwell: | much of economic theory is really fuzzily defined, I expect problems when you try to make a formal statement of security with an economic component and really can't connect it to useful economic thinking. |
| 03:04:52 | kanzure: | hehe i make no claims about security yet |
| 03:05:26 | andytoshi: | it would be a pretty big step if we could make a formal security argument that involved econ |
| 03:05:42 | kanzure: | probably something about thermodynamics and cost of entropy |
| 03:05:52 | andytoshi: | where i always get jammed is trying to model attackers who don't value the system, just want to destroy it |
| 03:05:55 | kanzure: | there are already various thermodynamic/economic things around energy |
| 03:06:37 | gmaxwell: | sure sure, though presumably one of the long term goals of identifying economic assumptions is to embed some of them in formalized security statements. Today we do this via a bit of abstraction, "we assume the world will look like x." is the security statement, and sowhere someone mutters "x isn't a crazy state, because economics handwave handwave" |
| 03:07:35 | gmaxwell: | well as I mentioned before, I have in mind a general framework that actually inverts some of these economic incentives under some conditions. |
| 03:08:41 | gmaxwell: | Basically, if you can short bitcoin in a way that won't also be broken by bitcoin breaking (e.g. existing bucketshoppy places don't count) ... then there potentially much money to be made by doing exactly the opposite thing that the incentives say you should do. |
| 03:09:01 | gmaxwell: | because you're worried about the value of anti-bitcoins, rather than bitcoins. |
| 03:09:12 | kanzure: | well, i agree that is a useful result to aim for. i was hoping for improving a reader's ability to forward-simulate incentive-compatibility issues and consensus. |
| 03:09:19 | kanzure: | a security model would be dramatically more useful, yes |
| 03:10:04 | andytoshi: | that's a good goal too, seems like people who come here with incentive-bad ideas get really ad-hoc responses.. |
| 03:10:16 | andytoshi: | and i'm not sure how good we are at general education |
| 03:11:08 | gmaxwell: | well I think we don't even have anything handy to point people to e.g. byzantine/rational/altruist as a framwork for reasoning. |
| 03:12:01 | kanzure: | i suppose i could throw in a definition of sybil attacks, non-sticky identity (node) creation (whatever that's called around these places), generic byzantine general problem description.. |
| 03:13:25 | gmaxwell: | I had a good conversation at dinner last night where I somehow managed to impress on some the extreme difficulty of building cryptographic consensus systems. What I failed to teach, however, is how hard it is to get other people to understand the challenge. |
| 03:14:18 | andytoshi: | if we said "go think about how this affects point 32b of kanzure's doc" and it took them half an hour for one bullet point in a giant document, that would help i bet :) |
| 03:15:42 | andytoshi: | my problem here is i don't know how i should be thinking about consensus systems, i don't even have a high-level model where i can be saying "this is roughly the concept i want to define", it's just lots of ad-hocky "bitcoin does this and here's why" |
| 03:16:01 | kanzure: | ideally they would have memorable names other than 32b =) |
| 03:17:57 | kanzure: | i think the ad hocy is fine as long as the reasons are being enumerated, for now |
| 03:18:25 | kanzure: | someone else can come along and try to reduce it into less ridiculous "Here's a pile of code" format |
| 03:19:45 | kanzure: | *into a format less ridiculous than "well, look at satoshi's pile of code" format |
| 03:22:00 | [nsh]: | ironically, executing the idea was immensely more didactic ultimately than explaining it would have been |
| 03:25:38 | kanzure: | andytoshi: okay, various updates https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex |
| 03:26:05 | Guest8706: | Guest8706 is now known as EasyAt |
| 03:29:12 | andytoshi: | kanzure: nice! |
| 03:38:20 | artilectinc: | artilectinc has left #bitcoin-wizards |
| 05:39:05 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 07:17:03 | Dr-G2: | Dr-G2 is now known as Dr-G |
| 08:05:18 | cameron.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 |
| 08:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: andy-logbot Guyver2 go1111111 aburan28 licnep coinheavy justanotheruser qualiabyte TheSeven arubi Dr-G koshii_ zwischenzug tacotime Quanttek_ zenojis LarsLarsen atgreen HaltingState freggles spinza jchp BigBitz EasyAt Graftec_ mortale samson_ gavinandresen SDCDev DougieBot5000 Sangheili waxwing emsid pen Adohgg Hunger- mkarrer drawingthesun Kretchfoop fanquake eristisk tromp_ berndj-blackout [d__d] nsh jcorgan nuke1989 copumpkin c0rw1n lysobit |
| 08:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: yoleaux irc88 jaekwon Transisto Iriez wizkid057 OneFixt hollandais ebfull Aquent Starduster lnovy gribble hguux livegnik rfreeman_w wiretapped stonecoldpat Dyaheon Fistful_of_coins digitalmagus dansmith_btc2 jgarzik dgenr8 MRL-Relay artifexd _2539 mappum jbenet [Derek] zibbo_ kanzure Luke-Jr petertodd optimator [\\\] Grishnakh warren puszl pi07r K1773R xmj Eliel HM gmaxwell amiller_ crescendo cfields btc_ kgk bobke iddo arowser comboy Happzz |
| 08:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: wumpus NikolaiToryzin coryfields michagogo LaptopZZ Meeh poggy_ Emcy_ UukGoblin danneu catcow TD-Linux [Tristan] helo smooth otoburb gwillen ryan-c mmozeiko roasbeef pajarillo sl01 Keefe Gnosis ahmed_ Muis Logicwax nanotube espes__ andytoshi so epscy BlueMatt tromp a5m0 starsoccer midnightmagic Graet kinlo pigeons BrainOverfl0w lianj Apocalyptic mr_burdell fluffypony bbrittain SomeoneWeird forrestv Anduck Nightwolf Krellan Taek42 asoltys |
| 08:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: @ChanServ phedny burcin lechuga_ abc56889 Alanius Guest47516 throughnothing harrow DoctorBTC phantomcircuit [nsh] sipa |
| 11:24:15 | amyntor: | amyntor has left #bitcoin-wizards |
| 14:33:34 | kanzure: | 23:28 < user_> kanzure: that's hard, maybe try "stable set of features of an anticipated or hypothetical environment, such that the reward for doing X (taking into account how you'll act after doing X and producing its consequences) is higher than the reward for not doing X, relative to how much higher it would be if those features were absent" |
| 15:34:00 | berndj-blackout: | berndj-blackout is now known as berndj |
| 16:55:58 | Aquent: | It feels like bitcoin is under attack |
| 16:56:07 | Aquent: | would it work perhaps if all timers bid walled exchanges |
| 16:56:15 | Aquent: | old* |
| 16:57:10 | [nsh]: | pardon? |
| 16:58:02 | brisque: | not *quite* the right thing for this channel. |
| 17:00:00 | brisque: | it's odd to imply that wizards have a lot of cash. |
| 17:00:44 | AlSzacrel: | AlSzacrel has left #bitcoin-wizards |
| 17:14:25 | Aquent: | I didn't, but not quite sure where they'd hang out so thought to post here |
| 17:16:05 | brisque: | this is the place for moon math and fabulous thinking beards (if applicable). |
| 17:18:53 | fluffypony: | Aquent: even if they were here, holders typically are BTC heavy, fiat light, so they don't have buying power |
| 17:27:36 | Aquent: | hmm thats a good point but they can use margins |
| 17:27:50 | Aquent: | that would exclude stamp though I guess |
| 17:28:48 | Aquent: | on the other hand sellers might be attracted by no slipage from the bid walls so yeah duno was just a thought to put out there I guess |
| 17:47:44 | Taek42: | Bid walling is an easy way to lose money, unless you're sure you understand why the price is falling |
| 17:49:14 | Taek42: | I'm tempted to say this is just a panic sell, but I'm also wondering if someone hasn't started doing fractional reserves and is inflating supply of Bitcoin. A big player could pull this off iteratively. |
| 17:51:14 | gmaxwell: | come on, this channel is for technical discussions. |
| 17:52:37 | Taek42: | Are economics out of scope? Or just economics that relate to current events? |
| 17:52:59 | andytoshi: | market games are out of scope |
| 17:58:24 | [nsh]: | if people are discussing it somewhere else, it's probably out of scope |
| 17:59:02 | cbeams: | Taek42: see #bitcoin-pricetalk |
| 17:59:31 | Taek42: | (Not trying to troll, legit question): you guys talked about writing a paper about the economics of bitcoin, what sorts of things will go in that paper? |
| 17:59:44 | Taek42: | cbeams thanks |
| 19:21:23 | Adohgg: | Adohgg is now known as twobltot |
| 19:21:25 | twobltot: | twobltot is now known as twobltbot |
| 19:21:39 | twobltbot: | twobltbot is now known as Adohgg |
| 19:56:06 | kanzure: | haha, http://en.wikipedia.org/wiki/Sybil_attack |
| 19:56:10 | kanzure: | "The term "pseudospoofing" had previously been coined by L. Detweiler on the Cypherpunks mailing list and used in the literature on peer-to-peer systems for the same class of attacks prior to 2002, but this term did not gain as much influence as "Sybil attack".[3]" |
| 19:56:15 | kanzure: | ... detweiler is the one that had the cray nick szabo theories :P. |
| 19:56:48 | kanzure: | *crazy |
| 20:13:13 | fluffypony: | kanzure: he must've been having an off day |
| 20:53:41 | brisque: | "mastering bitcoin" (the book) was finished today, according to reddit. take a look at it, first sentence I read is wrong. |
| 20:56:52 | [nsh]: | what is asserted? |
| 20:57:25 | brisque: | " If the result of executing the locking script with the stack data copied from the unlocking script is "TRUE", the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO." |
| 20:58:30 | [nsh]: | and what would have been a not-wrong phrasing? |
| 21:00:23 | brisque: | scripts evaluate to true if the top item in the stack is non-zero, where that reads to suggest it's a literal "true". |
| 21:03:09 | brisque: | it then goes on to talking about UTXO (unspent transaction outputs) being recorded into the block chain forever, which is not quite true either. |
| 21:05:55 | [nsh]: | so what you're saying is that people will read this book and inevitably cause total thermonuclear war, rather then some mild pedantic quibbles |
| 21:05:57 | [nsh]: | got it :) |
| 21:06:52 | brisque: | it's just wrong in subtle ways. like it's examples for script show OP_EQUAL pushing literal "true" to the stack, which it doesn't. |
| 21:07:21 | kanzure: | "wrong in subtle ways" should be the /topic |
| 21:08:04 | brisque: | * brisque bangs head into the desk |
| 21:08:16 | brisque: | the examples in the book use disabled opcodes. how useful. |
| 21:08:40 | brisque: | lets teach everybody to OP_MUL when they can't in the real world. |
| 21:09:02 | fluffypony: | who wrote the book? |
| 21:09:10 | lechuga_: | andreas |
| 21:09:18 | lechuga_: | antantntotptotltous |
| 21:09:19 | fluffypony: | oh. well. |
| 21:09:30 | brisque: | andreas antonopoulos, published by o'reilly. |
| 21:09:50 | fluffypony: | there are people that should publish technical material, and there are people that shouldn't |
| 21:12:34 | sipa: | brisque: bip62 changes the requurement to be pretty much "the result has to be true" (technically: a single non-zero element on the stack) |
| 21:14:35 | brisque: | sipa: the book isn't saying that though, in a number of examples it's showing a literal "TRUE" rather than a non-zero stack element |
| 21:17:11 | brisque: | "Pay-to-Script-Hash (P2SH) was introduced in the winter of 2012 as a powerful new type of transaction that greatly simplifies the use of complex transaction scripts." < because the whole world only has a single hemisphere |
| 21:17:40 | fluffypony: | hah hah |
| 21:17:51 | fluffypony: | as a South African...thank you ;) |
| 21:19:22 | [nsh]: | Q4 is hardly better.... |
| 21:19:30 | [nsh]: | i suppose the actual month would be best |
| 21:21:50 | brisque: | "The main bitcoin network, running the bitcoin P2P protocol, consists of between 7,000 to 10,000 nodes running various versions of the bitcoin reference client" < because you have to listen to be a "full node" |
| 21:34:33 | fridaynext: | fridaynext has left #bitcoin-wizards |
| 21:45:45 | brisque: | "Beyond a certain "depth", blocks are absolutely immutable, even under a sustained consensus attack that causes a fork." |
| 21:48:21 | brisque: | "There is no possible way for a solo miner to control even 1% of the total mining power." |
| 21:48:33 | fluffypony: | * fluffypony balks |
| 21:48:49 | [nsh]: | don't checkpoints mean the depth statement is kinda true? |
| 21:49:16 | kanzure: | presumably a consensus attack would be about whether or not the checkpoints are immutable |
| 21:49:23 | kanzure: | *a relevant consensus attack |
| 21:49:32 | brisque: | they'll be going away shortly, they're not intended to be a consensus tool rather DoS prevention |
| 21:49:43 | fluffypony: | [nsh]: then he should state that and define the depth, plus they're not around eternally |
| 21:49:56 | [nsh]: | * [nsh] nods |
| 21:54:29 | brisque: | I'm enjoying the chapter that pumps various altcoins an awful lot. not a single mention of anything that reminds me of andytoshi's pos.pdf. |
| 21:54:52 | brisque: | "MyriadCoin .. is notable because it uses five different Proof-of-Work algorithms (SHA256d, Scrypt, Qubit, Skein or Myriad-Groestl) simultaneously .. The intent is to make Myriad immune to ASIC specialization and centralization as well as much more resistant to consensus attacks, as multiple mining algorithms would have to be attacked simultaneously." |
| 21:55:14 | brisque: | "However, [proof of work] has been criticized by many as being “wasteful". The next set of alt-coins attempt to address this concern. Dual-purpose Proof-of-Work algorithms solve a specific "useful" problem, while producing Proof-of-Work to secure the network." |
| 21:57:02 | brisque: | "Darkcoin implements anonymous currency using a re-mixing protocol for all transactions called DarkSend. Darkcoin is also notable for using 11 rounds of different hash functions (blake, bmw, groestl, jh, keccak, skein, luffa, cubehash, shavite, simd, echo) for the Proof-of-Work algorithm." |
| 21:59:18 | brisque: | hehe, one last parting comment on that book. |
| 22:00:35 | brisque: | actually never mind. hope you all have fun refuting it's inaccuracies. |
| 22:00:39 | fluffypony: | this obsession with PoW is unhealthy. |
| 22:00:53 | fluffypony: | (I mean altcoins, not you) |
| 22:01:18 | brisque: | the insane bit is that the "super secure hashing" just makes it impossible to use SPV as intended. |
| 22:02:08 | fluffypony: | yeah |
| 22:02:14 | brisque: | I can validate a bitcoin UTXO proof on a microcontroller, would probably take me a week to do a Monero hash. |
| 22:03:14 | brisque: | (I get that you wouldn't be doing monero stuff on a microcontroller, but just as an example of PoW) |
| 22:03:34 | fluffypony: | yeah no, it's shitty for verification |
| 22:03:45 | fluffypony: | at least we acknowledge it...plus it's not our doing :-P |
| 22:04:19 | fluffypony: | this idea of "let's make PoW as hard as possible" forgets the verification bit |
| 22:04:35 | brisque: | I know! just a comment on being "ASIC-proof" in general probably hurting verification of proofs a lot more than people would think |
| 22:05:25 | fluffypony: | yeah but brisque, you have to understand that most developers don't think past the end of their nose...altcoin developers doubly so |
| 22:06:04 | brisque: | well, and we know part of the reasons behind the cryptonote PoW don't much help matters |
| 22:06:52 | fluffypony: | ah well, at least we're not stupid enough to pretend it's the be-all-and-end-all |
| 22:07:05 | andytoshi: | somebody should suggest a PoW that is co-NP or something so it actually cannot be validated any faster than it can be computed.. |
| 22:07:12 | brisque: | if you assume I can do 200h/s on my core i5 for Monero that's 20 minutes of just hashing to validate the chain, yikes |
| 22:09:59 | brisque: | fluffypony: did you ever read up about the "useful PoW" coins that book mentions? they're hilarious examples of not thinking (or caring) |
| 22:10:04 | kanzure: | andytoshi: to integrate into incentives.tex, http://web.archive.org/web/20111120165833/http://research.microsoft.com/en-us/people/avivz/bitcoin_red_balloons_summary.aspx |
| 22:11:15 | fluffypony: | andytoshi: isn't Cuckoo Cycle's whole point "hard to mine, easy to verify" ? |
| 22:12:04 | brisque: | they pretty much advertised as "lets replace PoW with something useful!!", reduced the difficulty to zero, and then handed out coins for credits on their BOINC/folding team pages. of course everybody cheated the chain forked and many tears all around. |
| 22:12:43 | andytoshi: | fluffypony: yeah, where "hard" is defined largely in terms of memory usage ... we are unsure about the economics of this and also nobody has really analyzed the paper :/ |
| 22:13:08 | andytoshi: | (no time + the economics make the result less interesting + apparently there is some costly setup phase right now that makes it non-progress-free) |
| 22:16:37 | brisque: | part of the reason I trust bitcoin's PoW is that it's easy to understand and say "nope, no shortcuts here" |
| 22:18:27 | brisque: | not to say I don't trust cuckoo cycle |
| 23:53:57 | gmaxwell: | brisque: I'm now of the opinion that "gate hardness" is a bad thing creating a form of non-progress-freeness. |
| 23:54:21 | gmaxwell: | brisque: the point is that you can look at PoW mining as being two costs, initial hardware costs and ongoing energy costs. |
| 23:54:39 | gmaxwell: | The hardware costs are amortized the longer you run, and so big established players have an advantage. |
| 23:55:20 | gmaxwell: | For SHA256 the power costs very rapidly surpass the initial costs. For a successful memory hard function much more of the cost is in hardware which enjoys the amoritization. |
| 23:56:29 | gmaxwell: | We're also less clear about what the potential speeds are for memory heavy circuits, since new techniques with 3d lithorgraphy and integrated compute/memory circuits appear to be able to provide substantial speedups for functions in that class compared to execution on conventional hardware. |
| 23:56:35 | Eliel: | so, to put it in other words, memory hard functions don't use enough energy. |
| 23:57:13 | gmaxwell: | Eliel: well you can convert all costs to energy. A successful memory hard function has a larger one time energy cost upfront. |
| 23:58:12 | gmaxwell: | You can perhaps use that somewhat in your favor if the hardware is general purpose (e.g. you'd be paying it anyways). ... but that dies the moment someone produces a specialized design which is much better than a general purpose computer. |