00:47:04 | aburan28: | aburan28 is now known as ab428 |
02:38:37 | dgenr8: | sipa: because every full nodes validates the rules, AND the nodes are connected in a cohesive p2p network. let it never be suggested that the p2p network is disposable, not integral, etc. |
03:08:54 | gmaxwell: | dgenr8: "the p2p network" is complete disposable and already unnecessary (there are nodes connected in ways other than the p2p network) |
03:09:31 | gmaxwell: | there are at least three other actively used alternative transports that I'm currently aware of, and we'll see more in the future. |
03:09:54 | gmaxwell: | (relay network, bitcoin-over-freenet, and the DVB radio blockchain stuff) |
03:17:02 | dgenr8: | the transport is not what's important, the way nodes find each other and relay inventory is |
03:17:47 | gmaxwell: | No thats not important either. |
03:17:58 | phantomcircuit: | dgenr8, censorship needs to be difficult, but that doesn't require a p2p network really |
03:18:08 | phantomcircuit: | it's just a relatively easy thing to build with bitcoin |
03:18:09 | gmaxwell: | It's important that you learn the blockchain. (that you're not partitioned from the honest users) but anything that accomplishes that is acceptable. |
03:18:18 | gmaxwell: | E.g. having transport over facebook would be fine. |
03:19:20 | gmaxwell: | (p2p of bitcoin's type is actually a very weak tool, easily attacked.. but fortunately the blockchain is strong enough that that weakness hardly matters. A friends network like cjdns links would be better, except the setup costs are unacceptable) |
03:19:36 | phantomcircuit: | gmaxwell, i wonder if facebook would let me upload pictures with blockchain data stuffed into EXIF fields |
03:20:54 | mappum: | phantomcircuit: or you can just steganographically put it in the image in a way that survives facebook's JPG compression |
03:21:57 | dgenr8: | if bitcoin were just the blockchain, it would not survive the 70% miner rule change scenario discussed above |
03:23:17 | dgenr8: | this is going to end up with the realization everyone was saying the same thing, sorry |
03:24:07 | phantomcircuit: | mappum, that might be hilarious |
03:24:48 | phantomcircuit: | i bet i could do giant qr codes |
03:24:57 | phantomcircuit: | lol im going to try that |
03:25:56 | mappum: | phantomcircuit: My photo albums: Summer Vacation 2012, Hawaii Trip 2013, Bitcoin Blockchain |
03:26:02 | dgenr8: | gmaxwell you say some crazy things in your quest to discredit my every utterance ;) |
03:26:29 | phantomcircuit: | are they crazy if they're true? |
03:26:34 | phantomcircuit: | im thinking no |
03:55:26 | gmaxwell: | genr8: if it were "just" the blockchain it wouldn't be a working system at all, there must be some method to communicate somehow. |
03:55:29 | gmaxwell: | dgenr8: We make two assumptions up front normally for bitcoin, that the majority of the hashpower is honest and that the honest participants |
03:55:32 | gmaxwell: | are not partitioned. The current p2p network is not very partitioning resistant, but it doesn't really need to be because partitioning alone |
03:55:35 | gmaxwell: | is mostly just a dos attack. |
03:55:37 | gmaxwell: | dgenr8: Under the example you're posing there (majority of miners want more subsidy) the current p2p network would not be ideal because it is |
03:55:40 | gmaxwell: | relatively cheap to partition. Other transport mechnisms may be better in a case where partitioning would be more valuable. |
03:55:43 | gmaxwell: | Certantly in no case is the current p2p specifically essential to the system. |
03:57:01 | gmaxwell: | dgenr8: As for "quest to discredit" insult, keep in mind that you're the one that decided to make a completely out of left field argument here; I didn't seek out anything. And your argument is just attempting to continue a position you've advanced before that I think is pretty easily demonstrated to be incorrect. |
03:57:17 | gmaxwell: | (by the fact that people aready use the full bitcoin system without using the p2p network) |
04:00:56 | gmaxwell: | (e.g. CJDNS and freenet non-opennet are example networks where partitioning a honest subgraph should be substantially more difficult; hub/spoke topologies are generally strongly partitioning resistant, though have other limitations) |
04:01:20 | gmaxwell: | Fortunate Bitcoin doesn't have just one transport so it can benefits from the benefits of multiple without suffering the all the costs of any single one. |
04:15:35 | op_mul: | phantomcircuit: I have done that. though for facebook the compression makes it almost useless. try somewhere like imgur or flickr which support PNGs. you can even leverage the pretty good compression in a PNG to get some savings over the original binary. |
04:16:01 | op_mul: | phantomcircuit: there's other methods, too. https://soundcloud.com/blockchain/00000000000000000f54a1fe88f6a4a2bf98952e60b57376eb15d80e9c753c04 |
04:21:19 | user7779_: | op_mul: can you explain what that is exactly |
04:21:28 | user7779_: | or how the block info is being rendered via sound? |
04:22:02 | op_mul: | http://www.whence.com/minimodem/ |
04:22:58 | user7779_: | awesome, thanks |
04:23:25 | op_mul: | there's no reason you couldn't do bitcoin-over-shopping-center-PA if you felt so inclined. though you might drive people inside a little insane. |
04:24:32 | user7779_: | hahah, yes probably. |
04:25:45 | contrapumpkin: | contrapumpkin is now known as copumpkun |
04:25:50 | copumpkun: | copumpkun is now known as copumpkin |
04:36:10 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
04:40:39 | rusty: | maaku: do you have an implementation or more details on your maarkle tree structure for prev blocks? |
04:43:18 | op_mul: | rusty: nice portmanteau. |
04:45:18 | rusty: | op_mul: thanks |
05:24:25 | nuke_: | nuke_ is now known as nuke1989 |
05:40:05 | maaku: | merkle tree structure? sure see this (unfinished) draft bip: https://gist.github.com/maaku/2aed2cb628024800044d |
05:40:24 | maaku: | regarding the block header back links, just what was posted here to -wizards and the mailing list |
05:40:41 | maaku: | but I intend to use the same structure in that bip |
05:40:57 | maaku: | the keys are just meaningless |
09:05:14 | hitchcock.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
09:05:14 | hitchcock.freenode.net: | Users on #bitcoin-wizards: andy-logbot soundx adam3us Guyver2 RoboTedd_ paveljanik kyletorpey Muis CryptOprah BlueMatt mappum bosma_ dgenr8 Baz____ btc__ OneFixt Rynomster copumpkin austinhill thrasher` rusty Adlai hashtag ryanxcharles tlrobinson Dr-G2 wallet42 mortale DougieBot5000 PaulCapestany hashtagg Starduster waxwing shesek afk11 bobke AdrianG wumpus isis_ [\\\] Luke-Jr MRL-Relay Dyaheon- phantomcircuit Greed` MoALTz stonecoldpat Aquent morcos pi07r c0rw1n |
09:05:14 | hitchcock.freenode.net: | Users on #bitcoin-wizards: prodatalab samson_ bsm117532 coiner GAit mr_burdell eric atgreen Shiftos dansmith_btc spinza tacotime berndj nuke1989 Graftec NikolaiToryzin mkarrer ompik [d__d] rfreeman_w Emcy toddf jaromil gues Iriez luny heath Guest3112 jgarzik go1111111 Graet_ Transisto bbrittain husebyAFK DoctorBTC BananaLotus Apocalyptic EasyAt tromp espes___ jbenet null_radix hollandais midnightmagic starsoccer gavinandresen postpre danneu catcow TD-Linux ryan-c |
09:05:14 | hitchcock.freenode.net: | Users on #bitcoin-wizards: roasbeef amiller smooth optimator_ mmozeiko Alanius epscy kobud JonTitor Hunger- fluffypony kanzure warren Krellan nanotube fenn otoburb LarsLarsen coutts jchp nsh_ asoltys_ sl01_ K1773R nickler_ a5m0 @ChanServ Meeh comboy btcdrak ahmed_ lnovy eordano nsh gribble gwillen Nightwolf Anduck cfields digitalmagus8 gmaxwell pigeons andytoshi lechuga_ artifexd hguux_ michagogo kumavis warptangent Fistful_of_Coins HM2 paperbot maaku Guest38445 |
09:05:14 | hitchcock.freenode.net: | Users on #bitcoin-wizards: coryfields iddo harrow BrainOverfl0w phedny Keefe helo BigBitz so crescendo petertodd throughnothing Taek poggy tromp_ wizkid057 burcin livegnik sipa harrigan sneak Eliel_ s1w lclc_bnc Logicwax yoleaux azariah kinlo |
09:05:14 | hitchcock.freenode.net: | [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp |
10:11:29 | lclc_bnc: | lclc_bnc is now known as lclc |
11:54:07 | Greed`: | Greed` is now known as Greed |
12:18:36 | samson2: | samson2 is now known as samson_ |
12:51:34 | lclc: | lclc is now known as lclc_bnc |
13:55:44 | wallet421: | wallet421 is now known as wallet42 |
14:30:31 | fanquake: | fanquake has left #bitcoin-wizards |
14:46:55 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
15:39:31 | amiller: | petertodd, it seems like you're trying to do formal reasoning with proof-of-publication and anti-replay-signatures as primitives but there's not a clear enough definition of either yet to really call it a theorem |
15:40:44 | amiller: | one thing is that you're willing to say that Proof-of-publication can implement anti-replay-signatures but you're not mentinoing the efficiency loss |
15:41:20 | amiller: | you're saying it counts as an "anti-replay-signature" protocol even if you have to rescan through every transaction in the blockchain to check it |
15:43:16 | amiller: | the other thing is you aren't saying anything about efficiency |
15:43:52 | amiller: | especially whether it's part of "proof of publication" to assume that everyone making proofs and checking proofs is *storing* or can readily access arbitrary pieces of data that have been previously published |
15:48:23 | amiller: | i think that for a proof-of-publication protocol that satisfies your definition, the audience has to be determined at the outset and everyone involved has to do retain all data forever |
16:00:25 | petertodd: | amiller: re: efficiency, I've pointed out elsewhere how rescan's aren't a given; appropriate indexes lead to obvious O(n log n) non-publication proofs |
16:00:41 | petertodd: | amiller: hell, with UTXO commitments you get an easy ~O(log n) way of doing it |
16:01:57 | petertodd: | (and I only say ~ because that's trusting miners fairly heavily) |
16:02:59 | amiller: | yeah but that's like |
16:03:34 | amiller: | well basically it undoes the entire assumptions about embedded consensus, that you can do this more cheaply than accessing the shared index (utxo index) for every message you want signed inthe system |
16:03:50 | petertodd: | huh? |
16:04:13 | petertodd: | embedded consensus just assumes we have some consensus system and we can do proof-of-publication (or really even just anti-replay) with it |
16:04:26 | petertodd: | e.g. colored coins *is* embedded consensus |
16:04:39 | amiller: | right, so, you can achieve 'proof of publication' while implying horrible efficiency for the resulting anti-replay-signature |
16:04:52 | petertodd: | well, yeah... |
16:05:17 | petertodd: | that's the whole point of something like treechains: O(n log n) non-publication proofs |
16:06:24 | petertodd: | you're log n is the path from top chain to specific part in the tree, the other n is just # of block headers needed to prove a non-spend |
16:06:39 | petertodd: | call it O(m log n) to be more specific |
16:08:13 | amiller: | okay well nevermind then i'm back to not understanding the significance of this philosophical difference at all then :) |
16:09:18 | amiller: | actually no i still want to dig apart at your definition |
16:09:22 | petertodd: | I understood it as an emphasis on trust vs. verification - if you're heavy on anti-replay you're more willing to accept third party trusting solutions |
16:09:59 | amiller: | in the anti-replay spend definition, you need to check that there's no previous message m' under the same pubkey p |
16:10:01 | petertodd: | e.g. how merge-mining is willing to accept some very dodgy economic assumptions to reduce that O(m log n) non-publication proof cost down to O(log n) |
16:10:07 | amiller: | that doesn't typecheck against proof-of-non-publication |
16:10:07 | petertodd: | yup |
16:10:19 | amiller: | in proof of non-publication you assert for a specific message m that m has not previously been published |
16:10:38 | petertodd: | ah, wait, no you see in the anti-replay spend definition you *trust* that *someone else* did that for you - for them the cost is still O(n log n) and probably worse |
16:10:40 | amiller: | so your reduction doesn't work because you can have a proof-of-publication system that can't support anti-replay-sig at all |
16:11:21 | petertodd: | nah, thing is you can arrange for that message to also have a signature, and prevent others from spamming invalid signatures |
16:11:36 | amiller: | within your current definition? |
16:11:49 | petertodd: | or equally, with an index mapping pubkeys to messages with valid signatures |
16:12:19 | amiller: | so it's not just about publication but also signature validation |
16:12:27 | petertodd: | amiller: there *isn't* a specific definition of exactly what we're saying when we say proof-of-publication; statements about it's efficiency are always going to be in the context of some actual implementation |
16:13:14 | amiller: | well look you tried in one letter to give it a definition and in another letter to establish some kind of reduction theorem |
16:13:19 | petertodd: | for starters, notice how in a treechains system w/o sig validation by anyone but end users it's O(m log n) with a k being the blocksize |
16:13:29 | petertodd: | yeah, you're way overthinkign that |
16:13:54 | amiller: | and this is supposed to be helpful for disentangling/comparing some different approaches re: tree chains, side chains, embedded consensus, etc |
16:14:23 | petertodd: | yeah, but all this stuff is so tied to actual implementations that getting abstract about it is silly |
16:14:45 | petertodd: | I mean, hell, I'm talking about taking advantage of UTXO indexes in my last post - that's got fuck all to do with abstract theory |
16:15:13 | petertodd: | equally, the other half of all this is economic considerations, even political considerations, which aren't exactly well captured by any of this |
16:17:50 | amiller: | yeah but it's so hard to actually evaluate all these actual implementations and concrete proposals that some abstract theory might help, so i guess my point is to encourage you for trying |
16:19:24 | petertodd: | all this stuff boils down to some pretty basic questions about who you are trusting and at what cost; I don't see the difficulty in comparing this stuff at all |
16:20:43 | gwollon: | gwollon is now known as Guest39855 |
16:20:48 | Anduck_: | Anduck_ is now known as Guest70465 |
16:23:24 | amiller: | "I don't see the difficulty in comparing this stuff at all" <-- maybe i'll get there someday |
16:25:45 | lclcd: | lclcd is now known as lclc |
16:28:53 | Anduck__: | Anduck__ is now known as Anduck |
16:30:01 | wizkidO57: | wizkidO57 is now known as wizkid057 |
16:33:34 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: wpsoftware.net (Ping timeout: 245 seconds)) |
16:44:09 | sendak.freenode.net: | Users on #bitcoin-wizards: @andy-logbot |
16:49:47 | sendak.freenode.net: | *** Notice -- TS for #bitcoin-wizards changed from 1419093849 to 1361863487 |
16:49:48 | sendak.freenode.net: | sendak.freenode.net has changed the topic to: 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 |
16:50:25 | 1JTABGVNA: | 1JTABGVNA is now known as nsh- |
16:50:43 | maaku: | maaku is now known as Guest64655 |
16:52:29 | otoburb: | otoburb is now known as Guest2104 |
17:12:23 | kanzure_: | kanzure_ is now known as kanzure |
18:05:59 | luny`: | luny` is now known as luny |
19:26:54 | Guest39855: | Guest39855 is now known as gwillen |
19:50:00 | OneFixt_: | OneFixt_ is now known as OneFixt |
20:46:39 | mr_burdell_: | mr_burdell_ is now known as mr_burdell |
20:47:08 | mr_burdell: | mr_burdell is now known as Guest29370 |
21:10:22 | BlueMatt_: | BlueMatt_ is now known as BlueMatt |
21:43:38 | Aquent: | do we have any estimate of when sidechains might be impelemented? |
21:55:53 | tacotime: | two weeks |
21:56:45 | tacotime: | ™ |
21:57:16 | tacotime: | the last read from the core devs was that it's still in its infancy unless you want to make a federated peg sidechain, which is more or less centralized |
21:57:41 | tacotime: | the git for that is referenced in the appendix of that paper |
22:07:36 | Aquent: | that seems what reddit is looking to do |
22:07:50 | Aquent: | centrelized sidechain reddit notes |
22:08:22 | op_mul: | I don't think even reddit knows what reddit is looking to do. |
22:08:30 | Aquent: | and, u saying, they dont have to wait? |
22:26:09 | gmaxwell: | Today's concetrated laughter dose: http://blog.bettercrypto.com/?p=1008 |
22:28:45 | nsh: | lol |
22:38:56 | user7779078: | ol whats that person's deal? are they just spewing nonsense? |
22:45:22 | gmaxwell: | user7779078: in this case it's halarious becuase the parameters he's pushing are widely discredited (they originate from NSA provided unjustified magic numbers). |
22:46:43 | user7779078: | gmaxwell: ah, thank you. |
22:47:01 | gmaxwell: | user7779078: in general I don't know what up with him. He makes a lot of weakly sensible very loud and over stated allegations about bitcoin. When he started up I'd wondered if he was not right in the head, but now I think he's just trying to make a job for himself as a "bitcoin critic". Too bad, because the people trying to make a job for themselves out of being critical usually also make genui |
22:47:07 | gmaxwell: | ne critics with helpful criticisms look stupid too. |
22:47:44 | user7779078: | interesting, not surprising either. someone was bound to do it |