| 00:01:51 | nsh: | about the same as the ratio of the diameter of the moon to the diameter of the sun :) |
| 00:02:04 | moa: | 1/389 then |
| 00:02:18 | moa: | on average |
| 00:02:57 | frankenmint: | yoleaux: earths atmosphere and space between that is a LOT of matter and particles to muck up resolution of said image - its like saying depend on your fingerprint for your password |
| 00:03:27 | nsh: | you'd want to read and 'print' from high-orbit satellites |
| 00:03:34 | nsh: | because screw the atmosphere |
| 00:03:42 | nsh: | but i still don't know what 'print' means here |
| 00:03:47 | frankenmint: | maybe passwords or sensitive documents that require an image overlay in cunjunction w/ a password to decrypt stuff |
| 00:17:32 | gmaxwell: | if you can laser edtch you can laser obliterate. |
| 00:19:14 | gmaxwell: | there is a constantly reoccuring thread on alt.lasers on reasoning about the laser power needed to even _see_ a laser reflected off the moon excluding things like the retroreflector we placed there; its completely impraticle even given totally insane scifi budgets and state level support. |
| 00:21:19 | nsh: | we could litter the surface with retroreflectors that operate like flip-flops |
| 00:21:26 | nsh: | this is still completely impractical |
| 00:22:27 | Taek: | you still have the problem of people writing bad data or trying to destroy/alter existing data |
| 00:22:38 | gmaxwell: | nsh: retroreflectors with saturatable absorbers that go opaque after you shine on them for a while like a worm disk? :) |
| 00:23:12 | nsh: | that would be a bit one-way, but i'd imagine you could have a bistable dye maybe |
| 00:23:23 | Adlai: | can't we program the moon to verify etched data? |
| 00:23:36 | gmaxwell: | And this was how the grey goo began. |
| 00:23:55 | nsh: | .t http://journals.aps.org/pra/abstract/10.1103/PhysRevA.47.2205 |
| 00:23:55 | yoleaux: | nsh: Sorry, I don't know a timezone by that name. |
| 00:23:57 | nsh: | .title http://journals.aps.org/pra/abstract/10.1103/PhysRevA.47.2205 |
| 00:23:58 | yoleaux: | Phys. Rev. A 47, 2205 (1993) - Stability analysis for an optical bistable dye system |
| 00:24:06 | nsh: | (i like it when i have ideas and it turns out they aren't crazy) |
| 00:24:29 | nsh: | (or that there are professional academics of equal craziness, at least) |
| 00:25:08 | gmaxwell: | nsh: saturatable absorbers are actually used in production lasers today as an alternative to q-switches for pulsed operation. |
| 00:25:23 | nsh: | oh, cool |
| 00:25:23 | gmaxwell: | though those reset rather than being bi-stable. |
| 00:25:31 | nsh: | how do they reset? |
| 00:26:05 | nsh: | oh, i see |
| 00:27:32 | nsh: | -- |
| 00:27:33 | nsh: | Absorption saturation, which results in decreased absorption at high incident light intensity, competes with other mechanisms (for example, increase in temperature, formation of color centers, etc.), which result in increased absorption.[3][4] In particular, saturable absorption is only one of several mechanisms that produce self-pulsation in lasers, especially in semiconductor lasers.[5] |
| 00:27:34 | nsh: | One atom thick layer of carbon, graphene, can be seen with the naked eye because it absorbs approximately 2.3% of white light, which is π times fine-structure constant.[6] The saturable absorption response of graphene is wavelength independent from UV to IR, mid-IR and even to THz frequencies.[7][8][9] In rolled-up graphene sheets (carbon nanotubes), saturable absorption is dependent on diameter and chirality |
| 00:27:39 | nsh: | -- http://en.wikipedia.org/wiki/Saturable_absorption#Saturation_fluence |
| 00:27:57 | nsh: | (wrong anchor, sorry) |
| 00:28:39 | nsh: | (browsers should autoselect the anchor when you copy text from an anchored page. in fact the entire clipboard system is backwards and awful) |
| 00:31:11 | nsh: | 833i-l |
| 00:32:13 | nsh: | ^ (don't try to carry bottles of beer up the stairs by resting them in your laptop hinge) |
| 01:00:52 | kanzure: | "completely impraticle even given totally insane scifi budgets and state level support." |
| 01:01:04 | kanzure: | well there goes my plans for causing remote whole-planetary chemical reactions |
| 01:01:44 | nsh: | * nsh smiles |
| 01:02:00 | nsh: | stars have prior-art on that anyway |
| 01:02:12 | nsh: | you don't want to deal with solar IP attack lawyers |
| 01:02:49 | moa: | experimenting with extinction level events is not allowed? where's the freedom in that |
| 01:07:59 | nsh: | :) |
| 01:08:18 | nsh: | (humanity is an extinction level event, sadly) |
| 01:08:44 | moa: | not for humans, at least as far as we know |
| 01:09:44 | nsh: | right, at least until we ruin all the things we forgot to think hard enough about how interdependent we are with |
| 01:10:22 | nsh: | .wik Holocene extinction |
| 01:10:22 | yoleaux: | "The Holocene extinction, sometimes called the Sixth Extinction, is a name proposed to describe the currently ongoing extinction event of species during the present Holocene epoch (since around 10,000 BCE) mainly due to human activity." — http://en.wikipedia.org/wiki/Holocene_extinction |
| 01:11:01 | nsh: | (some great photos of things wot don't exist no more in that article) *sadfaec* |
| 01:15:59 | moa: | evolution is a dynamic process unfortunately, freezing in an artificial stasis 'cause we can would be unwise but accelerating it may also be dangerous, it's not a simple question |
| 01:32:55 | nsh: | it's probably possible to measure to define some proxy measurement of the healthiness of complex adaptive interpenetrating dynamic equilibria |
| 01:33:11 | nsh: | we just don't tend to think in those terms |
| 01:33:18 | nsh: | because we're upstart primates |
| 01:33:54 | nsh: | *possible to define |
| 02:11:35 | wallet421: | wallet421 is now known as wallet42 |
| 02:44:10 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 04:05:47 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 04:52:43 | weex_: | weex_ is now known as weex |
| 05:15:22 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 07:12:01 | Tiraspol: | Tiraspol is now known as Chappy |
| 07:20:48 | Chappy: | Chappy is now known as Tiraspol |
| 08:05:16 | card.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 |
| 08:05:16 | card.freenode.net: | Users on #bitcoin-wizards: andy-logbot Pan0ram1x antanst jtimon_ akrmn Mably hktud0 felipelalli1 gill3s p15x o84wb76g b_lumenkraft thrasher` zooko p15 weex harrow gnusha Emcy [7] antgreen Populus nuke1989 wallet42 alferz fanquake shesek gavmatic d1ggy_ mkarrer Dr-G2 tlrobinson PRab Adlai tromp__ NewLiberty go1111111 rustyn nsh PaulCapestany luny sparetire_ triazo vonzipper Guest47933 spinza ttttemp Tiraspol jonasschnelli stonecoldpat LeMiner dc17523be3 gielbier Relos |
| 08:05:16 | card.freenode.net: | Users on #bitcoin-wizards: mountaingoat CryptoGoon wizkid057 mappum Luke-Jr hulkhogan_ berndj leakypat_ pollux-bts bosma jrayhawk platinuum metamarc Oizopower jmcn_ jbenet HM dasource arubi_ waxwing btcdrak tucenaber kyuupichan helo bassguitarman Taek ebfull hashtagg Madars gmaxwell lnovy crowleyman bedeho cdecker iddo justanotheruser mengine GreenIsMyPepper amiller prodatalab_ sneak epscy adams__ wiz michagogo mikolalysenko artifexd grandmaster dansmith_btc SubCreative |
| 08:05:16 | card.freenode.net: | Users on #bitcoin-wizards: airbreather lmacken dgenr8 c0rw|zZz Cory larraboj brand0 nickler yrashk cfields Krellan_ stevenroose coryfields Meeh catlasshrugged cryptowest_ Alanius null_radix kanzure gavinand1esen Logicwax bliljerk_ melvster azariah tromp_ isis scoria andytoshi warptangent harrigan sparetire davout comboy TD-Linux yorick crescend1 veox mm_1 theymos Zouppen huseby _whitelogger wumpus binaryatrocity heath BananaLotus maaku face_ Apocalyptic [d__d] optimator |
| 08:05:16 | card.freenode.net: | Users on #bitcoin-wizards: Eliel narwh4l lmatteis koshii mr_burdell throughnothing_ elastoma fluffypony Fistful_of_Coins yoleaux Jaamg se3000 xabbix mariorz catcow a5m0_ smooth dignork runeks Sqt poggy livegnik K1773R petertodd richardus nephyrin phedny so phantomcircuit afdudley pigeons SwedFTP guruvan ajweiss nanotube forrestv Muis warren Xzibit17 sdaftuar eric roasbeef s1w CryptOprah morcos EasyAt Iriez merlincorey [ace] sturles jaromil Graet indolering Keefe ryan-c |
| 08:05:16 | card.freenode.net: | Users on #bitcoin-wizards: jessepollak gribble BrainOverfl0w @ChanServ gwillen kinlo sl01 STRML espes__ AdrianG luigi1111 Anduck BlueMatt midnightmagic otoburb kumavis starsoccer d9b4bef9 |
| 10:37:39 | jaromil: | hay there, anyone knows what's up with bitcoin.it down ? |
| 10:40:10 | Taek: | jaromil: #bitcoin (server got hacked via social engineeering, had to be reset) |
| 10:49:13 | Mably: | Do you mean that bitcoin.it and bitcointalk.org are hosted on the same "machine"? |
| 10:57:32 | jaromil: | ACK, thx |
| 11:55:45 | b_lumenkraft_: | b_lumenkraft_ is now known as b_lumenkraft |
| 14:11:48 | PRab_: | PRab_ is now known as PRab |
| 14:22:09 | espes__: | espes__ is now known as espes |
| 14:37:38 | lnovy: | lnovy is now known as zz_lnovy |
| 15:06:04 | zooko`: | zooko` is now known as zooko |
| 15:06:46 | antanst: | antanst has left #bitcoin-wizards |
| 15:11:04 | nsh: | phantomcircuit / midnightmagic, do you have quote DH group prime generation performance numbers still? |
| 15:12:35 | nsh: | (discussing logjam mitigations at a security group meeting at some university) |
| 15:17:20 | kanzure: | so is this what you were trying to intern at gchq for? |
| 17:16:37 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 19:36:48 | phantomcircuit: | nsh, 4096 bit dh prime 7m52.618s |
| 19:36:54 | phantomcircuit: | nsh, real 396m55.804s |
| 19:36:57 | phantomcircuit: | for 8192 |
| 19:37:09 | phantomcircuit: | i can redo the smaller ones if you're interested |
| 19:37:40 | Taek: | phantomcircuit: what are you doing? |
| 19:37:58 | akrmn: | Hi so if someone wants to discuss the proposal I made on the mailing list, feel free to do so (titled "Scaling Bitcoin with Subchains"). |
| 19:38:00 | phantomcircuit: | i timed generating dh safe primes with openssl gendh |
| 19:38:14 | phantomcircuit: | akrmn, please dont call it scaling |
| 19:38:21 | phantomcircuit: | it's confusing to the general public |
| 19:38:24 | akrmn: | I prefer an answer by mail, but if you prefer IRC, I can also reply |
| 19:38:46 | phantomcircuit: | adjusting the blocksize limits via a hard or soft fork is at best a linear increase |
| 19:38:54 | phantomcircuit: | it doesn't change the fundamental scaling issues |
| 19:39:08 | petertodd: | phantomcircuit: +1 |
| 19:39:10 | akrmn: | phantomcircuit: True, that's another reason we should look to other solutions |
| 19:39:37 | akrmn: | I think petertodd would like my proposal. It's similar to his tree chains thing from what I remember. |
| 19:40:04 | phantomcircuit: | you mean the thing which he cant get the incentives right for? |
| 19:40:11 | phantomcircuit: | that's maybe not a ringing endorsement... |
| 19:40:46 | petertodd: | phantomcircuit: nah, incentives for tree chains are easy... actually using it is hard |
| 19:40:51 | Adlai: | akrmn: http://sourceforge.net/p/bitcoin/mailman/message/34127318/ ? |
| 19:40:58 | gmaxwell: | phantomcircuit: I don't know of any such problem. Its just that that vision needs either snarks or potentially huge proofs accepted with payments. |
| 19:41:26 | akrmn: | Adlai: Yes that one |
| 19:42:36 | phantomcircuit: | petertodd, i remember there being some issue with much larger miners being able to steal rewards from smaller miners |
| 19:42:44 | phantomcircuit: | am i mistaken or did you fix that? |
| 19:43:25 | phantomcircuit: | akrmn, there is active work being done on trustless micropayment channels in a hub/spoke topology supporting multiple hops |
| 19:43:29 | phantomcircuit: | ie lightning |
| 19:43:39 | phantomcircuit: | (that description is probably broken in some way...) |
| 19:43:39 | petertodd: | phantomcircuit: I think you're mistaken there - though the bigger issue, is I suspect it's not likely to get used for currency stuff directly anyway, for the forseeable future |
| 19:45:32 | akrmn: | Yes I heard of lightning, still don't fully understand it, but I think it's just if you want "instant" transactions, but doesn't really fix the low volume of transactions problem. |
| 19:45:36 | Luke-Jr: | akrmn: probably would be easier to just leave addresses as a deprecated mainchain-only thing, and extend the payment protocol to decide what sidechain you want to receive the payment on. this could work with non-"scaling" sidechains, and is really orthogonal to your idea IMO |
| 19:46:33 | Luke-Jr: | a year or so ago, I was thinking sidechains may be a scalability solution, but I decided to put further thoughts on this line off until sidechains were more mature, and now think Lightning may make such experiments unnecessary |
| 19:47:09 | phantomcircuit: | akrmn, micropayment channels (which lightning is an extension of) allow for net settlement |
| 19:47:26 | phantomcircuit: | lightning allows for net settlement through a hub |
| 19:47:26 | petertodd: | I suspect where we'll actually see ugly scaling pressure is in people using the blockchain for things like escrow, as well as less-directly financial use-cases |
| 19:48:14 | Taek: | what timeline are we assuming? Lightning still requires setup transactions, there currently isn't enough room on the blockchain for 7 billion people to each have a setup tranasction |
| 19:48:16 | phantomcircuit: | petertodd, the vast majority of financial cases really just need timestamping |
| 19:48:58 | akrmn: | Luke-Jr: OK that could work too I suppose, instead of deciding based on addresses. |
| 19:49:05 | petertodd: | phantomcircuit: no, they don't... timestamping is not interesting |
| 19:49:21 | Luke-Jr: | akrmn: if you did it based on address, the receiver would need to monitor every such sidechain basically |
| 19:50:28 | akrmn: | Luke-Jr: Well if they use addresses only in the same set, then it should stay in the same sidechain |
| 19:50:39 | akrmn: | But there would be duplication |
| 19:50:57 | phantomcircuit: | petertodd, eh |
| 19:51:02 | akrmn: | where if you have an address from another set involved, it would be duplicated in that one too |
| 19:51:14 | petertodd: | phantomcircuit: what do you mean exactly by "timestamping"? |
| 19:51:21 | petertodd: | phantomcircuit: what are you trying to prevent? |
| 19:51:41 | akrmn: | I don't see how lightning can solve the storage size problem |
| 19:51:47 | phantomcircuit: | petertodd, enabling someone to make a falsifiable statement is quite often enough |
| 19:52:01 | phantomcircuit: | "these were out accounting records on may 1, 2013" |
| 19:52:14 | akrmn: | I guess you just store only what you deal with in your own lightning networks |
| 19:52:30 | akrmn: | but I think it's less decentralized, then sidechains/subchains |
| 19:52:32 | Luke-Jr: | akrmn: I suppsoe they can "vanitygen" addresses in the same set, but that's ugly. |
| 19:52:33 | ajweiss: | akrmn: you open up a micropayment contract with an intermediary and fund it, then spend around on the lightning network. the intermediaries settle on occasion. |
| 19:53:03 | phantomcircuit: | this obviously doesn't enable interesting things like trustless exchange, but mostly ownership of financials is through a third party trusted issuer |
| 19:53:39 | akrmn: | ajweiss: Ya and it's a bit more restrictive, because it has to be a micropayment contract |
| 19:54:17 | akrmn: | lightning is still complementary to what I propose, just you use it only when you want very fast transactions. |
| 19:54:25 | ajweiss: | well that's the point, it moves from on-chain transactions to offchain transactions with guarantees that no intermediaries are going to screw you over. |
| 19:54:42 | Luke-Jr: | phantomcircuit: eh, the *users* settle on occasion, not the intermediaries.. |
| 19:54:49 | Luke-Jr: | phantomcircuit: Lightning is a trustless system |
| 19:55:28 | Luke-Jr: | ajweiss: Lightning hubs can't screw you over (other than locking funds for some predefined time period) |
| 19:55:32 | akrmn: | With subchains, you use the level of chain according to the size of transaction you want to make. |
| 19:55:57 | phantomcircuit: | Luke-Jr, yeah that's what i meant |
| 19:57:10 | petertodd: | phantomcircuit: remember that timestamping *only* proves that *a* particular bit of data existed before a certain time, nothing else |
| 19:57:48 | petertodd: | phantomcircuit: what you usually need for records is that for a given domain only *one* piece of data exists; what my proofchains implements with txouts as anti-doublespend devices |
| 19:58:25 | phantomcircuit: | petertodd, yeah i know, im saying that very often you actually dont need that proof |
| 19:59:01 | petertodd: | phantomcircuit: well, I'm saying you do :) heck, I just got back from ny and multiple meetings with various banks about this stuff... |
| 19:59:04 | phantomcircuit: | but that's maybe not interesting :P |
| 20:08:02 | akrmn: | I don't understand gmaxwell's response: "But it is a functonal reduction to SPV security for anyone who isn't validating the rest, so it retains most of the fundimental centeralization vs scale tradeoff" |
| 20:08:26 | akrmn: | The first part he's talking about SPV security. Aren't SPV nodes just fake unsafe full nodes? |
| 20:09:01 | akrmn: | Then the second part, he says it retains some kind of tradeoff. In a good or bad way? |
| 20:09:33 | Taek: | It's a lot easier to scale a system (distributed or otherwise) when you start introducing centralization |
| 20:10:08 | akrmn: | ok...? |
| 20:10:11 | Taek: | gmaxwell is saying that you have introduced centralization to achieve your scaling, something that is less interesting b/c there are other known ways to achieve that |
| 20:10:36 | phantomcircuit: | akrmn, SPV nodes provide Simple Payment Verification, they are generally safe if you assume that the majority of hashing power is following the rules |
| 20:10:44 | akrmn: | How did I introduce centralization? |
| 20:11:13 | phantomcircuit: | the primary difference in security between a full node and an spv client is the impact of an attack |
| 20:11:36 | akrmn: | Currently, for small transactions we have centralization (off chain transactions) so this eases it by having more decentralized off chain transactions (in sub chains) |
| 20:11:47 | phantomcircuit: | which is to say the security assumptions are the same, but that the consequences of those assumptions being broken is much worse with an spv client |
| 20:11:50 | akrmn: | I will read more about SPV |
| 20:12:39 | akrmn: | but I think the best model is: Run a bitcoin node on your home desktop. Connect to your home desktop bitcoin node via a VPN if you're outside (like on a phone). |
| 20:12:54 | akrmn: | So why do you need an SPV? |
| 20:13:21 | phantomcircuit: | akrmn, spv + trusted full node is the same security as a full node |
| 20:13:34 | ajweiss: | what if i don't want to run infrastructure at home and i just want a smartphone app that works? then i use spv. |
| 20:13:48 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 20:13:50 | phantomcircuit: | spv + lying full node is at least not horribly broken |
| 20:14:12 | phantomcircuit: | where as dumb client + compromised trusted full node is game over |
| 20:14:31 | phantomcircuit: | spv client if you have a trusted full node is just smart risk mitigation |
| 20:15:44 | akrmn: | ajweiss: OK if you don't want, then you can use SPV, but there should be the option for people to run a node themselves, instead of being forced to trust someone else. |
| 20:16:39 | akrmn: | Still I have to understand why the blockchain extension I propose actually weakens SPV security |
| 20:19:58 | gavinand1esen: | Time for more real-time peer review: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners |
| 20:23:02 | GGuyZ_: | GGuyZ_ is now known as GGuyZ |
| 20:26:09 | Taek: | gavinand1esen: I'm perhaps not the best person to say this, but my understanding is that the biggest opposition to larger blocks comes from the cost of validation, not from the risk of miner centralization. |
| 20:26:50 | gmaxwell: | gmaxwell has left #bitcoin-wizards |
| 20:26:58 | gavinand1esen: | Taek: I cover cost of validation in http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized |
| 20:27:51 | gavinand1esen: | I’m trying hard to get people to stop arguing angels-dancing-on-the-head-of-a-pin and actually work out costs so we can have a rational discussion of costs and benefits.... |
| 20:27:56 | phantomcircuit: | gavinand1esen, "I ran some simulations, and if blocks take 20 seconds to propagate" |
| 20:28:02 | phantomcircuit: | that's quite an assumption |
| 20:29:07 | gavinand1esen: | phantomcircuit: we validate at about 1MB per second…. I assume miners are on at least 1MB-per-second network connections. |
| 20:29:28 | gavinand1esen: | (well, my old Mac validates at MB per second) |
| 20:29:39 | Taek: | gavinand1esen: running a node on a datacenter requires you to trust that datacenter. It's much safer to run a node at home, where you lose the economic advantages of datacenters; it's especially a lot more expensive if you're in a less developed part of the world |
| 20:30:12 | Taek: | Furthermore, less developed parts of the world appear to have much more to gain from switching to Bitcoin as their banking/financial infrastructure is much weaker in the first place |
| 20:30:54 | phantomcircuit: | gavinand1esen, if slowing validation gives miners an advantage i can think of more than a few ways to do that |
| 20:30:55 | gavinand1esen: | Taek: if you are going to argue that everybody should be able to run a full node over a 56K dial-up modem connection then we’re going to have to agree to disagree |
| 20:31:29 | gavinand1esen: | phantomcircuit: slowing by messing with network connections? THat’s indepdent of block size. |
| 20:32:02 | gavinand1esen: | Taek: I’m not sure exactly what you are arguing. What should people be able to do on exactly what type of connection? Numbers, please. |
| 20:36:20 | Taek: | As many people worldwide should have access to a node that they trust which is capable of verifying the entire blockchain, furthremore, the process for verifying from genesis needs to achievable: if you can *just* keep up, you don't have enough space to verify from genesis. |
| 20:36:42 | Taek: | 'node that they trust' could include a local library I suppose. It doesn't necessarily need to be in-home |
| 20:36:53 | Taek: | but requiring it to be in a massive datacenter seems unreasonable |
| 20:36:58 | gavinand1esen: | Taek: numbers, please. The blockchain is 20GB now, and getting bigger… many people will be unable to keep up with what we have NOW. |
| 20:37:50 | gavinand1esen: | Taek: and why are you saying ‘massive datacenter’ ? I run a full node from home, from my office, and could easily continue to run with 20MB blocks..... |
| 20:38:19 | Luke-Jr: | gavinand1esen: I'm not sure I could. |
| 20:38:42 | phantomcircuit: | gavinand1esen, no ... by adding a bunch of previously unseen transactions to the block |
| 20:38:52 | phantomcircuit: | which will also stall any other blocks from being processed |
| 20:39:12 | Taek: | "I’ll use ChunkHost’s current pricing to do some back-of-the-envelope calculations." --> you're calulations are based on datacenter prices in your blog post. |
| 20:39:17 | Taek: | *your |
| 20:39:48 | gavinand1esen: | phantomcircuit: I cover that in the blog post— a 20MB block full of not-previously-seen transactions takes about 20 seconds to validate on a modest PC. |
| 20:40:04 | gavinand1esen: | phantomcircuit: … and 20 seconds extra propagation is not a big deal. |
| 20:40:10 | Luke-Jr: | uh |
| 20:40:13 | Luke-Jr: | that's 20 seconds *per hop* |
| 20:41:05 | gavinand1esen: | Luke-Jr: yes, but propagation is exponential so it doesn’t really matter. Play with my simulator a big, I was surprised at how robust even extreme network topologies are. |
| 20:41:32 | phantomcircuit: | gavinand1esen, that is nonsense |
| 20:41:33 | Luke-Jr: | hm |
| 20:41:51 | phantomcircuit: | a 20MB full block with cold cache takes 60 seconds on a 4 core i3 |
| 20:42:11 | Taek: | gavinand1esen: http://www.netindex.com/download/allcountries/ - based on this graph I would target 2mbps as a good assumption |
| 20:42:18 | phantomcircuit: | and about 50 seconds on my laptops i7-4700MQ |
| 20:42:35 | phantomcircuit: | and that's without intentionally trying to construct slow nonsense |
| 20:43:16 | gavinand1esen: | phantomcircuit: SSD or spinning disk? |
| 20:43:24 | ThomasV: | * ThomasV grabs popcorn |
| 20:43:53 | gavinand1esen: | phantomcircuit: I benchmarked on my 3.4ghz i7 (4-core, I think), hybrid SSD/spinning disk. |
| 20:44:09 | Luke-Jr: | start talking about SSD, suddenly the cost of storage goes up up up |
| 20:44:11 | phantomcircuit: | gavinand1esen, SSD each with dbcache=4096 and likely entire utxo in page cache |
| 20:44:18 | gavinand1esen: | phantomcircuit: I can easily run a simulation with 60-second propagation… one sec.... |
| 20:45:16 | gavinand1esen: | phantomcircuit: … but wait, what attack are you worried about? |
| 20:46:27 | phantomcircuit: | bad simulation leading to decision making attack |
| 20:47:05 | gavinand1esen: | phantomcircuit: (if 60 second propagation, a 30% miner could get 31% of blocks) (assuming the small miners produce 20MB blocks, if they produce 1MB blocks they’ll actually make the 30% miner produce fewer than 30% of blocks) |
| 20:47:19 | gavinand1esen: | phantomcircuit: patches welcome for the simulator code. |
| 20:47:21 | phantomcircuit: | ThomasV, someone was recently saying there's issues with links on electrum.org btw |
| 20:47:53 | ThomasV: | phantomcircuit: links were fixed yesterday I think |
| 20:48:58 | gavinand1esen: | phantomcircuit: RE: validation: I’m being pretty conservative— not assuming that secp256k1 happens, or any other optimizations. |
| 20:52:19 | phantomcircuit: | gavinand1esen, i have little interest in improving the simulation; a hard forking change to do something that is at best a 1:1 cost increase in transaction volume/full node cost is likely never going to be justifiable |
| 20:52:55 | gavinand1esen: | phantomcircuit: so you’re saying “my mind is made up and there is nothing you can say that will convince me” |
| 20:53:00 | gavinand1esen: | ...... |
| 20:53:09 | gavinand1esen: | okey dokey |
| 20:53:36 | phantomcircuit: | same to you |
| 20:54:11 | Taek: | phantomcircuit: I find that argument a little unreasonable. 20kb block sizes are obviously bad for the network. Clearly there's an optimal number, even if scaling is 1:1 |
| 20:54:26 | gavinand1esen: | I am completely open to rational arguments for why a blocksize increase would be : too expensive, too dangerous .... |
| 20:54:54 | gavinand1esen: | But “more expensive” if “more” is $11 per month will not convince me. |
| 20:55:48 | phantomcircuit: | Taek, there is probably some number which is better than 1MB and it would be nice if that and an algorithm for adjusting it had been implemented before bitcoin was a several billion dollar experiment |
| 20:56:14 | phantomcircuit: | Taek, but it wasn't; so the risk of doing a hard fork has to be weighed against the benefits |
| 20:56:24 | akrmn: | gavinand1esen: storage space is the problem. You can read my recent proposal on the bitcoin dev mailing list. I am open to counterarguments from people who take your side. |
| 20:56:33 | phantomcircuit: | the risk is clearly great and i view the benefits as being effectively zero |
| 20:56:40 | gavinand1esen: | akrmn: storage for what? blockchain or utxo? |
| 20:56:55 | phantomcircuit: | akrmn, storage space is irrelevant |
| 20:57:17 | phantomcircuit: | bandwidth/cpu time/storage in order of relative cost |
| 20:57:19 | akrmn: | Blocks. http://sourceforge.net/p/bitcoin/mailman/message/34127318/ |
| 20:57:51 | akrmn: | gavinand1esen: ^ |
| 20:57:54 | Relos: | phantomcircuit what exactly are the risks? |
| 20:57:57 | gavinand1esen: | akrmn: chain pruning fixes that problem. |
| 20:58:19 | akrmn: | Well I don't think regular people should accept only having pruned chains |
| 20:58:21 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 20:58:22 | Relos: | I mean, gavinand1esen has been posting some blogs to counter such general statements as " the risks are great" so mind being specific? |
| 20:58:29 | akrmn: | while datacenters have the whole thing |
| 20:59:33 | phantomcircuit: | Relos, http://sourceforge.net/p/bitcoin/mailman/message/34090559/ |
| 20:59:37 | akrmn: | You lose transaparency of the whole system. Being able to track all the transactions from the past 10 years of your government officials is a good thing that we don't want to lose no? |
| 21:00:17 | Taek: | gavinand1esen: at the Boston dev core you mentioned that your target 'node runner' was someone technically advanced, like a software dev. I'm having trouble accepting this as a good line for where people should stop running full nodes. I confess that I struggle to understand the complete picture when trying to draw the line between who should be able to run a validating node and who shouldn't. |
| 21:00:52 | phantomcircuit: | Relos, off the top of my head; increased cost of operating a full node, systemic risk of various factions economically forking bitcoin (ie coinbase bitcoin, btce bitcoin, bitpay bitcoin, because they all selected different block sizes as the limit) |
| 21:01:06 | Relos: | phantomcircuit, that post is largely general statements... |
| 21:01:20 | Taek: | is it 'good enough' if 99% of people heavily dependent on bitcoin don't run nodes and don't pay attention to the general evolution of the protocol? |
| 21:01:32 | phantomcircuit: | Relos, centralization of mining as a consequence of block processing being massively cpu limited |
| 21:01:34 | gavinand1esen: | Taek: yes |
| 21:01:34 | Relos: | gavin here is giving specific numbers and estimates which presumably is better than simple general statements |
| 21:01:49 | phantomcircuit: | ie i can easily buy a 20k server if i have $1m in hw |
| 21:01:53 | gavinand1esen: | Taek: we are already there, 99% of people use a SPV or hosted wallet. That is OK. |
| 21:01:54 | phantomcircuit: | but not if i have $5k in hw |
| 21:02:04 | phantomcircuit: | gavinand1esen, that is not ok |
| 21:02:06 | phantomcircuit: | what the fuck |
| 21:02:09 | Taek: | gavinand1esen: do you have a blog post explaining that more clearly? I think that's something I would be interested in reading |
| 21:02:16 | Relos: | so if we do specific numbers... increasing cost of operating a full node, by how much, would it increase it to such a degree that with some simple investment ordinary joe can't afford it... etc |
| 21:02:21 | gavinand1esen: | It is just fine, in the same way most people don’t run their own SMTP or web server. |
| 21:02:27 | Taek: | We are already there, you are correct, but I'm not sure that we should consider it an acceptable place to be |
| 21:02:35 | gavinand1esen: | As long as you CAN run your own SMTP or web server.... |
| 21:03:11 | gavinand1esen: | The vision was never, ever, everybody in the world will be fully validating every single transaction. |
| 21:03:20 | phantomcircuit: | Relos, his proposal is a 20MB block, which would increase the cost by a minimum of 20x and probably more since hardware costs tend to scale non-linearly with single system performance |
| 21:03:39 | Relos: | thats assuming everyone would use the full blocksize |
| 21:03:44 | Relos: | because of some sort of attack |
| 21:03:45 | ThomasV: | was there ever a vision? |
| 21:03:53 | Relos: | which gavin's new blog post can't see |
| 21:03:58 | Relos: | so maybe specify this attack? |
| 21:04:05 | Relos: | maybe be more objective I guess |
| 21:04:11 | gavinand1esen: | ThomasV: sure, go read THe Book of Satoshi |
| 21:04:18 | ThomasV: | :) |
| 21:04:38 | akrmn: | gavinand1esen: Obviously a regular person can't validate every small transaction, but using my partitioning scheme, you can validate exactly what you want to validate and nothing more and nothing less, without a softfork. That is superior IMO. |
| 21:04:57 | gavinand1esen: | akrmn: no, you can’t, because transaction inputs would span sub-chains. |
| 21:05:10 | phantomcircuit: | Relos, if 99% of the users switch to trusting someone else bitcoin has failed |
| 21:05:15 | gavinand1esen: | akrmn: you need to learn more about how things work..... |
| 21:05:36 | HostFat: | I think that many will argue as much as they can, even if they are wrong. But at the time there will be the problem, when confirmations will start to delay and tx disappear, the first and easy solution will prevail. |
| 21:05:36 | HostFat: | Maybe the 20 MB block, maybe something like the Lightning Network. It doesn't matter what people argue now. Users/market will want an easy and fast solution when they'll clash against the problem. |
| 21:05:42 | Relos: | phantomcircuit why is bitcoin decentralised? |
| 21:05:43 | phantomcircuit: | at that point we might as well just have a set of federated timestamping servers |
| 21:05:57 | gavinand1esen: | phantomcircuit: very modest hardware and pretty-good bandwidth will deal just fine with 20MB blocks |
| 21:06:03 | Relos: | I mean, what does decentralisation achieve? |
| 21:06:16 | gavinand1esen: | phantomcircuit: … or pay a modest amount of money for a VPS in a datacenter.... |
| 21:06:23 | Relos: | is the purpose decentralisation itself, or whatever its achievements are? |
| 21:06:38 | phantomcircuit: | gavinand1esen, even you were saying it would cost like $500/year |
| 21:07:08 | lnovy: | lnovy is now known as zz_lnovy |
| 21:07:08 | phantomcircuit: | no vps provider is going to let you run a bitcoin node that's spinning the cpu 24/7 |
| 21:07:20 | phantomcircuit: | they're all over sold 20-100x |
| 21:07:35 | binaryatrocity: | speaking of general statements o.0 |
| 21:08:00 | akrmn: | gavinand1esen: I don't fully understand what you mean. I hope your read what I wrote fully. If I have an address that is associated to only one series of subchains, then my transactions with that address will only end up in those subchains. Yes, there will be duplication if addresses associated with other subchains are involved in the transaction, but that is not a big effect, I think. |
| 21:08:07 | gavinand1esen: | phantomcircuit: why would 20MB blocks spin the CPU 24/7 ? Validation is spread out over 10 minutes.... |
| 21:08:10 | kanzure: | Relos: avoids middlemen |
| 21:08:28 | gavinand1esen: | akrmn: you need to learn more about how things work…. |
| 21:08:39 | akrmn: | gavinand1esen: Yes I am willing to learn |
| 21:08:42 | phantomcircuit: | Relos, possibly you're confusing decentralization with reduced trust |
| 21:08:48 | akrmn: | If I am wrong |
| 21:08:50 | Relos: | my pint was decentralisation itself isn't necessarily the aim, but what it achieves, so its an ends to a means, and we are speaking of extremes here really, sort of what if questions |
| 21:09:25 | Relos: | gavin is producing numbers to show that costs wouldnt increase to such a point where u cant run a node (without some super modest investment) |
| 21:09:35 | petertodd: | phantomcircuit: the funny thing for me about this discussion is how I just got back from NY giving a presentation on Ripple to about a dozen banks... who are all very concerned about how poorly Ripple scales... and this is !@#$ banks who have Budgets(TM) |
| 21:09:40 | Relos: | and giving numbers, analysis, estimates... |
| 21:10:19 | petertodd: | phantomcircuit: (Ripple Labs Ripple that is, the one with a global consensus ledger that every transaction goes on) |
| 21:10:27 | phantomcircuit: | Relos, seriously if you're ok with trusting 5 of 8 big banks to timestamp your messages you can build something much more scalable than bitcoin will ever be |
| 21:10:29 | Relos: | while on the other hand we have general statements without analysis, numbers or estimates, but simple and subjective opinions... |
| 21:10:39 | phantomcircuit: | as in trivially handles 1m tps |
| 21:11:25 | Taek: | petertodd: why are banks interested in decentralized ledgers? Is it fully internal or are there external reasons too? |
| 21:11:25 | Relos: | as I said gavin has produced numbers to show that anyone can run a node with a 20mb blocksize even if, for some reason, the full blcksize was used |
| 21:11:35 | Relos: | so why would it be 5-8 banks? or nodes |
| 21:11:45 | phantomcircuit: | petertodd, Ripple(tm) is how i refer to it |
| 21:12:31 | petertodd: | Taek: depending on what you mean by "internal" yes :) they're current systems tend to be so horribly insecure that when something goes wrong there aren't genuine audit trails |
| 21:12:39 | phantomcircuit: | petertodd, i still find Ripple(tm) to be super hilarious, they managed to bring together the worst properties of a bunch of systems and almost none of the good ones |
| 21:13:47 | petertodd: | Taek: what the architecture tends to be is to have a central clearing house where transactions are submitted *without* cryptography - at best point-to-point link-level encryption. If the records go out of sync you're never really sure why that happened, which they combat with spectacular amounts of human auditing and paper shuffling. |
| 21:14:41 | ThomasV: | gavinand1esen: assuming 20mb happens, are there other changes that you would like to include in the hard fork? |
| 21:15:05 | petertodd: | Taek: blockchains distributed across multiple parties, with access proven - to a first approximation - by crypto is a pretty big improvement there, but the smarter guys are wary about the poor scaling and inherent upgrade treadmills that blockchains have - the original Ripple concept was a good one in that vein |
| 21:15:15 | HostFat: | I'm waiting to see the new consensus of Stellar running |
| 21:15:22 | gavinand1esen: | ThomasV: no, because I think arguing over what to include or not would just slow things down. |
| 21:15:40 | ThomasV: | yeah, that's what I thought |
| 21:16:24 | petertodd: | Taek: as for where truly decentralized ledgers can play a part, basically you can use a "permissioned" ledger to prove that the rules were followed by validating the contents of the ledger, and then use a PoW blockchain to prove that there only exists one copy of that ledger - the latter can give a useful energy-based bound on what it'd take to double-spend (basically this is where my proofchains work is going, at ... |
| 21:16:30 | petertodd: | ... least with respect to those clients) |
| 21:17:01 | kanzure: | er with the available pow hashing markets, it's not just energy-based bound but also monetary-bound |
| 21:17:04 | petertodd: | ThomasV: in other contexts they call hard forks "flag days", and avoid them at all costs :) |
| 21:17:41 | petertodd: | kanzure: yeah, it's an imperfect thing, but it can certainly be better than "oh shit, you mean you've been using a different ledger for the past five months?!" |
| 21:18:11 | Taek: | petertodd: that's fascinating, and seems like it would improve regulation infrastructure substantially |
| 21:18:15 | kanzure: | petertodd: if you are interested in extracting projects and money out of them, i suggest something other than total ledger replacements. even just audit trail stuff sounds like it would be a net win :-/. |
| 21:19:11 | phantomcircuit: | gavinand1esen, lets make the huge assumption that a hard fork is possible without causing massive harm (im 90% sure this is false, but lets assume) |
| 21:19:14 | petertodd: | Taek: yes... and no. :) remember that banks hate regulation too - by "improve" part of that can be that point-to-point ledgers that *aren't* global but are proven consistent with a global blockchain can give you the best of both worlds: privacy, with security |
| 21:19:37 | phantomcircuit: | gavinand1esen, there are lots of things more interesting/useful than changing the blocksize limit |
| 21:19:54 | gavinand1esen: | phantomcircuit: … that don’t require SPV clients to upgrade? |
| 21:19:55 | petertodd: | Taek: there's also jurisdictional risk: if you're "decentralized" ledger is actually controlled by a small number of validators, even if you're law abiding you may find that the people in control of the system aren't in the same jurisdiction you're in, a huge business risk |
| 21:22:04 | gavinand1esen: | I’ve gotta go, catch y’all later…. |
| 21:22:09 | phantomcircuit: | gavinand1esen, any half sane spv client would need to upgrade anyways, they are checking merkle tree branch depth... right?? |
| 21:22:10 | petertodd: | Taek: one of the things they really like about Bitcoin is that for the purpose of securing other systems, you get this *extremely* jurisdictional neutral layer that anyone can choose to use - lots of prior efforts at modernising financial systems have failed because no-one could come to agreement on jurisdictions (the SWIFT system nearly ended up being a recent case in point when the US tried to kick Russia out - ... |
| 21:22:16 | petertodd: | ... that that could happen at all is really scary) |
| 21:22:34 | petertodd: | phantomcircuit: lol, I noticed today that bitcoinj android wallet doesn't even notice doublespends properly... |
| 21:22:35 | phantomcircuit: | (yeah i know they're not) |
| 21:23:09 | petertodd: | phantomcircuit: SPV trusts miners 99.9% :( |
| 21:23:30 | Relos: | its as if most people dont want to run a full node |
| 21:23:47 | Relos: | coders seem to forget that most people aren't coders |
| 21:23:52 | gavinand1esen: | phantomcircuit: mmm, if I was coding an SPV client I would just have a DoS limit on the merkle branch depth of 111 or something.... |
| 21:23:59 | petertodd: | Relos: ...which is an enormous existential risk for bitcoin :( |
| 21:24:24 | Relos: | If - say as a doctor - I want to use btc - I dont care about nodes, I dont care about anything more than pressing a button and making this thing which is ment to make my life better do what I want it to do |
| 21:24:49 | petertodd: | Relos: well, unfortunately we just don't have the tech yet to give you what you want, sorry |
| 21:25:02 | petertodd: | Relos: Bitcoin is a system that fails if people don't participate in it widely |
| 21:25:04 | Relos: | thats the vast majority which by any common reason would use an spv wallet if they use an offline wallet at all |
| 21:25:42 | Relos: | so petertodd you want to make everyone a coder? if people wanted to be coders they wouldn't have chosen other professions... |
| 21:25:55 | gavinand1esen: | petertodd: participate how? Bitcoin will succeed just fine if there are 100,000 fully-validating nodes and 2 billion people using it |
| 21:26:01 | petertodd: | Relos: I want a pony too, but we haven't invented one yet |
| 21:26:18 | Relos: | the vast majority of people dont want to code, don't want to learn about intricacies etc |
| 21:26:22 | ThomasV: | the absence of consensus on a hard fork is a good incentive to run full nodes |
| 21:26:45 | gavinand1esen: | petertodd: you have a tendency to claim that bitcoin is doomed if everybody isn’t downloading and compiling the code from scratch….. (ok, I exaggerate. Downloading then checking gpg signatures....) |
| 21:26:47 | petertodd: | gavinand1esen: there are roughly that number of banks in the world... |
| 21:27:23 | gavinand1esen: | petertodd: yes, and the big problem with the banking system is I can’t just up and decide to start one. If bitcoin ever has THAT problem then I’d worry. |
| 21:27:33 | petertodd: | gavinand1esen: no, as I was telling you even just yesterday in that interview, I have a much more nuanced take on it that you like to try to present - stop strawmanning |
| 21:27:48 | phantomcircuit: | gavinand1esen, except you can calculate the minimum size of a transaction and you know the maximum blocksize, so you can also calculate the maximum depth of the merkle tree, which provides a real security benefit, a miner that's generating a block to cheat spv clients is limited in how many fraudulent transactions they can put in the block |
| 21:28:07 | phantomcircuit: | it's not a massive improvement, but when you consider that most spv clients involve small amounts of funds |
| 21:28:09 | phantomcircuit: | it's likely enough |
| 21:28:09 | petertodd: | gavinand1esen: as I have said many times before, what matters most is that people have the option in a genuine and easy way, which changes the political landscape around the system |
| 21:28:51 | gavinand1esen: | petertodd: I think we agree, which is why I’m proposing modest minimum hardware/bandwidth requirements...... |
| 21:28:55 | petertodd: | phantomcircuit: also remember the discussions the previous time all this came up of how you need things like merkle sum trees committing too total blocksize |
| 21:29:42 | phantomcircuit: | petertodd, yeah, that is potentially a softforking change though |
| 21:29:45 | petertodd: | gavinand1esen: and they aren't modest, they conflict with the only way we know how to create an incentive to secure the blockchain in the future, and they give us a tiny improvement in the grand scheme of things, with no clear way to go further |
| 21:29:48 | phantomcircuit: | so im less worried about it |
| 21:29:51 | petertodd: | phantomcircuit: oh for sure |
| 21:30:43 | gavinand1esen: | petertodd: are you talking about “small blocks means more fees” argument to secure the chain in the future? I’m getting tired of answering arguments I’ve already written about.... |
| 21:31:04 | gavinand1esen: | petertodd: http://gavinandresen.ninja/block-size-and-miner-fees-again |
| 21:31:08 | petertodd: | gavinand1esen: well, you haven't answered those arguments to my satisfaction, or really, anyone else here, so I guess that's that... |
| 21:31:35 | Relos: | I'd rather have 1 million people pay 1 pence than 1 person pay 1 million dollars |
| 21:31:41 | Relos: | how doesn't that answer it? |
| 21:31:42 | phantomcircuit: | writing about something on your blog doesn't mean you've answered the question or even responded to all of the reasonable objections |
| 21:32:02 | phantomcircuit: | which im quite sure isn't true for either |
| 21:33:35 | gavinand1esen: | … now I really do have to go. The problem with “responding to all the reasonable objections” is I don’t have an infinite amount of time and it is much easier to raise theoretical objections than to carefully think about and explain why everything will be OK |
| 21:34:01 | petertodd: | gavinand1esen: the fact that you aren't even close to getting consensus on this issue should be telling you something |
| 21:34:11 | petertodd: | anyway, this discussion is unproductive... |
| 21:34:27 | phantomcircuit: | the burden of demonstrating that a huge unsafe change is infact safe lies with the person proposing the change |
| 21:34:30 | phantomcircuit: | as it should be |
| 21:34:34 | petertodd: | phantomcircuit: +1 |
| 21:34:41 | antanst: | antanst has left #bitcoin-wizards |
| 21:34:50 | gavinand1esen: | … which is why I’m spending so much time going through the objections.... |
| 21:35:13 | Relos: | and not changing the size is a change |
| 21:35:50 | HostFat: | I think that it's better to code than arguing, as satoshi was doing ... if people doesn't understand or just has much more time on talking than coding |
| 21:36:11 | gavinand1esen: | Through the whole discussion just now I got exactly two reasonable objections: that 20MB blocks will use up 100% CPU on a VPS (which I can test). And that a hard fork can’t happen because hard forks are bad (which is on my list to respond to) |
| 21:36:13 | phantomcircuit: | Relos, no it's not and that statement is nonsensical to the point of being absurd |
| 21:37:19 | petertodd: | gavinand1esen: btw, re: hearn's fee concerns, any objections to first-seen-safe RBF? (ie the all outputs must be >= replaced tx) |
| 21:38:15 | gavinand1esen: | petertodd: haven’t thought about it… (and now I am REALLY late, so gotta go) |
| 21:38:28 | petertodd: | gavinand1esen: cool |
| 21:42:53 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 23:18:33 | dgenr8: | suppose no blocksize limit, and naughty miner makes a 10TB block this afternoon. what would happen? |
| 23:19:39 | NewLiberty: | No one builds on it? |
| 23:20:53 | dgenr8: | that's what I was getting at ... but it's not clear what it means to assume no limit on network xfer size |
| 23:21:05 | ajweiss: | it's ~32MB last i checked |
| 23:21:24 | ajweiss: | but this is a #bitcoin discussion |
| 23:43:45 | Taek: | does 100,000 nodes count as decentralization if they are running code that's only been read/reviewed O(100s) of times? |
| 23:44:20 | Taek: | and if an ignorant person is running a full node, knowing nothing more about the network than it's just good hygene to run a full node, does that count for much? |
| 23:45:19 | Taek: | ah I meant to put this in #bitcoin, sorry |
| 23:56:36 | dgenr8: | Taek: it counts in proportion to the clients using that fullnode |