00:01:51nsh:about the same as the ratio of the diameter of the moon to the diameter of the sun :)
00:02:04moa:1/389 then
00:02:18moa:on average
00:02:57frankenmint: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:27nsh:you'd want to read and 'print' from high-orbit satellites
00:03:34nsh:because screw the atmosphere
00:03:42nsh:but i still don't know what 'print' means here
00:03:47frankenmint:maybe passwords or sensitive documents that require an image overlay in cunjunction w/ a password to decrypt stuff
00:17:32gmaxwell:if you can laser edtch you can laser obliterate.
00:19:14gmaxwell: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:19nsh:we could litter the surface with retroreflectors that operate like flip-flops
00:21:26nsh:this is still completely impractical
00:22:27Taek:you still have the problem of people writing bad data or trying to destroy/alter existing data
00:22:38gmaxwell:nsh: retroreflectors with saturatable absorbers that go opaque after you shine on them for a while like a worm disk? :)
00:23:12nsh:that would be a bit one-way, but i'd imagine you could have a bistable dye maybe
00:23:23Adlai:can't we program the moon to verify etched data?
00:23:36gmaxwell:And this was how the grey goo began.
00:23:55nsh:.t http://journals.aps.org/pra/abstract/10.1103/PhysRevA.47.2205
00:23:55yoleaux:nsh: Sorry, I don't know a timezone by that name.
00:23:57nsh:.title http://journals.aps.org/pra/abstract/10.1103/PhysRevA.47.2205
00:23:58yoleaux:Phys. Rev. A 47, 2205 (1993) - Stability analysis for an optical bistable dye system
00:24:06nsh:(i like it when i have ideas and it turns out they aren't crazy)
00:24:29nsh:(or that there are professional academics of equal craziness, at least)
00:25:08gmaxwell:nsh: saturatable absorbers are actually used in production lasers today as an alternative to q-switches for pulsed operation.
00:25:23nsh:oh, cool
00:25:23gmaxwell:though those reset rather than being bi-stable.
00:25:31nsh:how do they reset?
00:26:05nsh:oh, i see
00:27:33nsh: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:34nsh: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:39nsh:-- http://en.wikipedia.org/wiki/Saturable_absorption#Saturation_fluence
00:27:57nsh:(wrong anchor, sorry)
00:28:39nsh:(browsers should autoselect the anchor when you copy text from an anchored page. in fact the entire clipboard system is backwards and awful)
00:32:13nsh:^ (don't try to carry bottles of beer up the stairs by resting them in your laptop hinge)
01:00:52kanzure:"completely impraticle even given totally insane scifi budgets and state level support."
01:01:04kanzure:well there goes my plans for causing remote whole-planetary chemical reactions
01:01:44nsh:* nsh smiles
01:02:00nsh:stars have prior-art on that anyway
01:02:12nsh:you don't want to deal with solar IP attack lawyers
01:02:49moa:experimenting with extinction level events is not allowed? where's the freedom in that
01:08:18nsh:(humanity is an extinction level event, sadly)
01:08:44moa:not for humans, at least as far as we know
01:09:44nsh:right, at least until we ruin all the things we forgot to think hard enough about how interdependent we are with
01:10:22nsh:.wik Holocene extinction
01:10:22yoleaux:"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:01nsh:(some great photos of things wot don't exist no more in that article) *sadfaec*
01:15:59moa: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:55nsh:it's probably possible to measure to define some proxy measurement of the healthiness of complex adaptive interpenetrating dynamic equilibria
01:33:11nsh:we just don't tend to think in those terms
01:33:18nsh:because we're upstart primates
01:33:54nsh:*possible to define
02:11:35wallet421:wallet421 is now known as wallet42
02:44:10frankenmint:frankenmint has left #bitcoin-wizards
04:05:47frankenmint:frankenmint has left #bitcoin-wizards
04:52:43weex_:weex_ is now known as weex
05:15:22frankenmint:frankenmint has left #bitcoin-wizards
07:12:01Tiraspol:Tiraspol is now known as Chappy
07:20:48Chappy:Chappy is now known as Tiraspol
08:05:16card.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:16card.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:16card.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:16card.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:16card.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:16card.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:39jaromil:hay there, anyone knows what's up with bitcoin.it down ?
10:40:10Taek:jaromil: #bitcoin (server got hacked via social engineeering, had to be reset)
10:49:13Mably:Do you mean that bitcoin.it and bitcointalk.org are hosted on the same "machine"?
10:57:32jaromil:ACK, thx
11:55:45b_lumenkraft_:b_lumenkraft_ is now known as b_lumenkraft
14:11:48PRab_:PRab_ is now known as PRab
14:22:09espes__:espes__ is now known as espes
14:37:38lnovy:lnovy is now known as zz_lnovy
15:06:04zooko`:zooko` is now known as zooko
15:06:46antanst:antanst has left #bitcoin-wizards
15:11:04nsh:phantomcircuit / midnightmagic, do you have quote DH group prime generation performance numbers still?
15:12:35nsh:(discussing logjam mitigations at a security group meeting at some university)
15:17:20kanzure:so is this what you were trying to intern at gchq for?
17:16:37c0rw|zZz:c0rw|zZz is now known as c0rw1n
19:36:48phantomcircuit: nsh, 4096 bit dh prime 7m52.618s
19:36:54phantomcircuit: nsh, real 396m55.804s
19:36:57phantomcircuit:for 8192
19:37:09phantomcircuit:i can redo the smaller ones if you're interested
19:37:40Taek:phantomcircuit: what are you doing?
19:37:58akrmn: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:00phantomcircuit:i timed generating dh safe primes with openssl gendh
19:38:14phantomcircuit:akrmn, please dont call it scaling
19:38:21phantomcircuit:it's confusing to the general public
19:38:24akrmn:I prefer an answer by mail, but if you prefer IRC, I can also reply
19:38:46phantomcircuit:adjusting the blocksize limits via a hard or soft fork is at best a linear increase
19:38:54phantomcircuit:it doesn't change the fundamental scaling issues
19:39:08petertodd:phantomcircuit: +1
19:39:10akrmn:phantomcircuit: True, that's another reason we should look to other solutions
19:39:37akrmn:I think petertodd would like my proposal. It's similar to his tree chains thing from what I remember.
19:40:04phantomcircuit:you mean the thing which he cant get the incentives right for?
19:40:11phantomcircuit:that's maybe not a ringing endorsement...
19:40:46petertodd:phantomcircuit: nah, incentives for tree chains are easy... actually using it is hard
19:40:51Adlai:akrmn: http://sourceforge.net/p/bitcoin/mailman/message/34127318/ ?
19:40:58gmaxwell: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:26akrmn:Adlai: Yes that one
19:42:36phantomcircuit:petertodd, i remember there being some issue with much larger miners being able to steal rewards from smaller miners
19:42:44phantomcircuit:am i mistaken or did you fix that?
19:43:25phantomcircuit:akrmn, there is active work being done on trustless micropayment channels in a hub/spoke topology supporting multiple hops
19:43:29phantomcircuit:ie lightning
19:43:39phantomcircuit:(that description is probably broken in some way...)
19:43:39petertodd: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:32akrmn: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:36Luke-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:33Luke-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:09phantomcircuit:akrmn, micropayment channels (which lightning is an extension of) allow for net settlement
19:47:26phantomcircuit:lightning allows for net settlement through a hub
19:47:26petertodd: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:14Taek: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:16phantomcircuit:petertodd, the vast majority of financial cases really just need timestamping
19:48:58akrmn:Luke-Jr: OK that could work too I suppose, instead of deciding based on addresses.
19:49:05petertodd:phantomcircuit: no, they don't... timestamping is not interesting
19:49:21Luke-Jr:akrmn: if you did it based on address, the receiver would need to monitor every such sidechain basically
19:50:28akrmn:Luke-Jr: Well if they use addresses only in the same set, then it should stay in the same sidechain
19:50:39akrmn:But there would be duplication
19:50:57phantomcircuit:petertodd, eh
19:51:02akrmn:where if you have an address from another set involved, it would be duplicated in that one too
19:51:14petertodd:phantomcircuit: what do you mean exactly by "timestamping"?
19:51:21petertodd:phantomcircuit: what are you trying to prevent?
19:51:41akrmn:I don't see how lightning can solve the storage size problem
19:51:47phantomcircuit:petertodd, enabling someone to make a falsifiable statement is quite often enough
19:52:01phantomcircuit:"these were out accounting records on may 1, 2013"
19:52:14akrmn:I guess you just store only what you deal with in your own lightning networks
19:52:30akrmn:but I think it's less decentralized, then sidechains/subchains
19:52:32Luke-Jr:akrmn: I suppsoe they can "vanitygen" addresses in the same set, but that's ugly.
19:52:33ajweiss: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:03phantomcircuit:this obviously doesn't enable interesting things like trustless exchange, but mostly ownership of financials is through a third party trusted issuer
19:53:39akrmn:ajweiss: Ya and it's a bit more restrictive, because it has to be a micropayment contract
19:54:17akrmn:lightning is still complementary to what I propose, just you use it only when you want very fast transactions.
19:54:25ajweiss: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:42Luke-Jr:phantomcircuit: eh, the *users* settle on occasion, not the intermediaries..
19:54:49Luke-Jr:phantomcircuit: Lightning is a trustless system
19:55:28Luke-Jr:ajweiss: Lightning hubs can't screw you over (other than locking funds for some predefined time period)
19:55:32akrmn:With subchains, you use the level of chain according to the size of transaction you want to make.
19:55:57phantomcircuit:Luke-Jr, yeah that's what i meant
19:57:10petertodd:phantomcircuit: remember that timestamping *only* proves that *a* particular bit of data existed before a certain time, nothing else
19:57:48petertodd: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:25phantomcircuit:petertodd, yeah i know, im saying that very often you actually dont need that proof
19:59:01petertodd: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:04phantomcircuit:but that's maybe not interesting :P
20:08:02akrmn: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:26akrmn:The first part he's talking about SPV security. Aren't SPV nodes just fake unsafe full nodes?
20:09:01akrmn:Then the second part, he says it retains some kind of tradeoff. In a good or bad way?
20:09:33Taek:It's a lot easier to scale a system (distributed or otherwise) when you start introducing centralization
20:10:11Taek: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:36phantomcircuit: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:44akrmn:How did I introduce centralization?
20:11:13phantomcircuit:the primary difference in security between a full node and an spv client is the impact of an attack
20:11:36akrmn: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:47phantomcircuit: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:50akrmn:I will read more about SPV
20:12:39akrmn: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:54akrmn:So why do you need an SPV?
20:13:21phantomcircuit:akrmn, spv + trusted full node is the same security as a full node
20:13:34ajweiss: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:48frankenmint:frankenmint has left #bitcoin-wizards
20:13:50phantomcircuit:spv + lying full node is at least not horribly broken
20:14:12phantomcircuit:where as dumb client + compromised trusted full node is game over
20:14:31phantomcircuit:spv client if you have a trusted full node is just smart risk mitigation
20:15:44akrmn: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:39akrmn:Still I have to understand why the blockchain extension I propose actually weakens SPV security
20:19:58gavinand1esen:Time for more real-time peer review: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
20:23:02GGuyZ_:GGuyZ_ is now known as GGuyZ
20:26:09Taek: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:50gmaxwell:gmaxwell has left #bitcoin-wizards
20:26:58gavinand1esen:Taek: I cover cost of validation in http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
20:27:51gavinand1esen: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:56phantomcircuit:gavinand1esen, "I ran some simulations, and if blocks take 20 seconds to propagate"
20:28:02phantomcircuit:that's quite an assumption
20:29:07gavinand1esen:phantomcircuit: we validate at about 1MB per second…. I assume miners are on at least 1MB-per-second network connections.
20:29:28gavinand1esen:(well, my old Mac validates at MB per second)
20:29:39Taek: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:12Taek: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:54phantomcircuit:gavinand1esen, if slowing validation gives miners an advantage i can think of more than a few ways to do that
20:30:55gavinand1esen: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:29gavinand1esen:phantomcircuit: slowing by messing with network connections? THat’s indepdent of block size.
20:32:02gavinand1esen: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:20Taek: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:42Taek:'node that they trust' could include a local library I suppose. It doesn't necessarily need to be in-home
20:36:53Taek:but requiring it to be in a massive datacenter seems unreasonable
20:36:58gavinand1esen: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:50gavinand1esen: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:19Luke-Jr:gavinand1esen: I'm not sure I could.
20:38:42phantomcircuit:gavinand1esen, no ... by adding a bunch of previously unseen transactions to the block
20:38:52phantomcircuit:which will also stall any other blocks from being processed
20:39:12Taek:"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:48gavinand1esen: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:04gavinand1esen:phantomcircuit: … and 20 seconds extra propagation is not a big deal.
20:40:13Luke-Jr:that's 20 seconds *per hop*
20:41:05gavinand1esen: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:32phantomcircuit:gavinand1esen, that is nonsense
20:41:51phantomcircuit:a 20MB full block with cold cache takes 60 seconds on a 4 core i3
20:42:11Taek:gavinand1esen: http://www.netindex.com/download/allcountries/ - based on this graph I would target 2mbps as a good assumption
20:42:18phantomcircuit:and about 50 seconds on my laptops i7-4700MQ
20:42:35phantomcircuit:and that's without intentionally trying to construct slow nonsense
20:43:16gavinand1esen:phantomcircuit: SSD or spinning disk?
20:43:24ThomasV:* ThomasV grabs popcorn
20:43:53gavinand1esen:phantomcircuit: I benchmarked on my 3.4ghz i7 (4-core, I think), hybrid SSD/spinning disk.
20:44:09Luke-Jr:start talking about SSD, suddenly the cost of storage goes up up up
20:44:11phantomcircuit:gavinand1esen, SSD each with dbcache=4096 and likely entire utxo in page cache
20:44:18gavinand1esen:phantomcircuit: I can easily run a simulation with 60-second propagation… one sec....
20:45:16gavinand1esen:phantomcircuit: … but wait, what attack are you worried about?
20:46:27phantomcircuit:bad simulation leading to decision making attack
20:47:05gavinand1esen: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:19gavinand1esen:phantomcircuit: patches welcome for the simulator code.
20:47:21phantomcircuit:ThomasV, someone was recently saying there's issues with links on electrum.org btw
20:47:53ThomasV:phantomcircuit: links were fixed yesterday I think
20:48:58gavinand1esen:phantomcircuit: RE: validation: I’m being pretty conservative— not assuming that secp256k1 happens, or any other optimizations.
20:52:19phantomcircuit: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:55gavinand1esen:phantomcircuit: so you’re saying “my mind is made up and there is nothing you can say that will convince me”
20:53:09gavinand1esen:okey dokey
20:53:36phantomcircuit:same to you
20:54:11Taek: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:26gavinand1esen:I am completely open to rational arguments for why a blocksize increase would be : too expensive, too dangerous ....
20:54:54gavinand1esen:But “more expensive” if “more” is $11 per month will not convince me.
20:55:48phantomcircuit: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:14phantomcircuit:Taek, but it wasn't; so the risk of doing a hard fork has to be weighed against the benefits
20:56:24akrmn: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:33phantomcircuit:the risk is clearly great and i view the benefits as being effectively zero
20:56:40gavinand1esen:akrmn: storage for what? blockchain or utxo?
20:56:55phantomcircuit:akrmn, storage space is irrelevant
20:57:17phantomcircuit:bandwidth/cpu time/storage in order of relative cost
20:57:19akrmn:Blocks. http://sourceforge.net/p/bitcoin/mailman/message/34127318/
20:57:51akrmn:gavinand1esen: ^
20:57:54Relos:phantomcircuit what exactly are the risks?
20:57:57gavinand1esen:akrmn: chain pruning fixes that problem.
20:58:19akrmn:Well I don't think regular people should accept only having pruned chains
20:58:21zz_lnovy:zz_lnovy is now known as lnovy
20:58:22Relos:I mean, gavinand1esen has been posting some blogs to counter such general statements as " the risks are great" so mind being specific?
20:58:29akrmn:while datacenters have the whole thing
20:59:33phantomcircuit:Relos, http://sourceforge.net/p/bitcoin/mailman/message/34090559/
20:59:37akrmn: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:17Taek: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:52phantomcircuit: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:06Relos:phantomcircuit, that post is largely general statements...
21:01:20Taek: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:32phantomcircuit:Relos, centralization of mining as a consequence of block processing being massively cpu limited
21:01:34gavinand1esen:Taek: yes
21:01:34Relos:gavin here is giving specific numbers and estimates which presumably is better than simple general statements
21:01:49phantomcircuit:ie i can easily buy a 20k server if i have $1m in hw
21:01:53gavinand1esen:Taek: we are already there, 99% of people use a SPV or hosted wallet. That is OK.
21:01:54phantomcircuit:but not if i have $5k in hw
21:02:04phantomcircuit:gavinand1esen, that is not ok
21:02:06phantomcircuit:what the fuck
21:02:09Taek:gavinand1esen: do you have a blog post explaining that more clearly? I think that's something I would be interested in reading
21:02:16Relos: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:21gavinand1esen:It is just fine, in the same way most people don’t run their own SMTP or web server.
21:02:27Taek:We are already there, you are correct, but I'm not sure that we should consider it an acceptable place to be
21:02:35gavinand1esen:As long as you CAN run your own SMTP or web server....
21:03:11gavinand1esen:The vision was never, ever, everybody in the world will be fully validating every single transaction.
21:03:20phantomcircuit: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:39Relos:thats assuming everyone would use the full blocksize
21:03:44Relos:because of some sort of attack
21:03:45ThomasV:was there ever a vision?
21:03:53Relos:which gavin's new blog post can't see
21:03:58Relos:so maybe specify this attack?
21:04:05Relos:maybe be more objective I guess
21:04:11gavinand1esen:ThomasV: sure, go read THe Book of Satoshi
21:04:38akrmn: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:57gavinand1esen:akrmn: no, you can’t, because transaction inputs would span sub-chains.
21:05:10phantomcircuit:Relos, if 99% of the users switch to trusting someone else bitcoin has failed
21:05:15gavinand1esen:akrmn: you need to learn more about how things work.....
21:05:36HostFat: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:36HostFat: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:42Relos:phantomcircuit why is bitcoin decentralised?
21:05:43phantomcircuit:at that point we might as well just have a set of federated timestamping servers
21:05:57gavinand1esen:phantomcircuit: very modest hardware and pretty-good bandwidth will deal just fine with 20MB blocks
21:06:03Relos:I mean, what does decentralisation achieve?
21:06:16gavinand1esen:phantomcircuit: … or pay a modest amount of money for a VPS in a datacenter....
21:06:23Relos:is the purpose decentralisation itself, or whatever its achievements are?
21:06:38phantomcircuit:gavinand1esen, even you were saying it would cost like $500/year
21:07:08lnovy:lnovy is now known as zz_lnovy
21:07:08phantomcircuit:no vps provider is going to let you run a bitcoin node that's spinning the cpu 24/7
21:07:20phantomcircuit:they're all over sold 20-100x
21:07:35binaryatrocity:speaking of general statements o.0
21:08:00akrmn: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:07gavinand1esen:phantomcircuit: why would 20MB blocks spin the CPU 24/7 ? Validation is spread out over 10 minutes....
21:08:10kanzure:Relos: avoids middlemen
21:08:28gavinand1esen:akrmn: you need to learn more about how things work….
21:08:39akrmn:gavinand1esen: Yes I am willing to learn
21:08:42phantomcircuit:Relos, possibly you're confusing decentralization with reduced trust
21:08:48akrmn:If I am wrong
21:08:50Relos: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:25Relos: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:35petertodd: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:40Relos:and giving numbers, analysis, estimates...
21:10:19petertodd:phantomcircuit: (Ripple Labs Ripple that is, the one with a global consensus ledger that every transaction goes on)
21:10:27phantomcircuit: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:29Relos:while on the other hand we have general statements without analysis, numbers or estimates, but simple and subjective opinions...
21:10:39phantomcircuit:as in trivially handles 1m tps
21:11:25Taek:petertodd: why are banks interested in decentralized ledgers? Is it fully internal or are there external reasons too?
21:11:25Relos: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:35Relos:so why would it be 5-8 banks? or nodes
21:11:45phantomcircuit:petertodd, Ripple(tm) is how i refer to it
21:12:31petertodd: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:39phantomcircuit: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:47petertodd: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:41ThomasV:gavinand1esen: assuming 20mb happens, are there other changes that you would like to include in the hard fork?
21:15:05petertodd: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:15HostFat:I'm waiting to see the new consensus of Stellar running
21:15:22gavinand1esen:ThomasV: no, because I think arguing over what to include or not would just slow things down.
21:15:40ThomasV:yeah, that's what I thought
21:16:24petertodd: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:30petertodd:... least with respect to those clients)
21:17:01kanzure:er with the available pow hashing markets, it's not just energy-based bound but also monetary-bound
21:17:04petertodd:ThomasV: in other contexts they call hard forks "flag days", and avoid them at all costs :)
21:17:41petertodd: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:11Taek:petertodd: that's fascinating, and seems like it would improve regulation infrastructure substantially
21:18:15kanzure: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:11phantomcircuit: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:14petertodd: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:37phantomcircuit:gavinand1esen, there are lots of things more interesting/useful than changing the blocksize limit
21:19:54gavinand1esen:phantomcircuit: … that don’t require SPV clients to upgrade?
21:19:55petertodd: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:04gavinand1esen:I’ve gotta go, catch y’all later….
21:22:09phantomcircuit:gavinand1esen, any half sane spv client would need to upgrade anyways, they are checking merkle tree branch depth... right??
21:22:10petertodd: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:16petertodd:... that that could happen at all is really scary)
21:22:34petertodd:phantomcircuit: lol, I noticed today that bitcoinj android wallet doesn't even notice doublespends properly...
21:22:35phantomcircuit:(yeah i know they're not)
21:23:09petertodd:phantomcircuit: SPV trusts miners 99.9% :(
21:23:30Relos:its as if most people dont want to run a full node
21:23:47Relos:coders seem to forget that most people aren't coders
21:23:52gavinand1esen: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:59petertodd:Relos: ...which is an enormous existential risk for bitcoin :(
21:24:24Relos: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:49petertodd:Relos: well, unfortunately we just don't have the tech yet to give you what you want, sorry
21:25:02petertodd:Relos: Bitcoin is a system that fails if people don't participate in it widely
21:25:04Relos:thats the vast majority which by any common reason would use an spv wallet if they use an offline wallet at all
21:25:42Relos:so petertodd you want to make everyone a coder? if people wanted to be coders they wouldn't have chosen other professions...
21:25:55gavinand1esen:petertodd: participate how? Bitcoin will succeed just fine if there are 100,000 fully-validating nodes and 2 billion people using it
21:26:01petertodd:Relos: I want a pony too, but we haven't invented one yet
21:26:18Relos:the vast majority of people dont want to code, don't want to learn about intricacies etc
21:26:22ThomasV:the absence of consensus on a hard fork is a good incentive to run full nodes
21:26:45gavinand1esen: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:47petertodd:gavinand1esen: there are roughly that number of banks in the world...
21:27:23gavinand1esen: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:33petertodd: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:48phantomcircuit: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:07phantomcircuit:it's not a massive improvement, but when you consider that most spv clients involve small amounts of funds
21:28:09phantomcircuit:it's likely enough
21:28:09petertodd: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:51gavinand1esen:petertodd: I think we agree, which is why I’m proposing modest minimum hardware/bandwidth requirements......
21:28:55petertodd: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:42phantomcircuit:petertodd, yeah, that is potentially a softforking change though
21:29:45petertodd: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:48phantomcircuit:so im less worried about it
21:29:51petertodd:phantomcircuit: oh for sure
21:30:43gavinand1esen: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:04gavinand1esen:petertodd: http://gavinandresen.ninja/block-size-and-miner-fees-again
21:31:08petertodd:gavinand1esen: well, you haven't answered those arguments to my satisfaction, or really, anyone else here, so I guess that's that...
21:31:35Relos:I'd rather have 1 million people pay 1 pence than 1 person pay 1 million dollars
21:31:41Relos:how doesn't that answer it?
21:31:42phantomcircuit: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:02phantomcircuit:which im quite sure isn't true for either
21:33:35gavinand1esen:… 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:01petertodd:gavinand1esen: the fact that you aren't even close to getting consensus on this issue should be telling you something
21:34:11petertodd:anyway, this discussion is unproductive...
21:34:27phantomcircuit:the burden of demonstrating that a huge unsafe change is infact safe lies with the person proposing the change
21:34:30phantomcircuit:as it should be
21:34:34petertodd:phantomcircuit: +1
21:34:41antanst:antanst has left #bitcoin-wizards
21:34:50gavinand1esen:… which is why I’m spending so much time going through the objections....
21:35:13Relos:and not changing the size is a change
21:35:50HostFat: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:11gavinand1esen: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:13phantomcircuit:Relos, no it's not and that statement is nonsensical to the point of being absurd
21:37:19petertodd:gavinand1esen: btw, re: hearn's fee concerns, any objections to first-seen-safe RBF? (ie the all outputs must be >= replaced tx)
21:38:15gavinand1esen:petertodd: haven’t thought about it… (and now I am REALLY late, so gotta go)
21:38:28petertodd:gavinand1esen: cool
21:42:53frankenmint:frankenmint has left #bitcoin-wizards
23:18:33dgenr8:suppose no blocksize limit, and naughty miner makes a 10TB block this afternoon. what would happen?
23:19:39NewLiberty:No one builds on it?
23:20:53dgenr8: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:05ajweiss:it's ~32MB last i checked
23:21:24ajweiss:but this is a #bitcoin discussion
23:43:45Taek:does 100,000 nodes count as decentralization if they are running code that's only been read/reviewed O(100s) of times?
23:44:20Taek: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:19Taek:ah I meant to put this in #bitcoin, sorry
23:56:36dgenr8:Taek: it counts in proportion to the clients using that fullnode