08:05:17 | tepper.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:17 | tepper.freenode.net: | Users on #bitcoin-wizards: andy-logbot Guyver2 AaronvanW harrow ebfull mappum p15_ todays_tomorrow wallet42 cym tacotime CoinHeavy Graet Dr-G2 Taek42 torsthaldo kmels_ TheSeven Aquent Transisto mmozeiko qualiabyte nsh- midnightmagic Logicwax shesek atgreen bsm117532 oujh Guest42826 Luke-Jr Graftec cfields phantomcircuit K1773R jchp andytoshi mkarrer sthomas melvster drawingthesun HaltingState Starsoccer lnovy nsh tucenaber mortale spinza Sangheili devrandom kmels tromp__ |
08:05:17 | tepper.freenode.net: | Users on #bitcoin-wizards: iddo Emcy jgarzik grandmaster2 go1111111 dgenr8 SDCDev koshii LarsLarsen Alanius espes__ [Derek] comboy gmaxwell pajarillo Krellan throughnothing waxwing Guest14609 xenogis jaekwon1 quackgyver Meeh copumpkin roasbeef Dyaheon samson_ altoz jaromil wiretapped pi07r Eliel grubles ryan-c sipa Adohgg mr_burdell nickler kanzure EasyAt BigBitz gwillen nuke1989 BrainOverfl0w HM_ otoburb postpre CryptOprah_ DoctorBTC btc Keefe smooth michagogo warren |
08:05:17 | tepper.freenode.net: | Users on #bitcoin-wizards: Muis artifexd Fistful_of_coins azariah4 Hunger- zibbo tromp_ forrestv pigeons [\\\] bobke CodeShark Anduck zling_____ helo crescendo epscy Guest50253 asoltys berndj-blackout BlueMatt weex Iriez abc56889 digitalmagus7 sl01 lechuga_ nkuttler wumpus lianj Apocalyptic @ChanServ gribble phedny so kinlo wizkid057 UukGoblin petertodd [d__d] jcorgan optimator_ burcin LaptopZZ_ danneu dansmith_btc amiller catcow a5m0 TD-Linux poggy_ davidlatapie rs0 |
08:05:17 | tepper.freenode.net: | Users on #bitcoin-wizards: nanotube bbrittain SomeoneWeird |
11:55:15 | bsm117532: | What are the most interesting alt-coins, in your opinion? Who is actually exploring new ideas? (and which ideas?) |
12:04:19 | andytoshi: | bsm117532: bytecoin had a neat ringsignature scheme for privacy (and a ton of other batshit changes, a weird premine scam, and obviously trojanned source code) |
12:07:02 | bsm117532: | I'll throw one out...I like BitShares' Distributed PoS in that they've implemented a PRNG which relies on secret among their nodes. The PRNG is a hash of the shared secrets, so as long as there is at least one honest node, the PRNG is truly random (in that its seed is predictable by no one -- unlike the node selection mechanisms in most PoS). |
12:07:35 | bsm117532: | I've been trying to think of other ways to use their blockchain-based PRNG idea... |
12:12:25 | andytoshi: | shared secrets, plural? |
12:14:50 | bsm117532: | yes |
12:15:47 | andytoshi: | so what does the hash look like? seems like the last pair (group?) to reveal their shared secret can grind if they collude |
12:15:49 | bsm117532: | Each node basically picks a random number and publishes its hash with each block (so at the next block it's verifiable that he didn't change it). At the next block each node publishes his number, and the RNG is the hash of the concat of all the shared secrets. |
12:16:37 | bsm117532: | andytoshi: I think the publishing of the blinded secret in the previous block prevents that. |
12:17:44 | andytoshi: | yeah, i see. that's cool. still susceptible to nothing-at-stake but at first glance, not by grinding the tip of an existing chain.. |
12:18:08 | andytoshi: | i also don't see how it's sybil-resistant, how you handle new participants, etc |
12:18:10 | bsm117532: | Well it's just a shared PRNG...what you *use* it for up to you... |
12:19:00 | bsm117532: | If you add or lose nodes it's still a good PRNG as long as no one can predict which shared secrets will end up in the hash giving the PRNG. |
12:19:13 | andytoshi: | yeah, sure |
12:19:18 | bsm117532: | hence, "at least one honest node". |
12:19:45 | bsm117532: | Also resistant to byzantine failures. |
12:20:45 | andytoshi: | how are the commitments authenticated? |
12:21:16 | bsm117532: | You mean the hashed shared secret? I think each node just signs it... |
12:21:21 | bsm117532: | (I'm guessing) |
12:22:15 | andytoshi: | ah, ok. so if those keys are ever revealed then you can grind the prng, which is a vulnerability everytime you seed it (i guess only once?) |
12:22:46 | andytoshi: | and ofc you can just start at the beginning and change the node subset (or sybil them) (or only replace the ones whose keys you don't know) |
12:23:47 | bsm117532: | "keys are ever revealed" Why would a node reveal his private key? |
12:24:06 | andytoshi: | because key management is hard and/or somebody paid the node to |
12:24:24 | bsm117532: | And yes to your second comment. The scheme requires at least one honest node. If you know who the honest node is, and can knock him out, you can do whatever you want. |
12:24:48 | bsm117532: | "at least one" is a lot better than 51% agreement though... |
12:25:33 | andytoshi: | well sure, obviously you can get a better prng seed than "the current bitcoin history" |
12:25:49 | bsm117532: | Wasn't so obvious to me. ;-) |
12:26:14 | bsm117532: | Anyway, I thought it was a neat idea. |
12:27:13 | andytoshi: | yeah, it's definitely better "distributed rng" (though it's only distributed across the initial nodes and depends on them not being sybils) than anything else proposed |
12:28:50 | andytoshi: | i'm only arguing so it's clear to future readers that this doesn't solve costless simulation/nothing at stake |
12:30:17 | bsm117532: | Ok. I'm thinking of it just as a PRNG. Threre are lots of ways a PRNG could be used, but a hard part is making sure everyone has the same PRNG, and that it can't be brute-forced. |
13:42:44 | wallet42: | wallet42 is now known as Guest38825 |
13:42:44 | wallet421: | wallet421 is now known as wallet42 |
13:44:03 | nsh: | * nsh buys bsm117532 a shorter, more pleasant nickname |
13:44:29 | bsm117532: | bsm117532 is now known as bsm |
13:44:34 | nsh: | * nsh smiles |
13:44:41 | bsm: | MY IRC client does tab completion. |
13:45:06 | nsh: | oh, mine too; i'm just unashamedly aesthetically bigoted :) |
13:45:32 | nsh: | distributed RNG reminds me of some research (casually reading) i've been doing recently into quantum pseduo-telepathy |
13:45:57 | bsm: | bsm is now known as bsm9789837973716 |
13:46:01 | bsm9789837973716: | oh boo |
13:46:16 | nsh: | for distributed systems it seems quite important that you can have a nontrivial advantage in coordinating behaviour without a clear 'classical' signalling channel |
13:46:31 | nsh: | there are implications for anonymity and privacy too |
13:46:36 | bsm9789837973716: | bsm9789837973716 is now known as bsm191713117532 |
13:47:07 | bsm191713117532: | "quantum pseudo-telepathy" causes alarm bells in my head, and causes my shoes to point to the door. |
13:47:38 | nsh: | it's basically just bell inequality violations recast as in the context of game-theory |
13:47:53 | nsh: | just an evocative name, i suppose |
13:48:09 | bsm191713117532: | Another pet peeve: "quantum teleportation". Which isn't. Anyhoo... |
13:48:33 | nsh: | * nsh nods |
13:50:36 | bsm191713117532: | While I'm speculating...another thing I've had bouncing around in the attic upstairs is the notions of "fork" and "merge" in git. |
13:50:56 | bsm191713117532: | The major advantage there was that fork/merge was supposed to be an easy operation. |
13:51:14 | bsm191713117532: | Could fork/merge be made a part of a blockchain architecture? |
13:51:22 | bsm191713117532: | So that it is easy, atomic, and part of the normal operation? |
13:52:20 | nsh: | what would be forked and merged? |
13:52:31 | bsm191713117532: | The blockchain. |
13:53:11 | wumpus: | merges are only easy when they are trivial, if two people changed the same part of the source code they can be extrememly difficult, no matter what scm is used... same for blockchains, it's trivial to merge two chains that spend different inputs, if they spend the same inputs... well you the POW as tie breaker |
13:54:09 | bsm191713117532: | Yep. Make forking and merging non-conflicting blockchains easy, and develop rules for merging conflicts. |
13:54:38 | bsm191713117532: | As long as the utxo's are mutually exclusive, forking and merging is a no-brainer, and...load balancing. |
13:54:57 | wumpus: | merging non-conflicting block chains is already easy... just add all transactions together |
13:55:24 | bsm191713117532: | Yep |
14:22:02 | helo: | gmaxwell: +1 for the safe random beacon scheme. that made my day/week. |
18:55:20 | bsm117532: | I have another funny idea...since PoW relies on "burning" valuable assets, why not make those assets be stake on a different blockchain? If my node can talk to both my coin and BTC, and I can verify that a "burning" transaction in BTC exists, I accept the block from the corresponding miner. |
18:55:32 | bsm117532: | Proof of Burnt Work |
18:55:39 | sipa: | so what have you solved? |
18:55:53 | sipa: | that just sounds like delegating the problem |
18:55:54 | bsm117532: | I burn funny money instead of electricity. |
18:56:12 | bsm117532: | Not sure it solves anything. Just an idea... |
18:58:18 | bsm117532: | If a decentralized market existed, and the value of different assets could be compared, it could be a way away from computation-based PoW. |
18:58:47 | bsm117532: | But it has the same property as PoW that one has to commit economic resources to one fork or another. |
19:03:45 | Luke-Jr: | bsm117532: you only "burn funny money" if that "funny money" is already burning electricity .. |
19:04:21 | bsm117532: | Yep. Until there's no value left in the PoW chain. Then it's funny money everywhere. |
19:04:23 | Luke-Jr: | bsm117532: you might as well be merged mining |
19:05:35 | nsh-: | is the consensus now that merge-mining is intrinsically inviable, or just that it hasn't been done right so far for whatever reason? |
19:05:37 | bsm117532: | Well imagine only two or three blockchains, with a decentralized market such that you could determine the value of each one in terms of the others. None of the three is PoW. |
19:05:40 | amiller: | bsm117532, that seems close enough to #tendermint |
19:06:09 | nsh-: | i seem to recall people here being more in favor of the idea about a year or so ago then more dismissive recently, but my recall is highly imperfect |
19:06:21 | Luke-Jr: | nsh-: there's no problem with merged mining as it's been done before, although it can be improved on |
19:06:35 | nsh-: | but namecoin still can't work because...? |
19:06:45 | Luke-Jr: | namecoin is just broken becasue their codebase has bugs |
19:06:51 | Luke-Jr: | totally unrelated to merged mining |
19:06:55 | nsh-: | ah ok; my bad |
19:07:22 | Luke-Jr: | namecoind crashes after ~10 minutes of mining |
19:08:27 | Aquent: | Aquent is now known as aesu__ |
19:08:37 | bsm117532: | amiller: what's the connection to tendermint? |
19:09:00 | amiller: | nvm i see you're talking about assets on a diff blockchain not within the same blockchain |
19:09:44 | amiller: | maybe if you assume a) you have the 1:1 sidechain stuff, and b) the side chain is proof-of-burn within its own currency, then it's just like that? |
19:10:30 | bsm117532: | * bsm117532 googles "proof of burn sidechain" |
19:11:36 | bsm117532: | amiller: sounds similar |
19:11:58 | nsh-: | intuitively, i think you need a foundation of entropic work somewhere, but formalizing that seems difficlt |
19:18:18 | bsm117532: | nsh-: the only reason entropic work is important is that we all agree on its value. If you had a decentralized market providing value ratios... |
19:19:08 | bsm117532: | If you take the entire economic system, including all fiat currencies, bonds, stocks, etc, I could make ratios out of all of them and there would still be one value missing: the overall value "scale" of value. |
19:19:35 | bsm117532: | Bitcoin on the other hand has that "scale" built in, but it's the only value proposition in the system. |
19:19:57 | aesu__: | aesu__ is now known as Aquent |
19:22:55 | nsh-: | i'd have to think about that :) |
20:32:40 | david____: | Was thinking about using the Bitcoin blockchain for entropy, and I realized that there's another way you could extend the security of doing that. |
20:32:50 | david____: | (Taek42 from last night) |
20:33:30 | phantomcircuit: | [19:07:22] namecoind crashes after ~10 minutes of mining |
20:33:43 | david____: | You have some difficult computation that follows the block reward, perhaps that requires 16TB of storage and an estimated 30 minutes of latent computation |
20:33:45 | phantomcircuit: | build empty blocks |
20:33:49 | phantomcircuit: | magic it works |
20:33:58 | phantomcircuit: | also incentive for anybody who cares about namecoin to fix the client |
20:34:24 | david____: | and you deliberately pick a type of computation that's dramatically different from Bitcoin POW |
20:34:45 | david____: | the miner then will need to take a long time to figure out whether or not it wants to publish the block if it's trying to manipulate the outcome |
20:34:55 | david____: | in that time, another miner is likely to find a block and get it published first |
21:32:30 | Eliel: | david____: sounds good to me. |
21:35:53 | Eliel: | david____: however, it's difficult to estimate how much calculation power a potential attacker can have that can be dedicated to that task |
21:36:36 | Eliel: | if they can for example hash blocks at 10x the network rate, it's not unreasonable to expect them to be able to outmatch other systems in the following calculation by even more than 10x |
21:37:28 | david____: | I suppose that's true |
21:37:45 | andytoshi: | or maybe they could just mine several blocks and start the computations on them in parallel |
21:38:18 | david____: | they could do that, but they still have the issue where they need to finish the extra computations before someone else publishes a block |
21:39:23 | andytoshi: | yeah, sure. what i mean to say is, you want this to be really non-parallel or else there could be big speedups (you want a "sequential proof of work") |
21:39:39 | Eliel: | david____: if they can afford to have 10x network hashing power, I don't think it'll be a problem to have top of line equipment to calculate whatever extra computations you throw at them. |
21:39:40 | andytoshi: | but that'll necessarily open this avenue where miners start on an alternate block before they know they'll need one |
21:39:42 | david____: | right, I meant to say that |
21:40:25 | Eliel: | so, unless you can figure out how to build the extra computations so that it's just not feasible to make it go faster than 30 minutes, it could work |
21:40:28 | david____: | *about the sequential proof of work |
21:43:00 | Eliel: | uh, too tired to write straight :P |
21:45:56 | david____: | Eliel you could do something highly IO bound, needing to do large sequential lookups on disk, billions total, and you don't know which lookup is next until you've done the previous |
21:45:56 | Eliel: | s/could/can't/ |
21:45:56 | david____: | I think permacoin has something like this |
21:45:57 | Eliel: | david____: most systems will use disks for that but you can be assured the attacker will be using the fastest RAM available |
21:45:57 | david____: | So instead of 30 minuets, you make it take 24 hours |
21:45:58 | david____: | Although, at that point we're kind of reaching |
21:45:58 | david____: | We still don't have exponential cost for our attacker |
21:52:11 | Eliel: | I'm not sure how useful it is but there's also the option of using blocks from more than one blockchain. |
21:57:46 | andytoshi: | guys, there are existing papers out there with "sequential proof of work" in the title.. |
21:58:46 | andytoshi: | just set it up so on a modern CPU you need 24 hours and that should be fine, sequential work does not offer the same kind of hardware advantages as something parallelizable |
22:21:13 | btc_: | btc_ is now known as btc |
22:21:32 | artifexd_: | artifexd_ is now known as artifexd |
22:31:24 | mr_burdell_: | mr_burdell_ is now known as mr_burdell |
22:33:00 | K1773R_: | K1773R_ is now known as K1773R |
22:35:43 | maaku: | maaku is now known as Guest20979 |
22:36:27 | david__: | so I've only recently learned about obfuscation, and I'm a bit fuzzy on the subject, but would it be possible to do something like have an obfuscated program with a private key that will take as input a bitcoin block, and a previous blockchain and produce as output the signed block IFF the block is legal? |
22:37:03 | david__: | which would allow me to outsource block verification without needing to trust the person doing the verifying |
22:37:17 | Pan0ram1x: | Pan0ram1x is now known as Guest47516 |
22:37:32 | nsh: | program obfuscation isn't even earth's moonmath |