--- Log opened Fri Feb 13 00:00:53 2015
00:01 -!- hktud0 [wq@unaffiliated/fluffybunny] has quit [Read error: Connection reset by peer]
00:04 -!- hktud0 [wq@unaffiliated/fluffybunny] has joined #bitcoin-wizards
00:08 -!- lclc_bnc is now known as lclc
00:09 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-lceammlazwdcikko] has quit [Read error: Connection reset by peer]
00:12 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kqpjdrldaxwwpxtp] has joined #bitcoin-wizards
00:14 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
00:16 -!- xabbix__ [~xabbix@109.66.58.93] has quit [Read error: Connection reset by peer]
00:17 -!- jaekwon_ [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Ping timeout: 244 seconds]
00:25 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
00:50 -!- ielo [~ielo@host-92-24-40-10.ppp.as43234.net] has joined #bitcoin-wizards
00:54 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards
01:01 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection]
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards
01:05  * andy-logbot is logging
01:08 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kqpjdrldaxwwpxtp] has quit [Read error: Connection reset by peer]
01:12 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-irdvhglemcyltpsl] has joined #bitcoin-wizards
01:16 -!- lclc is now known as lclc_bnc
01:26 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards
01:38 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
01:42 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
01:47 -!- btcz [~benten@unaffiliated/benten] has joined #bitcoin-wizards
01:54 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
01:55 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has quit [Remote host closed the connection]
01:55 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards
01:57 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-wizards
01:58 -!- lclc_bnc is now known as lclc
01:59 -!- btcz [~benten@unaffiliated/benten] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
02:06 -!- coiner [~linker@115.79.43.208] has joined #bitcoin-wizards
02:08 -!- bit2017 [~linker@115.79.43.208] has joined #bitcoin-wizards
02:09 -!- bit2017 [~linker@115.79.43.208] has quit [Max SendQ exceeded]
02:09 -!- bit2017 [~linker@115.79.43.208] has joined #bitcoin-wizards
02:11 -!- coiner [~linker@115.79.43.208] has quit [Ping timeout: 265 seconds]
02:14 -!- bit2017 [~linker@115.79.43.208] has quit [Ping timeout: 250 seconds]
02:15 -!- TonyClifton [~TonyClift@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards
02:16 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 246 seconds]
02:20 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:f930:3d26:ce70:95f4] has joined #bitcoin-wizards
02:26 -!- ielo [~ielo@host-92-24-40-10.ppp.as43234.net] has quit [Ping timeout: 255 seconds]
02:31 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
02:31 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
02:52 -!- UmInAsHoE [~textual@156.18-35-82.static.virginmediabusiness.co.uk] has joined #bitcoin-wizards
03:01 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards
03:09 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds]
03:10 -!- p15__ [~p15@111.193.161.161] has joined #bitcoin-wizards
03:12 -!- p15_ [~p15@182.50.108.89] has quit [Ping timeout: 256 seconds]
03:14 -!- UmInAsHoE [~textual@156.18-35-82.static.virginmediabusiness.co.uk] has quit [Ping timeout: 250 seconds]
03:26 -!- lclc is now known as lclc_bnc
03:34 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
03:39 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards
03:42 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds]
03:43 -!- lclc_bnc is now known as lclc
03:43 -!- ielo [~ielo@134.219.227.35] has joined #bitcoin-wizards
03:45 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards
03:57 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
04:00 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-irdvhglemcyltpsl] has quit [Ping timeout: 250 seconds]
04:02 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-requkizdhwxnumsz] has joined #bitcoin-wizards
04:15 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards
04:21 -!- OneNomos [~OneNomos@gateway/vpn/privateinternetaccess/onenomos] has joined #bitcoin-wizards
04:23 -!- realcr [~real@bzq-79-183-147-92.red.bezeqint.net] has joined #bitcoin-wizards
04:26 -!- airbreather [~AirBreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards
04:26 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has quit [Remote host closed the connection]
04:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
04:39 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards
04:51 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-requkizdhwxnumsz] has quit [Ping timeout: 252 seconds]
04:53 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-tmhguvgjezhuclhz] has joined #bitcoin-wizards
05:07 -!- antgreen [~user@74.112.41.171] has joined #bitcoin-wizards
05:10 -!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 245 seconds]
05:16 -!- p15__ [~p15@111.193.161.161] has quit [Max SendQ exceeded]
05:17 -!- p15 [~p15@111.193.161.161] has joined #bitcoin-wizards
05:20 -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
05:28 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
05:30 < kanzure> "But, let's say, 5 years from now, some faction of miners who own soon-to-be-obsolete equipment will decide to boost their profits with a replace-by-fee pool and a corresponding wallet. They can market it as "1 of 10 hamburgers are free" if they have 10% of the total hashpower."
05:30 < kanzure> hamburgers?
05:31 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-tmhguvgjezhuclhz] has quit [Ping timeout: 250 seconds]
05:31 < fluffypony> replace-by-cheese
05:32 < kanzure> hah i have not heard this argument before, "They won't be attacking Bitcoin, they will attack merchants who accept payments with 0 confirmations. This attack has nothing to do with Bitcoin consensus mechanism (as Bitcoin protocol doesn't provide a consensus over mempool contents), thus it is not an attack on Bitcoin."
05:33 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-vbhgexgikxdjkjwq] has joined #bitcoin-wizards
05:48 -!- lclc is now known as lclc_bnc
05:48 < kanzure> "Deterministic Pay-to-script-hash multi-signature addresses through public key sorting" http://sourceforge.net/p/bitcoin/mailman/message/33408139/
05:52 -!- orperelman [~orperelma@bzq-79-181-128-67.red.bezeqint.net] has joined #bitcoin-wizards
05:56 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards
05:58 -!- lclc_bnc is now known as lclc
06:02 < instagibbs> I think people over-estimate the damage a serious 0-conf double-spend against a merchant would do to overall system confidence. People that don't trust 0-conf won't care, and people that do will change behavior over time. Miners can and have easily done it profitably to no detriment.
06:02 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has quit [Quit: Page closed]
06:07 -!- maraoz [~maraoz@43-161-16-190.fibertel.com.ar] has joined #bitcoin-wizards
06:26 -!- epscy_ [~epscy@176.126.241.239] has quit [Ping timeout: 245 seconds]
06:27 -!- epscy_ [~epscy@176.126.241.239] has joined #bitcoin-wizards
06:28 -!- linelevel [~mike@unaffiliated/linelevel] has joined #bitcoin-wizards
06:28 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Remote host closed the connection]
06:28 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has joined #bitcoin-wizards
06:39 -!- antgreen [~user@74.112.41.171] has quit [Ping timeout: 264 seconds]
06:40 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-ynphsuryknakxcvi] has joined #bitcoin-wizards
06:45 -!- linelevel1 [~mike@96.237.65.66] has joined #bitcoin-wizards
06:48 -!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 245 seconds]
06:56 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
06:59 -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Ping timeout: 256 seconds]
07:02 -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has quit [Remote host closed the connection]
07:08 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 245 seconds]
07:12 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Ping timeout: 256 seconds]
07:15 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
07:17 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
07:19 -!- Emcy [~MC@152.27.187.81.in-addr.arpa] has joined #bitcoin-wizards
07:19 -!- Emcy [~MC@152.27.187.81.in-addr.arpa] has quit [Changing host]
07:19 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
07:35 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds]
07:43 -!- siraj [~siraj@triband-mum-120.62.42.243.mtnl.net.in] has joined #bitcoin-wizards
07:47 -!- afk11 [~thomas@89.100.72.184] has joined #bitcoin-wizards
07:50 -!- xabbix_ [~xabbix@bzq-109-65-123-131.red.bezeqint.net] has joined #bitcoin-wizards
07:50 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Ping timeout: 250 seconds]
07:51 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 264 seconds]
07:52 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
07:52 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Remote host closed the connection]
07:53 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has joined #bitcoin-wizards
08:04 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
08:04 -!- xabbix__ [~xabbix@bzq-79-180-107-228.red.bezeqint.net] has joined #bitcoin-wizards
08:05 -!- xabbix_ [~xabbix@bzq-109-65-123-131.red.bezeqint.net] has quit [Read error: Connection reset by peer]
08:11 -!- siraj_ [~siraj@117.98.36.52] has joined #bitcoin-wizards
08:12 -!- linelevel1 is now known as linelevel
08:12 -!- linelevel [~mike@96.237.65.66] has quit [Changing host]
08:12 -!- linelevel [~mike@unaffiliated/linelevel] has joined #bitcoin-wizards
08:13 -!- siraj [~siraj@triband-mum-120.62.42.243.mtnl.net.in] has quit [Ping timeout: 252 seconds]
08:17 -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has joined #bitcoin-wizards
08:18 -!- gonedrk1 [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Read error: Connection reset by peer]
08:21 -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Max SendQ exceeded]
08:22 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
08:24 -!- orperelman [~orperelma@bzq-79-181-128-67.red.bezeqint.net] has quit [Ping timeout: 265 seconds]
08:24 -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has joined #bitcoin-wizards
08:25 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Remote host closed the connection]
08:25 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has joined #bitcoin-wizards
08:25 -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Max SendQ exceeded]
08:27 -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has joined #bitcoin-wizards
08:35 -!- op_mul [~op_mul@178.62.78.122] has joined #bitcoin-wizards
08:35 < op_mul> holy shit.
08:35 < op_mul> hey guys, guys, trust us we can make a distributed consensus with all these awesome new features, it's released in a few weeks!
08:36 < kanzure> which thing are you replying to
08:36 < op_mul> only our ECDSA library leaks the privkey in 256 signatures.
08:36 < kanzure> make 'em count
08:36 < op_mul> ethereum.
08:37 < nsh> really? :/
08:37 < op_mul> "Attack scenario: The attacker can recover the private key of the victim as long as the victim used the go implementation and the attacker collected 512 signatures. The reason for this is that the nonce is "msg `xor` private key" which is not unpredictable as required by ECDSA."
08:37 < nsh> oh my
08:37 < nsh> link?
08:37 < op_mul> https://bounty.ethdev.com/users/6fqhe7yn6XDCBr6wM\
08:37 < op_mul> https://github.com/jonasnick/ecdsaPredictableNonce/blob/master/explanation/explanation.pdf
08:37 < nsh> ty
08:38 < Apocalyptic> op_mul, heh
08:38 < nsh> friday the 13th is a good day to publish such a finding :)
08:38 < earlz> lawl
08:39 < earlz> ethereum sounds like some really cool technology that won't ever actually work in practice heh
08:40 < nsh> it's all grist for the mill. even if it never goes anywhere, whatever progress and insight and intermediary tools/results are achieved will be reusable
08:40 < kanzure> i'm sure there are many parts of ethereum that will work, such as any gui components
08:40 < nsh> lol
08:40 < earlz> lmfao
08:40 < op_mul> nsh: I'm pretty sure the gist is going to be "writing 5 different core clients in 5 languages was a bad idea"
08:41 < earlz> 5 different core clients, _that maintain consensus_
08:41 < nsh> lol :)
08:41 < earlz> Do they even have a conflict resolution mechanism when consensus breaks (like mining in bitcoin)
08:42 < nsh> do what the other silly did and reduce to a consensus of one
08:42 < nsh> the waffle about theory to justify it
08:42 < op_mul> it's set up a lot differently, but they are proof of work just like Bitcoin. the proof of stake stuff was just hot air.
08:42 < earlz> I know some retarded altcoin claimed to solve the 51% attack a while back.. by just ignoring any fork the wallet isn't currently on lol
08:43 < fluffypony> earlz: "solved" in much the same way Darkcoin has "instant transactions"
08:43 < op_mul> well there's no end to people making unworkable consensus systems like that. the current flavour is making proof of stake coins that can't reorganise more than X blocks.
08:44 < op_mul> fluffypony: ah yes, lets give masternodes the ability to invalidate blocks. that'll go well.
08:44 < earlz> I review the code in altcoins, and it's scary how many PoS coins don't even have sync checkpoints enabled
08:44 < fluffypony> no but you don't understand, op_mul, masternode operators are all friendly and they work in a spirit of cooperation because they're buddies, there could be no collusion or attacking of each other!
08:45 < fluffypony> best frendz 4 lyf, masternode ops 2015
08:45 < earlz> there really needs to be a tipbot in here rofl
08:45 < op_mul> fluffypony: of course not! it's not like they have a financial incentive to DoS anybody else for their own gain.
08:45 < siraj_> is it possible to send http api requests (to say, yelp) from a bitcoin script that lives on the blockchain?
08:45 < fluffypony> op_mul: incentivise *all* of the things!
08:46 < earlz> siraj_: wat/no
08:46 < fluffypony> siraj_: Bitcoin is specifically designed to be p2p and not reach out over other protocols
08:46 < fluffypony> except for payment protocol, but we don't talk about that :-P
08:46 < earlz> that's no on-chain
08:46 < earlz> not*
08:47 < kanzure> siraj_: wrong channel, use #bitcoin
08:47 < kanzure> earlz: checkpoints don't do what you think they do
08:48 < op_mul> kanzure: they do in proof of stake.
08:48 < earlz> they keep the coin centralized basically, but can allow for some double-spend/orphan attacks
08:48 < fluffypony> "checkpoints" in PoS aren't the same as "checkpoints" in PoW
08:48 < earlz> sync checkpoints* (ie, PoS oneS)
08:48 < op_mul> fluffypony: although probably illegal and totally unethical I did like block withholding / reorg proofs as proof of work.
08:48 < fluffypony> so yeah, what earlz said
08:48 < MRL-Relay> [tacotime] op_mul: ehm, kinda wondering why they just never used our lib https://github.com/btcsuite/btcd/tree/master/btcec
08:48 < earlz> Where there is a public key in the wallet and it listens to checkpoints broadcast from a server
08:48 < MRL-Relay> [tacotime] wheel reinvention..
08:49 < fluffypony> tacotime: because they don't understand Go?
08:49 < MRL-Relay> [tacotime] heh. we even wrapped it nicely into the native ec package!
08:49 < op_mul> tacotime: yours isn't innovative enough. needs a flashy name. does yours leak the private key in signatures?
08:50 < fluffypony> good point, and if you could please use "Dark" somewhere in the name that would be great
08:50 < earlz> that's a feature! it's for key recovery in case you lose it, right?
08:50 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]
08:51 < MRL-Relay> [tacotime] op_mul: "aerialSecpK", uses k values from random.org
08:51 < fluffypony> ouch
08:52 < fluffypony> at least its RNG is deterministic :-P
08:52 < fluffypony> (in a manner of speaking)
08:52 -!- dogetime [~dogetime@unaffiliated/dogetime] has joined #bitcoin-wizards
08:52 < op_mul> tacotime: you jest but I've seen that mentioned on bitcointalk several times as a serious suggestion.
08:52 < MRL-Relay> [tacotime] sigh
08:53 < earlz> deterministic RNG? wat
08:53 < op_mul> well for ECDSA deterministic nonces are what you want. just not ethereum flavoured ones.
08:55 < op_mul> in a way it's a bit of security theater, if your software's author is so incompetent that they can't make random nonces then their private key generation is unlikely to be any good either.
08:56 < fluffypony> pffft, just write your own RNG in JavaScript.
08:56 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-ynphsuryknakxcvi] has quit [Quit: Connection closed for inactivity]
08:57 < MRL-Relay> [tacotime] om_mul: well, they're cgo hooking libsecp256k1 it looks like, i guess they assumed if they wrote a wrapper they could do no evil unfortunately.
08:57 < earlz> Just make your own RNG real quick, but keep it closed source to make sure it's secure
08:57 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
08:58 < fluffypony> earlz: perfect
09:00 < MRL-Relay> [tacotime] just goes to show that even calling sane crypto functions is not so good if you're not sure how to use them... i'm not sure how much faster that is for go as cgo hooks are very expensive too.
09:00 -!- afk11 [~thomas@89.100.72.184] has quit [Quit: Leaving.]
09:00 -!- afk111 [~thomas@89.100.72.184] has joined #bitcoin-wizards
09:04 -!- siraj_ [~siraj@117.98.36.52] has quit [Read error: Connection reset by peer]
09:05 -!- siraj [~siraj@106.207.65.53] has joined #bitcoin-wizards
09:07 -!- siraj [~siraj@106.207.65.53] has quit [Client Quit]
09:09 -!- flower [~user@202.44.238.15] has quit [Max SendQ exceeded]
09:10 < op_mul> tacotime: I'm baffled why they even support uncompressed EC keys. they're a legacy bitcoin thing and they've got some reason just thrown it into the new mix.
09:11 < op_mul> s/got/for/
09:12 -!- bedeho [~bedeho@195.159.234.190] has quit [Quit: Nettalk6 - www.ntalk.de]
09:14 < MRL-Relay> [tacotime] op_mul: i can see if you would support for the reason you just feel more comfortable working with X,Y in the math, but, ehm, choose one way or the other.
09:15 < op_mul> tacotime: doesn't everybody just unpack the compressed points into X and Y anyway?
09:15 < MRL-Relay> [tacotime] op_mul: yes, but i mean, if you're uncomfortable coding the unpack steps because you're afraid you might introduce more mistakes.
09:16 < nickler> I don't want to protect the Ethereum team but I believe vbuterin's story: "[...] it was an experiment that Gav and Jeff did back in March 2014 that was never changed back for some reason; it was not intended to go into production code". (https://www.reddit.com/r/ethereum/comments/2vn7nd/ethereum_bug_bounty_has_first_leaderboard_entry/cojitc1)
09:17 < nickler> Nonetheless I am relatively sure that the code will be full of bugs in the foreseeable future and it would be good to be open about it.
09:17 < op_mul> tacotime: point taken. I'd just see that as an indication that I shouldn't be working with EC to begin with.
09:17 < nickler> By the way, I should point out that my attack only works against the textbook method and not libsecp because it might sign the negative nonce (as I pointed out here: https://github.com/jonasnick/ecdsaPredictableNonce). If somebody finds a better attack (and my intuition says there is) I'd be happy to learn about it.
09:19 -!- flower [~user@202.44.238.15] has joined #bitcoin-wizards
09:20 -!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards
09:21 < op_mul> nickler: probably one more for andytoshi than me. for testing or not, it's quite insane that it made it into their codebase to begin with.
09:21 < MRL-Relay> [tacotime] nickler: that code is a weird trainwreck anyway; if msg is anything other than a 32-byte hash you get an oob panic
09:21 < MRL-Relay> [tacotime] well, anything greater than 32 bytes
09:22 < op_mul> I'm a big believer in indicative behaviour in people's code. that's a pretty good example of a moronic one that's not immediately exploitable, but an indicator of future fun.
09:24 < nickler> fun, I fully agree :)
09:25 -!- ielo [~ielo@134.219.227.35] has quit [Ping timeout: 265 seconds]
09:27 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 246 seconds]
09:28 < gmaxwell> nickler: "because it might sign the negative" is a non-issue, even if you can't deal with it any other way you would only need twice the signatures on average to manage to sample both sides.
09:30 < gmaxwell> more horrifying that anyone who could think for a moment that that was an okay thing to do was writing that kind of code. Then again that kind of stupidity is predictable and was predicted... it's why a couple months ago the libsecp256k1 API was changed to make it really hard to abuse in that way.
09:31 < nickler> but my method leaks only one bit per key and for that I have to know the nonce. You would end up with a linear system with 512 equations for 256 bits which has no solution.
09:33 < nickler> *one bit per sig
09:33 < nsh> what measures were taken to make it harder to footshoot in libsecp256k1?
09:33 < gmaxwell> ah, fair enough, you don't know which one was right, and searching would be 2^256.
09:34 < nsh> not intuitive to me how you'd achieve
09:34 < nsh> that
09:34 < gmaxwell> nsh: we removed the callers ability to control the nonce unless they write a callback function and pass it in.
09:34 < nsh> ah, neat
09:36 < gmaxwell> (little unfortunate in that RFC6979 is slow as crap, and doing that also requires we have an internal copy of sha256 that doubles the object code size of the library; but immunity to stupid was worth it (as demonstrated...))
09:39 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
09:39 < op_mul> at the risk of sounding stupid, is there a reason that RFC6979 is so complex? I was blown away by that.
09:43 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
09:44  * nsh nods
09:46 < nsh> i think you can do detDSA more simply than RFC6979 but it might be some work to derive and prove secure
09:46 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has joined #bitcoin-wizards
09:50 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:f930:3d26:ce70:95f4] has quit [Ping timeout: 245 seconds]
10:01 -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards
10:01 -!- benten [~benten@unaffiliated/benten] has quit [Client Quit]
10:11 -!- afk111 [~thomas@89.100.72.184] has quit [Read error: No route to host]
10:11 -!- afk11 [~thomas@89.100.72.184] has joined #bitcoin-wizards
10:12 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
10:18 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
10:18 < gmaxwell> op_mul: because it's copying a pre-existing CSPRNG
10:19 < gmaxwell> doing so makes it easier to argue that 6979 isn't up to no good. But otherwise there is no reason for it that I'm aware of.
10:19 < gmaxwell> Partially it's not that complex, the RFC is just somewhat opaque.
10:20 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection]
10:21 < gmaxwell> (e.g. if you go look at the code in secp256k1 and were to write a spec for it, you'd likely end up with a much simpler description)
10:22 < op_mul> gmaxwell: ah. in a way you'd almost be better off just doing H(K + m) wouldn't you? in terms of simplicity and whatnot, I don't see any immediate problem with that.
10:25 -!- maaku_ is now known as maaku
10:25 < GAit> I'm really impressed with libsecp256k1
10:27 < GAit> did some ctypes bindings for python that we'll probably release soon (up to 600X times faster than pycoin) and even tried to compile it with emscripten, 10-20X speed up on bitcoinjs
10:30 < GAit> I think 20X with firefox and 10x on chrome
10:59 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Remote host closed the connection]
10:59 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards
11:00 -!- xabbix__ [~xabbix@bzq-79-180-107-228.red.bezeqint.net] has quit [Ping timeout: 246 seconds]
11:01 -!- xabbix__ [~xabbix@bzq-79-176-58-46.red.bezeqint.net] has joined #bitcoin-wizards
11:04 -!- sipa [~pw@2a02:348:5e:5a29::1] has joined #bitcoin-wizards
11:11 -!- lclc is now known as lclc_bnc
11:11 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
11:15 -!- TonyClifton [~TonyClift@gateway-nat.fmrib.ox.ac.uk] has quit [Remote host closed the connection]
11:15 -!- op_mul [~op_mul@178.62.78.122] has quit [Ping timeout: 240 seconds]
11:19 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
11:26 -!- siraj [~siraj@106.221.158.211] has joined #bitcoin-wizards
11:27 -!- tylersmith [~tylersmit@173.247.206.110] has joined #bitcoin-wizards
11:47 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
11:57 -!- ielo [~ielo@host-78-147-237-163.as13285.net] has joined #bitcoin-wizards
12:00 -!- AlienProject [~Alien_Pro@72.53.101.165] has quit [Ping timeout: 265 seconds]
12:03 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds]
12:04 < phantomcircuit> gmaxwell, i hadn't noticed that it was based on an HMAC function before
12:06 -!- siraj [~siraj@106.221.158.211] has quit [Remote host closed the connection]
12:09 -!- tylersmith [~tylersmit@173.247.206.110] has quit []
12:20 -!- orik [~orik@75.149.169.53] has joined #bitcoin-wizards
12:20 -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards
12:22 -!- dogetime [~dogetime@unaffiliated/dogetime] has left #bitcoin-wizards []
12:27 < gmaxwell> it's based on one of the NIST HMAC DRBG functions.
12:27 < gmaxwell> I think the RFC itself doesn't actually point this out (or if it does its burried in it someplace)
12:27 < sipa> *brrr*
12:28 < sipa> it does mention this:
12:28 < sipa> Rationale
12:28 < sipa> The process described in the previous sections mimics the "Approved" generation process of k described in Annex D of [X9.62], with the "HMAC_DRBG" pseudorandom number generator.
12:28 < gmaxwell> ah good. this explains why I knew it was. :)
12:29 < gmaxwell> really for our use in bitcoin land it's super irrelevant that its slow.
12:30 -!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards
12:32 -!- afk11 [~thomas@89.100.72.184] has quit [Read error: Connection reset by peer]
12:32 -!- afk111 [~thomas@89.100.72.184] has joined #bitcoin-wizards
12:36 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
12:45 -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
12:50 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
12:51 -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Remote host closed the connection]
12:55 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-vbhgexgikxdjkjwq] has quit [Read error: Connection reset by peer]
12:58 -!- Starsoccer [~starsocce@unaffiliated/starsoccer] has quit [Ping timeout: 252 seconds]
12:59 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-zdxgazusmltlmqvg] has joined #bitcoin-wizards
13:11 < phantomcircuit> gmaxwell, right
13:11 < phantomcircuit> i assume there isn't any question of it's sanity other wise?
13:21 -!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 256 seconds]
13:32 -!- AlienProject [~Alien_Pro@72.53.101.165] has quit [Ping timeout: 245 seconds]
13:34 -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards
13:49 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
13:50 < bramc> Hey everybody I have questions/thoughts about replace-by-fee and the general stuff surrounding it
13:51 < bramc> First, a really dumb question: Does bitcoin support utxos being spent at the same layer as they're generated on? The complications behind that seem not worth it, although it's a relatively minor detail.
13:52 < tromp__> hi Bram. txs must redeem all inputs from earlier blocks
13:53 < kanzure> ".. suggests that searching for a storage medium that lives forever may be a waste of energy, because the laws of physics themselves limit the amount of time that any information can be kept."
13:53 -!- paperbot [~paperbot@unaffiliated/kanzure/bot/paperbot] has joined #bitcoin-wizards
13:53 < kanzure> paperbot: http://iopscience.iop.org/1367-2630/16/12/123049
13:53 < paperbot> http://libgen.info/scimag/get.php?doi=10.1088%2F1367-2630%2F16%2F12%2F123049
13:53 < kanzure> hmph
13:53 < phantomcircuit> tromp__, i dont think that's right, iirc a transaction can spend outputs from any tx that appears in a prior block OR before it in the current block
13:53 < bramc> The other question, actually a thought/proposal has to do with the logic behind what transactions to accept/distribute
13:53 < kanzure> paperbot: http://iopscience.iop.org/1367-2630/16/12/123049/pdf/1367-2630_16_12_123049.pdf
13:54 < bramc> phantomcircuit, AUGH
13:54 < paperbot> http://diyhpl.us/~bryan/papers2/paperbot/e2eeadf8dbaf1a207adaaac0659729e8.pdf
13:55 < phantomcircuit> bramc, it's actually not that bad
13:55 < phantomcircuit> but yeah it can be kind of annoying
13:56 < phantomcircuit> bramc, basically you want to keep all valid non-confirmed transactions and then only make a decision about which to include in the next block if you actually are a miner
13:56 < phantomcircuit> but actually doing that is a trivial dos vector
13:56 < phantomcircuit> so you need to store a subset of all of the valid non-confirmed transactions
13:56 < phantomcircuit> the easiest way to do that is to simply not store conflicted transactions
13:56 < kanzure> wouldn't a miner be picking a subset anyway?
13:57 < kanzure> are you saying the subset is still vulnerable to a denial of service attack?
13:57 < phantomcircuit> kanzure, depends on whether theres > 1MB of transactions total
13:57 < kanzure> what if you have strict bounds...?
13:57 < phantomcircuit> you need to implement some sort of dos mitigation strategy
13:57 < phantomcircuit> what that is is entirely implementation dependent
13:57 < bramc> I'm basically sold on replace-by-fee and having priority be based on fee-per-byte, on the grounds that it will have to get there eventually so it might as well be done now
13:57 < phantomcircuit> like i have a server with 256gb of ram
13:57 < kanzure> ah i see (i thought you were saying "make a decision about which to include" is vulnerable to denial of service)
13:57 < phantomcircuit> i can basically just ignore dos mitigation on that server
13:58 -!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards
13:58 < phantomcircuit> bramc, welllll for a miner what they actually want to do is calculate which block would result in the highest total rewards
13:58 < phantomcircuit> rewards include fees, block reward, but also modifications for increased orphan rates based on size
13:59 < phantomcircuit> this calculation is non trivial and potentially proprietary black magic
13:59 < bramc> phantomcircuit, yes that dos is exactly my concern as well, you can trivially dos the network as a whole by introducing lots of garbage transactions which won't get accepted but use up a ton of bandwidth everywhere, and the trivial fix for that (ignore transactions which don't meet the local threshold for acceptance) can result in transactions which are published when everybody's full never getting out there
13:59 < phantomcircuit> (not to mention heavily dependent on whether the miner has a high bandwidth block broadcasting network to rely on)
13:59 -!- Mably is now known as Skipppy
14:00 < tromp__> bramc: i was wrong and phantomcircuit is right; you can spent outputs of earlier txs in the same block
14:00 < bramc> phantomcircuit, What do you mean 'increased orphan rates based on size'? The decision of what to accept is trivial: make a list of everything, then start knocking out transactions with the lowest fee/byte first until you're under the limit.
14:01 < tromp__> which makes me wonder, what is the earliest tx to do so?
14:01 < bramc> tromp__, I have a sneaking suspicion that that functionality is hardly ever used
14:01 < phantomcircuit> bramc, well lets say im a very large sophisticated miner
14:02 < phantomcircuit> i might have a hundred nodes monitoring transaction propogation on the network to get a block propogation advantage
14:02 < phantomcircuit> the selection algorithm for transactions is potentially very much non trivial
14:02 < phantomcircuit> or it can be pretty dumb
14:02 < phantomcircuit> bramc, im sure it's been used since i've done it before
14:03 < bramc> Oh, you mean you're concerned about larger blocks propogating slower? Let's live in a shiny happy place and pretend that the transaction rate limit is low enough that that isn't a major issue
14:03 < bramc> phantomcircuit, you bastard, now that functionality must be forever supported because of your one stupid transaction in the block chain
14:03 < phantomcircuit> the limit is that bitcoin core wallet for a very long time refused to generate transactions with unconfirmed inputs
14:03 < tromp__> i'm also curious to know what is the longest chain of txs in a single block
14:04 < phantomcircuit> heh pretty sure you'd have to support it either way
14:05 < bramc> Anyhow, here's my proposal as to how to deal with transaction dos, which doesn't affect the issues of acceptance strategy because it's versatile enough to support all of them: There's a new message in the peer protocol which means 'don't send me anything with a fee/byte less than X', and when a peer locally accepts something with a lower fee/byte it remembers which peers it didn't send it to and forwards it along to them
14:05 < bramc>  at such time as they decide they are willing to accept it.
14:06 < bramc> tromp__, I'm guessing 2 or 3, and that it's been used dozens, perhaps even hundreds, of times.
14:07 -!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards
14:08 < bramc> Some people are freaking out about this all being a conspiracy to make zeroconf stop working. My instinctive rebuttal to that is 'get away from me you fucking moron'.
14:10 < phantomcircuit> bramc, zeroconf doesn't work to start with
14:10 < phantomcircuit> so that's easy enough
14:10 < bramc> phantomcircuit, Yes that's my point. It feels like debating with a flat earther.
14:11 < bramc> But on a more serious note I'd like to hear thoughts about my proposed anti-dos protocol extension, which I'm honestly surprised isn't already in there.
14:15 -!- belcher [~belcher-s@5ec3238c.skybroadband.com] has joined #bitcoin-wizards
14:15 -!- belcher [~belcher-s@5ec3238c.skybroadband.com] has quit [Changing host]
14:15 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards
14:15 < bramc> Also I think petertodd's logic for replacement to require both a better fee/byte and a higher absolute fee is a little odd, because it doesn't guarantee canonical results. It seems better to go with simple fee/byte and use the transaction id as a tiebreak, so that the same transaction will always win regardless of order received.
14:17 < bramc> The headache here with new utxos is that you can get a whole bunch of transactions distributed and then invalidate them all by having their dependency get replaced if it's done greedily. A simple solution is for miner software to not distribute transactions dependent on unspent utxos even if the earlier transaction has been accepted. That seems unlikely to hurt any miner in a meaningful way.
14:23 < bramc> It seems there's a lot of idling on this channel
14:23 < kanzure> many of us don't type things unless they are stoic and awesome
14:23 < kanzure> you should be thanking them for not spamming you with crap :)
14:24 < kanzure> petertodd: dawg have you rationalized absolute fee and better byte in public and in a link that you could link?
14:24 < bramc> kanzure, That is appreciated, but sometimes I make a serious point and can't tell if people are idling, or think it's stupid, or don't have the spare cycles to evaluate it seriously at the moment
14:25 < kanzure> ah well people in here are quite vocal about identifying idiocy so you'll be informed in a timely manner
14:26 < kanzure> in the past i would have raised concerns about relying on txid but i'm not really sure what the current eventual plan is
14:26 -!- orik [~orik@75.149.169.53] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
14:28 < kanzure> bramc: regarding your anti-dos strategy i would be worried about things like penalizing a peer that relays a transaction that was actually included in a block that you haven't seen yet but that also in fact exists
14:28 < bramc> kanzure, Well that's reassuring. The core of what I'm working on now is highly controversial so getting into an involved discussion of that would likely set off a flame war again.
14:29 < bramc> kanzure, if a peer gives you a transaction which is invalid/redundant in your current head you just ignore it, not sure what you mean by 'penalize'
14:29 < kanzure> a lot of the current anti-dos stuff is about penalizing peers and marking them as shitrude
14:30 < kanzure> or at least the set of discussed things as relevant to anti-dos in bitcoin.. i haven't looked at what's actually implemented on this front (oops)
14:30 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Remote host closed the connection]
14:30 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has joined #bitcoin-wizards
14:30 < bramc> kanzure, My thought is that my proposed extension would allow you to throw out all the shitrude detection code
14:32 < kanzure> also, in your experience from uh other relevant p2p networks, how imminently solvable is anti-dos and how much does bitcoind infringe on borders of things others know how to do well?
14:32 < bramc> kanzure, What's actually implemented appears to be a pile of miscellaneous hacky crap https://en.bitcoin.it/wiki/Transaction_fees
14:32 < kanzure> hmm that's not what i meant by anti-dos-- there's another set of things in the p2p network
14:33 < kanzure> for example, https://github.com/bitcoin/bitcoin/blob/66b473457bc94adcd3d277462f9d619f5a198d96/src/net.h#L578
14:33 -!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has quit [Remote host closed the connection]
14:33 < bramc> In my experience anti-dos can be done better than you expect up front, DHTs being the prime example. It appears to be in this case that it's totally reasonable to rely exclusively on the transaction rate limit and take it at face value though.
14:33 < kanzure> sorry i seem to have inflated a different anti-dos topic with another one
14:33 < kanzure> *conflated
14:34 -!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards
14:34 < bramc> kanzure, The high-level comment in that link is a good one, I don't know what the specific logic does though.
14:37 < bramc> In general with anti-DOS the threshold you're trying to hit is to make it so that a peer can't do better than they can trivially by sending you garbage packets.
14:40 < bramc> Here's an annoying attack which someone could pull off: after a block is minted, fill the whole next block with transactions with fee epsilon, then 2*epsilon, then 3*epsilon, etc. causing the network to use a huge amount of bandwidth. That can be mitigated easily by limiting the rate at which you send along transactions so that the lower value ones get thrown out before they're even sent, although that has some downsides.
14:43 < bramc> Transactions with multiple inputs make the replacement logic more complicated. At a minimum it's likely to be a huge pain to make canonical, because if transaction A has X and Y as inputs and fee 7, and transaction B has X as an input and fee 5, and C has Y and 5, then it's going to be hard to make logic for acceptance which isn't order dependent
14:43 < kanzure> i'm not sure why you would transaction ids to factor into that
14:44 < bramc> Transaciton ids are a tiebreak in case there are two transactions which both spend X with fee 5 and you need to decide which one wins
14:45 < kanzure> in the past those transaction ids would have varied (because the outputs count when making txid)
14:45 < kanzure> unless you mean the input txids
14:46 -!- NewLiberty_ is now known as NewLiberty
14:47 < bramc> Not sure what you mean. A miner gets two different transactions both of which spend the same input and give the same fee, and needs to pick which one of them to include and forward along
14:48 < nsh> transaction IDs are malleable because change address can be grinded
14:48 < nsh> so someone could increase their chance of winning a tie
14:49 < nsh> (s/grinded/varied/)
14:49 < bramc> nsh, The transactions have to be signed anyway, so it isn't a matter of someone 'winning', it's a matter of someone causing mischief by giving different transactions to different peers
14:50 -!- orik [~orik@75.149.169.53] has joined #bitcoin-wizards
14:50 -!- Skipppy is now known as Mably
14:50 < nsh> okay
14:51 < petertodd> kanzure: my thinking behind requiring both higher absolute fee and fee/byte, is the former ensures that the bandwidth of the replaced transactions is being paid for, and the latter ensures the replacement is more profitable under any circumstance
14:51 < petertodd> kanzure: I'd rather err on the side of *not* replacing than replacing
14:51 -!- AlienProject [~Alien_Pro@72.53.101.165] has quit [Quit: Leaving]
14:52 < petertodd> kanzure: note how requiring both acts as an obvious "one-way-rachet" that guarantees any attacker will eventually run out of money to spend on the DoS attack, the same logic behind non-rplace-by-fee anti-dos
14:52 -!- afk111 [~thomas@89.100.72.184] has quit [Ping timeout: 255 seconds]
14:54 < bramc> It seems that the only thing really holding the status quo together is a lack of anybody doing sophisticated transaction dos attacks
14:54 < petertodd> bramc: re: the "2*epsilon" attack, remember that epsilon is you must pay at least as much in fees as the transactions you're replacing, and on top of that, you additionally need to pay as much fees as would be required to broadcast the transaction in the first place: nReplacedFees + nFeesToRelayReplacement
14:55 < petertodd> bramc: nah, the status quo isn't so bad - I've done a fair bit of work on doing transaction dos attacks and we've gotten most if not all the vulnerabilities out
14:55 < petertodd> bramc: main thing we don't have right now that would be nice to have is a size-limited mempool
14:55 < bramc> There's one interesting idea in the anti-spam stuff though, which translating to my proposed message would make the threshold be for transaction size * fee/byte instead of fee/byte
14:56 < petertodd> huh?
14:56 < bramc> petertodd, Backing up a bit, I proposed adding a message saying 'don't send me transactions of less than X fee/byte' to the peer protocol
14:57 < petertodd> bramc: oh, sure, but we already have that message, it's just implicit :)
14:57 < petertodd> bramc: everyone has a fixed minimum fee/byte lower limit, and transactions that don't pay at least that get rejected by everyone
14:57 < bramc> petertodd, You mean by ignoring any such messages? My concern is that in that case the peer doesn't know that you ignored the message previously
14:58 < petertodd> so? as long as the lower limit isn't variable this isn't an issue; your idea is a good one, but only if that limit is variable
14:58 < bramc> petertodd, Shouldn't it be set dynamically based on the currently outstanding transactions?
14:58 < petertodd> bramc: yes it should be, hence the size-limited mempool suggestion
14:58 < bramc> so basically there's a real-time auction for whose transactions get in based on fee/byte
14:59 < bramc> If you have a size-limited mempool, how do you decide what to throw out when it gets full?
14:59 < petertodd> exactly! we've implemented nearly that, modulo the fact that the mempool isn't limited in size. But using up ram globally requires access to a lot of bitcoins so we haven't seen many (any?) attacks
14:59 < petertodd> bramc: throw away the cheapest?
15:00 < bramc> It's a moderately sophisticated attack. Easy for you or me, but we aren't about to do it.
15:01 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Remote host closed the connection]
15:01 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has joined #bitcoin-wizards
15:01 < bramc> So here's my concern: you have a transaction which gets sent to everybody, then gets thrown out by everybody because it gets nudged out by other transactions, then the fee/byte goes down later, but that earlier transaction was already permanently forgotten and has disappeared into the ether
15:02 < bramc> Also not sure what you mean by nReplacedFees + nFeesToRelayReplacement there's some piece of logic in there which I'm unfamiliar with
15:03 -!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving]
15:04 < petertodd> sorry, one sec
15:05 -!- orik [~orik@75.149.169.53] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
15:10 < gmaxwell> petertodd: per byte is also a one way ratchet in the limit.
15:11 < gmaxwell> bramc's comment about the path dependance is interesting; I'd missed that and I think it's important. At lunch today luke made some comment that was effectively saying that RBF makes mempools eventually consistent, but thats not actually true with the two fold rule.
15:12 < gmaxwell> (there is actually a design flaw in BGP due to multidimensional non-determinstic tiebreaking that causes networks to not converge that looks a lot like this (called MED oscillation)... there is no oscillation risk in bitcoin, but the two tier rule does mean mempools don't become more consistent over time under all conditions)
15:12 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has quit [Ping timeout: 244 seconds]
15:14 < bramc> gmaxwell, To be fair they have to eventually consistify as transactions are accepted. What the logic should be about transactions with multiple partially overlapping inputs should be is much less clear.
15:14 < gmaxwell> bramc: sure I mean in the absense of blocks.
15:14 < gmaxwell> It's not mandatory but a nice property that two nodes whove seen the same txn in any order that have the same policy should have the same mempool.
15:16 < bramc> Yes that's a good property, although it might have downsides
15:17 < petertodd> gmaxwell: my concern with pure fee-per-byte is that it means I can replace a large transaction(s) that consumed a lot of bandwidth with a smaller one with higher per-byte fees, but lower absolute fees. that could easily be used as a DoS attack
15:17 < bramc> for example if you want that property a peer can potentially do thousands of replacement transactions in order and get everyone to keep forwarding and replacing
15:17 < bramc> petertodd, Ah that makes sense
15:18 < gmaxwell> petertodd: indeed, though it's bounded. ... bleh. so that attack always exists in some form if you don't have a hurestis to prevent updating of some kind which implies order dependence. :(
15:18 < gmaxwell> so we can only have one or the other.
15:18 < gmaxwell> E.g. you can just have a "replace if the fee per byte is at least $non-negligible-higher" but thats order dependant. :(
15:19 < petertodd> gmaxwell: yup, I'd rather have the system that's obviously free from DoS attacks - after all everything is secondary to keeping relaying of blocks reliable
15:19 < gmaxwell> just irritating to not have the order independance. :(
15:20 < bramc> petertodd, What logic do you have for replacement of transactions with multiple inputs?
15:21 < petertodd> bramc: multiple inputs? um, why would that matter? multiple outputs is interesting, if they're already spent
15:21 < bramc> or by things with multiple inputs? It seems very different to have order independence there for different reasons
15:21 < bramc> petertodd, If you have inputs X and Y, then you can have a conflict with two transactions, one with input X and the other with input Y
15:21 < petertodd> bramc: ah ok, so if you replace with a tx with fewer inputs, then sure, the now unspent inputs can be spent (I should have a testcase for that actually)
15:22 -!- delll [~chatzilla@yh97.internetdsl.tpnet.pl] has joined #bitcoin-wizards
15:22 < petertodd> bramc: I'm sure you can construct cases where this leads to non-convergence :)
15:22 < bramc> petertodd, I meant in terms of deciding which one takes priority, do you look at the fee/byte across everything being replaced?
15:23 < bramc> And yes, there's a very simple case of non-convergence which is hard to get around. It seems like convergence is a lost cause which shouldn't be worried about.
15:23 < petertodd> oh, absolutely, there's code that sums up total fees and total bytes for *all* transactions being replaced and compares against that - subject to a total visited limit to also prevent DoS attacks
15:23 < petertodd> that code is very fast as we cache nFees and nSize, so it's just walking memory via pointers
15:24 -!- maraoz [~maraoz@43-161-16-190.fibertel.com.ar] has quit [Quit: Leaving]
15:24 < petertodd> yeah, I'd be happy to see it converge later, but least risk is to ship something that prioritises Actually Working :)
15:25 -!- aburan28 [~ubuntu@static-108-45-93-93.washdc.fios.verizon.net] has joined #bitcoin-wizards
15:26 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
15:28 < bramc> petertodd, So what was that about the increasing epsilons again? Something about nFeesToRelayReplacement
15:29 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
15:30 < petertodd> bramc: we don't relay a transaction unles it pays nSize * min-fees-per-kb. I'm just saying I won't replace unless the transaction pays more fees than the replaced transactions, and on top of that pays at least nSize * min-fees-per-kb additional fees, *and* also ends up paying a higher overall fees-per-kb than the replaced transactions
15:30 < gmaxwell> nickler: oh wow, nice result against bitcoinj. We knew before that it had nearly no privacy; but the intersection it a very nice observation.
15:30 -!- maaku is now known as Guest99135
15:32 < petertodd> bramc: (hmm... I should double-check all three conditions are actually possible... :P)
15:32 < bramc> petertodd, What's min-fees-per-kb set to?
15:32 < petertodd> bramc: 0.1uBTC/KB
15:32 < sipa> whatever is the relay fee is configured to, i suppose?
15:32 < petertodd> ^
15:35 < bramc> petertodd, My back of the envelope calculation says that that amounts to 2 cents/block at max size
15:36 -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 245 seconds]
15:36 < petertodd> bramc: wait, no that's wrong, it's 10uBTC/KB
15:37 < petertodd> bramc: $2.5/block, which is absurd
15:38 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has quit [Read error: Connection reset by peer]
15:38 < bramc> petertodd, isn't that $2/block? And that's a total of $500/day to stop anybody from being able to get any transactions done. That seems expensive but doable.
15:39 < petertodd> bramc: but fees are a market, so modulo shitty wallets that don't let you set them that attack will fail
15:39 < phantomcircuit> gmaxwell, ?
15:39 < sipa> well relay fee is different from mining fee
15:39 < petertodd> bramc: the real worry is using up bandwidth and especially memory
15:40 < sipa> relay fee gets your transaction across the network; i doubt it will be enough for getting it into a block much longer
15:40 -!- cluckj [~cluckj@c-71-225-211-210.hsd1.nj.comcast.net] has joined #bitcoin-wizards
15:40 < petertodd> sipa: which is potentially bad, because you shouldn't be relaying stuff that isn't going to get mined reasonably soon
15:41 < sipa> petertodd: agree
15:41 < bramc> petertodd, The problem being that wallets don't currently increase their fees when their transactions aren't going through
15:41 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has joined #bitcoin-wizards
15:42 < petertodd> bramc: for awhile bitcoin wallet for android made it impossible to set fees; right now you only have a x10 option that's fixed
15:42 < petertodd> bramc: replace-by-fee will help that as it'll be easy to bump tx fees
15:42 < bramc> s/easy/possible/
15:43 < bramc> My concern about rebroadcasting a transaction isn't much of an issue if the wallet can be responsible for rebroadcasting
15:45 < petertodd> bramc: yeah, anyway, lots of work needs to be done on wallets for sure
15:46 < petertodd> bramc: main thing is will replace-by-fee make the DoS attack situation worse? a little bit, for replace-by-fee nodes, while it's getting adoption, but the basic principles seem sound
15:47 -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has quit [Remote host closed the connection]
15:47 -!- antgreen [~user@74.112.41.171] has joined #bitcoin-wizards
15:48 -!- shesek [~shesek@87.68.49.90.cable.012.net.il] has quit [Ping timeout: 256 seconds]
15:48 < bramc> petertodd, How does it make things a little bit worse in the short term? I totally agree with the basic principles.
15:48 < petertodd> bramc: because the replaced transactions are dropped, it's also *only* worse in terms of bandwidth DoS, not memory usage DoS, and it's being deployed on high-bandwidth nodes for the most part
15:49 < petertodd> bramc: basically because the replacement isn't guaranteed to get mined because few people are mining w/ replace-by-fee, so you can use up a bunch of bandwidth by replacing with long strings of transactions for relatively little cost
15:51 < bramc> petertodd, Well said for the ringleader of the conspiracy to destroy zeroconf :-) http://www.reddit.com/r/Bitcoin/comments/28jp0y/why_is_peter_todd_wrecking_zeroconf_security/
15:52 < petertodd> bramc: !@#$ coinbase promised I'd get hookers AND coke, and all I got was the hookers. Bitcoin was way cooler when it was unregulated.
15:52 < kanzure> they might honor that kind of invoice, you'll never know unless you try
15:53 < petertodd> kanzure: I did, they said only the hookers were legal, not the coke.
15:53 < petertodd> kanzure: meanwhile greenaddress tried to give me medical pot instead, and demanded to see my card... sheesh
15:54 -!- nuke1989 [~nuke@178-241-15.dynamic.cyta.gr] has quit [Ping timeout: 256 seconds]
15:54 < kanzure> terrible
15:54 < bramc> You guys should go on tour with me, I have more groupies than I know what to do with.
15:54 < kanzure> wouldn't that just increase your groupie count?
15:55 < petertodd> bramc: male or female groupies? (or both?)
15:55 < nsh> but we could increase his ideas-of-things-to-do-with-groupies count
15:55 < nsh> for example, human pyramids
15:55 < bramc> Real rock stars have groupies who are 19 year old girls. Programming rock stars have groupies who are 13 year old boys.
15:55 < petertodd> nsh: that's not how Metcalfe's law works...
15:55 < petertodd> bramc: lol
15:56 < nsh> lol
15:56 < nsh> damn
15:56 -!- ielo [~ielo@host-78-147-237-163.as13285.net] has quit [Ping timeout: 252 seconds]
15:57 < petertodd> bramc: https://twitter.com/petertoddbtc/status/566385692276584449
15:57 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]
15:58 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
15:58 < nsh> .t
15:58 < yoleaux> Fri, 13 Feb 2015 23:58:35 UTC
15:58 < nsh> ah :)
15:58 -!- aburan28 [~ubuntu@static-108-45-93-93.washdc.fios.verizon.net] has quit [Remote host closed the connection]
15:58 -!- nuke1989 [~nuke@78-103-15.adsl.cyta.gr] has joined #bitcoin-wizards
15:59 < bramc> I'm coming up with some more somewhat annoying dos attacks. It's a bit of a cat and mouse game
16:00 < petertodd> heh
16:01 < bramc> But I'm now convinced that the protocol as it stands is sufficient, although wallets need work and there should probably be some extensions to the light protocol to find out what the acceptance threshold was on previous blocks
16:02 < justanotheruser> I don't understand. Is that a pedophile joke or do programmers have 13 year old fans?
16:02 < bramc> justanotheruser, We have 13 year old fans. Or at least I do.
16:03 -!- shesek [~shesek@87.68.49.90.cable.012.net.il] has joined #bitcoin-wizards
16:03 < justanotheruser> thats strange
16:04 < bramc> justanotheruser, It's because of what I'm known for writing
16:04 < justanotheruser> some game?
16:05 < bramc> some p2p thing
16:05 < petertodd> justanotheruser: really, we have groupies that act like 13 year old boys on 4chan...
16:06 < justanotheruser> o_O
16:06 < bramc> By the way, for the vast multitudes of people out there awaiting technical details of the thing I'm working on, I'm still getting it to the point where I feel it's solid before everybody starting jumping on me claiming that it's impossible, the details of the construction are fairly subtle.
16:06 < justanotheruser> after whoising you "some p2p thing" is hilarious
16:08 < petertodd> bramc: what are you working on??? :P
16:08 -!- aburan [~ubuntu@static-108-45-93-93.washdc.fios.verizon.net] has joined #bitcoin-wizards
16:08 < bramc> petertodd, an altcoin whose mining doesn't involve burning electricity
16:08 < kanzure> still?
16:08 < justanotheruser> thats disappointing
16:08 < kanzure> what were your objections to the previous arguments we brought to you about that, bramc?
16:08 < petertodd> bramc: ah, the proof of capacity thing?
16:09 < bramc> kanzure, Basically I've figured out how to engineer it so that there are a bunch of things which are calculated canonically so there's nothing to do parallel attacks on. It's a bit of a subtle contraption though
16:10 < bramc> petertodd, It's a somewhat involved combination of proofs of storage and proofs of time
16:10 < petertodd> bramc: well, I'm going to say it sucks until you find a way to explain it to a dumb arts student like myself in five minutes :)
16:11 < justanotheruser> bramc: the scarce resource that is being burned is just the electricity used to make that hardware then isn't it?
16:12 < bramc> petertodd, Once I've done a clearer writeup you might be able to understand a basic overview in five minutes, I don't think convincing you that it's secure can be done in five minutes. There are many potential attacks and the reasons they don't work are subtle
16:12 < petertodd> justanotheruser: +1
16:12 < justanotheruser> s/electricity/energy
16:12 < kanzure> you'll often be replacing most of your parallel processes with work based on the network
16:12 < bramc> justanotheruser, no because it's really depreciation on storage which was already made for other reasons, of which there's mass quantities in the world
16:12 < petertodd> bramc: well, it's not to say it doesn't work - explaining why sha256 is secure *can't* be done in five minutes to anyone - but I'm not going to bet it does :)
16:13 < kanzure> "It doesn't reduce to plain pow because the costs are such that you're burning more on spow than the value you're gaining from it." but that's irrelevant because you don't need to gain value from burning anything (value could be defined as breaking consensus)
16:14 < kanzure> man i hate how you treat us as forgetful morons
16:15 < bramc> petertodd, fair enough I don't fault anyone for being skeptical, hence my not wasting everyone's time with explaining it in detail while I'm still working on it because I don't want to go through a break/fix/break/fix cycle on things I'm entirely capable of fixing on my own
16:15 -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards
16:15 < bramc> kanzure, not exactly sure what you mean there but I've added some important details since then
16:16 < bramc> capable of breaking and fixing on my own I mean
16:16 < bramc> Hey adam3us
16:16 < adam3us> hey
16:16 -!- shesek [~shesek@87.68.49.90.cable.012.net.il] has quit [Ping timeout: 250 seconds]
16:17 < bramc> adam3us, You just missed me half-starting a flame war again
16:17 < kanzure> could you instead make direct statements instead of dangling hooks
16:17 < adam3us> bramc: another day another flame war.
16:17 < justanotheruser> bramc: I'm going to assume that regular harddisks aren't as powerful as some ASIC for proving that you are expending some resource.
16:18 < kanzure> i'm sure there's many optimizations you can make over a conventional ssd, for example
16:18 < kanzure> but that's also irrelevant i think
16:18 < bramc> kanzure, I'm not trying to taunt, the details are really quite subtle and explaining them over irc isn't likely to work well. If there are a bunch of people in the bay area maybe I can do an in-person discussion some day so they can all jump on me at once
16:19 < kanzure> ugh
16:20 < bramc> justanotheruser, asic and hard drive aren't even vaguely comparable resources, for what I'm working on the whole concept of asic-based optimization is essentially irrelevant, at least for the main reward-getting part of mining
16:20 < petertodd> bramc: fwiw I might be in the bay area again beginning of march, though like last time my schedule may be fucked
16:20 < kanzure> imposing physical constraints on people's time and attention is annoying
16:20 < kanzure> if i had to physically visit every one of you to relay my messages i'd never get anything done
16:21 -!- Guest99135 is now known as maaku
16:21 < bramc> kanzure, trust me it will go way faster in person than over irc, and I haven't even put together decent materials for people to read over yet, I'm still in the process of working on those.
16:22 < bramc> So it's like 'if people are in the bay area I can explain this to them, if not easier for you to wait until I've put real documentation together and finished a prototype'
16:22 < ajweiss> do i get coins for throwing bandwidth at p2p livestreaming?
16:22 < kanzure> then why would you even advertise anything. blah.
16:23 < justanotheruser> bramc: Whatever computation you're doing that involves storing lots of information can probably be optomized using special hardware.
16:23 < justanotheruser> At the very least, I could buy a ton of RAM and use that
16:24 < kanzure> his complaint was about energy utilization, not resource utilization
16:24 < petertodd> justanotheruser: one of these days we'll give up on all these crazy ASICs and just use the signing chips in stolen passports as PoW
16:24 < bramc> ajweiss, No it's a meaningless proof of work like in bitcoin, but the meaningless proof of work has to do with demonstrating that you have storage space sitting around doing nothing rather than burning electricity
16:24 < justanotheruser> petertodd: isn't that a hearnism?
16:24 < justanotheruser> kanzure: who is that directed at?
16:25 < kanzure> justanotheruser: i was informing you about bramc's complaints
16:25 < petertodd> justanotheruser: not quite - I'm suggesting using the (slow!) speed they sign as a PoW (semi-seriously)
16:25 < bramc> justanotheruser, Nope, RAM is very small compared to disk, and it's set up so there are pauses between lookups, so speed of lookup doesn't matter
16:25 < justanotheruser> kanzure: I'm pointing out the possible optomizations.
16:26 < justanotheruser> bramc: what does "RAM is very small compared to disk" mean?
16:26 < petertodd> justanotheruser: the Android pin entry code key derivation function apparently uses a secure element/TPM thing that does HMAC against a secret, and just calls the secure element repeatedly
16:26 < kanzure> 23:34 < gmaxwell> I think with infinite parallel spow the benefit is actually infinite at least when everone's storage is also infinite. Basically you lose this round, but one of your next steps which takes episilon longer than the honest network, ends up with a perfect match, and then do the next set of SPOW in time 0 and end up producing infinite blocks before the honest network has produces two.
16:26 < bramc> The storage proof is basically finding a closest match very fast, which peers do by having a whole lot of things sorted on their hard drives
16:26 < kanzure> 23:36 < gmaxwell> Well the point of the infinite is to say that this process (at least when storage is sufficiently large) reduces to plain
16:26 < bramc> justanotheruser, For these proofs of work RAM won't do them any better than the same amount of disk will
16:26 < kanzure> aaaa
16:26 < kanzure> 23:36 < gmaxwell> Well the point of the infinite is to say that this process (at least when storage is sufficiently large) reduces to plain POW.
16:27 < bramc> kanzure, That's combatted by making it so there's nothing to parellelize, the thing you're trying to find closest match on for the next block is based on the key and spow for the last block and nothing else, and the spow is canonical
16:27 < kanzure> ( http://diyhpl.us/~bryan/papers2/bitcoin/Publicly%20verifiable%20proofs%20of%20sequential%20work.pdf )
16:28 -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.]
16:28 < kanzure> "nothing to parallelize" you still have spow
16:28 < bramc> Yeah but the spow is canonical, you can't do n of them in parallel and get n different outputs, it will give the same output every time
16:29 < kanzure> then what's the point of that function?
16:29 < kanzure> it must have a different output given a different input
16:30 -!- freewil [~freewil@unaffiliated/freewil] has joined #bitcoin-wizards
16:30 < bramc> It's canonical on the input, obviously it varies based on the input. The input can be varied, but the only way it can vary is based on what signature was used last time, and using a different one makes the spow take longer
16:31 < bramc> I'm using a different and dumber spow than the one in that paper, because it isn't sufficiently canonical
16:31 -!- shesek [~shesek@87.68.49.90.cable.012.net.il] has joined #bitcoin-wizards
16:33 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 246 seconds]
16:33 < kanzure> taking longer doesn't seem to be very important- you could even run for the previous few blocks as well because you don't care about causing a reorg i think
16:35 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
16:35 < kanzure> (which gets you parallelism again (and reduction back to proof of work))
16:35 < bramc> I've run through that and there's a potential advantage to mining pooling but it's small: about 15% if you have 1/3 of all mining capacity, 6% if you have 1/10th. The countervailing forces are that the mining operation is nonoutsourceable, and there's much more potential resources which can be used in mining because the marginal cost of using already extant resources for mining is nothing
16:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:37 < bramc> You don't really get parallelism because the alternate values fall behind because they're worse. The amount of time the proof of time takes is dependant on how close a match the last block's public key is, and there's usually a clear winner there where the non-winners will never catch up once they've fallen behind
16:38 < bramc> There's this goofy proof of work adjustment which is for an aggregate value per block where the quality of the block times the number of generations used in the proof of time must be greater than the current work difficulty threshold
16:40 < bramc> That has the property I was just talking about of making individual blocks win and also solves the very important problem that proof of work difficulty resets only have one value to go off of, which is amount of time taken in the previous period, so they can only reset a single value, which must be an aggregate when you're using two different work types.
16:41 -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Remote host closed the connection]
16:42 < bramc> I have, in fact, taken the objections people raised before seriously and figured out how to fix them, although it does result in a bit of a contraption.
16:44 < bramc> Hopefully the stuff I'm describing doesn't sound like gibberish. It's hard to discuss these things without falling into custom jargon
16:44 -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
16:45 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
16:48 < bramc> I'm also happy to keep answering questions, although this rathole continues for a while.
16:50 < ryan-c> ethereum screwed up deterministic nonces?
16:51 < gmaxwell> ryan-c: sure, why do you ask?
16:51 < andytoshi> ryan-c: https://github.com/obscuren/secp256k1-go/blob/master/secp256.go#L126-L161
16:51 < ryan-c> gmaxwell: was just reading the scrollback
16:51 < andytoshi> line 130 in particular
16:51 < ryan-c> oh fuck
16:51 < ryan-c> what the hell
16:52 < andytoshi> :P it's actually stronger than it looks..
16:52 < gmaxwell> ethereum's ether sale generated private keys by using math.random() (a 48 bit LCG seeded by time in firefox) and reading the mouse position something like three times in a tight loop... and then defeneded the scheme as a "best practice".
16:52 < ryan-c> andytoshi: I know that  'nonce = msg + seckey' leaks the private key
16:53 < gmaxwell> Anticipation of that kind of behavior is why the libsecp256k1 API makes it really hard to do that now (but they had a really old fork)
16:53 < andytoshi> ryan-c: yeah, this doesn't fall prey to that directly because xor plays hell with the field operations
16:54 < andytoshi> ryan-c: (i think) nickler has made more progress than me attacking this, but i don't yet have an attack that works with much less than 100 bits of work
16:54  * bramc has an aneurysm
16:54 < ryan-c> I managed a working attack for 'nonce = msg + seckey' a few months ago, though I haven't seen anyone actually do that.
16:54 < bramc> The lack of so much as an API call for decent random numbers is a problem which goes back decades. And should have been solved long ago.
16:55 < ryan-c> (unrelated) anyone know where maaku is on utxo with coinbase commitment and if he's still working on it?
16:56 < gmaxwell> ryan-c: '+' in the group is more problematic than ^ on the seralizations. As ^ is not trivially algebraic in the group. ^ is still obviously insecure but making the attack pratical takes multiple signatures most likely.
16:56 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
16:57 < ryan-c> gmaxwell: Makes sense.
16:57 < maaku> ryan-c: yes. my employer is supporting finishing this work, but it's not a very high priority. i'm sorry that it has taken as long as it has, but work will continue
16:58 < ryan-c> maaku: Can I throw money at you to get it done sooner?
16:58 -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards
16:58 < sipa> i'm increasingly unconvinced that UTXO commitments are the right solution
16:58 < sipa> though part of the work - the commitment structure as such - is very valuable for many things
16:59 < bramc> What is this utxo commitment thing?
16:59 < sipa> bramc: have blocks commit to a merkleized tree set structure of the UTXO set
16:59 < ryan-c> sipa: My particular interest is using it to enable Namecoin light clients.
16:59 < ryan-c> bramc: UTXO = unspent transaction outputs
17:00 < sipa> bramc: so you can prove a particular coin still exists (or doesn't exist), as opposed to just being able to prove you've been paid at some point
17:00 < bramc> sipa, Ah, that, I've looked into it and am not convinced that it doesn't do more harm than good, because it creates a bunch more edge cases to look out for, the main benefit seems to be in proving over the light protocol that a particular utxo hasn't been spent yet
17:00 < sipa> it also adds huge extra costs for validation nodes
17:01 < bramc> Yeah those turn out to be bigger than expected
17:01 < justanotheruser> can a UTXO proof be constructed cheaply?
17:01 < ryan-c> (though we need a second utxo structure for authenticated denial)
17:01 < ryan-c> well, not utxo
17:01 < bramc> justanotheruser, depends what you mean by 'cheaply'. It turns out that the log(n) factor in the disk seeks necessary to do it is a bigger deal than you would guess up front
17:03 -!- adam3us [~Adium@12.203.200.220] has quit [Ping timeout: 265 seconds]
17:03 < bramc> After having spent a bunch of time looking into all the proposals I've seen links to, my conclusion has been that Gavin's wish list for what to fix is mostly right: http://www.reddit.com/r/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj
17:03 < justanotheruser> I mean is comparing each UTXO in your current copy and the merkle tree the fastest way to do it?
17:04 < bramc> justanotheruser, It's updating the merkle tree which gets expensive
17:04 -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards
17:04 < bramc> Because it's too big to fit in memory, and requires a whole bunch of seeks to update on disk
17:05 < bramc> To gavin's list I'd add 'simplify the damn acceptance language' because the only things which seems to matter for smart transactions are multisig, hash pre-image with length specification, and transaction timelock
17:05 < justanotheruser> acceptance language?
17:06 < ryan-c> justanotheruser: i think he means bitcoin script
17:06 < bramc> justanotheruser, p2sh
17:06 < justanotheruser> what about p2sh?
17:06 < justanotheruser> you mean Script?
17:07 < bramc> justanotheruser, Yeah the script, it's overly complicated with no clear benefit. All the proposed extensions are op_verify anyway
17:08 < justanotheruser> While Bitcoin is young, it is nice to be able to create new scripts without having to softfork
17:08 < bramc> There's a clear argument for being able to make new op_verify opcodes. There's no clear justification for having acceptance criteria more complicated than enumerated subsets of the verifies which can be used to pass
17:09 < ryan-c> I've had things I wanted to do that would require OP_CAT
17:09 < ryan-c> they may have been bad ideas
17:09 -!- adam3us [~Adium@12.203.200.220] has quit [Client Quit]
17:09 < justanotheruser> and OP_XOR would be nice
17:09 < bramc> ryan-c, and op_cat is one of those things which Isn't Going To Happen
17:09 < ryan-c> bramc: I know.
17:09 < justanotheruser> why not?
17:10 < bramc> justanotheruser, op_cat allows dos by making extremely large strings.
17:10 < justanotheruser> and if the strings can't be made extremely large?
17:10 < bramc> justanotheruser, In all seriousness if you know of an explanation for a smart transaction which would require xor I'd love to see a link
17:11 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]
17:11 < ryan-c> oh, now i remember what i wanted to do
17:11 -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards
17:11 < bramc> justanotheruser, there's no agreement on what the max length should be
17:11 < ryan-c> have a script that could be redeemed either by a normal key or by multisig
17:12 < bramc> ryan-c, How is than not just a special case of multisig which allows a particular single key to work?
17:12 -!- antgreen [~user@74.112.41.171] has quit [Ping timeout: 244 seconds]
17:12 < justanotheruser> bramc: http://arxiv.org/abs/1402.3698
17:13 < bramc> justanotheruser, that can be done using length specifications of hash preimages
17:13 < ryan-c> bramc: it isn't - is multisig with 1+N keys that requires either the 1 or M of N possible?
17:14 < justanotheruser> bramc: that's a hack
17:15 < bramc> ryan-c, uh... I assume it's trivial using script as it stands today. For what it's worth when I say 'multisig' I mean specifying a list of pubkeys and all the possible subsets of them which can be used to spend the utxo
17:15 < justanotheruser> afaics, it doesn't work for >2 people and the transactions become larger as your odds become smaller
17:15 < bramc> justanotheruser, It may be a hack, but it works just fine, and implemented correctly leaves little record of what was done on the block chain in the non-error case.
17:15 < ryan-c> bramc: I might not be remembering correctly.
17:17 < bramc> justanotheruser, Does work for >2 people, and with larger odds you can chain together multiple transactions, although it isn't a terribly elegant solution. But it does, you know, work, and require hardly anything in the protocol.
17:17 < justanotheruser> what does chaining together multiple transactinos accomplish?
17:18 < bramc> justanotheruser, instead of you having to guess a single number between 1 and a million, you have to guess six numbers between 1 and ten, presto under control transactions sizes
17:19 < ryan-c> bramc: can the numbers between one and ten be guessed separately?
17:20 < bramc> ryan-c, Yeah that's the idea they're based on different preimages, but the right answers have to be committed to in advance
17:20 < justanotheruser> thats pretty ineffecient. IT's better to just OP_XOR and check if it's below a certain value rather than paying for 6 transactions.
17:20 < bramc> justanotheruser, It also isn't a very important use case :-P
17:21 < ryan-c> oh, you're talking about stuff in the paper that i didn't read
17:21 < justanotheruser> It demonstrates that some opcodes have uses we may not know of yet though
17:21 < bramc> justanotheruser, that sort of functionality could also be crammed into a new op_verify
17:22 < bramc> ryan-c https://eprint.iacr.org/2013/784.pdf
17:22 < ryan-c> bramc: don't have time to read it right now, thanks though
17:22 < justanotheruser> yes, like I said, I agree in the long term that we should move to a simple scripting language where you just have a few op_verifies, but since that requires a softfork, for now it is better to allow these scripts to be discovered
17:23 < bramc> ryan-c, The summary is that you can hack gambling by using hash preimage length as your commitment technique, and you use a bunch of returns with timelock similarly to atomic transfers
17:24 < bramc> justanotheruser, To be clear I'm talking about what makes sense if you're doing stuff from scratch, not seriously proposing anything in Bitcoin per se be changed
17:24 < justanotheruser> yeah, satoshi did know how useless a lot of the opcodes would be though
17:24 < ryan-c> that reminds me of a CTF challenge I solved that required you to do a hash length extension attack against truncated hash
17:25 < justanotheruser> if bitcoin had to be remade today it probably would be very different
17:25 < ryan-c> (it was in the context of a "provably fair" casino)
17:25 < ryan-c> someone should make an altcoin with Script based on INTERCAL
17:26 < bramc> justanotheruser, Less different than you might think. The changes we're discussing are quite minor, and nobody has proposed a fully fleshed out convincing solution to the problem of scaling. Maybe sidechains will get there.
17:27 < justanotheruser> nah, it should be lisp based
17:27 < bramc> I also view the wastage of mining as a serious problem and claim to have a solution to that one, but you've seen how convinced people are of that one :-)
17:28 < kanzure> "but you've seen how convinced people are of [the wastage of mining]"?
17:28 < justanotheruser> mining isn't really wasteful since people are getting a valuable service and paying for it
17:28 < ryan-c> bramc: were you saying you had some inherently serial thing that couldn't be hardware accelerated effectively?
17:28 < bramc> kanzure, No you've seen how convinced people are that my claimed solution works
17:29 < kanzure> huh?
17:29 < ryan-c> i didn't read the scrollback very throughly
17:29 < bramc> kanzure, sarcasm, meaning they clearly aren't
17:29 < kanzure> why would i care what they think?
17:30 < kanzure> i forget what your objection was to the thermodynamic arguments for proof of work
17:30 < bramc> ryan-c, There are lots of inherently serial things which are hard to hardware accelerate effectively, but can of course be done somewhat. The idea is that multiple parties will run very accelerated hardware to keep each other from getting an unfair advantage and wind up in a stalemate
17:30 < kanzure> i remember something like you refusing to address an argument
17:31 < bramc> kanzure, The idea is that there's far more depreciation of storage out there than mining rewards
17:31 < ryan-c> bramc: the stalemate thing sounds like how mining is already
17:31 < kanzure> bramc: mgo on
17:31 < kanzure> -m
17:31 < bramc> No I did in fact address that argument, the arguments around how people can't weasel around my proofs of work by doing some parallelization are much more subtle
17:32 < bramc> ryan-c, Yes it's very similar, although in this case instead of a huge number of people burning lots of resources on the fast CPU stuff it's just a few machines running while everybody else waits
17:32 < kanzure> that was not the argument i was talking about
17:32 < kanzure> i remember asking you why you thought asic resistance was useful and your response was "i'm not even going to dignify that with a comment"
17:33 < kanzure> 17:30 < kanzure> i forget what your objection was to the thermodynamic arguments for proof of work
17:33 < kanzure> this was an accurate on-topic reply that could have gone somewhere:
17:33 < kanzure> 17:31 < bramc> kanzure, The idea is that there's far more depreciation of storage out there than mining rewards
17:33 < bramc> kanzure, Oh it's because there's nothing in the main part of mining which requires much of any CPU
17:34 < bramc> kanzure, hold on, two very different points here
17:34 < kanzure> in your system?
17:36 < bramc> The higher level point is the economic one about storage depreciation vs mining rewards. If mining is entirely dependent on proofs of storage and anyone who already has depreciating storage has to spend literally nothing on doing the mining then noone will ever acquire new resources specifically to do mining because they'll lose money on it
17:36 < kanzure> why is it important they lose money on it?
17:36 < adam3us> bramc: is this another attempt to repair proof of stake?
17:37 < kanzure> adam3us: no
17:37 < adam3us> bramc: ok then is it a variant of memory hard, like tromp's cuckoo cycle pow?
17:37 < bramc> adam3us, No! No proofs of stake! This is all about shifting around the form of the proofs of, uh, 'work'
17:37 < kanzure> adam3us: around 23:04 http://gnusha.org/bitcoin-wizards/2015-01-01.log
17:37 < kanzure> or uh earlier
17:37 -!- richardkiss [~richardki@108-94-29-170.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
17:38 < bramc> adam3us, no the proof of work is nothing like cuckoo. It's actually much simpler
17:38 < kanzure> http://diyhpl.us/~bryan/papers2/bitcoin/Publicly%20verifiable%20proofs%20of%20sequential%20work.pdf
17:39 < bramc> kanzure, What I'm using is even dumber than that, it's just a straightforward sequential operation with checkpoints along the way included in the actual proof so it can be spot checked
17:39 < kanzure> yes you already mentioned that today
17:39 < adam3us> sequential? ah yes, i have applications for those.
17:39 < adam3us> well more time-lock decryption which is related
17:40 < bramc> adam3us, the proof of work is to find the closest match to the hash of the previous proof of time. To do this everybody has a whole bunch of them stored in sorted order on their hard drive and goes and looks up the closest match
17:41 < bramc> Then whoever has the best match mints a new block and everybody sits around waiting for the next proof of time to be done.
17:42 < bramc> adam3us, cuckoo-like things don't really work because they use enough electricity that the electricity winds up being the limiting factor anyway. To move from electricity limited to resource limited it really needs to use *no* electricity.
17:42 < adam3us> bramc: oh yeah; did you see rivests micromint protocol based on k-way collisions? they keep buckets of collisions as its a generalisation of a birthday attack.
17:43 < bramc> adam3us, no I'll have to read through that
17:44 < bramc> adam3us, in my scheme the match quality is based on the hash of a public key and it's only accepted if it comes with a signature on a new block
17:45 < adam3us> bramc: yeah ic.  micromint is only slightly related probably. they gain advantage overtime by storing large amounts of k-way collision candidates
17:47 < bramc> adam3us, My thing is most closely related to amiller's nonoutsourcability
17:47 < bramc> As a result it happens to be very resistant to outsourcing
17:47 < kanzure> 22:34 < bramc> adam3us, There's plenty of hardware sitting around depreciating all the time. If the costs of mining were adjusted to be primarily hardware depreciation then the amount of new investment in mining would go down, and it would be relying primarily on sunk costs
17:47 < kanzure> 22:34 < adam3us> bramc: if coins have a production cost below their value, rational economic actors will spend up to the market value chasing it.  if thats via politics, buying or bribing stake holders (pos) etc
17:47 < kanzure> 22:35 < adam3us> bramc: i dont think my arguments change.  its economic fundamental of commodity pricing.
17:47 < kanzure> haven't we been through this time loop before
17:48 < bramc> kanzure, Sort of, I didn't do the greatest job explaining my argument before
17:48 < kanzure> yes i'm trying to do you justice by finding the exact argument that was given to you
17:49 < phantomcircuit> kanzure, to achieve the sunk costs model you need the efficiency of the hardware to change significantly as the amount of work being done drops
17:49 < phantomcircuit> that's mostly only true of existing hardware in theory now
17:50 < bramc> kanzure, And there are a bunch of much more involved cat and mouse games where an attacker tries to do stuff in parallel to use cpu to their advantage which I didn't have good answers for before. That argument was mostly a highly technical one between me and gmaxwell where he was shitting on what I was saying but there weren't nice sound bites on either side
17:51 < kanzure> actually what i'm looking for is the argument given to you about scarcity being used to secure decentralized consensus, which then got turned into an argument about necessary properties like progress freeness, etc
17:52 < kanzure> (something involving a complaint about waste..?)
17:52 < bramc> kanzure, I'm still using mining rewards which are doled out proportianately to resources put in!
17:53 < bramc> It's just that the resources are depreciating storage rather than electricity, on the grounds that that can be done with no increase in marginal spend
17:53 < kanzure> "But none of that is an understanding of Bitcoin.  Bitcoins aren't produced from work, they're just handed out by the system. The work in bitcoin exists to provide security, and there no spurrious economic argument exists."
17:53 < kanzure> i don't know why you are bringing up proportionality to resource input(?)
17:54 < kanzure> -( -)
17:54 < bramc> kanzure, at points I'm honestly not sure what you're trying to say
17:55 < kanzure> yeah i suppose i have muddled this a little bit; i keep trying to probe you about why you think pow is wasteful, and then i was trying to remember some other argument about depreciation.
17:55 < kanzure> sorry
17:56 < phantomcircuit> pow is wasteful
17:56 < phantomcircuit> but the alternatives dont work
17:56 < kanzure> that's easy when you don't offer a definition
17:56 < phantomcircuit> it's the only option
17:56 < phantomcircuit> it is thus by definition not wasteful as there is no other option
17:57 < bramc> There's this argument about waste in bitcoin being unavoidable, in that if that the value of mining rewards is X dollars, then exactly X dollars with of resources will be blown mining them, and that will generally be in the form of electricity. My counter is that if you engineer things carefully instead of new resources being spent on mining, mining can only be done by demonstrating usage of resources you were wasting an
17:57 < bramc> yway, and if the value of those resources is greater than X then no *additional* waste will happen to do mining
17:57 < adam3us> i guess if u use less resources per unit of participation you'll end up with more units and equal aggregate cost (the quote above that kanzure posted about "if coins have a production cost below their value, rational economic actors will spend up to the market value chasing it. "
17:57 < kanzure> do you see why or how "bitcoins aren't produced from work"?
17:57 < bramc> In this case, the resources already wasted is that there's hard drive capacity sitting out there doing nothing.
17:58 < bramc> kanzure, I don't see what the point of that semantic distinction is
17:59 < adam3us> bramc: the security comes from the cost of the forgone alternative; a fully reusable or sunk cost may provide no security
17:59 < tromp> what's the electricity cost of filling 100TB of hard disk space with sorted hashes?
17:59 < bramc> adam3us, Oh it isn't reusable exactly because the work is storage space times time, and you can't manufacture extra time
18:00 < kanzure> tromp: arguably that doesn't matter
18:00 < bramc> tromp, small
18:00 < ryan-c> tromp: Funny you should ask, I have about 40TB of drives filled with sorted hashes.
18:00 < bramc> ryan-c, if I may ask a stupid question, why?
18:01 < kanzure> rainbow tables, i'd guess
18:01 < ryan-c> bramc: I'm running a birthday attack on something.
18:01 -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Quit: Leaving]
18:01 < ryan-c> (really need to finish that project...)
18:01 < bramc> tromp, it requires a little bit of cleverness to do it in only a few passes over the hard drive because memory is so small by comparison
18:02 < adam3us> bramc: right so its not fully reusable because the disks cost money to manufacture, store and operate.  if the cost per unit participation (per disk say) is low there will be lots of disks participating.
18:02 < ryan-c> bramc, tromp yeah, much pain in the ass. I used a merge sort that does delta compression on each pass.
18:02 < ryan-c> hard disks are cheap to run
18:03 < ryan-c> 5-10W
18:03 < bramc> adam3us, Yeah the idea is to keep the costs per unit participating as low as possible. Someone might have a massive rack of drives which are all spun down then when they want to look up they spin up the relevant drive, do the lookup, and spin it back down again
18:03 < tromp> every new computer comes with a hard disk that takes years to fill up. might as well use that space until actually needed
18:03 < ryan-c> maybe a dollar or two per month to run a low power drive
18:03 < bramc> tromp, yes exactly
18:04 < ryan-c> (keeping it spun up)
18:04 < kanzure> "might as well ues the space to do x" is not a security argument and is boring
18:04 < kanzure> that has nothing to do with whether or not it achieves consensus
18:04 < kanzure> nobody cares if it's a hard drive or a rhinocerus, as long as it works
18:04 < bramc> kanzure, the consensus part is straightforward: the best match wins
18:05 < bramc> Over time you have a series of completed blocks, consisting of match/proof of time/match/proof of time
18:05 < kanzure> i don't see how that fits into the same problem domain as something like "a fully reusable or sunk cost may provide no security"
18:05 < kanzure> "best match" is not a security argumet
18:05 < kanzure> argument
18:05 < ryan-c> I have a server at my apartment with 12 disks in it, and I keep them spun down as much as possible.
18:06 < bramc> So someone else can't catch up, because they have less storage space than the system as a whole, and no more time
18:06 < kanzure> bramc: i'm only harsh because i love you
18:06 < kanzure> just fyi
18:06 < bramc> kanzure, I'm trying to make a coherent but subtle technical argument here and it seems like I'm not being very clear
18:07 < kanzure> yes something about parallel time not existing
18:08 < bramc> Let's say that the current work factor is 10^40
18:08 < bramc> The network as a whole has 10^20 storage, while you little peon that you are have a mere 10^19 of storage.
18:09 < kanzure> (why do i have storage? why not giant spow farm?)
18:09 < bramc> For each block, the networks proof of storage will on average be worth ten times as much as yours
18:09 < adam3us> bramc: imagine lets say bitcoin farms total cost $500m and are using say $100m of elec, and over time the balance moves more torwards pure elec because manufacture is cheap.  the disk farm would tend towards having hirer storage cost (more bulky) lower electricity cost (maybe can spin down) and some reuse (use end of life disks)
18:10 < bramc> kanzure, hold on for a sec on the spow farm, I can only type so fast
18:11 < kanzure> http://www.seanwrona.com/typeracer/profile.php?username=kanzure
18:12 < bramc> So if your spow takes about as long as the fastest spow on the network, it will take you ten times as long to complete blocks on average, and you'll fall behind the rest of the network quite rapidly unless you get really lucky, and the amount of lucky you need goes up exponentially as you fall further behind
18:12 < adam3us> bramc: i think you'd want to estimate the number of disks that would be supported by the reward
18:12 < bramc> adam3us, hold on I can only type so fast
18:13 < adam3us> bramc: probably it exhausts production capacity.  faster man :)
18:13 < kanzure> if you are interested i know of some drugs that increase typing speed
18:13 < kanzure> adam3us: i'm not sure reward support is very important?
18:14 < bramc> kanzure, Now about the spow farm point. This is an important and subtle one. The challenge algorithm is set up so that it's dependent on (1) the previous block (2) the spow, (3) the current work factor and (4) absolutely nothing else. It's very important that the spow is canonical and the hash of the public key for the block determines its match value so malleability doesn't matter
18:14 < adam3us> kanzure: reward is subsidising security.  we hope even in the long run that fees pay enough to provide adequate security.
18:15 < kanzure> adam3us: well i mean, if you have a decentralized security argument similar to some consensus set of nodes operating still, then the subsidy is worthy of investigation, but not before
18:15 < adam3us> bramc: i guess this spow execution time s chosen to be >> a block interval
18:16 < bramc> So you can calculate spows in parallel, but you'll be doing it off of not as good matches to the last block, so they'll finish after and you're basically just hoping that you'll get really lucky on the generation after so it gets ahead of the best head overall which of course is increasingly unlikely based on how little of the general storage you have and how bad of a match you used for the previous generation
18:16 < bramc> adam3us, the spow execution time *is* the block interval
18:16 < kanzure> do you mean equal to, or some other semantic intent
18:17 < adam3us> bramc: just wondering about time security
18:17 < bramc> I mean a block isn't complete until it has the corresponding spow, and once it does have the spow the next block can be found
18:17 -!- d1ggy [~d1ggy@dslb-092-076-025-214.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards
18:18 < bramc> kanzure, so I've run the numbers on it, and it turns out that the advantage you get by running multiple spow in parallel is finite, because the alternate matches tend to be so bad. Not only finite but small.
18:18 < adam3us> bramc: i thought the disks were filled with spows, maybe not.  there will be variance in spow execution speed based on overclocking if there is a strong advantage to finishing first
18:18 < bramc> adam3us, Oh no, the spow is dependent on an input, so you can't precompute them
18:19 < adam3us> bramc: so who computes the spow and does it matter who completes it first?
18:19 < bramc> adam3us, there's some advantage to getting a spow done first, which is why there's no explicit reward for doing it. The idea is that multiple miners are each trying to get a head and they wind up all finishing close to the same time on their spow in a sort of mutually assured destruction
18:20 < bramc> (I did say that this thing is a bit of a contraption)
18:20 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
18:20 -!- d1ggy_ [~d1ggy@dslc-082-082-145-182.pools.arcor-ip.net] has quit [Ping timeout: 255 seconds]
18:21 < bramc> It doesn't matter who completes the spow first because it's canonical, you can't even tell who completed it first. A miner who has a fair amount of mining capacity and a faster spow than everybody else can get a small advantage by not releasing the spow immediately and getting to work on their own best match for the next block early so they can win in case of a near tie
18:21 < adam3us> bramc: ok so you accept the closest hash match within a time-interval.  i am wondering if htere is a nothing at stake risk that i can continue to try find closer matches well into the next block interval to reorg the block by finding a higher pow one later.
18:22 < bramc> adam3us, You can of course grind through generating new keys in memory, that's sufficiently slow to be not worth it though: The sheer size of hard drives is important here
18:23 < adam3us> bramc: bearing in mind that it is the pow that enforces non-history-rewriting as there is a forgone alternative
18:23 < adam3us> bramc: ok so thats paramterised such that its not worth it
18:24 < bramc> adam3us, Yeah one could be cute and require extra work be done on the hash of the public key to prevent grinding but it turns out that the amount of work necessary to generate public keys gets it about right anyway
18:25 < adam3us> bramc: so lets pretend for analysis that there is a trusted oracle that is broadcasting a beacon (random chosen value) which this construct approximates, and people just publish their best bet and move on.
18:25 < bramc> Although of course I'll have to do some actual measurements on that
18:25 < adam3us> bramc: but over time there will be new disks. say capacity doubles 2 weeks later, could they then find a closer hash to the beacon from 2 weeks ago and reorg 2 weeks work?
18:26 < bramc> adam3us, It's important that the amount of time it takes for the beacon to broadcast is dependent on how good the previous match was
18:27 < bramc> adam3us, It's like in Bitcoin. Hash capacity greater than what existed at the beginning of the block chain exists easily today, and you could redo up to the current point in not too long, but by then everybody else would have gotten farther along.
18:27 < bramc> That aspect of the whole thing is unchanged.
18:33 < bramc> This is, in fact, mining.
18:36 < bramc> Given the sudden lack of questions, clearly I've now convinced everyone :-)
18:36 -!- p15 [~p15@111.193.161.161] has quit [Quit: Textual IRC Client: www.textualapp.com]
18:37 -!- p15 [~p15@182.50.108.84] has joined #bitcoin-wizards
18:37 < bramc> (But there are some important and not completely trivial details necessary for it to work which i haven't explained yet, not even badly)
18:38 < kanzure> my telepathic link to adam3us seems to be working so i will continue to lazily rely on him to word my complaints
18:41 < adam3us> i think u need to define what it is that prevents indefinite long range historic reorgs from future growth in computational capacity
18:41 < bramc> I'm afk for a few. Feeding the pet hairless apes.
18:42 < bramc> adam3us, It's storage space times time
18:43 < bramc> The value of a block chain is the integral of the storage that went in over the course of its history (with a bunch of noise added, again much like in Bitcoin)
18:44 -!- Dr-G2 [~Dr-G@gtng-4d08ddbe.pool.mediaWays.net] has joined #bitcoin-wizards
18:47 -!- Dr-G3 [~Dr-G@gtng-4d08d252.pool.mediaWays.net] has quit [Ping timeout: 245 seconds]
18:51 -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.]
18:51 -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards
18:52 -!- Dr-G2 [~Dr-G@gtng-4d08ddbe.pool.mediaWays.net] has quit [Ping timeout: 252 seconds]
18:55 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has quit [Ping timeout: 245 seconds]
19:01 -!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaWays.net] has joined #bitcoin-wizards
19:01 -!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaWays.net] has quit [Changing host]
19:01 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards
19:02 -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.]
19:02 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 256 seconds]
19:03 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Quit: Leaving]
19:06 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 250 seconds]
19:16 -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has quit [Remote host closed the connection]
19:21 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards
19:31 -!- Starsoccer [~starsocce@unaffiliated/starsoccer] has joined #bitcoin-wizards
19:32 -!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaways.net] has joined #bitcoin-wizards
19:32 -!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaways.net] has quit [Changing host]
19:32 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards
19:37 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards
19:37 < bramc> Okay, the apes have been fed and are happy
19:37 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 256 seconds]
19:38 < kanzure> not convinced about your dimensional analysis (particularly the one about time)
19:38 < bramc> It isn't that different from Bitcoin, which is based on number of CPUs times time
19:39 < kanzure> that doesn't make sense
19:40 < kanzure> i don't think that's a valid reduction?
19:40 < bramc> Sure it is. The number of hashes you'll have is the integral of the hashing capacity over time
19:43 < bramc> There's also energy consumed, but that isn't what's keeping anyone from getting ahead. What's keeping people from getting ahead is their capacity limitations.
20:03 -!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaways.net] has joined #bitcoin-wizards
20:03 -!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaways.net] has quit [Changing host]
20:03 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards
20:05 -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Ping timeout: 246 seconds]
20:06 -!- OneNomos [~OneNomos@gateway/vpn/privateinternetaccess/onenomos] has quit [Remote host closed the connection]
20:08 -!- siraj [~siraj@triband-mum-120.62.22.172.mtnl.net.in] has joined #bitcoin-wizards
20:10 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 265 seconds]
20:15 -!- freewil [~freewil@unaffiliated/freewil] has quit [Quit: Leaving.]
20:17 -!- koeppelmann [~koeppelma@dyn-160-39-213-51.dyn.columbia.edu] has joined #bitcoin-wizards
20:23 -!- koeppelmann [~koeppelma@dyn-160-39-213-51.dyn.columbia.edu] has quit [Ping timeout: 245 seconds]
20:33 -!- richardkiss [~richardki@108-94-29-170.lightspeed.sntcca.sbcglobal.net] has quit [Quit: richardkiss]
20:35 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards
20:43 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds]
20:45 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:55 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 250 seconds]
20:58 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
21:04 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]
21:07 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
21:44 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 264 seconds]
21:47 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:6d06:2acc:44a9:2046] has joined #bitcoin-wizards
21:49 -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards
21:53 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
21:56 -!- op_mul [~op_mul@178.62.133.216] has joined #bitcoin-wizards
21:58 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep]
22:01 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
22:02 < op_mul> bramc: I don't think that's accurate either. you can see bitcoin blocks as a measure of hash-time only because the hashes can't be retroactively moved to a different chain. with this sort of "proof of capacity" type design the proof can be moved to any chain the user wants, making it really proof of nothing at all.
22:02 < op_mul> there's an alt coin currently that exists using something like this. precomputed lookup tables which every block, the user scans and looks for low hashes. the system "works" up to a point, but it completely breaks down when you realise that the work can be ground just like proof of stake.
22:03 < bramc> op_mul, No the proofs can't be moved around. Each successive proof in the chain directly references the one before it by hash and can't be moved around
22:04 < bramc> Although, yeah, there's a fair amount of subtlety in making it so that grinding can't be done, which I explained how that works earlier, although likely not very well.
22:05 < adam3us> bramc: the thing is with this pow i think there is not much disincentive to repeatedly try to rewrite history as storage grows.  unless there is checkpointing or something centralising that remains a risk.  and this is because there isnt really a cost to mining - its quite proof of stake like in restricting a node to voting once per time-interval. (but with a put your current best vote forward).
22:06 < adam3us> bramc: what if the networks capacity doubles in 2 weeks and then there is a non-negligible chance that someone can collect slightly better pows (closer to the target) from a point in the past
22:06 < op_mul> that doesn't much mesh with my understanding of proof of work particularly very well. I need to be more versed in moon math, or high, or something. I don't see how proof of time can exist the way it's been described.
22:07 < justanotheruser> What is a proof of time?
22:07 < op_mul> the straight forward method of what you are saying is that Proof of Capacity stuff, which is just trivial to grind the crap out of and isn't a method of distributed consensus.
22:07 < bramc> adam3us, You can't catch up unless you have a conspiracy of the entire network. The current network is progressing at a rate determined by all the current capacity, where the retroactive work is progressing at a rate determined by the capacity of whoever's trying to do it, so it's always falling behind
22:08 < bramc> adam3us, reward times are noisy but in *exactly* the same way as Bitcoin rewards are noisy
22:08 < op_mul> justanotheruser: no idea man. this is what I'm reading. https://botbot.me/freenode/bitcoin-wizards/2015-02-14/?msg=31971068&page=2
22:08 < adam3us> bramc: sipa has a graph of days to replace bitcoin history, surprisingly it was as low as 50 days at times because of fast hashrate increase.
22:09 < phantomcircuit> adam3us, i've been wondering for a while whether you can do a pow in which you burn coins to get tokens that give you the right to build a block 100 blocks after that block
22:09 < sipa> http://bitcoin.sipa.be/powdays-50k.png
22:09 < bramc> It's a little bit less resistant to history rewriting than bitcoin is because in bitcoin when someone is mining they have to do either current mining or historical rewriting but can't parallelize both, but that doesn't matter all that much
22:09 < adam3us> bramc: but here its sort of like proof of stake turning into a proof of work, any rational attacker (dishonest but rational) might as well use spare disk access capacity once they have increased their disk capacity might as well have a go at rewriting history - the extra disk lookups are basically free
22:10 < phantomcircuit> at first glance it has all the same economic incentives as true pow mining except is missing things like capital expenditure
22:10 < sipa> http://bitcoin.sipa.be/powdays-ever.png
22:10 < op_mul> phantomcircuit: that sounds a little weak from the out set. presumably you can burn the coins on one chain and then mine on an alternate one?
22:11 < bramc> Proofs of time are very simple: You take a value, and hash it N times for some N, and the result is the proof of time. The problem with that trivial scheme is that it takes just as long to verify as it does to generate, so you store checkpoints along the way and when someone gets a proof they spot check it and if any problems are noticed they report it to whoever sent it to them.
22:11 < adam3us> bramc: i think u may be assuming a slightly weaker threat model like honest majority where bitcoin somewhat aims for economic rational majority (they lose money because of the forgone alternative cost).  the alternative cost to regrind history is missing because of the excess lookup disk IO bandwidth
22:11 < phantomcircuit> op_mul, thus the delay
22:12 < phantomcircuit> it gives a very strong incentive not to generate an orphaned block
22:12 < adam3us> phantomcircuit: maybe you can make a synthetic miner that imitates capital ownership
22:12 < bramc> adam3us, No it fails at the same point bitcoin does, when half the capacity decides to defect. That capacity has to stop participating in the main chain for it to work or they're working against themselves.
22:13 < op_mul> phantomcircuit: better idea: make miners with remote control thermite in them. if the manufacturer thinks you're being bad with their hardware you get to scrape the melted miner off the DC floor :P
22:13 < phantomcircuit> ha
22:13 < adam3us> bramc: but like you're assuming this behavior is stable; its also stable for all miners to constantly attack history and they have a small incentive to do so and its undetectable and zero cost.  this is why PoS degrades to alternate history grinding
22:13 < phantomcircuit> adam3us, if you try you end up with s weird PoS looking PoB system
22:13 < bramc> op_mul, the thing I'm describing most definitely has consensus building: The chain with the highest work factor wins. Same as anything else with mining. Although the calculation of work factor is slightly more complicated.
22:14 < phantomcircuit> ie you need to burn 10x to mine 1 but that only consumes having burned 1 so it's 1:1 but with 10x risk
22:14 < op_mul> bramc: I don't see how that scheme proves time at all, to be quite honest. it seems like it would devalue into someone just making a multi gigahertz FPGA and faking "time".
22:14 < bramc> adam3us, Attacking the history just keeps falling behind unless everybody's doing it as one giant conspiracy.
22:15 -!- Guest83163 [~Pan0ram1x@095-096-084-122.static.chello.nl] has quit [Ping timeout: 244 seconds]
22:15 < phantomcircuit> adam3us, this of course does lose a few of the inherent decentralization effects of electricity based mining
22:15 < bramc> op_mul, There are likely to be several counterparties who do in fact run very fast time provers, but the strategy is that the best match is spammed out to everybody and then people with fast time provers all run on the best thing they can find to keep each other honest
22:15 < adam3us> bramc: right but thats what i mean about stable strategy, that is actually what people end up doing with PoS - the protocol for honest mining says vote once per interval, but there's another protocol that says you get an advantage by simultaneously trying permutations of history that you'll increase your chance of winning
22:16 < adam3us> phantomcircuit: not sure elec based decentralisation is on a winning streak right now :|
22:17 < op_mul> bramc: I don't think that's a good assumption at all. someone with a fast FPGA and a big bag of dry ice would be able to tear through that particular proof type in an unsustainable way.
22:17 < bramc> adam3us, I've worked through this in detail and with the very specific way of calculating work factor I have it just doesn't work. If you take your second, third, fourth, etc. best matches their quality degrades so quickly that they become essentially worthless.
22:18 < bramc> op_mul, Did you read through the whole discussion previously about the alternating between work types and multiplying for the aggregate work factor? The details are subtle and important.
22:18 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards
22:19 < phantomcircuit> adam3us, heh
22:19 < phantomcircuit> adam3us, there's at least a delay
22:20 < adam3us> phantomcircuit: i was thinking of a coingen variant where the coins are virtual, and no electricity is used; via a provably fair central server protocol - eg you buy some mining research and get a quantum miner, sort of randomized tech, success ratio etc, gamify it like d&d dice etc
22:20 < op_mul> adam3us: no no, do it like Spore
22:20 < adam3us> phantomcircuit: use the saved electricity (being paid to the server) for some socially redeeming purpose
22:20 < phantomcircuit> heh
22:20 < bramc> *sigh*
22:21 < phantomcircuit> something deliciously ironic about you suggesting to replace hash based pow with something else
22:21 < phantomcircuit> :P
22:21 < adam3us> bramc: maybe the attack is clearer if we look at a large hashrate difference from a rapid mining escalation, or mining compared over a long period.
22:21 -!- Pan0ram1x [~Pan0ram1x@095-096-084-122.static.chello.nl] has joined #bitcoin-wizards
22:22 < adam3us> bramc: say its 1 years later and there is 1million x more storage online.  now as well as trying to stay up each miner adopts the alternate strategy of trying to rewrite all history.
22:22 < bramc> adam3us, It all doesn't matter. If you pick a point in the past and mine forward from that, you can only add work factor to the chain at a rate dependent on your storage capacity, and if your storage capacity is less than the storage capacity of the current network, you're still falling behind
22:22 < adam3us> bramc: ok maybe i am missing the effect of the time-lock
22:23 < adam3us> bramc: so the timelock is like a deterministic serialisable but efficiently verifiable proof of work that connects one block to the challenge for the next block?
22:23 < bramc> There's this important detail: The amount of time it takes to do the proof of time is inversely proportional to the quality of the proof of storage
22:24 < bramc> adam3us, Yes, there are goofy caveats and cheats but that's basically it.
22:25 < adam3us> bramc: you have to grind harder on the spow to use a closer sorted hash value?
22:26 < bramc> adam3us, You can't grind on the spow, it's deterministic on the sorted hash value used. You can only grind on the sorted hash values, and the problem there is that the less good ones are (usually) a lot less good
22:26 < bramc> Their distribution is in fact exactly the same as the distribution of how long it takes to mint a block in bitcoin
22:26 < bramc> (well, asymptotically so close that you can't tell the difference anyway)
22:28 < bramc> You take a hash, put a decimal point in front of it, multiply that by the current mining difficulty, and that tells you the number of iterations which the proof of time has to go through to complete the block.
22:28 -!- GnarSith [~far@onegrandcircle.com] has joined #bitcoin-wizards
22:28 < adam3us> bramc: yes but i am thinking of rewriting history at a point from the future where the storage capacity is 1mil x current say.  then i could rewrite history easily. however i think that creates a different spow challenge which is the network heartbeat so then you dont catchup
22:29 < bramc> You can rewrite history easily but it's like rewriting bitcoin history: I can easily make a chain which gives me the first few years's worth of coins, which is most of them, but it loses because its total work factor is less than what the network as a whole has generated.
22:29 < adam3us> bramc: grind i didnt mean to search alternates, just that i am assuming the spow deterministically starts from the best solution to the last block.  and because you said you have to work harder if your closest match was weak
22:30 < adam3us> bramc: well in bitcoin with < 50% of hashrate you basically cant catchup and you lose money fast with < 50% doing that from the forgone reward
22:31 < adam3us> bramc: i am not sure how it works with your system but unless fresh spows' take effect slowing down the historiy rewrite someone with a future much larger storage can maybe catchup or repeatedly try until they get lucky
22:32 < bramc> adam3us, Yeah same thing happens, although there's the caveat that you can participate in the current chain and try alternate histories in parallel, which creates a small advantage to larger pools because they have a greater chance of getting lucky and overtaking. They fall behind so fast that the effect is small though, and it's counterbalanced by the proofs being nonoutsourceable.
22:35 < bramc> The repeated trying, as I keep trying to explain, doesn't work, because if you take the chances that your second, third, fourth, etc. best matches will overtake on the next generation the sum is not only finite, it's small
22:35 < bramc> You really get obliterated by the expected quality of your follow-on match being based on your own storage capacity, which of course is less than the network as a whole.
22:37 < adam3us> bramc: i suppose you would repeatedly gind the disk in the background to also make the hashes closer to equidistant to improve your odds a little
22:37 < bramc> and, uh, yeah, the spow is based directly off the previous history. If you change a match used at one point every subsequent spow must be redone from scratch
22:39 < adam3us> bramc: right that maybe by itself mostly kills history rewriting, though perhaps someone can make an asic and liquid nitrogen cool it
22:39 < bramc> adam3us, unless you're close to half the capacity of the network as a whole that's unlikely to matter. There are somewhat crazier tricks where you can squeeze out a bit more virtual space out of your storage media in exchange for a bit more CPU though.
22:40 < adam3us> bramc: the usual time-memory tradeofss (TMTO) yeah.  they can bite you though… momentum pow was weakened by that, scrypt also has TMTOs
22:40 < bramc> adam3us, if somebody has a faster spow they have a much more straightforward attack where they win more of the current mining by making themselves win in the event of a near tie. That one winds up being a lot like making ASICs: multiple people can do it but they wind up in a stalemate
22:40 < adam3us> bramc: anyway everyone can run that algo so its not a trap door advantage
22:41 < bramc> Anyone with any significant mining capacity has an incentive to run their own accelerated spow server on the best match they get just to keep anybody else from getting ahead.
22:41 < adam3us> bramc: also i suppose there is nothing stopping you trying hundreds of spow alternate histories in parallel so luck can be searched for more widely
22:42 < bramc> adam3us, Yes you can do that but like I said the chances of any of them catching up are so low that it hardly matters
22:43 < adam3us> bramc: the more convincing argument on that is if big miners have their own liquid nitrogen asic spow chip and are fighting with the history rewriters
22:44 < op_mul> adam3us: if you assume that the network is on a level playing field you can have them making multiple attempts at once, which is interesting.
22:44 < bramc> adam3us, the spow resources are pooled: everybody takes the best match they has and publishes it and the best one gets distributed everywhere, and the spow servers all get to work on that and send out the proof of time as quickly as they can
22:45 < adam3us> bramc: but maybe they will keep it secret if there is selfish time advantage to doing that
22:45 < bramc> So if you have the very fastest spow server you can use it to get ahead a little, but if you have the second fastest you can use it to undermine the very fastest.
22:45 < phantomcircuit> adam3us, huh
22:45 < phantomcircuit> i think the PoB mining might actually be incentives compatible
22:46 < phantomcircuit> ooh i remember what im missing
22:46 < phantomcircuit> delays
22:46 < bramc> adam3us, It does create an interesting oligopoly situation
22:47 < bramc> I'm expecting/hoping that it's very expensive to get a speed advantage over the obvious approaches and that the advantage you gain isn't really all that much. This is analogous to how efficient people can make ASICs of course. If someone could make an ASIC 100x as efficient as everybody else's in bitcoin they could rule the whole network
22:48 < op_mul> efficient? don't you just want raw speed?
22:48 < bramc> phantomcircuit, Proof of Boron?
22:48 < bramc> op_mul, no the costs are mostly determined by electricity usage
22:48 < op_mul> if you let me throw efficiency out the window and a big enough tank of LN2, we're going to the moon.
22:48 < op_mul> hm.
22:48 < bramc> I mean for Bitcoin mining, not for proofs of time
22:48 < op_mul> ah
22:49 < bramc> obviously for proofs of time all that matters is speed, my point is that the risks of somebody coming up with fundamentally better technology are analogous.
22:49 -!- koshii_ [~0@node-vp9.pool-101-109.dynamic.totbb.net] has joined #bitcoin-wizards
22:50 < adam3us> bramc: similar yes.  here the single core speed optimisation gives the miner a linear speed up on their history rewriting so they might gain something by being 2x-5x as fast which might be possible
22:50 -!- koshii [~0@node-gvc.pool-180-180.dynamic.totbb.net] has quit [Ping timeout: 250 seconds]
22:50 < adam3us> bramc: but anyway presumably competitors would move forward in parallel of having fast spow chips
22:51 < bramc> adam3us, That's the hope, yes
22:52 < bramc> The whole thing is a bit of an experiment. Of course so is Bitcoin.
22:53 < op_mul> sort of feels like the network would just boil down (haha) to liquid nitrogen, but it would be fun to get to play with hardware again.
22:54 < bramc> op_mul, I feel a lot better about subsidizing the development of chips with faster clock rates than ASICs which pile on more sha1 calculations
22:56 < gmaxwell> in the context of sequential mining faster clock rates probably means make 10,000 copies of the same circuit; and drive them at 200% of the clockrate any sensible logic would run at, and find that only 2 of the 10,000 gave a correct result at the end.
22:57 < gmaxwell> (which is analogous to how bitcoin mining hardware today already works, they do closed loop control to maximize good hashrate out, often running at a fault rate of about 1% or so)
22:57 < bramc> gmaxwell, Sounds plausible, I wouldn't know, I'm not a hardware person
22:57 < op_mul> gmaxwell: and some deep pity for whoever has to sit there with a ZIF socket and trays and trays of chips to bin
22:58 < gmaxwell> op_mul: probably can do a fair bit of profiling per die before packaging.
22:59 < bramc> gmaxwell, there might be benefit in having three cores run together and vote about the result after each iteration to keep the reliability up.
22:59 < op_mul> gmaxwell: I was thinking the lead frame and bond wires would alter the performance at least a bit, but I suppose you'd do a rough cut and then a find cut once they're packaged? super not my area either.
23:00 < op_mul> gmaxwell: (and again I'm forgetting that they wouldn't be DIP, I don't think BGA stuff even has a lead frame so.. maybe just ignore that)
23:00 -!- richardkiss [~richardki@108-94-29-170.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
23:01 < gmaxwell> bramc: yea, indeed, each iteration do a vote and have the majority broadcast to the rest. also do fun things like build half with positive going logic half with negative going, so the load is equalized out.. lots of fun analog hacks that arise when you're at the boundary of correctness and can't use the parallelism for anything else anyways.
23:02 < gmaxwell> op_mul: you can probably do initial binning with purely electrical tests. E.g. measuring the idle load and such.
23:03 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
23:04 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
23:04 < bramc> There's this goofy detail which nobody's asked about, which is how to avoid retroactive changing of the transaction roots, because they don't factor into the trunk of the proof of work. You have to have two parallel chains, the trunks, which is very canonical and decides the challenges for the next generation, and the leaves which are of necessity extremely malleable because they contain the transaction roots but shadow
23:04 < bramc> the trunk and has its own spows. To be accepted a proof of time must contain the proofs for both the trunk and the leaves.
23:05 -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.]
23:06 -!- d1ggy [~d1ggy@dslb-092-076-025-214.092.076.pools.vodafone-ip.de] has quit [Ping timeout: 245 seconds]
23:06 < op_mul> wait, doesn't this system mean that a new node coming to the network can never sync?
23:06 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 245 seconds]
23:06 < op_mul> ie, they'd never catch up with the 1:1 verification of the linear hashing
23:07 < bramc> No it syncs the same way nodes in bitcoin sync, it downloads and verifies the chain with the largest work factor it can find
23:07 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 252 seconds]
23:07 < op_mul> but verifying would be symmetrical
23:08 -!- dansmith_ [~dansmith@static-ip-188-138-127-218.inaddr.ip-pool.com] has quit [Ping timeout: 246 seconds]
23:08 < bramc> oh, you don't verify all the steps in the proofs of time, you spot check them, and that can be done in parallel unlike the generation which has to be done sequentially
23:09 -!- dansmith_btc [~dansmith@static-ip-188-138-127-218.inaddr.ip-pool.com] has joined #bitcoin-wizards
23:09 < bramc> There's also a message to say 'that proof of time you just sent me is busted, recheck position X'
23:09 < op_mul> you can do verification in parallel too I suppose.
23:09 < bramc> this is that 'gimmicky cheat' I was talking about
23:09 -!- adam3us [~Adium@172.56.32.216] has joined #bitcoin-wizards
23:12 < bramc> It makes designing the protocol and database logic even weirder than it is in Bitcoin
23:12 < bramc> Having data which can get invalidated and revalidated in multiple ways is bizarre
23:13 -!- adam3us [~Adium@172.56.32.216] has quit [Client Quit]
23:13 < op_mul> anything that's strating from scratch can have arguably better code than bitcoin, so it probably evens out. having all transactions P2SH would be nice, for example.
23:15 < bramc> Yes of course that's done, and using schnorr signatures, and have utxo identities not include the signature so transactions aren't malleable. These are small things though, they aren't worth restarting from scratch just for them.
23:16 < bramc> Also these proofs of work happen to be somewhat nonoutsourcable by nature, which is another good feature
23:17 < phantomcircuit> gmaxwell, fun fact, making the chip testable costs 1-5% of the die area
23:17 < phantomcircuit> brb un binnable chip
23:21 < bramc> But the other really big issues in Bitcoin: scaling and transaction clearing time, are ones which I don't know of any super compelling answers for, and truth be known the not super compelling stuff petertodd's working on to make transaction fees behave properly at the scaling limit is the immediate thing which needs to happen and an experiment worth running
23:21 -!- Anduck_ [~anduck@anduck.net] has joined #bitcoin-wizards
23:22 -!- Anduck_ is now known as Guest4097
23:22 < bramc> As in, I want to know how much transactions are really worth.
23:22 < bramc> Of course transactions could all clear instantly if only people weren't spreading FUD about how insecure zeroconf is :-)
23:23 < op_mul> bramc: is that sarcasm?
23:25 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 256 seconds]
23:25 < bramc> op_mul, yes you missed the discussion earlier where I posted this link http://www.reddit.com/r/Bitcoin/comments/28jp0y/why_is_peter_todd_wrecking_zeroconf_security/
23:26 < op_mul> ah yes I'm aware of that post.
23:26 < op_mul> I'm fond of greenaddress.it's solution to it really. works well within the constraints.
23:26 < bramc> I can't tell if the poster is a troll or mental
23:26 < op_mul> third option, working with an agenda
23:27 < bramc> Yes greenadress is a good idea, and likely the best which can be done all things considered. There should ideally be multiple vendors of that service though.
23:28 -!- Netsplit *.net <-> *.split quits: burcin, gmaxwell, ebfull, Anduck, brad__
23:28 < bramc> Although it's unclear whether well-designed protocol venders can succeed given that they cheat themselves out of the 'oops we accidentally your whole deposit' business model.
23:28 -!- c0rw1n [~c0rw1n@91.176.85.209] has quit []
23:29 < bramc> Wow a netsplit, it feels so 90s
23:29 < op_mul> no, feels like freenode.
23:29 < bramc> Almost like we're on freenode
23:30 < phantomcircuit> bramc, they can still do that for the most part
23:30 < op_mul> I think with systems like GAit you're mainly fighting people who think that their moronic system of "watch the whole network" is somehow a solution. we know miners will do finney attacks. it's happened before.
23:31 -!- Netsplit over, joins: burcin
23:33 < bramc> My early impressions of bitcoin were a bit overly negative because I had the impression that that 'watch the whole network' stuff was central to its security guarantees, which of course it isn't at all.
23:34 < op_mul> sadly that's a pretty common misconnection.
23:34 < bramc> It seems even people who believe in bitcoin as a religion have only the vaguest understanding of what it actually does.
23:35 < bramc> Like, people go off on these asinine things about how somebody figured out a way to make mining do work to improve the environment, and I'm like 'that's the stupidest thing I've ever heard'.
23:35 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards
23:35 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards
23:35 -!- brad__ [~brad@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards
23:36 < op_mul> the reason they get any level of traction is that they stand unattacked.
23:37 < bramc> Who/what is the 'they' you're talking about here?
23:37 < op_mul> there's heaps of altcoins with no consensus model at all which have stood for months or years. that's held as proof that the system is secure.
23:37 < bramc> And Bernie Madoff's fund was worth billions
23:37 < op_mul> they == consensusless altcoins
23:37 < op_mul> which lets face it, is most of them
23:38 < bramc> I thought most altcoins are trivial forks with nothing much done other than modifications of the PoW, but I haven't done a survey
23:38 -!- aburan [~ubuntu@static-108-45-93-93.washdc.fios.verizon.net] has quit [Ping timeout: 252 seconds]
23:39 < gmaxwell> [OT] http://the-toast.net/2015/02/12/tell-logic-puzzle/ "How To Tell If You Are In A Logic Puzzle"
23:39 < midnightmagic> Almost every single of them is; half of them don't even have a PoW mod. Some of them just have shorter block confirm times.
23:41 -!- lclc_bnc is now known as lclc
23:42 -!- d1ggy [~d1ggy@dslb-092-076-025-214.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards
23:43 < bramc> midnightmagic, I've decided that a reasonable threshold for seriousness of an altcoin is whether it makes utxos be referred to by the transaction rather than the signature. Haven't done a survey, but I think that's hardly any of them.
23:44 < gmaxwell> uh? I don't think there is a single system in production that managed to make the trivial change or reorging things to get the witness(/signature) out of the transaction ID, is there?
23:45 < bramc> Haven't done a survey, subject too depressing.
23:47 < op_mul> even just counting the total number of altcoins is a problem.
23:47 < op_mul> by some counts it's 6-700, I think it's closer to 1500
23:49 -!- bedeho [~bedeho@195.159.234.190] has joined #bitcoin-wizards
23:56 < phantomcircuit> gmaxwell, that would require understanding
23:56 < phantomcircuit> so
23:56 < phantomcircuit> no
23:57 < phantomcircuit> op_mul, it's infinity
23:57 < phantomcircuit> i actually did generate about 1m altcoins just to prove a point to someone
23:57 < phantomcircuit> they are of course unreleased as they dont work
23:57 < op_mul> not much different to the real thing then
23:58 < op_mul> you can't beat the one that's in obfsucated javascript though.
23:59 -!- siraj_ [~siraj@223.232.150.77] has joined #bitcoin-wizards
--- Log closed Sat Feb 14 00:00:54 2015