2015-02-13.log

--- 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-wizards00:04
-!- lclc_bnc is now known as lclc00: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-wizards00:12
-!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards00: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-wizards00:25
-!- ielo [~ielo@host-92-24-40-10.ppp.as43234.net] has joined #bitcoin-wizards00:50
-!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards00: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-wizards01:05
* andy-logbot is logging01: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-wizards01:12
-!- lclc is now known as lclc_bnc01:16
-!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards01:26
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards01: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-wizards01: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-wizards01:55
-!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-wizards01:57
-!- lclc_bnc is now known as lclc01: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-wizards02:06
-!- bit2017 [~linker@115.79.43.208] has joined #bitcoin-wizards02:08
-!- bit2017 [~linker@115.79.43.208] has quit [Max SendQ exceeded]02:09
-!- bit2017 [~linker@115.79.43.208] has joined #bitcoin-wizards02: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-wizards02: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-wizards02: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-wizards02:31
-!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards02:31
-!- UmInAsHoE [~textual@156.18-35-82.static.virginmediabusiness.co.uk] has joined #bitcoin-wizards02:52
-!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards03:01
-!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds]03:09
-!- p15__ [~p15@111.193.161.161] has joined #bitcoin-wizards03: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_bnc03:26
-!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]03:34
-!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards03:39
-!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds]03:42
-!- lclc_bnc is now known as lclc03:43
-!- ielo [~ielo@134.219.227.35] has joined #bitcoin-wizards03:43
-!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards03:45
-!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards03: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-wizards04:02
-!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards04:15
-!- OneNomos [~OneNomos@gateway/vpn/privateinternetaccess/onenomos] has joined #bitcoin-wizards04:21
-!- realcr [~real@bzq-79-183-147-92.red.bezeqint.net] has joined #bitcoin-wizards04:23
-!- airbreather [~AirBreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards04: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-wizards04:29
-!- erasmospunk [~erasmospu@net-2-38-211-181.cust.vodafonedsl.it] has joined #bitcoin-wizards04: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-wizards04:53
-!- antgreen [~user@74.112.41.171] has joined #bitcoin-wizards05: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-wizards05:17
-!- mkarrer [~mkarrer@4.Red-83-34-47.dynamicIP.rima-tde.net] has joined #bitcoin-wizards05: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
kanzurehamburgers?05:30
-!- dc17523be3 [unknown@gateway/vpn/mullvad/x-tmhguvgjezhuclhz] has quit [Ping timeout: 250 seconds]05:31
fluffyponyreplace-by-cheese05:31
kanzurehah 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-wizards05:33
-!- lclc is now known as lclc_bnc05: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-wizards05:52
-!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards05:56
-!- lclc_bnc is now known as lclc05:58
instagibbsI 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-wizards06:07
-!- epscy_ [~epscy@176.126.241.239] has quit [Ping timeout: 245 seconds]06:26
-!- epscy_ [~epscy@176.126.241.239] has joined #bitcoin-wizards06:27
-!- linelevel [~mike@unaffiliated/linelevel] has joined #bitcoin-wizards06: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-wizards06: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-wizards06:40
-!- linelevel1 [~mike@96.237.65.66] has joined #bitcoin-wizards06:45
-!- linelevel [~mike@unaffiliated/linelevel] has quit [Ping timeout: 245 seconds]06:48
-!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards06: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-wizards07:15
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards07:17
-!- Emcy [~MC@152.27.187.81.in-addr.arpa] has joined #bitcoin-wizards07:19
-!- Emcy [~MC@152.27.187.81.in-addr.arpa] has quit [Changing host]07:19
-!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards07: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-wizards07:43
-!- afk11 [~thomas@89.100.72.184] has joined #bitcoin-wizards07:47
-!- xabbix_ [~xabbix@bzq-109-65-123-131.red.bezeqint.net] has joined #bitcoin-wizards07: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-wizards07: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-wizards07:53
-!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards08:04
-!- xabbix__ [~xabbix@bzq-79-180-107-228.red.bezeqint.net] has joined #bitcoin-wizards08: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-wizards08:11
-!- linelevel1 is now known as linelevel08:12
-!- linelevel [~mike@96.237.65.66] has quit [Changing host]08:12
-!- linelevel [~mike@unaffiliated/linelevel] has joined #bitcoin-wizards08: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-wizards08: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-wizards08: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-wizards08:25
-!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has quit [Max SendQ exceeded]08:25
-!- gonedrk [~gonedrk@d40a6497.rev.stofanet.dk] has joined #bitcoin-wizards08:27
-!- op_mul [~op_mul@178.62.78.122] has joined #bitcoin-wizards08:35
op_mulholy shit.08:35
op_mulhey 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
kanzurewhich thing are you replying to08:36
op_mulonly our ECDSA library leaks the privkey in 256 signatures.08:36
kanzuremake 'em count08:36
op_mulethereum.08:36
nshreally? :/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
nshoh my08:37
nshlink?08:37
op_mulhttps://bounty.ethdev.com/users/6fqhe7yn6XDCBr6wM\08:37
op_mulhttps://github.com/jonasnick/ecdsaPredictableNonce/blob/master/explanation/explanation.pdf08:37
nshty08:37
Apocalypticop_mul, heh08:38
nshfriday the 13th is a good day to publish such a finding :)08:38
earlzlawl08:38
earlzethereum sounds like some really cool technology that won't ever actually work in practice heh08:39
nshit's all grist for the mill. even if it never goes anywhere, whatever progress and insight and intermediary tools/results are achieved will be reusable08:40
kanzurei'm sure there are many parts of ethereum that will work, such as any gui components08:40
nshlol08:40
earlzlmfao08:40
op_mulnsh: I'm pretty sure the gist is going to be "writing 5 different core clients in 5 languages was a bad idea"08:40
earlz5 different core clients, _that maintain consensus_08:41
nshlol :)08:41
earlzDo they even have a conflict resolution mechanism when consensus breaks (like mining in bitcoin)08:41
nshdo what the other silly did and reduce to a consensus of one08:42
nshthe waffle about theory to justify it08:42
op_mulit'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
earlzI know some retarded altcoin claimed to solve the 51% attack a while back.. by just ignoring any fork the wallet isn't currently on lol08:42
fluffyponyearlz: "solved" in much the same way Darkcoin has "instant transactions"08:43
op_mulwell 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_mulfluffypony: ah yes, lets give masternodes the ability to invalidate blocks. that'll go well.08:44
earlzI review the code in altcoins, and it's scary how many PoS coins don't even have sync checkpoints enabled08:44
fluffyponyno 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
fluffyponybest frendz 4 lyf, masternode ops 201508:45
earlzthere really needs to be a tipbot in here rofl08:45
op_mulfluffypony: 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
fluffyponyop_mul: incentivise *all* of the things!08:45
earlzsiraj_: wat/no08:46
fluffyponysiraj_: Bitcoin is specifically designed to be p2p and not reach out over other protocols08:46
fluffyponyexcept for payment protocol, but we don't talk about that :-P08:46
earlzthat's no on-chain08:46
earlznot*08:46
kanzuresiraj_: wrong channel, use #bitcoin08:47
kanzureearlz: checkpoints don't do what you think they do08:47
op_mulkanzure: they do in proof of stake.08:48
earlzthey keep the coin centralized basically, but can allow for some double-spend/orphan attacks08:48
fluffypony"checkpoints" in PoS aren't the same as "checkpoints" in PoW08:48
earlzsync checkpoints* (ie, PoS oneS)08:48
op_mulfluffypony: although probably illegal and totally unethical I did like block withholding / reorg proofs as proof of work.08:48
fluffyponyso yeah, what earlz said08:48
MRL-Relay[tacotime] op_mul: ehm, kinda wondering why they just never used our lib https://github.com/btcsuite/btcd/tree/master/btcec08:48
earlzWhere there is a public key in the wallet and it listens to checkpoints broadcast from a server08:48
MRL-Relay[tacotime] wheel reinvention..08:48
fluffyponytacotime: 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_multacotime: yours isn't innovative enough. needs a flashy name. does yours leak the private key in signatures?08:49
fluffyponygood point, and if you could please use "Dark" somewhere in the name that would be great08:50
earlzthat'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.org08:51
fluffyponyouch08:51
fluffyponyat least its RNG is deterministic :-P08:52
fluffypony(in a manner of speaking)08:52
-!- dogetime [~dogetime@unaffiliated/dogetime] has joined #bitcoin-wizards08:52
op_multacotime: you jest but I've seen that mentioned on bitcointalk several times as a serious suggestion.08:52
MRL-Relay[tacotime] sigh08:52
earlzdeterministic RNG? wat08:53
op_mulwell for ECDSA deterministic nonces are what you want. just not ethereum flavoured ones.08:53
op_mulin 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
fluffyponypffft, 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
earlzJust make your own RNG real quick, but keep it closed source to make sure it's secure08:57
-!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards08:57
fluffyponyearlz: perfect08: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-wizards09: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-wizards09: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_multacotime: 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_muls/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_multacotime: 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
nicklerI 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
nicklerNonetheless 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_multacotime: point taken. I'd just see that as an indication that I shouldn't be working with EC to begin with.09:17
nicklerBy 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-wizards09:19
-!- AlienProject [~Alien_Pro@72.53.101.165] has joined #bitcoin-wizards09:20
op_mulnickler: 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 panic09:21
MRL-Relay[tacotime] well, anything greater than 32 bytes09:21
op_mulI'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
nicklerfun, 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
gmaxwellnickler: "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
gmaxwellmore 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
nicklerbut 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 sig09:33
nshwhat measures were taken to make it harder to footshoot in libsecp256k1?09:33
gmaxwellah, fair enough, you don't know which one was right, and searching would be 2^256.09:33
nshnot intuitive to me how you'd achieve09:34
nshthat09:34
gmaxwellnsh: we removed the callers ability to control the nonce unless they write a callback function and pass it in.09:34
nshah, neat09: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-wizards09:39
op_mulat 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-wizards09:43
* nsh nods09:44
nshi think you can do detDSA more simply than RFC6979 but it might be some work to derive and prove secure09:46
-!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has joined #bitcoin-wizards09: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-wizards10: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-wizards10:11
-!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards10:12
-!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards10:18
gmaxwellop_mul: because it's copying a pre-existing CSPRNG10:18
gmaxwelldoing 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
gmaxwellPartially 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_mulgmaxwell: 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 maaku10:25
GAitI'm really impressed with libsecp256k110:25
GAitdid 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 bitcoinjs10:27
GAitI think 20X with firefox and 10x on chrome10: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-wizards10: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-wizards11:01
-!- sipa [~pw@2a02:348:5e:5a29::1] has joined #bitcoin-wizards11:04
-!- lclc is now known as lclc_bnc11: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-wizards11:26
-!- tylersmith [~tylersmit@173.247.206.110] has joined #bitcoin-wizards11:27
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards11:47
-!- ielo [~ielo@host-78-147-237-163.as13285.net] has joined #bitcoin-wizards11: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
phantomcircuitgmaxwell, i hadn't noticed that it was based on an HMAC function before12: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-wizards12:20
-!- TonyClifton [~TonyClift@cpc69058-oxfd26-2-0-cust984.4-3.cable.virginm.net] has joined #bitcoin-wizards12:20
-!- dogetime [~dogetime@unaffiliated/dogetime] has left #bitcoin-wizards []12:22
gmaxwellit's based on one of the NIST HMAC DRBG functions.12:27
gmaxwellI 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
sipait does mention this:12:28
sipaRationale12:28
sipaThe 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
gmaxwellah good. this explains why I knew it was. :)12:28
gmaxwellreally 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-wizards12: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-wizards12: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-wizards12: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-wizards12:59
phantomcircuitgmaxwell, right13:11
phantomcircuiti 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-wizards13:34
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards13:49
bramcHey everybody I have questions/thoughts about replace-by-fee and the general stuff surrounding it13:50
bramcFirst, 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 blocks13: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-wizards13:53
kanzurepaperbot: http://iopscience.iop.org/1367-2630/16/12/12304913:53
paperbothttp://libgen.info/scimag/get.php?doi=10.1088%2F1367-2630%2F16%2F12%2F12304913:53
kanzurehmph13:53
phantomcircuittromp__, 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 block13:53
bramcThe other question, actually a thought/proposal has to do with the logic behind what transactions to accept/distribute13:53
kanzurepaperbot: http://iopscience.iop.org/1367-2630/16/12/123049/pdf/1367-2630_16_12_123049.pdf13:53
bramcphantomcircuit, AUGH13:54
paperbothttp://diyhpl.us/~bryan/papers2/paperbot/e2eeadf8dbaf1a207adaaac0659729e8.pdf13:54
phantomcircuitbramc, it's actually not that bad13:55
phantomcircuitbut yeah it can be kind of annoying13:55
phantomcircuitbramc, 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 miner13:56
phantomcircuitbut actually doing that is a trivial dos vector13:56
phantomcircuitso you need to store a subset of all of the valid non-confirmed transactions13:56
phantomcircuitthe easiest way to do that is to simply not store conflicted transactions13:56
kanzurewouldn't a miner be picking a subset anyway?13:56
kanzureare you saying the subset is still vulnerable to a denial of service attack?13:57
phantomcircuitkanzure, depends on whether theres > 1MB of transactions total13:57
kanzurewhat if you have strict bounds...?13:57
phantomcircuityou need to implement some sort of dos mitigation strategy13:57
phantomcircuitwhat that is is entirely implementation dependent13:57
bramcI'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 now13:57
phantomcircuitlike i have a server with 256gb of ram13:57
kanzureah i see (i thought you were saying "make a decision about which to include" is vulnerable to denial of service)13:57
phantomcircuiti can basically just ignore dos mitigation on that server13:57
-!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards13:58
phantomcircuitbramc, welllll for a miner what they actually want to do is calculate which block would result in the highest total rewards13:58
phantomcircuitrewards include fees, block reward, but also modifications for increased orphan rates based on size13:58
phantomcircuitthis calculation is non trivial and potentially proprietary black magic13:59
bramcphantomcircuit, 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 there13: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 Skipppy13:59
tromp__bramc: i was wrong and phantomcircuit is right; you can spent outputs of earlier txs in the same block14:00
bramcphantomcircuit, 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
bramctromp__, I have a sneaking suspicion that that functionality is hardly ever used14:01
phantomcircuitbramc, well lets say im a very large sophisticated miner14:01
phantomcircuiti might have a hundred nodes monitoring transaction propogation on the network to get a block propogation advantage14:02
phantomcircuitthe selection algorithm for transactions is potentially very much non trivial14:02
phantomcircuitor it can be pretty dumb14:02
phantomcircuitbramc, im sure it's been used since i've done it before14:02
bramcOh, 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 issue14:03
bramcphantomcircuit, you bastard, now that functionality must be forever supported because of your one stupid transaction in the block chain14:03
phantomcircuitthe limit is that bitcoin core wallet for a very long time refused to generate transactions with unconfirmed inputs14:03
tromp__i'm also curious to know what is the longest chain of txs in a single block14:03
phantomcircuitheh pretty sure you'd have to support it either way14:04
bramcAnyhow, 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 them14:05
bramc at such time as they decide they are willing to accept it.14:05
bramctromp__, 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-wizards14:07
bramcSome 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
phantomcircuitbramc, zeroconf doesn't work to start with14:10
phantomcircuitso that's easy enough14:10
bramcphantomcircuit, Yes that's my point. It feels like debating with a flat earther.14:10
bramcBut 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-wizards14:15
-!- belcher [~belcher-s@5ec3238c.skybroadband.com] has quit [Changing host]14:15
-!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards14:15
bramcAlso 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
bramcThe 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
bramcIt seems there's a lot of idling on this channel14:23
kanzuremany of us don't type things unless they are stoic and awesome14:23
kanzureyou should be thanking them for not spamming you with crap :)14:23
kanzurepetertodd: dawg have you rationalized absolute fee and better byte in public and in a link that you could link?14:24
bramckanzure, 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 moment14:24
kanzureah well people in here are quite vocal about identifying idiocy so you'll be informed in a timely manner14:25
kanzurein the past i would have raised concerns about relying on txid but i'm not really sure what the current eventual plan is14:26
-!- orik [~orik@75.149.169.53] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]14:26
kanzurebramc: 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 exists14:28
bramckanzure, 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
bramckanzure, 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
kanzurea lot of the current anti-dos stuff is about penalizing peers and marking them as shitrude14:29
kanzureor 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-wizards14:30
bramckanzure, My thought is that my proposed extension would allow you to throw out all the shitrude detection code14:30
kanzurealso, 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
bramckanzure, What's actually implemented appears to be a pile of miscellaneous hacky crap https://en.bitcoin.it/wiki/Transaction_fees14:32
kanzurehmm that's not what i meant by anti-dos-- there's another set of things in the p2p network14:32
kanzurefor example, https://github.com/bitcoin/bitcoin/blob/66b473457bc94adcd3d277462f9d619f5a198d96/src/net.h#L57814:33
-!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has quit [Remote host closed the connection]14:33
bramcIn 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
kanzuresorry i seem to have inflated a different anti-dos topic with another one14:33
kanzure*conflated14:33
-!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards14:34
bramckanzure, The high-level comment in that link is a good one, I don't know what the specific logic does though.14:34
bramcIn 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
bramcHere'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
bramcTransactions 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 dependent14:43
kanzurei'm not sure why you would transaction ids to factor into that14:43
bramcTransaciton ids are a tiebreak in case there are two transactions which both spend X with fee 5 and you need to decide which one wins14:44
kanzurein the past those transaction ids would have varied (because the outputs count when making txid)14:45
kanzureunless you mean the input txids14:45
-!- NewLiberty_ is now known as NewLiberty14:46
bramcNot 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 along14:47
nshtransaction IDs are malleable because change address can be grinded14:48
nshso someone could increase their chance of winning a tie14:48
nsh(s/grinded/varied/)14:49
bramcnsh, 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 peers14:49
-!- orik [~orik@75.149.169.53] has joined #bitcoin-wizards14:50
-!- Skipppy is now known as Mably14:50
nshokay14:50
petertoddkanzure: 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 circumstance14:51
petertoddkanzure: I'd rather err on the side of *not* replacing than replacing14:51
-!- AlienProject [~Alien_Pro@72.53.101.165] has quit [Quit: Leaving]14:51
petertoddkanzure: 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-dos14:52
-!- afk111 [~thomas@89.100.72.184] has quit [Ping timeout: 255 seconds]14:52
bramcIt seems that the only thing really holding the status quo together is a lack of anybody doing sophisticated transaction dos attacks14:54
petertoddbramc: 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 + nFeesToRelayReplacement14:54
petertoddbramc: 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 out14:55
petertoddbramc: main thing we don't have right now that would be nice to have is a size-limited mempool14:55
bramcThere'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/byte14:55
petertoddhuh?14:56
bramcpetertodd, Backing up a bit, I proposed adding a message saying 'don't send me transactions of less than X fee/byte' to the peer protocol14:56
petertoddbramc: oh, sure, but we already have that message, it's just implicit :)14:57
petertoddbramc: everyone has a fixed minimum fee/byte lower limit, and transactions that don't pay at least that get rejected by everyone14:57
bramcpetertodd, You mean by ignoring any such messages? My concern is that in that case the peer doesn't know that you ignored the message previously14:57
petertoddso? 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 variable14:58
bramcpetertodd, Shouldn't it be set dynamically based on the currently outstanding transactions?14:58
petertoddbramc: yes it should be, hence the size-limited mempool suggestion14:58
bramcso basically there's a real-time auction for whose transactions get in based on fee/byte14:58
bramcIf you have a size-limited mempool, how do you decide what to throw out when it gets full?14:59
petertoddexactly! 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?) attacks14:59
petertoddbramc: throw away the cheapest?14:59
bramcIt'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-wizards15:01
bramcSo 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 ether15:01
bramcAlso not sure what you mean by nReplacedFees + nFeesToRelayReplacement there's some piece of logic in there which I'm unfamiliar with15:02
-!- eudoxia [~eudoxia@r179-25-171-142.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving]15:03
petertoddsorry, one sec15:04
-!- orik [~orik@75.149.169.53] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]15:05
gmaxwellpetertodd: per byte is also a one way ratchet in the limit.15:10
gmaxwellbramc'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
bramcgmaxwell, 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
gmaxwellbramc: sure I mean in the absense of blocks.15:14
gmaxwellIt'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
bramcYes that's a good property, although it might have downsides15:16
petertoddgmaxwell: 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 attack15:17
bramcfor example if you want that property a peer can potentially do thousands of replacement transactions in order and get everyone to keep forwarding and replacing15:17
bramcpetertodd, Ah that makes sense15:17
gmaxwellpetertodd: 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
gmaxwellso we can only have one or the other.15:18
gmaxwellE.g. you can just have a "replace if the fee per byte is at least $non-negligible-higher" but thats order dependant. :(15:18
petertoddgmaxwell: yup, I'd rather have the system that's obviously free from DoS attacks - after all everything is secondary to keeping relaying of blocks reliable15:19
gmaxwelljust irritating to not have the order independance. :(15:19
bramcpetertodd, What logic do you have for replacement of transactions with multiple inputs?15:20
petertoddbramc: multiple inputs? um, why would that matter? multiple outputs is interesting, if they're already spent15:21
bramcor by things with multiple inputs? It seems very different to have order independence there for different reasons15:21
bramcpetertodd, 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 Y15:21
petertoddbramc: 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-wizards15:22
petertoddbramc: I'm sure you can construct cases where this leads to non-convergence :)15:22
bramcpetertodd, I meant in terms of deciding which one takes priority, do you look at the fee/byte across everything being replaced?15:22
bramcAnd 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
petertoddoh, 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 attacks15:23
petertoddthat code is very fast as we cache nFees and nSize, so it's just walking memory via pointers15:23
-!- maraoz [~maraoz@43-161-16-190.fibertel.com.ar] has quit [Quit: Leaving]15:24
petertoddyeah, 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-wizards15:25
-!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]15:26
bramcpetertodd, So what was that about the increasing epsilons again? Something about nFeesToRelayReplacement15:28
-!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards15:29
petertoddbramc: 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 transactions15:30
gmaxwellnickler: 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 Guest9913515:30
petertoddbramc: (hmm... I should double-check all three conditions are actually possible... :P)15:32
bramcpetertodd, What's min-fees-per-kb set to?15:32
petertoddbramc: 0.1uBTC/KB15:32
sipawhatever is the relay fee is configured to, i suppose?15:32
petertodd^15:32
bramcpetertodd, My back of the envelope calculation says that that amounts to 2 cents/block at max size15:35
-!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 245 seconds]15:36
petertoddbramc: wait, no that's wrong, it's 10uBTC/KB15:36
petertoddbramc: $2.5/block, which is absurd15:37
-!- NewLiberty [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has quit [Read error: Connection reset by peer]15:38
bramcpetertodd, 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
petertoddbramc: but fees are a market, so modulo shitty wallets that don't let you set them that attack will fail15:39
phantomcircuitgmaxwell, ?15:39
sipawell relay fee is different from mining fee15:39
petertoddbramc: the real worry is using up bandwidth and especially memory15:39
siparelay fee gets your transaction across the network; i doubt it will be enough for getting it into a block much longer15:40
-!- cluckj [~cluckj@c-71-225-211-210.hsd1.nj.comcast.net] has joined #bitcoin-wizards15:40
petertoddsipa: which is potentially bad, because you shouldn't be relaying stuff that isn't going to get mined reasonably soon15:40
sipapetertodd: agree15:41
bramcpetertodd, The problem being that wallets don't currently increase their fees when their transactions aren't going through15:41
-!- NewLiberty [~NewLibert@2602:304:cff8:1580:4947:3f5f:560b:63ea] has joined #bitcoin-wizards15:41
petertoddbramc: for awhile bitcoin wallet for android made it impossible to set fees; right now you only have a x10 option that's fixed15:42
petertoddbramc: replace-by-fee will help that as it'll be easy to bump tx fees15:42
bramcs/easy/possible/15:42
bramcMy concern about rebroadcasting a transaction isn't much of an issue if the wallet can be responsible for rebroadcasting15:43
petertoddbramc: yeah, anyway, lots of work needs to be done on wallets for sure15:45
petertoddbramc: 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 sound15: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-wizards15:47
-!- shesek [~shesek@87.68.49.90.cable.012.net.il] has quit [Ping timeout: 256 seconds]15:48
bramcpetertodd, How does it make things a little bit worse in the short term? I totally agree with the basic principles.15:48
petertoddbramc: 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 part15:48
petertoddbramc: 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 cost15:49
bramcpetertodd, 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
petertoddbramc: !@#$ 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
kanzurethey might honor that kind of invoice, you'll never know unless you try15:52
petertoddkanzure: I did, they said only the hookers were legal, not the coke.15:53
petertoddkanzure: meanwhile greenaddress tried to give me medical pot instead, and demanded to see my card... sheesh15:53
-!- nuke1989 [~nuke@178-241-15.dynamic.cyta.gr] has quit [Ping timeout: 256 seconds]15:54
kanzureterrible15:54
bramcYou guys should go on tour with me, I have more groupies than I know what to do with.15:54
kanzurewouldn't that just increase your groupie count?15:54
petertoddbramc: male or female groupies? (or both?)15:55
nshbut we could increase his ideas-of-things-to-do-with-groupies count15:55
nshfor example, human pyramids15:55
bramcReal rock stars have groupies who are 19 year old girls. Programming rock stars have groupies who are 13 year old boys.15:55
petertoddnsh: that's not how Metcalfe's law works...15:55
petertoddbramc: lol15:55
nshlol15:56
nshdamn15:56
-!- ielo [~ielo@host-78-147-237-163.as13285.net] has quit [Ping timeout: 252 seconds]15:56
petertoddbramc: https://twitter.com/petertoddbtc/status/56638569227658444915:57
-!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]15:57
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]15:58
nsh.t15:58
yoleauxFri, 13 Feb 2015 23:58:35 UTC15:58
nshah :)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-wizards15:58
bramcI'm coming up with some more somewhat annoying dos attacks. It's a bit of a cat and mouse game15:59
petertoddheh16:00
bramcBut 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 blocks16:01
justanotheruserI don't understand. Is that a pedophile joke or do programmers have 13 year old fans?16:02
bramcjustanotheruser, 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-wizards16:03
justanotheruserthats strange16:03
bramcjustanotheruser, It's because of what I'm known for writing16:04
justanotherusersome game?16:04
bramcsome p2p thing16:05
petertoddjustanotheruser: really, we have groupies that act like 13 year old boys on 4chan...16:05
justanotherusero_O16:06
bramcBy 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
justanotheruserafter whoising you "some p2p thing" is hilarious16:06
petertoddbramc: what are you working on??? :P16:08
-!- aburan [~ubuntu@static-108-45-93-93.washdc.fios.verizon.net] has joined #bitcoin-wizards16:08
bramcpetertodd, an altcoin whose mining doesn't involve burning electricity16:08
kanzurestill?16:08
justanotheruserthats disappointing16:08
kanzurewhat were your objections to the previous arguments we brought to you about that, bramc?16:08
petertoddbramc: ah, the proof of capacity thing?16:08
bramckanzure, 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 though16:09
bramcpetertodd, It's a somewhat involved combination of proofs of storage and proofs of time16:10
petertoddbramc: 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
justanotheruserbramc: the scarce resource that is being burned is just the electricity used to make that hardware then isn't it?16:11
bramcpetertodd, 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 subtle16:12
petertoddjustanotheruser: +116:12
justanotherusers/electricity/energy16:12
kanzureyou'll often be replacing most of your parallel processes with work based on the network16:12
bramcjustanotheruser, no because it's really depreciation on storage which was already made for other reasons, of which there's mass quantities in the world16:12
petertoddbramc: 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
kanzureman i hate how you treat us as forgetful morons16:14
bramcpetertodd, 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 own16:15
-!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards16:15
bramckanzure, not exactly sure what you mean there but I've added some important details since then16:15
bramccapable of breaking and fixing on my own I mean16:16
bramcHey adam3us16:16
adam3ushey16:16
-!- shesek [~shesek@87.68.49.90.cable.012.net.il] has quit [Ping timeout: 250 seconds]16:16
bramcadam3us, You just missed me half-starting a flame war again16:17
kanzurecould you instead make direct statements instead of dangling hooks16:17
adam3usbramc: another day another flame war.16:17
justanotheruserbramc: 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
kanzurei'm sure there's many optimizations you can make over a conventional ssd, for example16:18
kanzurebut that's also irrelevant i think16:18
bramckanzure, 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 once16:18
kanzureugh16:19
bramcjustanotheruser, 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 mining16:20
petertoddbramc: fwiw I might be in the bay area again beginning of march, though like last time my schedule may be fucked16:20
kanzureimposing physical constraints on people's time and attention is annoying16:20
kanzureif i had to physically visit every one of you to relay my messages i'd never get anything done16:20
-!- Guest99135 is now known as maaku16:21
bramckanzure, 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
bramcSo 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
ajweissdo i get coins for throwing bandwidth at p2p livestreaming?16:22
kanzurethen why would you even advertise anything. blah.16:22
justanotheruserbramc: Whatever computation you're doing that involves storing lots of information can probably be optomized using special hardware.16:23
justanotheruserAt the very least, I could buy a ton of RAM and use that16:23
kanzurehis complaint was about energy utilization, not resource utilization16:24
petertoddjustanotheruser: one of these days we'll give up on all these crazy ASICs and just use the signing chips in stolen passports as PoW16:24
bramcajweiss, 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 electricity16:24
justanotheruserpetertodd: isn't that a hearnism?16:24
justanotheruserkanzure: who is that directed at?16:24
kanzurejustanotheruser: i was informing you about bramc's complaints16:25
petertoddjustanotheruser: not quite - I'm suggesting using the (slow!) speed they sign as a PoW (semi-seriously)16:25
bramcjustanotheruser, 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 matter16:25
justanotheruserkanzure: I'm pointing out the possible optomizations.16:25
justanotheruserbramc: what does "RAM is very small compared to disk" mean?16:26
petertoddjustanotheruser: 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 repeatedly16:26
kanzure23: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
bramcThe storage proof is basically finding a closest match very fast, which peers do by having a whole lot of things sorted on their hard drives16:26
kanzure23:36 < gmaxwell> Well the point of the infinite is to say that this process (at least when storage is sufficiently large) reduces to plain16:26
bramcjustanotheruser, For these proofs of work RAM won't do them any better than the same amount of disk will16:26
kanzureaaaa16:26
kanzure23: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
bramckanzure, 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 canonical16: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 spow16:28
bramcYeah 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 time16:28
kanzurethen what's the point of that function?16:29
kanzureit must have a different output given a different input16:29
-!- freewil [~freewil@unaffiliated/freewil] has joined #bitcoin-wizards16:30
bramcIt'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 longer16:30
bramcI'm using a different and dumber spow than the one in that paper, because it isn't sufficiently canonical16:31
-!- shesek [~shesek@87.68.49.90.cable.012.net.il] has joined #bitcoin-wizards16:31
-!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 246 seconds]16:33
kanzuretaking 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 think16:33
-!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards16:35
kanzure(which gets you parallelism again (and reduction back to proof of work))16:35
bramcI'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 nothing16:35
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]16:36
bramcYou 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 behind16:37
bramcThere'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 threshold16:38
bramcThat 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
bramcI 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
bramcHopefully the stuff I'm describing doesn't sound like gibberish. It's hard to discuss these things without falling into custom jargon16:44
-!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards16:44
-!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]16:45
bramcI'm also happy to keep answering questions, although this rathole continues for a while.16:48
ryan-cethereum screwed up deterministic nonces?16:50
gmaxwellryan-c: sure, why do you ask?16:51
andytoshiryan-c: https://github.com/obscuren/secp256k1-go/blob/master/secp256.go#L126-L16116:51
ryan-cgmaxwell: was just reading the scrollback16:51
andytoshiline 130 in particular16:51
ryan-coh fuck16:51
ryan-cwhat the hell16:51
andytoshi:P it's actually stronger than it looks..16:52
gmaxwellethereum'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-candytoshi: I know that  'nonce = msg + seckey' leaks the private key16:52
gmaxwellAnticipation 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
andytoshiryan-c: yeah, this doesn't fall prey to that directly because xor plays hell with the field operations16:53
andytoshiryan-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 work16:54
* bramc has an aneurysm16:54
ryan-cI managed a working attack for 'nonce = msg + seckey' a few months ago, though I haven't seen anyone actually do that.16:54
bramcThe 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
gmaxwellryan-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-wizards16:56
ryan-cgmaxwell: Makes sense.16:57
maakuryan-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 continue16:57
ryan-cmaaku: Can I throw money at you to get it done sooner?16:58
-!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards16:58
sipai'm increasingly unconvinced that UTXO commitments are the right solution16:58
sipathough part of the work - the commitment structure as such - is very valuable for many things16:58
bramcWhat is this utxo commitment thing?16:59
sipabramc: have blocks commit to a merkleized tree set structure of the UTXO set16:59
ryan-csipa: My particular interest is using it to enable Namecoin light clients.16:59
ryan-cbramc: UTXO = unspent transaction outputs16:59
sipabramc: 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 point17:00
bramcsipa, 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 yet17:00
sipait also adds huge extra costs for validation nodes17:00
bramcYeah those turn out to be bigger than expected17:01
justanotherusercan a UTXO proof be constructed cheaply?17:01
ryan-c(though we need a second utxo structure for authenticated denial)17:01
ryan-cwell, not utxo17:01
bramcjustanotheruser, 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 front17:01
-!- adam3us [~Adium@12.203.200.220] has quit [Ping timeout: 265 seconds]17:03
bramcAfter 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/clfp3xj17:03
justanotheruserI mean is comparing each UTXO in your current copy and the merkle tree the fastest way to do it?17:03
bramcjustanotheruser, It's updating the merkle tree which gets expensive17:04
-!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards17:04
bramcBecause it's too big to fit in memory, and requires a whole bunch of seeks to update on disk17:04
bramcTo 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 timelock17:05
justanotheruseracceptance language?17:05
ryan-cjustanotheruser: i think he means bitcoin script17:06
bramcjustanotheruser, p2sh17:06
justanotheruserwhat about p2sh?17:06
justanotheruseryou mean Script?17:06
bramcjustanotheruser, Yeah the script, it's overly complicated with no clear benefit. All the proposed extensions are op_verify anyway17:07
justanotheruserWhile Bitcoin is young, it is nice to be able to create new scripts without having to softfork17:08
bramcThere'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 pass17:08
ryan-cI've had things I wanted to do that would require OP_CAT17:09
ryan-cthey may have been bad ideas17:09
-!- adam3us [~Adium@12.203.200.220] has quit [Client Quit]17:09
justanotheruserand OP_XOR would be nice17:09
bramcryan-c, and op_cat is one of those things which Isn't Going To Happen17:09
ryan-cbramc: I know.17:09
justanotheruserwhy not?17:09
bramcjustanotheruser, op_cat allows dos by making extremely large strings.17:10
justanotheruserand if the strings can't be made extremely large?17:10
bramcjustanotheruser, In all seriousness if you know of an explanation for a smart transaction which would require xor I'd love to see a link17:10
-!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]17:11
ryan-coh, now i remember what i wanted to do17:11
-!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards17:11
bramcjustanotheruser, there's no agreement on what the max length should be17:11
ryan-chave a script that could be redeemed either by a normal key or by multisig17:11
bramcryan-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
justanotheruserbramc: http://arxiv.org/abs/1402.369817:12
bramcjustanotheruser, that can be done using length specifications of hash preimages17:13
ryan-cbramc: it isn't - is multisig with 1+N keys that requires either the 1 or M of N possible?17:13
justanotheruserbramc: that's a hack17:14
bramcryan-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 utxo17:15
justanotheruserafaics, it doesn't work for >2 people and the transactions become larger as your odds become smaller17:15
bramcjustanotheruser, 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-cbramc: I might not be remembering correctly.17:15
bramcjustanotheruser, 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
justanotheruserwhat does chaining together multiple transactinos accomplish?17:17
bramcjustanotheruser, 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 sizes17:18
ryan-cbramc: can the numbers between one and ten be guessed separately?17:19
bramcryan-c, Yeah that's the idea they're based on different preimages, but the right answers have to be committed to in advance17:20
justanotheruserthats 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
bramcjustanotheruser, It also isn't a very important use case :-P17:20
ryan-coh, you're talking about stuff in the paper that i didn't read17:21
justanotheruserIt demonstrates that some opcodes have uses we may not know of yet though17:21
bramcjustanotheruser, that sort of functionality could also be crammed into a new op_verify17:21
bramcryan-c https://eprint.iacr.org/2013/784.pdf17:22
ryan-cbramc: don't have time to read it right now, thanks though17:22
justanotheruseryes, 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 discovered17:22
bramcryan-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 transfers17:23
bramcjustanotheruser, 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 changed17:24
justanotheruseryeah, satoshi did know how useless a lot of the opcodes would be though17:24
ryan-cthat reminds me of a CTF challenge I solved that required you to do a hash length extension attack against truncated hash17:24
justanotheruserif bitcoin had to be remade today it probably would be very different17:25
ryan-c(it was in the context of a "provably fair" casino)17:25
ryan-csomeone should make an altcoin with Script based on INTERCAL17:25
bramcjustanotheruser, 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
justanotherusernah, it should be lisp based17:27
bramcI 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
justanotherusermining isn't really wasteful since people are getting a valuable service and paying for it17:28
ryan-cbramc: were you saying you had some inherently serial thing that couldn't be hardware accelerated effectively?17:28
bramckanzure, No you've seen how convinced people are that my claimed solution works17:28
kanzurehuh?17:29
ryan-ci didn't read the scrollback very throughly17:29
bramckanzure, sarcasm, meaning they clearly aren't17:29
kanzurewhy would i care what they think?17:29
kanzurei forget what your objection was to the thermodynamic arguments for proof of work17:30
bramcryan-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 stalemate17:30
kanzurei remember something like you refusing to address an argument17:30
bramckanzure, The idea is that there's far more depreciation of storage out there than mining rewards17:31
ryan-cbramc: the stalemate thing sounds like how mining is already17:31
kanzurebramc: mgo on17:31
kanzure-m17:31
bramcNo 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 subtle17:31
bramcryan-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 waits17:32
kanzurethat was not the argument i was talking about17:32
kanzurei 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
kanzure17:30 < kanzure> i forget what your objection was to the thermodynamic arguments for proof of work17:33
kanzurethis was an accurate on-topic reply that could have gone somewhere:17:33
kanzure17:31 < bramc> kanzure, The idea is that there's far more depreciation of storage out there than mining rewards17:33
bramckanzure, Oh it's because there's nothing in the main part of mining which requires much of any CPU17:33
bramckanzure, hold on, two very different points here17:34
kanzurein your system?17:34
bramcThe 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 it17:36
kanzurewhy is it important they lose money on it?17:36
adam3usbramc: is this another attempt to repair proof of stake?17:36
kanzureadam3us: no17:37
adam3usbramc: ok then is it a variant of memory hard, like tromp's cuckoo cycle pow?17:37
bramcadam3us, No! No proofs of stake! This is all about shifting around the form of the proofs of, uh, 'work'17:37
kanzureadam3us: around 23:04 http://gnusha.org/bitcoin-wizards/2015-01-01.log17:37
kanzureor uh earlier17:37
-!- richardkiss [~richardki@108-94-29-170.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards17:37
bramcadam3us, no the proof of work is nothing like cuckoo. It's actually much simpler17:38
kanzurehttp://diyhpl.us/~bryan/papers2/bitcoin/Publicly%20verifiable%20proofs%20of%20sequential%20work.pdf17:38
bramckanzure, 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 checked17:39
kanzureyes you already mentioned that today17:39
adam3ussequential? ah yes, i have applications for those.17:39
adam3uswell more time-lock decryption which is related17:39
bramcadam3us, 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 match17:40
bramcThen 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
bramcadam3us, 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
adam3usbramc: 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
bramcadam3us, no I'll have to read through that17:43
bramcadam3us, 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 block17:44
adam3usbramc: yeah ic.  micromint is only slightly related probably. they gain advantage overtime by storing large amounts of k-way collision candidates17:45
bramcadam3us, My thing is most closely related to amiller's nonoutsourcability17:47
bramcAs a result it happens to be very resistant to outsourcing17:47
kanzure22: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 costs17:47
kanzure22: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) etc17:47
kanzure22:35 < adam3us> bramc: i dont think my arguments change.  its economic fundamental of commodity pricing.17:47
kanzurehaven't we been through this time loop before17:47
bramckanzure, Sort of, I didn't do the greatest job explaining my argument before17:48
kanzureyes i'm trying to do you justice by finding the exact argument that was given to you17:48
phantomcircuitkanzure, to achieve the sunk costs model you need the efficiency of the hardware to change significantly as the amount of work being done drops17:49
phantomcircuitthat's mostly only true of existing hardware in theory now17:49
bramckanzure, 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 side17:50
kanzureactually 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, etc17:51
kanzure(something involving a complaint about waste..?)17:52
bramckanzure, I'm still using mining rewards which are doled out proportianately to resources put in!17:52
bramcIt's just that the resources are depreciating storage rather than electricity, on the grounds that that can be done with no increase in marginal spend17: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
kanzurei don't know why you are bringing up proportionality to resource input(?)17:53
kanzure-( -)17:54
bramckanzure, at points I'm honestly not sure what you're trying to say17:54
kanzureyeah 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
kanzuresorry17:55
phantomcircuitpow is wasteful17:56
phantomcircuitbut the alternatives dont work17:56
kanzurethat's easy when you don't offer a definition17:56
phantomcircuitit's the only option17:56
phantomcircuitit is thus by definition not wasteful as there is no other option17:56
bramcThere'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 an17:57
bramcyway, and if the value of those resources is greater than X then no *additional* waste will happen to do mining17:57
adam3usi 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
kanzuredo you see why or how "bitcoins aren't produced from work"?17:57
bramcIn this case, the resources already wasted is that there's hard drive capacity sitting out there doing nothing.17:57
bramckanzure, I don't see what the point of that semantic distinction is17:58
adam3usbramc: the security comes from the cost of the forgone alternative; a fully reusable or sunk cost may provide no security17:59
trompwhat's the electricity cost of filling 100TB of hard disk space with sorted hashes?17:59
bramcadam3us, Oh it isn't reusable exactly because the work is storage space times time, and you can't manufacture extra time17:59
kanzuretromp: arguably that doesn't matter18:00
bramctromp, small18:00
ryan-ctromp: Funny you should ask, I have about 40TB of drives filled with sorted hashes.18:00
bramcryan-c, if I may ask a stupid question, why?18:00
kanzurerainbow tables, i'd guess18:01
ryan-cbramc: 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
bramctromp, 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 comparison18:01
adam3usbramc: 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-cbramc, tromp yeah, much pain in the ass. I used a merge sort that does delta compression on each pass.18:02
ryan-chard disks are cheap to run18:02
ryan-c5-10W18:03
bramcadam3us, 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 again18:03
trompevery new computer comes with a hard disk that takes years to fill up. might as well use that space until actually needed18:03
ryan-cmaybe a dollar or two per month to run a low power drive18:03
bramctromp, yes exactly18: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 boring18:04
kanzurethat has nothing to do with whether or not it achieves consensus18:04
kanzurenobody cares if it's a hard drive or a rhinocerus, as long as it works18:04
bramckanzure, the consensus part is straightforward: the best match wins18:04
bramcOver time you have a series of completed blocks, consisting of match/proof of time/match/proof of time18:05
kanzurei 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 argumet18:05
kanzureargument18:05
ryan-cI have a server at my apartment with 12 disks in it, and I keep them spun down as much as possible.18:05
bramcSo someone else can't catch up, because they have less storage space than the system as a whole, and no more time18:06
kanzurebramc: i'm only harsh because i love you18:06
kanzurejust fyi18:06
bramckanzure, I'm trying to make a coherent but subtle technical argument here and it seems like I'm not being very clear18:06
kanzureyes something about parallel time not existing18:07
bramcLet's say that the current work factor is 10^4018:08
bramcThe 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
bramcFor each block, the networks proof of storage will on average be worth ten times as much as yours18:09
adam3usbramc: 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
bramckanzure, hold on for a sec on the spow farm, I can only type so fast18:10
kanzurehttp://www.seanwrona.com/typeracer/profile.php?username=kanzure18:11
bramcSo 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 behind18:12
adam3usbramc: i think you'd want to estimate the number of disks that would be supported by the reward18:12
bramcadam3us, hold on I can only type so fast18:12
adam3usbramc: probably it exhausts production capacity.  faster man :)18:13
kanzureif you are interested i know of some drugs that increase typing speed18:13
kanzureadam3us: i'm not sure reward support is very important?18:13
bramckanzure, 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 matter18:14
adam3uskanzure: reward is subsidising security.  we hope even in the long run that fees pay enough to provide adequate security.18:14
kanzureadam3us: 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 before18:15
adam3usbramc: i guess this spow execution time s chosen to be >> a block interval18:15
bramcSo 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 generation18:16
bramcadam3us, the spow execution time *is* the block interval18:16
kanzuredo you mean equal to, or some other semantic intent18:16
adam3usbramc: just wondering about time security18:17
bramcI mean a block isn't complete until it has the corresponding spow, and once it does have the spow the next block can be found18:17
-!- d1ggy [~d1ggy@dslb-092-076-025-214.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards18:17
bramckanzure, 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
adam3usbramc: 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 first18:18
bramcadam3us, Oh no, the spow is dependent on an input, so you can't precompute them18:18
adam3usbramc: so who computes the spow and does it matter who completes it first?18:19
bramcadam3us, 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 destruction18:19
bramc(I did say that this thing is a bit of a contraption)18:20
-!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards18:20
-!- d1ggy_ [~d1ggy@dslc-082-082-145-182.pools.arcor-ip.net] has quit [Ping timeout: 255 seconds]18:20
bramcIt 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 tie18:21
adam3usbramc: 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
bramcadam3us, 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 here18:22
adam3usbramc: bearing in mind that it is the pow that enforces non-history-rewriting as there is a forgone alternative18:23
adam3usbramc: ok so thats paramterised such that its not worth it18:23
bramcadam3us, 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 anyway18:24
adam3usbramc: 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
bramcAlthough of course I'll have to do some actual measurements on that18:25
adam3usbramc: 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
bramcadam3us, It's important that the amount of time it takes for the beacon to broadcast is dependent on how good the previous match was18:26
bramcadam3us, 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
bramcThat aspect of the whole thing is unchanged.18:27
bramcThis is, in fact, mining.18:33
bramcGiven 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-wizards18: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
kanzuremy telepathic link to adam3us seems to be working so i will continue to lazily rely on him to word my complaints18:38
adam3usi think u need to define what it is that prevents indefinite long range historic reorgs from future growth in computational capacity18:41
bramcI'm afk for a few. Feeding the pet hairless apes.18:41
bramcadam3us, It's storage space times time18:42
bramcThe 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-wizards18: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-wizards18: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-wizards19: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-wizards19: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-wizards19:21
-!- Starsoccer [~starsocce@unaffiliated/starsoccer] has joined #bitcoin-wizards19:31
-!- Dr-G [~Dr-G@gtng-d9ba104d.pool.mediaways.net] has joined #bitcoin-wizards19: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-wizards19:32
-!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards19:37
bramcOkay, the apes have been fed and are happy19:37
-!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Ping timeout: 256 seconds]19:37
kanzurenot convinced about your dimensional analysis (particularly the one about time)19:38
bramcIt isn't that different from Bitcoin, which is based on number of CPUs times time19:38
kanzurethat doesn't make sense19:39
kanzurei don't think that's a valid reduction?19:40
bramcSure it is. The number of hashes you'll have is the integral of the hashing capacity over time19:40
bramcThere'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-wizards20: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-wizards20: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-wizards20: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-wizards20: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-wizards20:35
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds]20:43
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards20: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-wizards20:58
-!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]21:04
-!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards21: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-wizards21:47
-!- adam3us [~Adium@12.203.200.220] has joined #bitcoin-wizards21:49
-!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards21:53
-!- op_mul [~op_mul@178.62.133.216] has joined #bitcoin-wizards21: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-wizards22:01
op_mulbramc: 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_multhere'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
bramcop_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 around22:03
bramcAlthough, 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
adam3usbramc: 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
adam3usbramc: 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 past22:06
op_multhat 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
justanotheruserWhat is a proof of time?22:07
op_multhe 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
bramcadam3us, 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 behind22:07
bramcadam3us, reward times are noisy but in *exactly* the same way as Bitcoin rewards are noisy22:08
op_muljustanotheruser: no idea man. this is what I'm reading. https://botbot.me/freenode/bitcoin-wizards/2015-02-14/?msg=31971068&page=222:08
adam3usbramc: 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
phantomcircuitadam3us, 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 block22:09
sipahttp://bitcoin.sipa.be/powdays-50k.png22:09
bramcIt'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 much22:09
adam3usbramc: 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 free22:09
phantomcircuitat first glance it has all the same economic incentives as true pow mining except is missing things like capital expenditure22:10
sipahttp://bitcoin.sipa.be/powdays-ever.png22:10
op_mulphantomcircuit: 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
bramcProofs 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
adam3usbramc: 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 bandwidth22:11
phantomcircuitop_mul, thus the delay22:11
phantomcircuitit gives a very strong incentive not to generate an orphaned block22:12
adam3usphantomcircuit: maybe you can make a synthetic miner that imitates capital ownership22:12
bramcadam3us, 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_mulphantomcircuit: 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 :P22:13
phantomcircuitha22:13
adam3usbramc: 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 grinding22:13
phantomcircuitadam3us, if you try you end up with s weird PoS looking PoB system22:13
bramcop_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
phantomcircuitie you need to burn 10x to mine 1 but that only consumes having burned 1 so it's 1:1 but with 10x risk22:14
op_mulbramc: 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
bramcadam3us, 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
phantomcircuitadam3us, this of course does lose a few of the inherent decentralization effects of electricity based mining22:15
bramcop_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 honest22:15
adam3usbramc: 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 winning22:15
adam3usphantomcircuit: not sure elec based decentralisation is on a winning streak right now :|22:16
op_mulbramc: 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
bramcadam3us, 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
bramcop_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-wizards22:18
phantomcircuitadam3us, heh22:19
phantomcircuitadam3us, there's at least a delay22:19
adam3usphantomcircuit: 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 etc22:20
op_muladam3us: no no, do it like Spore22:20
adam3usphantomcircuit: use the saved electricity (being paid to the server) for some socially redeeming purpose22:20
phantomcircuitheh22:20
bramc*sigh*22:20
phantomcircuitsomething deliciously ironic about you suggesting to replace hash based pow with something else22:21
phantomcircuit:P22:21
adam3usbramc: 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-wizards22:21
adam3usbramc: 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
bramcadam3us, 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 behind22:22
adam3usbramc: ok maybe i am missing the effect of the time-lock22:22
adam3usbramc: 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
bramcThere'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 storage22:23
bramcadam3us, Yes, there are goofy caveats and cheats but that's basically it.22:24
adam3usbramc: you have to grind harder on the spow to use a closer sorted hash value?22:25
bramcadam3us, 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 good22:26
bramcTheir distribution is in fact exactly the same as the distribution of how long it takes to mint a block in bitcoin22:26
bramc(well, asymptotically so close that you can't tell the difference anyway)22:26
bramcYou 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-wizards22:28
adam3usbramc: 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 catchup22:28
bramcYou 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
adam3usbramc: 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 weak22:29
adam3usbramc: well in bitcoin with < 50% of hashrate you basically cant catchup and you lose money fast with < 50% doing that from the forgone reward22:30
adam3usbramc: 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 lucky22:31
bramcadam3us, 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
bramcThe 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 small22:35
bramcYou 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
adam3usbramc: i suppose you would repeatedly gind the disk in the background to also make the hashes closer to equidistant to improve your odds a little22:37
bramcand, 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 scratch22:37
adam3usbramc: right that maybe by itself mostly kills history rewriting, though perhaps someone can make an asic and liquid nitrogen cool it22:39
bramcadam3us, 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
adam3usbramc: the usual time-memory tradeofss (TMTO) yeah.  they can bite you though… momentum pow was weakened by that, scrypt also has TMTOs22:40
bramcadam3us, 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 stalemate22:40
adam3usbramc: anyway everyone can run that algo so its not a trap door advantage22:40
bramcAnyone 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
adam3usbramc: also i suppose there is nothing stopping you trying hundreds of spow alternate histories in parallel so luck can be searched for more widely22:41
bramcadam3us, Yes you can do that but like I said the chances of any of them catching up are so low that it hardly matters22:42
adam3usbramc: the more convincing argument on that is if big miners have their own liquid nitrogen asic spow chip and are fighting with the history rewriters22:43
op_muladam3us: 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
bramcadam3us, 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 can22:44
adam3usbramc: but maybe they will keep it secret if there is selfish time advantage to doing that22:45
bramcSo 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
phantomcircuitadam3us, huh22:45
phantomcircuiti think the PoB mining might actually be incentives compatible22:45
phantomcircuitooh i remember what im missing22:46
phantomcircuitdelays22:46
bramcadam3us, It does create an interesting oligopoly situation22:46
bramcI'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 network22:47
op_mulefficient? don't you just want raw speed?22:48
bramcphantomcircuit, Proof of Boron?22:48
bramcop_mul, no the costs are mostly determined by electricity usage22:48
op_mulif you let me throw efficiency out the window and a big enough tank of LN2, we're going to the moon.22:48
op_mulhm.22:48
bramcI mean for Bitcoin mining, not for proofs of time22:48
op_mulah22:48
bramcobviously 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-wizards22:49
adam3usbramc: 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 possible22:50
-!- koshii [~0@node-gvc.pool-180-180.dynamic.totbb.net] has quit [Ping timeout: 250 seconds]22:50
adam3usbramc: but anyway presumably competitors would move forward in parallel of having fast spow chips22:50
bramcadam3us, That's the hope, yes22:51
bramcThe whole thing is a bit of an experiment. Of course so is Bitcoin.22:52
op_mulsort 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
bramcop_mul, I feel a lot better about subsidizing the development of chips with faster clock rates than ASICs which pile on more sha1 calculations22:54
gmaxwellin 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
bramcgmaxwell, Sounds plausible, I wouldn't know, I'm not a hardware person22:57
op_mulgmaxwell: and some deep pity for whoever has to sit there with a ZIF socket and trays and trays of chips to bin22:57
gmaxwellop_mul: probably can do a fair bit of profiling per die before packaging.22:58
bramcgmaxwell, 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_mulgmaxwell: 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_mulgmaxwell: (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-wizards23:00
gmaxwellbramc: 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
gmaxwellop_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-wizards23:03
-!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards23:04
bramcThere'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 shadow23:04
bramcthe 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_mulwait, 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_mulie, they'd never catch up with the 1:1 verification of the linear hashing23:06
bramcNo it syncs the same way nodes in bitcoin sync, it downloads and verifies the chain with the largest work factor it can find23:07
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 252 seconds]23:07
op_mulbut verifying would be symmetrical23:07
-!- dansmith_ [~dansmith@static-ip-188-138-127-218.inaddr.ip-pool.com] has quit [Ping timeout: 246 seconds]23:08
bramcoh, 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 sequentially23:08
-!- dansmith_btc [~dansmith@static-ip-188-138-127-218.inaddr.ip-pool.com] has joined #bitcoin-wizards23:09
bramcThere's also a message to say 'that proof of time you just sent me is busted, recheck position X'23:09
op_mulyou can do verification in parallel too I suppose.23:09
bramcthis is that 'gimmicky cheat' I was talking about23:09
-!- adam3us [~Adium@172.56.32.216] has joined #bitcoin-wizards23:09
bramcIt makes designing the protocol and database logic even weirder than it is in Bitcoin23:12
bramcHaving data which can get invalidated and revalidated in multiple ways is bizarre23:12
-!- adam3us [~Adium@172.56.32.216] has quit [Client Quit]23:13
op_mulanything 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
bramcYes 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
bramcAlso these proofs of work happen to be somewhat nonoutsourcable by nature, which is another good feature23:16
phantomcircuitgmaxwell, fun fact, making the chip testable costs 1-5% of the die area23:17
phantomcircuitbrb un binnable chip23:17
bramcBut 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 running23:21
-!- Anduck_ [~anduck@anduck.net] has joined #bitcoin-wizards23:21
-!- Anduck_ is now known as Guest409723:22
bramcAs in, I want to know how much transactions are really worth.23:22
bramcOf course transactions could all clear instantly if only people weren't spreading FUD about how insecure zeroconf is :-)23:22
op_mulbramc: is that sarcasm?23:23
-!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 256 seconds]23:25
bramcop_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_mulah yes I'm aware of that post.23:26
op_mulI'm fond of greenaddress.it's solution to it really. works well within the constraints.23:26
bramcI can't tell if the poster is a troll or mental23:26
op_multhird option, working with an agenda23:26
bramcYes 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
bramcAlthough 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
bramcWow a netsplit, it feels so 90s23:29
op_mulno, feels like freenode.23:29
bramcAlmost like we're on freenode23:29
phantomcircuitbramc, they can still do that for the most part23:30
op_mulI 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: burcin23:31
bramcMy 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_mulsadly that's a pretty common misconnection.23:34
bramcIt seems even people who believe in bitcoin as a religion have only the vaguest understanding of what it actually does.23:34
bramcLike, 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-wizards23:35
-!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards23:35
-!- brad__ [~brad@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards23:35
op_multhe reason they get any level of traction is that they stand unattacked.23:36
bramcWho/what is the 'they' you're talking about here?23:37
op_multhere'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
bramcAnd Bernie Madoff's fund was worth billions23:37
op_multhey == consensusless altcoins23:37
op_mulwhich lets face it, is most of them23:37
bramcI thought most altcoins are trivial forks with nothing much done other than modifications of the PoW, but I haven't done a survey23: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
midnightmagicAlmost 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 lclc23:41
-!- d1ggy [~d1ggy@dslb-092-076-025-214.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards23:42
bramcmidnightmagic, 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
gmaxwelluh? 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
bramcHaven't done a survey, subject too depressing.23:45
op_muleven just counting the total number of altcoins is a problem.23:47
op_mulby some counts it's 6-700, I think it's closer to 150023:47
-!- bedeho [~bedeho@195.159.234.190] has joined #bitcoin-wizards23:49
phantomcircuitgmaxwell, that would require understanding23:56
phantomcircuitso23:56
phantomcircuitno23:56
phantomcircuitop_mul, it's infinity23:57
phantomcircuiti actually did generate about 1m altcoins just to prove a point to someone23:57
phantomcircuitthey are of course unreleased as they dont work23:57
op_mulnot much different to the real thing then23:57
op_mulyou can't beat the one that's in obfsucated javascript though.23:58
-!- siraj_ [~siraj@223.232.150.77] has joined #bitcoin-wizards23: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!