| 00:00:43 | petertodd: | nsh: my big question about this is basically how close is, say, the intel AES extensions to implementing optimal silicon? if fed constant data, perhaps not that far away |
| 00:01:14 | petertodd: | nsh: scalar speed is basically just a function of how compact the circuits are and fundemental clockspeed |
| 00:01:44 | nsh: | right |
| 00:02:10 | nsh: | comes down to noise floor distinguishability |
| 00:02:41 | nsh: | but as Feynman said, there's plenty of room at the bottom |
| 00:02:45 | petertodd: | nsh: that and literally the speed of light, well, electrical wave propagation |
| 00:03:16 | petertodd: | nsh: for scalar speed, no there isn't... we're already building circuits with features that countable integer number of atoms wide |
| 00:03:16 | nsh: | or the speed at which we think information moves while it doesn't because we're apes |
| 00:04:33 | nsh: | * nsh nods |
| 00:05:24 | nsh: | well, there's a whole lot of mathematics going into the color dynamics of each minuscule bit of each minuscule bit of those atoms |
| 00:05:54 | petertodd: | meh, I wouldn' |
| 00:05:57 | nsh: | whether we can overload that dynamics to perform useful calculations and derive classical results is probably an open question below atomic levels |
| 00:06:07 | petertodd: | I wouldn't trust timelock to keep a secret safe for more than ~5yr anyway |
| 00:06:24 | nsh: | * nsh nods |
| 00:06:29 | petertodd: | you're talking physics voodo - 20 years? maybe? probably not |
| 00:06:40 | nsh: | aye |
| 00:25:14 | kanzure: | is http://people.xiph.org/~greg/simple_verifyable_execution.txt really something more like "the output of the program is such that only the unmodified program could have produced that particular output, independent of the value of the output, given that someone else is actually checking my hashes and commitments"? |
| 00:25:50 | kanzure: | i think i am butchering it |
| 00:31:00 | gmaxwell: | kanzure: you have a circuit (the program). There is an wire labeling. The procedure shows that I know a consistent wire labeling. |
| 00:31:30 | kanzure: | second try.. "the output of the program is deterministically encrypted based on the program/circuit"? |
| 00:32:25 | gmaxwell: | (with computational soundness, of course, both from the strength of the comittments and from the F/S sampling) |
| 00:33:42 | gmaxwell: | kanzure: I commit to a wire labeling, without revealing the decryption keys, but tell you enough that you can check its consistency in the encrypted domain. At the end I can selectively reveal some of it (e.g. the output, or some of the inputs) |
| 00:46:25 | kanzure: | a verifier interested in checking the validity of the output would check that they can encrypt the (decrypted, non-verifier-provided) output value (using the encryption keys for the output wires) and get the same encrypted output as the executor claims? |
| 00:46:47 | kanzure: | and then they would check the encrypted output against the commitments (and this is what you call the "encrypted domain")? |
| 00:47:55 | gmaxwell: | yes, note that the encryption keys are comitted too, and their value probablistic verified. |
| 01:01:18 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 01:03:11 | kanzure: | what can be done without revealing the output? |
| 01:03:50 | gmaxwell: | the output is whatever you want it to be; I mean, it can reveal a single bit if you like. |
| 01:06:49 | kanzure: | uh, is it safe to encrypt a single bit in a public key system? |
| 01:07:33 | kanzure: | oh i'm thinking of signing |
| 01:09:18 | gmaxwell: | there is no public key anything in this. |
| 01:09:44 | gmaxwell: | it's all one-time-pad encryption and hashing. |
| 01:23:03 | lechuga_: | in case any1 has a use for the contracthashtool in ruby: https://github.com/aalness/contracthashtool-ruby |
| 01:35:37 | kanzure: | what is the name of the method for verifying that the encryption key for the final output wires is correct r consistent with the other known properties of the circuit? |
| 01:35:45 | kanzure: | *correct or consistent |
| 04:00:07 | rusty: | gmaxwell: OK, so I've been persuing this fountain code server idea. It doesn't seem to quite work with a normal LT code (but I think it's fixable) |
| 04:01:05 | rusty: | gmaxwell: assuming the malicious server fails to answer any query which would reveal the corrupt tx, that's much smaller than 50% of queries. |
| 04:01:37 | rusty: | gmaxwell: unless each query asks for about num-txs/2 codes. |
| 04:01:56 | rusty: | gmaxwell: or am I barking up the wrong tree? Again :) |
| 04:02:18 | lechuga_: | fountain code |
| 04:02:22 | lechuga_: | for wat |
| 04:03:15 | gmaxwell: | rusty: depends on the rate of the code; and yes, you may need to move to an edge distribution that is denser than the optimal. |
| 04:04:48 | rusty: | gmaxwell: yes, that was what I was thinking. More like powers of two? So you get the tx you ask for, plus xor of two txs, plus xor of 4 txs ... xor of 2^N txs. |
| 04:04:57 | gmaxwell: | rusty: but wrt rate, you need to be treating it as an infinite rate code, so no two queries are the same, and there needs to be some overhead. (I actually think the overhead can be negligible beyond the decoding bound, but it's probably easier to prove for a factor of two) |
| 04:06:16 | gmaxwell: | lechuga_: Its an approach I came up with a while ago for encoding blocks so that they can be randomly verified and the server can't selectively censor the transcript. (or at least can't do so very effectively while still answering many queries) |
| 04:06:59 | lechuga_: | interesting |
| 04:07:02 | nsh: | nice |
| 04:07:20 | rusty: | gmaxwell: yes, any repeated queries are a waste, but I think feeding two numbers (offset, plus bit pattern of which halves to xor) and getting back log2(num_blocks) might work. |
| 04:08:33 | gmaxwell: | there probably is a completely regular lattice (e.. like what you're describing) that gets the properties we want, esp since we're willing to tolerate overhead. |
| 04:09:09 | rusty: | gmaxwell: I'll play with that, see what I can come up with. Good to know it sounds sane... |
| 04:10:05 | lechuga_: | gmaxwell: is it in your alt-ideas repo? |
| 04:10:07 | rusty: | gmaxwell: I haven't thought hard about deliberately false responses yet, nor about how you'd actually collaborate to detect cheating, given responses are unauthenticated. But perhaps the possibility is sufficient disincentive. |
| 04:12:14 | gmaxwell: | lechuga_: I've posted about it someplace; but IIRC its not on the altideas page as it's somewhat newer than most of the things there. |
| 04:13:44 | lechuga_: | https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding |
| 04:13:47 | lechuga_: | found it thx |
| 04:13:59 | gmaxwell: | Thats related, not quite the same thing. |
| 04:14:01 | lechuga_: | ic |
| 04:14:10 | gmaxwell: | lechuga_: the basic premise is straight forward, blocks are coded with a locally decodable error correcting code such that if you serve out {$blocksize} worth of requests for parts of the block, then those answers if combined could recover the whole block. |
| 04:15:01 | gmaxwell: | The reasoning for this is if you're imagining a model where everyone only randomly verfies parts of blocks, then one attack is to put incorrect data in a single place in the block and just 'magically fall offline' should anyone try to request specifically that part. |
| 04:16:35 | lechuga_: | whats the motivation to only verify random parts, scaling? |
| 04:17:58 | rusty: | lechuga_: yes, and robustness. AFAICT it's the only missing part of https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs |
| 04:18:16 | gmaxwell: | lechuga_: yes, it has better scaling. It goes hand in hand with this idea of fraud proofs.. Once you've made it efficient to randomly verify, if you find a problem it's also efficient to tell other people about the problem. |
| 04:18:37 | lechuga_: | ah ok |
| 04:19:04 | gmaxwell: | And that means that instead of having tens of thousands of nodes all verifying the same thing redundantly, we might get nearly as good security with a thousand fold reduction in computation. |
| 04:19:18 | lechuga_: | swam validation |
| 04:19:21 | lechuga_: | swarm* |
| 04:19:32 | phantomcircuit: | except there's only maybe 6k nodes that are public |
| 04:19:40 | phantomcircuit: | so maybe not 1000x improvement :P |
| 04:20:23 | gmaxwell: | phantomcircuit: nodes don't have to be publicly listening to particpate (and there are a _lot_ more non-listening bitcoin nodes; based on connection counts closer to 100k at least when I last tried estimating it a few months ago; probably down since then) |
| 04:20:34 | gmaxwell: | they just have to not be partitioned. |
| 04:20:47 | phantomcircuit: | hmm that's true |
| 04:20:53 | gmaxwell: | certantly such a system would have more to lose from sybil attacks. |
| 04:21:19 | gmaxwell: | But there are other tools we can deploy to reduce sybil attack risks. |
| 04:22:17 | phantomcircuit: | micro pow schemes? |
| 04:23:07 | rusty: | gmaxwell: inventivising nodes to verify is another issue. I was thinking to have miners to include a few random server responses in their coinbase. |
| 04:23:30 | gmaxwell: | rusty: I actually think that incentivized sybil attacks instead. :( |
| 04:23:54 | rusty: | * rusty thinks harder.... |
| 04:24:01 | gmaxwell: | (e.g. just run some stupid botnet proxy to pretend to be 100,000 nodes and collect all the monies) |
| 04:24:30 | gmaxwell: | (and now an attack which used to have really speculative profit is guarenteed to be profitable, ... and you can cause whatever trouble you like along the way) |
| 04:25:20 | gmaxwell: | I don't think it's that much of an issue, assuming the cost is made low enough. |
| 04:25:37 | gmaxwell: | but then again, I've thought lots of wrong things before. |
| 04:26:33 | nsh: | dozens even :) |
| 04:26:37 | gmaxwell: | phantomcircuit: so some fun things for anti-sybil: friend network topologies, e.g. "I don't consider myself non-isolated unless I have authenticted connections up to at least two manually configured friends who themselves claim to be non-isolated." |
| 04:28:04 | rusty: | gmaxwell: I'm missing something, clearly. Asking to include server response for tx SHA(SHA(prev-blockhash | yourcoinbase-outputs)) % prev_num_txs (query seed generated similarly, etc) means (1) either the know all the block contents anyway, or (2) they asked the server. |
| 04:28:10 | op_null: | gmaxwell: that is something I would like to explore. having private bitcoin peering with a "friends" model would be nice for stability. I know it happens today, but you could do some nice encrypted connections and relax the DoS rules a bit inside. |
| 04:28:33 | gmaxwell: | phantomcircuit: another one is, beacon servers. It's pretty easy to make a server with massive scale that does nothing but serve headers on a lazy non-super realtime manner. ... so you could plausable use a federation of centeralized servers to detect partitioning. |
| 04:28:55 | nsh: | mm, you can possible couch that into a kind of tiling problem where you constrict the graph control of adversarial arrangement and population primitives through tiling 'shapes' |
| 04:28:56 | rusty: | gmaxwell: ha, I was thinking of serving block headers via SMS. |
| 04:29:17 | gmaxwell: | rusty: petertodd was relaying them via twitter; until twitter blocked it. :( |
| 04:29:38 | gmaxwell: | rusty: oh! I thought you were saying that miners would pay to random nodes in their coinbases. |
| 04:29:56 | rusty: | gmaxwell: no, I'm not quite that dumb! |
| 04:30:14 | gmaxwell: | rusty: right having "proof you know something" in your blocks is reasonable. If its in the innerloop you have a throuput proof that strongly encourages storing data. |
| 04:30:40 | gmaxwell: | rusty: sorry, well, it's not that its dumb, these things are subtle and varrious similar schemes are frequently proposed. :) |
| 04:31:09 | rusty: | gmaxwell: heh... I wasn't going to go that far! I'm trying to see how far I can push the "partial-knowledge miner" idea. |
| 04:31:35 | op_null: | gmaxwell: via twitter is hard. 80 bytes in 140 characters. |
| 04:31:47 | gmaxwell: | rusty: well so a notion there is you have an allowable notion of how partial they're allowed to be. and then let them specify what part their query should be restricted to. |
| 04:32:16 | gmaxwell: | op_null: you can fit about 2k in a tweet in fact, using unicode fun as the limits are characters, not bytes. |
| 04:32:50 | rusty: | gmaxwell: if everyone starts feeding you txs with UTXO proofs, UTXO commitments allows a block-header only miner. |
| 04:33:01 | op_null: | gmaxwell: oh. duh. usenet. |
| 04:33:04 | gmaxwell: | Bitcoin block headers are a nice and friendly 1bps on average, assuming you don't care about latency. Would be a fine fit for shortwave. :) |
| 04:33:33 | op_null: | maybe we need a bitcoin-headers mailing list. |
| 04:33:35 | gmaxwell: | Though just having the headers alone without a way to get their content is only of moderate value. |
| 04:34:41 | gmaxwell: | op_null: well I thought the obvious thing to do w/ twitter is see if there is an encoding from 80 bytes (really more like 40 if you do some compression) to plausable chinese text. :P |
| 04:34:54 | gmaxwell: | er to <140 characters of plausable chinese text. |
| 04:35:05 | rusty: | gmaxwell: well, having a receive-only system (eg. the bitsat project), I'd say it's 90% of the value. |
| 04:35:37 | op_null: | gmaxwell: yes, you're right you can git unicode characters in there just fine. that's the same sort of trick used in alt.binaries.*. |
| 04:35:46 | gmaxwell: | rusty: I'd agree with that. (actually bitsat can have enough bandwidth to send more than headers though...) |
| 04:36:01 | gmaxwell: | op_null: alt.binaries uses base64 |
| 04:36:40 | rusty: | gmaxwell: yes, but I argue a cubesat is too much. I'd aim for a minimal xmitter, and pay people $10k to add it to their cubesats. Since they have 6mo lifespans anyway... |
| 04:37:00 | nsh: | you can fit relatively arbitrary things into tweets via the url shortener and embedding deterministic-decodable images |
| 04:37:39 | op_null: | gmaxwell: huh, I thought yEnc was unicode? |
| 04:37:51 | nsh: | (yet to test whether you can construct double-linked reply lists by predicting the tweet number) |
| 04:39:38 | op_null: | gmaxwell: oh right. it's ASCII but it uses the whole character set. not unicode. |
| 04:40:05 | op_null: | and not base64, either. |
| 04:42:22 | op_null: | nsh: probably hard to get data into a tweet image in any sort of reasonable density due to the JPEG compression |
| 04:43:06 | nsh: | jpeg can be gamed, i suspect |
| 04:44:09 | gmaxwell: | hm? if you control the jpeg you just set whatever data you want. |
| 04:44:27 | gmaxwell: | if it's getting compressed on your behalf, then ... yea you lose a lot of data rate that way. |
| 04:45:13 | op_null: | you don't though, they resize and recompress it. if you could do a PNG you'd get an almost 1-1 mapping of file size. when I messed about with this ages ago I actually got compression from binary > PNG due to it's efficient encoder. |
| 04:46:55 | gmaxwell: | yes, png has chunk adaptive preprocessing on top of zlib that can outperform zlib for quite a few things, not just the line art it was really optimized for. |
| 04:47:03 | nsh: | .title http://arstechnica.com/security/2014/05/how-to-stash-secret-messages-in-tweets-using-point-and-click-steganography/ |
| 04:47:04 | yoleaux: | How to stash secret messages in tweets using point-and-click steganography | Ars Technica |
| 04:47:50 | nsh: | (not particularly enlightening) |
| 04:48:32 | nsh: | .title https://medium.com/@willkirkby/twitter-and-audio-steganography-568c8eae5ead |
| 04:48:33 | yoleaux: | Twitter and Audio Steganography — Medium |
| 04:48:35 | nsh: | (better) |
| 04:49:27 | phantomcircuit: | gmaxwell, beacon servers should be relatively easy to implement also |
| 04:49:42 | phantomcircuit: | could be something as simple as spamming you with all the headers on connect |
| 04:51:14 | nsh: | (more generally: http://www.cs.ox.ac.uk/andrew.ker/docs/ADK60B.pdf -- Linguistic Steganography on Twitter: Hierarchical Language Modelling with Manual Interaction) |
| 04:51:56 | gmaxwell: | phantomcircuit: for scalablity it would ideally be connectionless, but .. bleh, nat traversal. |
| 04:52:41 | nsh: | it's 2014, everyone has had ipv6 addresses for years |
| 04:52:47 | nsh: | oh no, that's that timeline i keep not waking up in |
| 04:53:08 | nsh: | (it would just be differently awful) |
| 04:54:56 | phantomcircuit: | gmaxwell, easy enough to set that up with udp and get reasonably effective nat transferval |
| 04:55:01 | phantomcircuit: | traversal |
| 04:55:35 | gmaxwell: | ( https://twitter.com/blockheaders ) |
| 04:56:02 | gmaxwell: | phantomcircuit: yea, sure it doesn't take much code when you're sure the server is never behind nat, but it will also fail to work in many places. |
| 04:56:12 | gmaxwell: | Might have moderately higher success if it is run over port 53. |
| 05:05:09 | adam3us: | petertodd: "so, AFAICT your symkey arrangement basically makes it a semi-parallelizable problem?" the stages are fully serialized. each solution needs brute forcing one by one, and cant start on stage2 until completed stage1. but the work within the stages is parallelizable yes. not clear how to do that without repeating work without having pub key construct as with the rivest time-lock |
| 06:00:58 | maaku: | maaku is now known as Guest17879 |
| 06:33:29 | rusty: | gmaxwell: you mentioned compressing bitcoin headers to 40 bytes. I can see how to shed ~12 bytes of block SHA, and intuit version and target (8 bytes), compress or rebuild timestamp, but I can't get below 56 bytes... |
| 06:35:25 | phantomcircuit: | rusty, you can remove the nonce entirely |
| 06:36:36 | phantomcircuit: | indeed you can remove/guess nearly everything |
| 06:36:57 | phantomcircuit: | version. previous block hash, bits, and nonce |
| 06:37:07 | phantomcircuit: | and the timestamp should be easy enough to guess |
| 06:37:18 | phantomcircuit: | leaving you with basically just the merkle tree root |
| 06:37:33 | phantomcircuit: | and maybe a height value to help with guessing the previous block hash |
| 06:38:08 | phantomcircuit: | so 32 bytes + block height |
| 06:40:33 | op_null: | might end up finding a different block :P |
| 06:42:29 | op_null: | it's so much easier just to squirt out the 80 bytes somehow |
| 06:43:18 | phantomcircuit: | op_null, that's pretty unlikely |
| 06:43:34 | phantomcircuit: | nearly all of the entropy is in the merkle tree root now |
| 06:43:48 | op_null: | I know, but it's a fun thought |
| 06:52:04 | op_null: | encrypt things with a bitcoin address! - haven't people tried this before with unfortunate results? |
| 06:53:34 | rusty: | phantomcircuit: you mean do 4bn probes to figure out the nonce? |
| 06:54:08 | op_null: | that's not that long even on a normal CPU |
| 06:55:19 | phantomcircuit: | rusty, sure why not? |
| 06:55:47 | op_null: | rusty: on average it's going to be 2.1B attempts, too. |
| 06:55:57 | phantomcircuit: | hell throw in 1 byte to make it <1s |
| 06:56:13 | rusty: | op_null: hmm, I don't know, seems like ~1000 seconds @4MH/sec. I guess you can send 1 byte.... |
| 06:57:06 | op_null: | rusty: 4MH/s seems a little on the low size, and Intels next CPUs will have SHA256 instructions |
| 06:57:14 | op_null: | s/size/side |
| 06:59:16 | rusty: | op_null: fair enough... |
| 06:59:20 | rusty: | rusty is now known as rusty_afk |
| 07:01:19 | kanzure: | https://github.com/papers-we-love/papers-we-love/tree/master/gossip |
| 07:01:57 | kanzure: | and https://github.com/papers-we-love/papers-we-love/tree/master/distributed_systems |
| 07:12:27 | gmaxwell: | so an encoding for batches of headers: first a minimum time, 4 bytes, then first block height varint 4+ bytes, then a tx version, 4 bytes, then 4 bytes bits, then prevhash 28-24 bytes depending on bits (or 32 if height is congruent to one mod 2016), then mroot, 32 bytes, then timestamp relative to minimum time 2 bytes (if 0xFFFF then code 4 more bytes), then nonce, 4 bytes= 78 bytes. Next (and all following) header is 1 byte ... |
| 07:12:33 | gmaxwell: | ... version (if version is 255 read 5 more bytes, one to select a table entry to overwrite, table initlizalzed as 0..254), if heights%2016, 4 bytes bits, 32 bytes mr, 2 bytes timestamp, 4 bytes nonce = 39.002 bytes |
| 07:13:03 | gmaxwell: | and yea, sure you can save more ditching the nonce, though you still need to code if the first found in the search is correct... but really, I don't think its worth the bother. |
| 07:13:19 | gmaxwell: | since it's only another 10% at most. |
| 09:05:13 | orwell.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot fanquake Guyver2 DougieBot5000 woah tacotime hashtagg_ Guest17879 adam3us MoALTz_ TheSeven askmike Aquent Dr-G2 rfreeman_w Shiftos aburan28 op_null null_radix eristisk grandmaster bitbumper prodatalab spinza Meeh gues samson_ devrandom waxwing rusty_afk Starduster wallet42 Nightwolf jgarzik mortale koshii c0rw|sleep nuke1989 hollandais atgreen berndj Baz____ epscy dgenr8 zibbo tromp Emcy mkarrer Luke-Jr jaekwon_ go1111111 Graftec |
| 09:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: fenn postpre ryanxcharles iddo Hunger- HaltingState d4de luny SDCDev Pan0ram1x adlai arowser jaekwon lclc_bnc K1773R s1w Eliel_ kanzure bobke LaptopZZ warptangent isis btcdrak iambernie sneak harrigan michagogo hguux_ gavinandresen SubCreative JonTitor ebfull phantomcircuit sl01 Cory Grishnakh sipa DoctorBTC Flyer33 Alanius jbenet HM dansmith_btc artifexd btc__ kumavis mappum Muis azariah4 nanotube orw MRL-Relay fluffypony PaulCapestany |
| 09:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: BlueMatt a5m0 kgk LarsLarsen gazab AdrianG yoleaux gwillen livegnik BananaLotus Myagui @ChanServ burcin coutts wizkid057 Dyaheon bbrittain NikolaiToryzin forrestv nickler mr_burdell Logicwax tromp_ Krellan poggy pi07r_ comboy mmozeiko lnovy Taek optimator_ [\\\] Apocalyptic throughnothing petertodd crescendo CryptOprah cfields-away Fistful_of_Coins gmaxwell kinlo ahmed_ so Anduck [d__d] espes BigBitz otoburb wumpus EasyAt starsoccer jaromil |
| 09:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: helo Keefe Iriez huseby phedny midnightmagic nsh coryfields andytoshi BrainOverfl0w warren pigeons asoltys gribble Graet smooth amiller danneu catcow TD-Linux [Tristan] ryan-c roasbeef harrow lechuga_ |
| 09:32:21 | c0rw|sleep: | c0rw|sleep is now known as c0rw|away |
| 09:34:58 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:54:08 | maaku: | maaku is now known as Guest10156 |
| 10:12:55 | wallet421: | wallet421 is now known as wallet42 |
| 10:16:33 | lclc: | lclc is now known as lclc_bnc |
| 10:41:04 | lclc_bnc: | lclc_bnc is now known as lclc |
| 12:13:33 | lclc: | lclc is now known as lclc_bnc |
| 12:53:40 | lclc_bnc: | lclc_bnc is now known as lclc |
| 13:21:43 | adam3us: | adam3us has left #bitcoin-wizards |
| 15:14:48 | cbeams_: | cbeams_ is now known as cbeams |
| 15:55:22 | lclc: | lclc is now known as lclc_bnc |
| 17:14:26 | belcher_: | belcher_ is now known as belcher |
| 17:30:21 | adam3us: | so if we see $10k, $100k or $1m btcusd over the coming years one thing people wonder about is what does that imply for the mining hashrace - equipment expenditure & electrical usage. |
| 17:32:47 | adam3us: | so a what-if to react to that. if the hashrate increases by > 2x per 2week interval, then something else happens: the reward schedule is lengthened, by immediately reducing the next block payout by eg 1%. the reward just gets delayed towards the 2140 end. |
| 17:33:23 | adam3us: | alternatively it could be that if the hashrate drops by > 2x per 2 week interval 1% block payout is added back. |
| 17:33:42 | adam3us: | (parameters could be more sensibly tuned) |
| 17:35:32 | belcher: | cant we just wait until the block reward gets lower ? |
| 17:35:54 | belcher: | if the problem is that a huge amount of electricity has be used |
| 17:37:38 | adam3us: | point is maybe if btc price goes to $10k jan 2015 (for some reason - eg a government buying reserves, the chinese govt endorsing btc,, or a btc etf coming online), there will be a massive push into mining equipment purchase spurred by the $10k price, the manufacturers will ram up production, take more capital and electricity consumption will probably go up by a factor of 10ish also. |
| 17:39:02 | adam3us: | then you have the what-if its $100k jan 2016 and $1m jan 2017. there is a scale at which it perhaps get unsustainable or the people that will be able to get and use the power maybe increasingly governments. there will no doubt be some side-effects |
| 17:40:01 | adam3us: | who nows maybe the params are chosen to make that tolerable. someone would have to do electricity projections for $1m btcusd. |
| 17:40:24 | belcher: | something like that will just have to wait, it seems to me, governments will have to wait a decade or so before making btc their offical currency |
| 17:41:03 | belcher: | a downside to changing the block reward schedule might be a reduction of confidence in things like the 21m btc limit, since 'oh look the devs can change it easily' |
| 17:41:16 | adam3us: | unclear. things in bitcoin have a habit of surprising to the upside. (happen faster & more than people expect) |
| 17:41:34 | kanzure: | adam3us: in particular you are worried about protocol-level modifications that would need to be made for surprisingly-early-even-faster-growth? or are worried about physical resource utilization to support network growth rates that high? |
| 17:42:04 | adam3us: | betcher you could the 21btc cap could be unchanged, just the schedule longer. |
| 17:42:42 | kanzure: | i don't know if anyone has put serious thought into the implications of "surprising"-growth (whatever counts as surprising these days, since evidently $1M BTC thoughts aren't surprising) regarding protocol-level changes |
| 17:43:12 | adam3us: | kanzure: not worried about protocol. just about resource utilization its a question people ask - and one response can be well restraint by miners, or community consensus to slow down the schedule. |
| 17:43:29 | kanzure: | and by community consensus what do you mean |
| 17:43:39 | kanzure: | if not protocol? |
| 17:44:40 | adam3us: | kanzure: yes i just mean i dont see protocol scaling problems. but a hashrate growth reactive payout adjustment would be a protocol change, and would need near unanimous approval. its just a far-future what-if :) |
| 17:44:48 | belcher: | it could be corrected by market principles, for the price to stay at $1m/btc that would mean demand for btc needs to grow by $25m every 10 minutes, and if it doesnt the price will fall until demand growth = (block reward + fee)*price |
| 17:45:06 | kanzure: | yes i see lots of benefits to considering what might even be called silly what-ifs. contigencies are important... |
| 17:45:38 | kanzure: | re: increasingly only government-operated mining, that might still work out especially if they are multiple separate governments. i would be more worried about a single government head start against other governments. |
| 17:46:31 | adam3us: | belcher: well soon enough that'll be $12.5m/block and then $6.25m/block. but when governments get into bitcoin to augment or replace gold, that could fairly easily happen i would think. |
| 17:46:41 | kanzure: | strangely enough this seems to have lots in common with "what happens if a certain government creates agi first" lines of argumentation, so maybe you should go spelunking for ideas from those people |
| 17:48:25 | adam3us: | an argument for never changing is its a security subsidy and a more expensive btc imples a linear need for more security. |
| 17:48:57 | kanzure: | central banks are problematic as adversaries since they can spend themselves into oblivion |
| 17:49:22 | kanzure: | even the employees of the central banks don't work like normal employees ("well once you devalue the currency you're paying me in, i wont operate your central bank anymore") because they are probably compensated, ah, differently |
| 17:49:39 | adam3us: | well decentralisation in a government btc reserve world is probably a balance of govt sponsored mining power. |
| 17:50:56 | kanzure: | oh right, it will probably appear more like government subsidies of mining companies |
| 17:52:07 | adam3us: | it can be that such entities would go -ve EV on mining for strategic control reasons. |
| 17:52:17 | kanzure: | (related context: recently i have been working on some reorg-related threat modeling regarding central banks as adversaries for a client of mine) |
| 17:52:49 | adam3us: | for that reason not changing is good also because it escalates the -EV until it breaks their banks resolve. |
| 17:53:41 | kanzure: | so one of the things that bitcoiners sometimes get wrong is treating all governments as hostile from day one. they might become hostile, that's true. |
| 17:53:47 | kanzure: | but providing a plan to them that works pretty well is also useful |
| 17:53:59 | kanzure: | and eventually you *will* be called into their offices to discuss such things |
| 17:54:03 | kanzure: | so having something prepared is important |
| 17:54:05 | adam3us: | kanzure: that wouldnt even be hostile just mutually strategic and selfish. |
| 17:54:42 | kanzure: | right, sorry. i didn't mean to imply precisely that behavior would be hostile. just the typical "stay away from BTC, governments are evil, they will just try to destroy everything". |
| 17:55:05 | kanzure: | bitcoin has a lot to offer the currently insolvent governments, so they should be correctly informed about their options and opportunities |
| 17:56:42 | adam3us: | kanzure: governments are capable of articulating economic principles and aspirations that reflect peoples wishes and economic interests now and then. they are also quite bad often at sticking to their own rules in times of crisis. bitcoin is a commodity. gold wont jump out of the ground because a politician is under pressure, and thats a feature. same for bitcoin. |
| 17:57:25 | kanzure: | sure |
| 17:58:04 | adam3us: | kanzure: the commodity behaviour plus improved features over physical gold can be a feature to governments too. (they also buy gold) the fact that they cant individually unilaterally control it or gain an unfair advantage is actually to their advantage collectively. |
| 17:58:30 | adam3us: | pity the swiss referendum on returning to 20% gold standard failed. |
| 17:58:38 | kanzure: | yep. so for these reasons they may not be interested in unintentionally screwing up mining trends. |
| 17:59:08 | kanzure: | or at least having good understanding of the current dynamics and when to jump into the game or something |
| 17:59:09 | adam3us: | i was thinking maybe it'd be cheaper for them to go to 20% btc standard. if they moved carefully the announce of the intent would jump the price making it quite cheap. |
| 17:59:34 | kanzure: | you lost me at cheap |
| 17:59:36 | adam3us: | ie there is a first mover advantage for a government to buy btc reserves |
| 17:59:45 | kanzure: | oh cheap now compared to then |
| 17:59:57 | kanzure: | yeah i don't think they would be open to that line of argument |
| 18:00:10 | kanzure: | as true as it may be, it sounds an awful lot like "you should buy silver because it would make silver bugs happy" |
| 18:03:28 | kanzure: | it would be interesting to figure out the least disruptive onboarding process if governments were interested in dabbling |
| 18:03:39 | kanzure: | including scenarios for mining or not mining |
| 18:05:04 | adam3us: | well its just an observation. i mean if they wanted to play nice they could hold secret talks and buy btc on the quiet all of them before the price leapt on the news. but its unclear if they operate that way… there is some evidence of quiet gold hoarding, but also pre-announcements about intent of given govts to increase or decrease their reserves |
| 18:07:32 | kanzure: | adam3us: for a dose of humor... https://bitcointalk.org/index.php?topic=437926.0 |
| 19:52:18 | belcher_: | belcher_ is now known as belcher |
| 21:20:35 | belcher_: | belcher_ is now known as belcher |
| 22:02:40 | sipa: | so general inquiry: who here is going to (the bitcoin sessions at) fc'15? |
| 22:02:52 | sipa: | wumpus, cfields-away, gavinandresen: ^ |
| 22:04:00 | tromp_: | i am |
| 22:04:00 | BlueMatt: | jgarzik: |
| 22:04:05 | BlueMatt: | amiller: |
| 22:04:11 | sipa: | roconnor: |
| 22:04:21 | sipa: | tromp_: cool! |
| 22:04:31 | tromp_: | gotta present cuckoo cycle |
| 22:04:48 | sipa: | gmaxwell: |
| 22:04:55 | sipa: | petertodd: |
| 22:05:23 | sipa: | also, when did this channel grow from 5 people to 181? |
| 22:05:50 | tromp_: | when you weren't looking |
| 22:06:21 | BlueMatt: | sipa: lots of people lurking to see whats being discussed, and lots of people figuring they'd come here to discuss $DUMB_IDEA instead of -dev |
| 22:06:31 | BlueMatt: | and lots of smart people getting into bitcoin, of course |
| 22:14:40 | amiller: | i'll be at FC :) |
| 22:14:46 | amiller: | also congrats tromp for getting in! |
| 22:15:53 | tromp_: | thanx, amiller. got 2 weak and 1 strong accept |
| 22:21:07 | roconnor: | sipa: what/when/where? |
| 22:21:26 | sipa: | roconnor: http://fc15.ifca.ai/ |
| 22:22:02 | roconnor: | won't be going |
| 22:22:04 | BlueMatt: | tromp_: at the bitcoin workshop? |
| 22:22:15 | tromp_: | yes, BlueMatt |
| 22:35:02 | lechuga_: | BlueMatt: re: contracthashtool, is it intentional that a random nonce is generated for each tweak vs. a single nonce for one full round of tweaking? |
| 22:35:48 | lechuga_: | (in the case where the nonce wasn't provided by the user) |
| 22:37:23 | BlueMatt: | lechuga_: hmm? it only uses one nonce no matter what, but it is incredibly deliberate that each key gets a different tweak (and very much required) |
| 22:38:09 | lechuga_: | o nm misread, it is 1 nonce |
| 22:39:09 | lechuga_: | i ported the tool to ruby and was considering building an mdf service |
| 22:39:21 | BlueMatt: | I saw that :) |
| 22:39:36 | lechuga_: | curious for any feedback on: https://github.com/aalness/contracthashtool-ruby/issues/2 |
| 22:39:37 | BlueMatt: | well, the port |
| 22:39:37 | lechuga_: | (no rush) |
| 22:40:02 | lechuga_: | you guys have obv thought about this a bit more than me |
| 22:40:09 | lechuga_: | im just anxious to start messing around |
| 22:40:20 | BlueMatt: | 1. should be done locally |
| 22:40:47 | BlueMatt: | 2. will probably be done locally as well, in the form of putting a tx on a chain |
| 22:41:16 | BlueMatt: | 3. might be as well, but could also be an exposed api |
| 22:41:29 | lechuga_: | i assumed prior to 2. the user wouldve put the tx on the chain |
| 22:41:51 | lechuga_: | (didnt want to force the MDFs to scan) |
| 22:41:55 | BlueMatt: | really, functionaries will more likely just be transaction signers |
| 22:42:03 | BlueMatt: | meh, they already have to be full nodes, so scanning the chain is cheap |
| 22:42:33 | gmaxwell: | If the tweak is not different per key then these scripts are trivially distinguhable. Say one usage uses keys {A,B,C} and another uses {A',B',C'} if the tweak is a constant then A'-A+B = B'. Among other motivations... if the pubkey isn't part of the mac then it's not strong binding, e.g. I can generate a pubkey that appears to commit to two messages, and if the pubkey has to be in the hash then it ends up needing to be per key. |
| 22:42:55 | lechuga_: | gmaxwell: right i know the tweak needs to be unique per key, bad phrasing of initial question on my part |
| 22:43:00 | BlueMatt: | gmaxwell: I thought that was obvious :p |
| 22:43:30 | gmaxwell: | BlueMatt: Dunno, not that obvious. Timo's original contract hash writeup got the latter part wrong. |
| 22:43:50 | sipa: | many things are obvious once you've heard about them :) |
| 22:44:01 | lechuga_: | :) |
| 22:44:04 | BlueMatt: | sipa: sorry, yes, I meant it was obvious once you see it there |
| 22:44:30 | BlueMatt: | ie seeing it in the code, its not hard to work back to why its needed, not neccessarily that its obviously needed |
| 22:44:45 | nsh: | * nsh obviates with alacrity |
| 23:23:27 | gmaxwell: | GAH. http://www.reddit.com/r/Bitcoin/comments/2ntpvh/bitcrypt_encryption_with_bitcoin_addresses/ |
| 23:24:47 | gmaxwell: | (see also my respone there) |