| --- Log opened Fri Feb 13 00:00:53 2015 | ||
| -!- hktud0 [wq@unaffiliated/fluffybunny] has quit [Read error: Connection reset by peer] | 00:01 | |
| -!- hktud0 [wq@unaffiliated/fluffybunny] has joined #bitcoin-wizards | 00:04 | |
| -!- lclc_bnc is now known as lclc | 00:08 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-lceammlazwdcikko] has quit [Read error: Connection reset by peer] | 00:09 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kqpjdrldaxwwpxtp] has joined #bitcoin-wizards | 00:12 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 00:14 | |
| -!- xabbix__ [~xabbix@109.66.58.93] has quit [Read error: Connection reset by peer] | 00:16 | |
| -!- jaekwon_ [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Ping timeout: 244 seconds] | 00:17 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 00:25 | |
| -!- ielo [~ielo@host-92-24-40-10.ppp.as43234.net] has joined #bitcoin-wizards | 00:50 | |
| -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards | 00:54 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 01:01 | |
| -!- 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:05 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kqpjdrldaxwwpxtp] has quit [Read error: Connection reset by peer] | 01:08 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-irdvhglemcyltpsl] has joined #bitcoin-wizards | 01:12 | |
| -!- lclc is now known as lclc_bnc | 01:16 | |
| -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards | 01:26 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 01:38 | |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 01:42 | |
| -!- btcz [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 01:47 | |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] | 01:54 | |
| -!- 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:55 | |
| -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-wizards | 01:57 | |
| -!- lclc_bnc is now known as lclc | 01:58 | |
| -!- btcz [~benten@unaffiliated/benten] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 01:59 | |
| -!- coiner [~linker@115.79.43.208] has joined #bitcoin-wizards | 02:06 | |
| -!- bit2017 [~linker@115.79.43.208] has joined #bitcoin-wizards | 02:08 | |
| -!- bit2017 [~linker@115.79.43.208] has quit [Max SendQ exceeded] | 02:09 | |
| -!- bit2017 [~linker@115.79.43.208] has joined #bitcoin-wizards | 02:09 | |
| -!- coiner [~linker@115.79.43.208] has quit [Ping timeout: 265 seconds] | 02:11 | |
| -!- bit2017 [~linker@115.79.43.208] has quit [Ping timeout: 250 seconds] | 02:14 | |
| -!- TonyClifton [~TonyClift@gateway-nat.fmrib.ox.ac.uk] has joined #bitcoin-wizards | 02:15 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 246 seconds] | 02:16 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:f930:3d26:ce70:95f4] has joined #bitcoin-wizards | 02:20 | |
| -!- ielo [~ielo@host-92-24-40-10.ppp.as43234.net] has quit [Ping timeout: 255 seconds] | 02:26 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 02:31 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 02:31 | |
| -!- UmInAsHoE [~textual@156.18-35-82.static.virginmediabusiness.co.uk] has joined #bitcoin-wizards | 02:52 | |
| -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 03:01 | |
| -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] | 03:09 | |
| -!- p15__ [~p15@111.193.161.161] has joined #bitcoin-wizards | 03:10 | |
| -!- p15_ [~p15@182.50.108.89] has quit [Ping timeout: 256 seconds] | 03:12 | |
| -!- UmInAsHoE [~textual@156.18-35-82.static.virginmediabusiness.co.uk] has quit [Ping timeout: 250 seconds] | 03:14 | |
| -!- lclc is now known as lclc_bnc | 03:26 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] | 03:34 | |
| -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards | 03:39 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds] | 03:42 | |
| -!- lclc_bnc is now known as lclc | 03:43 | |
| -!- ielo [~ielo@134.219.227.35] has joined #bitcoin-wizards | 03:43 | |
| -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards | 03:45 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 03:57 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-irdvhglemcyltpsl] has quit [Ping timeout: 250 seconds] | 04:00 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-requkizdhwxnumsz] has joined #bitcoin-wizards | 04:02 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 04:15 | |
| -!- OneNomos [~OneNomos@gateway/vpn/privateinternetaccess/onenomos] has joined #bitcoin-wizards | 04:21 | |
| -!- realcr [~real@bzq-79-183-147-92.red.bezeqint.net] has joined #bitcoin-wizards | 04:23 | |
| -!- 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:26 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 04:29 | |
| -!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards | 04:39 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-requkizdhwxnumsz] has quit [Ping timeout: 252 seconds] | 04:51 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-tmhguvgjezhuclhz] has joined #bitcoin-wizards | 04:53 | |
| -!- antgreen [~user@74.112.41.171] has joined #bitcoin-wizards | 05:07 | |
| -!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 245 seconds] | 05:10 | |
| -!- p15__ [~p15@111.193.161.161] has quit [Max SendQ exceeded] | 05:16 | |
| -!- p15 [~p15@111.193.161.161] has joined #bitcoin-wizards | 05:17 | |
| -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 05:20 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 05:28 | |
| 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:30 |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-tmhguvgjezhuclhz] has quit [Ping timeout: 250 seconds] | 05:31 | |
| fluffypony | replace-by-cheese | 05:31 |
| 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:32 |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-vbhgexgikxdjkjwq] has joined #bitcoin-wizards | 05:33 | |
| -!- 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:48 |
| -!- orperelman [~orperelma@bzq-79-181-128-67.red.bezeqint.net] has joined #bitcoin-wizards | 05:52 | |
| -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards | 05:56 | |
| -!- lclc_bnc is now known as lclc | 05:58 | |
| 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:02 | |
| -!- maraoz [~maraoz@43-161-16-190.fibertel.com.ar] has joined #bitcoin-wizards | 06:07 | |
| -!- epscy_ [~epscy@176.126.241.239] has quit [Ping timeout: 245 seconds] | 06:26 | |
| -!- epscy_ [~epscy@176.126.241.239] has joined #bitcoin-wizards | 06:27 | |
| -!- 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:28 | |
| -!- antgreen [~user@74.112.41.171] has quit [Ping timeout: 264 seconds] | 06:39 | |
| -!- dabura667 [uid43070@gateway/web/irccloud.com/x-ynphsuryknakxcvi] has joined #bitcoin-wizards | 06:40 | |
| -!- linelevel1 [~mike@96.237.65.66] has joined #bitcoin-wizards | 06:45 | |
| -!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 245 seconds] | 06:48 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 06:56 | |
| -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Ping timeout: 256 seconds] | 06:59 | |
| -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] | 07:02 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 245 seconds] | 07:08 | |
| -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Ping timeout: 256 seconds] | 07:12 | |
| -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards | 07:15 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 07:17 | |
| -!- 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:19 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds] | 07:35 | |
| -!- siraj [~siraj@triband-mum-120.62.42.243.mtnl.net.in] has joined #bitcoin-wizards | 07:43 | |
| -!- afk11 [~thomas@89.100.72.184] has joined #bitcoin-wizards | 07:47 | |
| -!- 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:50 | |
| -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 264 seconds] | 07:51 | |
| -!- 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:52 | |
| -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has joined #bitcoin-wizards | 07:53 | |
| -!- 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:04 | |
| -!- xabbix_ [~xabbix@bzq-109-65-123-131.red.bezeqint.net] has quit [Read error: Connection reset by peer] | 08:05 | |
| -!- siraj_ [~siraj@117.98.36.52] has joined #bitcoin-wizards | 08:11 | |
| -!- 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:12 | |
| -!- siraj [~siraj@triband-mum-120.62.42.243.mtnl.net.in] has quit [Ping timeout: 252 seconds] | 08:13 | |
| -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has joined #bitcoin-wizards | 08:17 | |
| -!- gonedrk1 [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Read error: Connection reset by peer] | 08:18 | |
| -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Max SendQ exceeded] | 08:21 | |
| -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 08:22 | |
| -!- 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:24 | |
| -!- 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:25 | |
| -!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has joined #bitcoin-wizards | 08:27 | |
| -!- 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:35 |
| 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:36 |
| 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:37 |
| Apocalyptic | op_mul, heh | 08:38 |
| nsh | friday the 13th is a good day to publish such a finding :) | 08:38 |
| earlz | lawl | 08:38 |
| earlz | ethereum sounds like some really cool technology that won't ever actually work in practice heh | 08:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| kanzure | siraj_: wrong channel, use #bitcoin | 08:47 |
| kanzure | earlz: checkpoints don't do what you think they do | 08:47 |
| 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:48 |
| 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:49 |
| 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:50 | |
| MRL-Relay | [tacotime] op_mul: "aerialSecpK", uses k values from random.org | 08:51 |
| fluffypony | ouch | 08:51 |
| 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:52 |
| earlz | deterministic RNG? wat | 08:53 |
| op_mul | well for ECDSA deterministic nonces are what you want. just not ethereum flavoured ones. | 08:53 |
| 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:55 |
| 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:56 | |
| 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:57 | |
| fluffypony | earlz: perfect | 08:58 |
| 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:00 | |
| -!- siraj_ [~siraj@117.98.36.52] has quit [Read error: Connection reset by peer] | 09:04 | |
| -!- siraj [~siraj@106.207.65.53] has joined #bitcoin-wizards | 09:05 | |
| -!- siraj [~siraj@106.207.65.53] has quit [Client Quit] | 09:07 | |
| -!- flower [~user@202.44.238.15] has quit [Max SendQ exceeded] | 09:09 | |
| 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:10 |
| op_mul | s/got/for/ | 09:11 |
| -!- bedeho [~bedeho@195.159.234.190] has quit [Quit: Nettalk6 - www.ntalk.de] | 09:12 | |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| -!- flower [~user@202.44.238.15] has joined #bitcoin-wizards | 09:19 | |
| -!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards | 09:20 | |
| 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:21 |
| 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:22 |
| nickler | fun, I fully agree :) | 09:24 |
| -!- ielo [~ielo@134.219.227.35] has quit [Ping timeout: 265 seconds] | 09:25 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 246 seconds] | 09:27 | |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:36 |
| -!- 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:39 |
| -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 09:43 | |
| * nsh nods | 09:44 | |
| 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:46 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:f930:3d26:ce70:95f4] has quit [Ping timeout: 245 seconds] | 09:50 | |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 10:01 | |
| -!- benten [~benten@unaffiliated/benten] has quit [Client Quit] | 10:01 | |
| -!- 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:11 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 10:12 | |
| -!- 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:18 |
| 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:19 |
| -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection] | 10:20 | |
| 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:21 |
| 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:22 |
| -!- maaku_ is now known as maaku | 10:25 | |
| GAit | I'm really impressed with libsecp256k1 | 10:25 |
| 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:27 |
| GAit | I think 20X with firefox and 10x on chrome | 10:30 |
| -!- 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 | 10:59 | |
| -!- xabbix__ [~xabbix@bzq-79-180-107-228.red.bezeqint.net] has quit [Ping timeout: 246 seconds] | 11:00 | |
| -!- xabbix__ [~xabbix@bzq-79-176-58-46.red.bezeqint.net] has joined #bitcoin-wizards | 11:01 | |
| -!- sipa [~pw@2a02:348:5e:5a29::1] has joined #bitcoin-wizards | 11:04 | |
| -!- 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:11 | |
| -!- 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:15 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] | 11:19 | |
| -!- siraj [~siraj@106.221.158.211] has joined #bitcoin-wizards | 11:26 | |
| -!- tylersmith [~tylersmit@173.247.206.110] has joined #bitcoin-wizards | 11:27 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 11:47 | |
| -!- ielo [~ielo@host-78-147-237-163.as13285.net] has joined #bitcoin-wizards | 11:57 | |
| -!- AlienProject [~Alien_Pro@72.53.101.165] has quit [Ping timeout: 265 seconds] | 12:00 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds] | 12:03 | |
| phantomcircuit | gmaxwell, i hadn't noticed that it was based on an HMAC function before | 12:04 |
| -!- siraj [~siraj@106.221.158.211] has quit [Remote host closed the connection] | 12:06 | |
| -!- tylersmith [~tylersmit@173.247.206.110] has quit [] | 12:09 | |
| -!- 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:20 | |
| -!- dogetime [~dogetime@unaffiliated/dogetime] has left #bitcoin-wizards [] | 12:22 | |
| 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:27 |
| 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:28 |
| gmaxwell | really for our use in bitcoin land it's super irrelevant that its slow. | 12:29 |
| -!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards | 12:30 | |
| -!- 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:32 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 12:36 | |
| -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 12:45 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] | 12:50 | |
| -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Remote host closed the connection] | 12:51 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-vbhgexgikxdjkjwq] has quit [Read error: Connection reset by peer] | 12:55 | |
| -!- Starsoccer [~starsocce@unaffiliated/starsoccer] has quit [Ping timeout: 252 seconds] | 12:58 | |
| -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-zdxgazusmltlmqvg] has joined #bitcoin-wizards | 12:59 | |
| phantomcircuit | gmaxwell, right | 13:11 |
| phantomcircuit | i assume there isn't any question of it's sanity other wise? | 13:11 |
| -!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 256 seconds] | 13:21 | |
| -!- AlienProject [~Alien_Pro@72.53.101.165] has quit [Ping timeout: 245 seconds] | 13:32 | |
| -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards | 13:34 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 13:49 | |
| bramc | Hey everybody I have questions/thoughts about replace-by-fee and the general stuff surrounding it | 13:50 |
| 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:51 |
| tromp__ | hi Bram. txs must redeem all inputs from earlier blocks | 13:52 |
| 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:53 |
| bramc | phantomcircuit, AUGH | 13:54 |
| paperbot | http://diyhpl.us/~bryan/papers2/paperbot/e2eeadf8dbaf1a207adaaac0659729e8.pdf | 13:54 |
| phantomcircuit | bramc, it's actually not that bad | 13:55 |
| phantomcircuit | but yeah it can be kind of annoying | 13:55 |
| 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:56 |
| 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:57 |
| -!- 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:58 |
| 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 | 13:59 | |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| phantomcircuit | heh pretty sure you'd have to support it either way | 14:04 |
| 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:05 |
| bramc | tromp__, I'm guessing 2 or 3, and that it's been used dozens, perhaps even hundreds, of times. | 14:06 |
| -!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards | 14:07 | |
| 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:08 |
| 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:10 |
| 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:11 |
| -!- 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:15 |
| 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:17 |
| 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:23 |
| 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:24 |
| kanzure | ah well people in here are quite vocal about identifying idiocy so you'll be informed in a timely manner | 14:25 |
| 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:26 | |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:32 |
| 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:33 |
| -!- 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:34 |
| 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:37 |
| 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:40 |
| 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:43 |
| 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:44 |
| 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:45 |
| -!- NewLiberty_ is now known as NewLiberty | 14:46 | |
| 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:47 |
| 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:48 |
| 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:49 |
| -!- orik [~orik@75.149.169.53] has joined #bitcoin-wizards | 14:50 | |
| -!- Skipppy is now known as Mably | 14:50 | |
| nsh | okay | 14:50 |
| 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:51 | |
| 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:52 | |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 14:59 |
| bramc | It's a moderately sophisticated attack. Easy for you or me, but we aren't about to do it. | 15:00 |
| -!- 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:01 |
| bramc | Also not sure what you mean by nReplacedFees + nFeesToRelayReplacement there's some piece of logic in there which I'm unfamiliar with | 15:02 |
| -!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 15:03 | |
| petertodd | sorry, one sec | 15:04 |
| -!- orik [~orik@75.149.169.53] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 15:05 | |
| gmaxwell | petertodd: per byte is also a one way ratchet in the limit. | 15:10 |
| 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:11 |
| 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:12 | |
| 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:14 |
| bramc | Yes that's a good property, although it might have downsides | 15:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| bramc | petertodd, What logic do you have for replacement of transactions with multiple inputs? | 15:20 |
| 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:21 |
| -!- 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:22 |
| 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:23 |
| -!- 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:24 |
| -!- aburan28 [~ubuntu@static-108-45-93-93.washdc.fios.verizon.net] has joined #bitcoin-wizards | 15:25 | |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 15:26 | |
| bramc | petertodd, So what was that about the increasing epsilons again? Something about nFeesToRelayReplacement | 15:28 |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 15:29 | |
| 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:30 | |
| 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:32 |
| bramc | petertodd, My back of the envelope calculation says that that amounts to 2 cents/block at max size | 15:35 |
| -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 245 seconds] | 15:36 | |
| petertodd | bramc: wait, no that's wrong, it's 10uBTC/KB | 15:36 |
| petertodd | bramc: $2.5/block, which is absurd | 15:37 |
| -!- 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:38 |
| 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:39 |
| 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:40 |
| 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:41 | |
| 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:42 |
| bramc | My concern about rebroadcasting a transaction isn't much of an issue if the wallet can be responsible for rebroadcasting | 15:43 |
| petertodd | bramc: yeah, anyway, lots of work needs to be done on wallets for sure | 15:45 |
| 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:46 |
| -!- 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:47 | |
| -!- 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:48 |
| 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:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| -!- 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:54 |
| 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:55 |
| nsh | lol | 15:56 |
| nsh | damn | 15:56 |
| -!- ielo [~ielo@host-78-147-237-163.as13285.net] has quit [Ping timeout: 252 seconds] | 15:56 | |
| petertodd | bramc: https://twitter.com/petertoddbtc/status/566385692276584449 | 15:57 |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 15:57 | |
| -!- 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:58 | |
| bramc | I'm coming up with some more somewhat annoying dos attacks. It's a bit of a cat and mouse game | 15:59 |
| petertodd | heh | 16:00 |
| 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:01 |
| 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:02 |
| -!- shesek [~shesek@87.68.49.90.cable.012.net.il] has joined #bitcoin-wizards | 16:03 | |
| justanotheruser | thats strange | 16:03 |
| bramc | justanotheruser, It's because of what I'm known for writing | 16:04 |
| justanotheruser | some game? | 16:04 |
| bramc | some p2p thing | 16:05 |
| petertodd | justanotheruser: really, we have groupies that act like 13 year old boys on 4chan... | 16:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| justanotheruser | bramc: the scarce resource that is being burned is just the electricity used to make that hardware then isn't it? | 16:11 |
| 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:12 |
| 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:13 |
| kanzure | man i hate how you treat us as forgetful morons | 16:14 |
| 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:15 |
| 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:16 | |
| 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:17 |
| 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:18 |
| kanzure | ugh | 16:19 |
| 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:20 |
| -!- 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| -!- 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:28 |
| kanzure | then what's the point of that function? | 16:29 |
| kanzure | it must have a different output given a different input | 16:29 |
| -!- 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:30 |
| 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:31 | |
| -!- 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:33 |
| -!- 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:35 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 16:36 | |
| 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:37 |
| 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:38 |
| 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:40 |
| -!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has quit [Remote host closed the connection] | 16:41 | |
| 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:42 |
| 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:44 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 16:45 | |
| bramc | I'm also happy to keep answering questions, although this rathole continues for a while. | 16:48 |
| ryan-c | ethereum screwed up deterministic nonces? | 16:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| ryan-c | (unrelated) anyone know where maaku is on utxo with coinbase commitment and if he's still working on it? | 16:55 |
| 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:56 | |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| 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:01 |
| -!- 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| bramc | justanotheruser, Yeah the script, it's overly complicated with no clear benefit. All the proposed extensions are op_verify anyway | 17:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| -!- 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:11 |
| 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:12 |
| 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:13 |
| justanotheruser | bramc: that's a hack | 17:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| ryan-c | bramc: can the numbers between one and ten be guessed separately? | 17:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| bramc | kanzure, hold on, two very different points here | 17:34 |
| kanzure | in your system? | 17:34 |
| 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:36 |
| 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:37 | |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| bramc | adam3us, no I'll have to read through that | 17:43 |
| 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:44 |
| adam3us | bramc: yeah ic. micromint is only slightly related probably. they gain advantage overtime by storing large amounts of k-way collision candidates | 17:45 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| kanzure | -( -) | 17:54 |
| bramc | kanzure, at points I'm honestly not sure what you're trying to say | 17:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| bramc | kanzure, I don't see what the point of that semantic distinction is | 17:58 |
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| kanzure | yes something about parallel time not existing | 18:07 |
| 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:08 |
| 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:09 |
| bramc | kanzure, hold on for a sec on the spow farm, I can only type so fast | 18:10 |
| kanzure | http://www.seanwrona.com/typeracer/profile.php?username=kanzure | 18:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 | |
| 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:18 |
| 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:19 |
| 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:20 | |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| bramc | This is, in fact, mining. | 18:33 |
| 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:36 | |
| -!- 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:37 |
| kanzure | my telepathic link to adam3us seems to be working so i will continue to lazily rely on him to word my complaints | 18:38 |
| 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:41 |
| bramc | adam3us, It's storage space times time | 18:42 |
| 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:43 |
| -!- Dr-G2 [~Dr-G@gtng-4d08ddbe.pool.mediaWays.net] has joined #bitcoin-wizards | 18:44 | |
| -!- Dr-G3 [~Dr-G@gtng-4d08d252.pool.mediaWays.net] has quit [Ping timeout: 245 seconds] | 18:47 | |
| -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.] | 18:51 | |
| -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards | 18:51 | |
| -!- Dr-G2 [~Dr-G@gtng-4d08ddbe.pool.mediaWays.net] has quit [Ping timeout: 252 seconds] | 18:52 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has quit [Ping timeout: 245 seconds] | 18:55 | |
| -!- 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:01 | |
| -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.] | 19:02 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 256 seconds] | 19:02 | |
| -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Quit: Leaving] | 19:03 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 250 seconds] | 19:06 | |
| -!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] | 19:16 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 19:21 | |
| -!- Starsoccer [~starsocce@unaffiliated/starsoccer] has joined #bitcoin-wizards | 19:31 | |
| -!- 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:32 | |
| -!- 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:37 | |
| 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:38 |
| kanzure | that doesn't make sense | 19:39 |
| 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:40 |
| 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. | 19:43 |
| -!- 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:03 | |
| -!- koeppelmann [~koeppelma@dyn-160-39-29-101.dyn.columbia.edu] has quit [Ping timeout: 246 seconds] | 20:05 | |
| -!- OneNomos [~OneNomos@gateway/vpn/privateinternetaccess/onenomos] has quit [Remote host closed the connection] | 20:06 | |
| -!- siraj [~siraj@triband-mum-120.62.22.172.mtnl.net.in] has joined #bitcoin-wizards | 20:08 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 265 seconds] | 20:10 | |
| -!- freewil [~freewil@unaffiliated/freewil] has quit [Quit: Leaving.] | 20:15 | |
| -!- koeppelmann [~koeppelma@dyn-160-39-213-51.dyn.columbia.edu] has joined #bitcoin-wizards | 20:17 | |
| -!- koeppelmann [~koeppelma@dyn-160-39-213-51.dyn.columbia.edu] has quit [Ping timeout: 245 seconds] | 20:23 | |
| -!- richardkiss [~richardki@108-94-29-170.lightspeed.sntcca.sbcglobal.net] has quit [Quit: richardkiss] | 20:33 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards | 20:35 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds] | 20:43 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:45 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 250 seconds] | 20:55 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 20:58 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake] | 21:04 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 21:07 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 264 seconds] | 21:44 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:6d06:2acc:44a9:2046] has joined #bitcoin-wizards | 21:47 | |
| -!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards | 21:49 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 21:53 | |
| -!- op_mul [~op_mul@178.62.133.216] has joined #bitcoin-wizards | 21:56 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 21:58 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 22:01 | |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| -!- 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:15 |
| adam3us | phantomcircuit: not sure elec based decentralisation is on a winning streak right now :| | 22:16 |
| 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:17 |
| 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:18 | |
| phantomcircuit | adam3us, heh | 22:19 |
| phantomcircuit | adam3us, there's at least a delay | 22:19 |
| 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:20 |
| 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:21 | |
| 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:22 |
| 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:23 |
| bramc | adam3us, Yes, there are goofy caveats and cheats but that's basically it. | 22:24 |
| adam3us | bramc: you have to grind harder on the spow to use a closer sorted hash value? | 22:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:35 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| phantomcircuit | ooh i remember what im missing | 22:46 |
| phantomcircuit | delays | 22:46 |
| bramc | adam3us, It does create an interesting oligopoly situation | 22:46 |
| 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:47 |
| 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:48 |
| 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:49 | |
| 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:50 |
| bramc | adam3us, That's the hope, yes | 22:51 |
| bramc | The whole thing is a bit of an experiment. Of course so is Bitcoin. | 22:52 |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:57 |
| gmaxwell | op_mul: probably can do a fair bit of profiling per die before packaging. | 22:58 |
| 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. | 22:59 |
| 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:00 | |
| 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:01 |
| gmaxwell | op_mul: you can probably do initial binning with purely electrical tests. E.g. measuring the idle load and such. | 23:02 |
| -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 23:03 | |
| -!- 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:04 |
| -!- adam3us [~Adium@12.203.200.220] has quit [Quit: Leaving.] | 23:05 | |
| -!- 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:06 |
| 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:07 |
| -!- 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:08 |
| -!- 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:09 | |
| 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:12 |
| -!- 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:13 |
| 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:15 |
| bramc | Also these proofs of work happen to be somewhat nonoutsourcable by nature, which is another good feature | 23:16 |
| phantomcircuit | gmaxwell, fun fact, making the chip testable costs 1-5% of the die area | 23:17 |
| phantomcircuit | brb un binnable chip | 23:17 |
| 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:21 | |
| -!- 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:22 |
| op_mul | bramc: is that sarcasm? | 23:23 |
| -!- 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:25 |
| 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:26 |
| 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:27 |
| -!- 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:28 | |
| 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:29 |
| 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:30 |
| -!- Netsplit over, joins: burcin | 23:31 | |
| 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:33 |
| 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:34 |
| 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:35 | |
| op_mul | the reason they get any level of traction is that they stand unattacked. | 23:36 |
| 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:37 |
| 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:38 | |
| 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:39 |
| -!- lclc_bnc is now known as lclc | 23:41 | |
| -!- d1ggy [~d1ggy@dslb-092-076-025-214.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards | 23:42 | |
| 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:43 |
| 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:44 |
| bramc | Haven't done a survey, subject too depressing. | 23:45 |
| 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:47 |
| -!- bedeho [~bedeho@195.159.234.190] has joined #bitcoin-wizards | 23:49 | |
| phantomcircuit | gmaxwell, that would require understanding | 23:56 |
| phantomcircuit | so | 23:56 |
| phantomcircuit | no | 23:56 |
| 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:57 |
| op_mul | you can't beat the one that's in obfsucated javascript though. | 23:58 |
| -!- siraj_ [~siraj@223.232.150.77] has joined #bitcoin-wizards | 23:59 | |
| --- Log closed Sat Feb 14 00:00:54 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
