--- Log opened Thu Dec 26 00:00:28 2013
14:14 < adam3us> nxt yet another big-claim-alt?  100% proof of stake in their case and its own block chain, no source code so far.  all very confusing.  claimed market cap > mastercoin already $100mil http://coinmarketcap.com/ i guess those market caps could do with some market depth caveats really
14:15 < adam3us> for the solidcoin spectators https://nextcoin.org/index.php/topic,104.0.html
14:15 < maaku> adam3us: it's pre-listed on a regular old web exchange
14:15 < adam3us> yes its unclear what if anything the price on dgex.com means - could be manipulated and controlled by nxt devs with ~0 mkt depth
14:16 < maaku> presumably with withdrawls eventually being handled via a premine
14:16 < adam3us> maaku: 71 "investors" donated a total of 21 btc < 1month ago and yet the claim it has a market cap of $100m... ha ha
14:17 < maaku> personally, I never understood the utility of proof-of-stake mining in any fraction
14:17 < maaku> especially when subsidies are involved ... all sorts of bad incentives
14:17 < maaku> about all its done is distract people from the real utility of PoS
14:18 < adam3us> maaku: well superficially it sounds interesting that eg ppcoin claim that for self interest someone holding 10% of stake would not want to double spend or he'd damage value of his own holdings however, then there is an unfair mining advantage to the stake holders which is a diff problem
14:19 < maaku> adam3us: yes, but the way to achieve that control is to allow the PoS participant to vote on something akin to a checkpoint
14:19 < maaku> not to have some sort of protocol-level conversion metric between stake and hashpower
14:19 < adam3us> maaku: i presume u mean effectively different votes for validity vs reward
14:20 < maaku> adam3us: i mean a different protocol for considering best block which takes into account out-of-band stakeholder votes
14:21 < adam3us> maaku: well nxt is 100% stake.. not sure if that even quite makes sense.  the stake was bought for 21 btc in the last month!
14:23 < pigeons> I thought this was um, interesting or funny or weird or dangerous or something, "Moreover, the developers have purposefully introduced three security flaws into the source code that they will be releasing, as a means of encouraging the community to scrutinize the code and to prevent people from creating copies of Nxt by simply taking the source code and re-using it.  People who discover the security holes will be able to claim rewards for fin
14:23 < pigeons> http://nxtcrypto.wikia.com/wiki/FAQ
14:24 < adam3us> maaku: i was thinking maybe one could have a trusted server for simulating alts.  rent virtual "VPS" resources.  buy virtual "ASICs" and so on, the actual money goes to charity or btc QA or something. then its green.  and it doesnt matter if its centralized because dogecoin grade alts have largely no tx anyway.
14:25 < pigeons> there was a game that did that, but its gone now
14:25 < pigeons> it had an internal exchange and you could make your own coins too etc and "virtually" mine them without really mining or using electricity
14:27 < adam3us> pigeons: seems like a lower energy sandbox for dogecoin, shitcoin et al play in, pity it died
14:28 < pigeons> yeah it added simulated pools when they came along and you culd run your own mining pool without having to get ddossed
14:29 < pigeons> you could virtually pre-order your asics and virtually never get them
14:30 < adam3us> pigeons: fantastic
14:31 < pigeons> he sold the code before he closed to a guy who was in over his head and couldnt keep it running but i think at this point it wouldnt really help, best to just start with your own bugs instead of someone else's
14:32 < adam3us> $1k by end of year ;)
14:32 < adam3us> ?
14:36 < adam3us> heh hash rate went over 10 PH and now the format is confused 1.045E7 https://blockchain.info/q/hashrate
15:17 < nsh> someone asks in ##crypto why ripemd-160 is used for addresses rather than just a truncation of sha-256 output
15:17 < nsh> i'm not sure how to answer...
15:20 < maaku> because the great satoshi said so
15:21 < maaku> retroactive reason: because breaking sha-256 doesn't mean a break of the address format, meaning coins would still be secure
15:21  * nsh prostrates before the ceremonial altar
15:21 < nsh> mmm
15:21 < maaku> obviously lots of other things would have to change if sha256 was broken, but you could still keep the same ledger
15:22 < nsh> right
15:34 < iddo> maaku: thats not so clear, if you can do sha256 collisions then you also have collisions for Bitcoin addresses (though i'm not sure how to use it to attack), and if you can do 2nd-preimage attack on sha256 then you can steal coins if someone re-uses an address
15:37 < iddo> an answer on stackexchange says that it's just "belt and suspenders" approach: http://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad
15:39 < andytoshi> gmax suggested that using a second hash function would guarantee that addresses still have a uniform distribution, while truncated-sha is not proven to have this property
15:39 < andytoshi> well, not just the distribution, preimage resistance as well
15:40 < iddo> hmm not sure what you mean by proven, there are no rigorous proofs for heuristic constructions like sha2
15:41 < andytoshi> true, i guess what i mean is "commonly believed"
15:41 < iddo> if sha2 is computationally indistinguishable from a random oracle, then truncated-sha2 is fine
15:42 < andytoshi> sure, but this isn't true because eg there are length extension attacks
15:42 < andytoshi> which distinguish it from a random oracle
15:42 < iddo> not for sha256d
15:43 < andytoshi> yeah -- and mining even depends on sha256d looking like a random oracle
15:43 < andytoshi> so tbh i am just as confused by the ripemd usage as anybody
15:46 < maaku> andytoshi: as I said, if a weakness is found in sha256, it is more likely to be able to be applied to sha256^2 than ripemd160(sha256())
15:47 < iddo> another question is why not just use the full 256 bits of sha256d, then you get an even better benefit of 256 bits of security if you don't re-use addresses, instead of 160 bits... the drawbacks are more bloat on the blockchain, and longer addresses for people to use
15:47 < maaku> so therefore, it's more likely that the current setup would protect users even in a catastrophic break of sha256
15:47 < maaku> iddo: even 160 bits is excessive. the birthday paradox doesn't apply here
15:47 < iddo> maaku: but what if a weakness is found in ripemd-160 ... ?
15:48 < maaku> iddo: nothing happens unless a weakness is found in ripemd-160 AND sha-256
15:48 < maaku> its additive security
15:50 < iddo> maaku: no, if you have 2nd-preimage attack on ripemd-160, then just create fresh ECDSA keypairs + sha256 hash, in a way that you get the same image (i.e. the 2nd-preimage attack) as someone elses Bitcoin address, and then steal his coins
15:52 < iddo> well actually it's not clear, depends how the 2nd-preimage attack works
15:52 < andytoshi> you'd have to get a preimage for the sha256 as well
15:52 < andytoshi> if you can 2nd-preimage SHA256 then i think you've got a problem, because if you can get the same SHA256 hash, it won't matter that you apply RIPEMD-160 on top of it
15:52 < andytoshi> but this is only a concern if you know the pubkey that you are trying to preimage
15:53 < andytoshi> pubkey whose image you are trying to duplicate*
15:54 < andytoshi> but until you spend a coin with a certain address, you don't expose the pubkey (or even its SHA256 hash), so you're ok in the case of no address reuse
15:54 < iddo> if you just find 2nd-preimage of random pubkey, then it wouldn't help you because you wouldn't know the corresponding privkey
15:55 < andytoshi> oh, right, derp
15:57 < iddo> i actually don't really see how either sha2 or ripemd 2nd-preimage attacks can be done in this context (i.e. in the context where you create random-looking pubkeys that are supposed to be the preimage, by invoking the ECDSA keygen)
19:02 < nsh> oh
19:03 < nsh> andytoshi / gmaxwell: thinking back to the question of the factor of 8 in curve25519 scalars, could it be to do with the square property of x coordinates?
19:04 < nsh> --
19:04 < nsh> Firstly, since the field is only 255 bits, the 256th bit is always zero. Thus if an attacker sees a series of 32-byte strings where the top bit of the last byte is always zero, then they can be confident that they are not random strings. This is easy to fix however, just XOR in a random bit and mask it out before processing.
19:04 < nsh> Secondly, the attacker can assume that a 32-byte string is an x coordinate and check whether x3 + 486662x2 + x is a square. This will always be true if the strings are x coordinates, by the curve equation, but will only be true 50% of the time otherwise. This problem is a lot harder to fix.
19:04 < nsh> -- https://www.imperialviolet.org/2013/12/25/elligator.html
19:04 < nsh> (probably not, but it just came back to mind while reading that page)
19:06 < nsh> "Square roots are defined in the standard way for finite fields where q ≅ 5 mod 8:"
19:07 < nsh> (eight is rather low number for which to ascribe meaning to coincidence, i know...)
19:35 < andytoshi> nice find nsh, i dunno, i'll have to study this
19:36 < andytoshi> it looks to me that this is about disguising x coordinates, which isn't a goal of plain old ed25519
19:36 < andytoshi> eg they have bit 254 always set, which is a pretty obvious tell
19:38 < nsh> right
19:38 < andytoshi> also iirc we are talking about privkey encoding anyway, which is not broadcast
19:39  * nsh nods
19:39 < andytoshi> otoh, the square property of x coordinates could very well be involved with the factor of 8, i don't know
19:39 < nsh> yes, maybe very vaguely
19:39 < maaku> anyone asked DJB?
19:40 < nsh> no, i was going to tweet him
19:40 < andytoshi> no, i think everyone here is intimidated by him :P
19:40 < nsh> but he doesn't use twitter that extensively. might be better to email him
19:40 < nsh> oh, i don't have that problem :)
19:40 < andytoshi> :)
19:40 < nsh> i fell in the contempt couldron as an infant and the potion had a permanent effect
19:41 < nsh> cauldron*
19:41 < maaku> well it'd spoil the puzzle anyway :)
19:42 < andytoshi> haha
22:38 < warren> http://coinmarketcap.com/  interesting how they count #2
22:44 < phantomcircuit> warren, XRP is an altcoin with bad security
22:44 < phantomcircuit> and a totally fucking HUGE premine
22:45 < warren> phantomcircuit: they included the entire premine in that "market cap"
22:46 < gmaxwell> of course they did, it's part of the market cap.
22:47 < gmaxwell> I dunno how else you'd calculate it.
22:51 < phantomcircuit> warren, the premine is already on the network
22:51 < phantomcircuit> that is a reasonable way to calculate the market cap
22:52 < BlueMatt> it'd be nice if they showed market depth too, though
22:52 < phantomcircuit> however XRP is very illiquid
22:52 < phantomcircuit> so that doesn't mean much of naything
23:01 < phantomcircuit> BlueMatt, nearly all of the bids are for the exact same amount of btc
23:01 < phantomcircuit> 0.2625
23:02 < phantomcircuit> which tells me they're fake bids
23:02 < CodeShark> market caps in general for any of these coins is not particularly meaningful :)
23:02 < CodeShark> you need to take depth into account
23:03 < CodeShark> but these numbers do sound impressive, nonetheless
23:03 < CodeShark> so they do have press value
23:04 < maaku> yeah market cap is totally useless
23:04 < maaku> http://37signals.com/svn/posts/1941-press-release-37signals-valuation-tops-100-billion-after-bold-vc-investment
23:04 < CodeShark> lol
23:06 < BlueMatt> phantomcircuit: even sill, the market depth is significantly lower than btc, which should be shown there
23:07 < CodeShark> a meaningful statistic would be, say, how much you could get in dollars if you currently held 10% of it and sold it right now
23:07 < BlueMatt> maaku: lol, nice
23:08 < CodeShark> for most coins, if you sold 10% of it on any public orderbook, the price would drop to zero :)
23:08 < phantomcircuit> maaku, lolol i love that
23:09 < phantomcircuit> BlueMatt, the most meaningful thing is the total size of all the bids
23:09 < phantomcircuit> asks are useless since you'll have some fools with things like 1 BTC @ 100000000000000000000000 USD
23:09 < BlueMatt> phantomcircuit: yes, agreed
23:11 < CodeShark> you could look at depth on both sides up to, say, 1% of total coins in existence
23:12 < phantomcircuit> for example
23:12 < phantomcircuit> there is 39275377.92397302 USD in bids on mtgox
23:12 < phantomcircuit> which is actually not even that much money
23:13 < phantomcircuit> but iirc the kraken XRP exchange has the equivalent of like a few thousand dollars total
23:13 < BlueMatt> phantomcircuit: yea, but that is mtgox...you cant really count mtgusd as usd anyway
23:13 < BlueMatt> anyway, yea, total bids isnt that high compared to the market cap
23:14  * BlueMatt ponders how that ratio compares to other assets...
23:15 < phantomcircuit> BlueMatt, it's difficult to compare because most assets the orderbooks are full of highly leveraged offers
23:15 < phantomcircuit> especially currency markets
23:15 < phantomcircuit> people there are often trading on 10000:1 leverage
23:16 < phantomcircuit> or more
23:16 < BlueMatt> true, but you can trade on leverage on btc on...whats the exchange again?
23:16 < phantomcircuit> bitfinex?
23:16 < phantomcircuit> the idiot who stole the bitcoinica source code
23:17 < BlueMatt> I suppose you cant really compare the numbers until the exchange markets grow up a bit, but still, would be interesting to compare those numbers
--- Log closed Fri Dec 27 00:00:31 2013