| 00:43:58 | gmaxwell: | has anyone read sergios recent bitcoin development post and can summarize it for me? I read it and am not seeing the point-- I think he's trying to solve a different and much less interesting problem, but I could be wrong--, perhaps a different perspective may be helpful. |
| 01:15:00 | bramc: | Having met peter todd in person I'm no longer inclined to give his ideas which sound stupid the benefit of the doubt. Colored coins in particular. |
| 01:22:16 | zooko: | *sigh* |
| 01:31:50 | moa: | bramc: are you saying colored coins are stupid? |
| 01:33:36 | bramc: | moa, they're like bitcoin, but accepted less places and with more dependencies (I suppose ripple-style backing of some other asset with them just as an accounting measure is okay, but a little silly because you need a trusted party anyway) |
| 01:48:36 | midnightmagic: | gmaxwell: 'assymetric-speed encryption allows 100:1 slowdown for honest peers to prove local storage to sceptical verifiers with pitchforks' plus 'gmaxwells proof-of-storage doesn't scale well for honest nodes that want to be superhubs for *hand-wavey reasons that ignore most-likely performance avenues*' |
| 01:50:43 | bramc: | midnightmagic, What proof of storage is this? Something about keeping malicious peers from hogging peer connections? |
| 01:52:23 | midnightmagic: | bramc: a way to try to ensure that a peer does in fact have the whole blockchain locally, it was posted to bitcoin-development by Sergio Lerner, and sergio contrasted his idea with greg's in order to facilitate 'easier' scaling up of the proof mechanism. |
| 01:53:33 | bramc: | midnightmagic, Is there a link for this proof mechanism? |
| 01:54:06 | midnightmagic: | bramc: as far as I understand it, it uses assymetric encryption using IP-based seeds so the verifier has an easier go of it and can't be as-easily attacked by equivalent horsepower. |
| 01:54:27 | midnightmagic: | bramc: it's the bitcoin-development mailing list. lemme find it one sec. |
| 01:55:01 | midnightmagic: | http://sourceforge.net/p/bitcoin/mailman/message/33602678/ |
| 01:58:21 | midnightmagic: | for some reason he is adding CPU cycles on top of the costs required for the proof, to save some memory core. |
| 02:02:25 | midnightmagic: | or rather 'and saving some memory core' |
| 02:22:45 | fanquake_: | fanquake_ is now known as fanquake |
| 02:46:07 | dgenr8: | if it works, it sounds like challenger could gain confidence that a blockchain copy was built in expectation of a particular IP being queried. that would seem to stop storageless blockchain proxies unless they were supported by somebody with storage. |
| 06:33:46 | bramc: | So I had a thought today about anyonecanpay. The same functionality can be implemented on the signature side, where in a transaction with multiple inputs some of the inputs some of the signatures sign something other than the complete list of inputs and outputs |
| 06:34:43 | bramc: | The cases appear to be (a) signatures signs everything (b) signature signs just their input and the output, and my new one for today (c) signature signs their input and a list of other inputs |
| 06:35:02 | bramc: | and I guess (d) signature signs their input and at least one other input |
| 06:35:24 | bramc: | As in, they're saying a specific other input must be included in the list but not requiring it be the only one |
| 06:36:36 | bramc: | So really it's a single thing with options in it: Signer signs their own input, a list of other inputs, a boolean about whether there might be other inputs, and optionally the output |
| 06:37:09 | bramc: | the output can similarly be a list of outputs and a boolean about whether that's the complete list |
| 06:37:45 | bramc: | That seems like a good intuitive feature set to support |
| 07:15:36 | maaku: | maaku is now known as Guest86498 |
| 08:01:30 | pgokeeffe_: | pgokeeffe_ is now known as pgokeeffe |
| 08:05:18 | asimov.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:18 | asimov.freenode.net: | Users on #bitcoin-wizards: andy-logbot thrasher` pgokeeffe go1111111 Guest86498 hktud0 bramc user7779078 RoboTeddy dc17523be3 koshii TheSeven coiner justanotheruser prodatalab Pan0ram1x Emcy_ rusty fanquake jgarzik damethos molec Dr-G2 d1ggy_ sneak moa kyletorpey coblee Starduster nuke__ waxwing Luke-Jr elevation SwedFTP zooko aakselrod LeMiner EasyAt arubi GAit afk11 amincd SDCDev PaulCapestany larraboj dignork spinza devrandom mkarrer gmaxwell midnightmagic lnovy xerox |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: Iriez nsh sipa bosma forrestv Adlai MoALTz x98gvyn JustAnotherVogon gavinandresen iddo hylyt face jonasschnelli c0rw1n CoinMuncher p15 berndj gabridome bedeho s1w dgenr8 PRab Apocalyptic copumpkin DoctorBTC espes__ crowleyman adam3us1 jaekwon_ grandmaster HM adams_ SubCreative AdrianG roasbeef OneFixt JonTitor jcorgan Tiraspol harrow tromp_ Transisto [d__d] realcr binaryatrocity kyuupichan NikolaiToryzin luny ahmed_ huseby betarigs_admin |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: airbreather Visheate phedny yorick amiller_ petertodd kanzure michagogo yrashk catcow Muis cfields Zouppen coryfields_ stevenroose alferz gribble Cory LarsLarsen cryptowest_ ajweiss kinlo Logicwax crescendo wizkid057 otoburb wumpus GreenIsMyPepper phantomcircuit BlueMatt jaromil gwillen dasource fenn tromp eordano nickler Alanius BananaLotus guruvan ryan-c ebfull sdaftuar veorq helo Hunger- xabbix runeks null_radix epscy nanotube andytoshi |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: bliljerk101 starsoccer comboy Taek livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc morcos Fistful_of_Coins dardasaba isis smooth Xzibit17 artifexd kumavis mariorz Krellan platinuum Oizopower catlasshrugged Keefe eric mappum jbenet wiz heath gnusha warren lechuga_ jessepollak BrainOverfl0w so hguux__ MRL-Relay azariah btc___ throughnothing @ChanServ brand0 davout NeatBasis mr_burdell d9b4bef9 a5m0 Anduck CryptOprah leakypat |
| 08:05:18 | asimov.freenode.net: | Users on #bitcoin-wizards: TD-Linux K1773R indolering warptangent veox Eliel Graet |
| 12:08:07 | crowleyman: | crowleyman is now known as crwlymn |
| 12:24:57 | crwlymn: | crwlymn is now known as crowleyman |
| 13:02:26 | waxwing__: | waxwing__ is now known as waxwing |
| 13:48:12 | sipa: | Muis: you can introduce a new script language as a softfork, by using an OP_EVAL like construct |
| 13:49:01 | Muis: | And that language has only 1 command: recover public key from signature |
| 13:49:17 | Muis: | Or how would the op codes look? |
| 13:49:29 | sipa: | tell me when you figure it out :) |
| 13:51:42 | Muis: | https://github.com/sipa/bitcoin/commit/6e223c405988a1002eeeee69db88a1128a38b0a3 |
| 13:52:15 | sipa: | yes, that's the code to implement them |
| 13:52:22 | sipa: | the tricky part is using it in scripts |
| 13:52:25 | Muis: | yes thats all i need |
| 13:52:32 | sipa: | good luck then |
| 13:52:43 | Muis: | Because there are no scripts in my protocol |
| 13:52:53 | Muis: | So they all look the same |
| 13:53:06 | sipa: | what do you store in script outputs? |
| 13:53:10 | sipa: | eh, in transaction outputs |
| 13:54:32 | Luke-Jr: | sounds like more of a topic for ##altcoin-dev |
| 13:56:44 | Muis: | Just the public key of the receiver |
| 13:57:34 | sipa: | Muis: then how are you going to use pubkey recovery to _not_ store that pubkey |
| 13:57:43 | sipa: | if your protocol already says storing it :p |
| 14:00:38 | Muis: | Good question. But your scheme decreases Bitcoin tx from 133 to 65 bytes, so why would it work ffor Bitcoin and not in my case? |
| 14:02:00 | sipa: | i'm asking you to think how to make it work |
| 14:02:12 | sipa: | you seem to assume it's pixie dust that just decreases things |
| 14:02:18 | Muis: | " Currently, bitcoin txin's for spend-to-address transactions use a DER-encoded signature + DER-encoded public key, resulting in 139-byte scripts. Assuming we drop the DER-encoding (except for a version byte), we could reduce this to 65 bytes." |
| 14:02:29 | sipa: | you need to significantlty redesign things to make it work |
| 14:03:33 | Muis: | So i must limit to spend-to txs |
| 14:03:38 | sipa: | first of all, it just doesn't apply to your design |
| 14:03:55 | sipa: | it's inherent to how bitcoin's pay-to-pubkeyhash works |
| 14:04:12 | sipa: | it wouldn't work for pay-to-pubkey, which is what you're using |
| 14:04:13 | sipa: | sipa has left #bitcoin-wizards |
| 14:07:55 | Muis: | sipa: i can still change to pay-to-pubkeyhash, im just experimenting with a design |
| 14:08:44 | sipa: | well understand former design decisions before changing them :) |
| 14:09:06 | kanzure: | agreed |
| 14:09:43 | sipa: | you can't just say "hey i'm going to use this optimization which was described years ago in a different context", and expect it to just work |
| 14:09:55 | Muis: | true |
| 14:17:40 | Muis: | Im just trying to build a fork of Bitcoin where each address is the start of a new chain you can follow, and each address in that chain is also a possible genesis for a new chain. I did this by mis-using the nServices field for a peer, so that each peer can indicate which chains it follows (by filtering them on the first x bytes which match their IP). And if |
| 14:17:41 | Muis: | you need the headers of chain X, you dont connect to different networks/peers, but there is a large chance you can ask your existing peers. |
| 14:18:27 | Muis: | Because there will be a lot of mini chains, just like a forum with topics, the chains need to be as small as possible |
| 14:18:38 | sipa: | sipa has left #bitcoin-wizards |
| 14:18:43 | Muis: | Thats why im interested in your idea to save space |
| 15:16:39 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 16:08:55 | Guest86498: | Guest86498 is now known as maaku |
| 16:42:29 | gavinandresen: | gavinandresen has left #bitcoin-wizards |
| 17:34:00 | mrkent: | mrkent is now known as Guest23227 |
| 19:10:48 | benjyz1: | hi. is anyone using RPC via Java with bitcoinj objects? |
| 19:13:39 | amiller_: | benjyz1, that sounds better for #bitcoin-dev |
| 19:15:08 | benjyz1: | maybe. in general I think core people could more engage with devs working on API's. |
| 19:15:57 | kanzure: | "core people" are in #bitcoin-dev |
| 19:16:33 | benjyz1: | kk. so how do I go about acquiring the wizards title? |
| 19:17:28 | kanzure: | the channel name has already been registered with chanserv |
| 19:19:41 | waxwing__: | waxwing__ is now known as waxwing |
| 19:46:56 | binaryatrocity_: | binaryatrocity_ is now known as binaryatrocity |
| 19:59:42 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
| 21:41:26 | waxwing__: | waxwing__ is now known as waxwing |
| 22:21:25 | luny`: | luny` is now known as luny |
| 22:29:58 | kanzure: | http://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/ |
| 23:05:10 | bsm117532_: | bsm117532_ is now known as bsm117532 |
| 23:38:42 | andytoshi: | gmaxwell: adam3us1: can you guys think of a technical security definition for DMMS that doesn't outright exclude PoS? |
| 23:39:43 | andytoshi: | i think this "creating a block is super easy for the signers (who change each block) but impossible for everyone else" idea actually doesn't fit under the same umbrella as bitcoin's "every block is equally hard to make for all parties", but i'd like to be wrong for didactic reasons |
| 23:54:36 | nsh: | hmm |
| 23:55:49 | andytoshi: | like, i've heard it said (at least in my own thoughts) that "pos is a broken dmms" but i think the mechanism that it tries to produce consensus by is conceptually totally independent of dmms |
| 23:56:52 | c0rw|away: | c0rw|away is now known as c0rw1n |