03:04:59 | zooko: | When's the next time and place that Bitcoin core devs are going to congregate at? I want to go there then. |
03:11:34 | kanzure: | i believe they rotate irc channels every 5 minutes. it's hard to keep up. |
03:13:49 | TrollsRoyce: | lol |
03:16:39 | kanzure: | but you can figure out which channels by referring to your super secret decoder ring.. |
03:34:40 | gmaxwell: | zooko: I think we'll all be at FC2015. Other than that, pieter and I are in mtv at the moment. |
03:34:46 | BlueMatt: | zooko: I think that has only ever happened at foundation-sponsored bitcoin conferences |
03:34:51 | BlueMatt: | that, and fc15 |
03:35:24 | zooko: | gmaxwell: What are you doing in mtv? |
03:35:33 | gmaxwell: | I live here. Sipa is visiting. |
03:35:51 | zooko: | Oh yeah. :-) |
03:35:52 | Luke-Jr: | BlueMatt: he didn't say *all* <.< |
03:35:55 | gmaxwell: | (so have lots of bitcoin people recently for various reasons) |
03:36:03 | BlueMatt: | * BlueMatt lives in the city, fwiw |
03:36:51 | gmaxwell: | Probably 95% of the lines of traffic from this channel have been in the bay area at one point or another in the last month or so. |
03:39:44 | gmaxwell: | lets see recent bitcoin technical people from this channel/#bitcoin-dev I've seen in person, myself, pieter, jtimon, petertodd, maaku, adam3us, andytoshi, phantomcircuit, Luke-Jr, gavin, BlueMatt, gwillen, devrandom, plus some additional people I know less well. |
03:40:30 | BlueMatt: | thanks for tagging /everyone/ |
03:40:33 | Luke-Jr: | lol |
03:40:34 | gmaxwell: | hah |
03:40:52 | Luke-Jr: | gmaxwell: does a day go by that you don't see yourself? |
03:41:11 | gmaxwell: | probably. |
03:41:16 | BlueMatt: | Luke-Jr: mirror could be dirty... |
03:41:28 | Luke-Jr: | BlueMatt: doesn't have to be his head |
03:41:29 | gmaxwell: | may not make it as far as a mirror. |
03:41:46 | Luke-Jr: | hard to avoid seeing ones hands |
03:42:47 | sipa: | i don't think all people with bitcoin commit rights have ever been in one place together since 2011 |
03:43:16 | BlueMatt: | ams conference, no? |
03:43:24 | sipa: | gmaxwell was not there |
03:43:30 | BlueMatt: | ahh |
03:43:42 | gmaxwell: | everyone with commit access has never been in one room. |
03:43:43 | sipa: | and wumpus wasn't in san jose 2013 |
03:43:57 | gmaxwell: | AFAIK, unless it happened once before I did. |
03:43:57 | BlueMatt: | gmaxwell: when it was only satoshi..... |
03:44:09 | gmaxwell: | well sure, but not long after. |
03:44:16 | sipa: | or when it was just jeff gavin and tcatm |
04:01:37 | zooko: | gmaxwell: so the answer seems to be that "hang out at gmaxwell's house". |
04:05:35 | gmaxwell: | or in the area, at least. I've been conciously playing a bit of a social butterfly and bringing people togeather when they were in proximity. |
04:07:57 | zooko: | Nice. Good for you. |
04:08:01 | zooko: | How long is sipa staying? |
04:08:28 | sipa: | let's ask him |
04:08:58 | sipa: | october 24th |
04:09:32 | zooko: | Hi there. :-) |
04:10:09 | sipa: | hi! |
12:47:22 | 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 |
12:47:22 | tepper.freenode.net: | Users on #bitcoin-wizards: andy-logbot Aquent_ zooko Starduster pen adam3us phantomcircuit lysobit Luke-Jr Krellan p15 SDCDev rdponticelli hearn waxwing torsthaldo gloriusAgain CoinMuncher emsid mkarrer c0rw1n rfreeman_w cbeams OX3 AaronvanW HaltingState justanotheruser AlSzacrel vmatekol_ ubuntu_ austinhill TheSeven tacotime TrollsRoyce jchp Dr-G2 mortale espes__ digitalmagus Adlai devrandom Graftec wiretapped jgarzik Nightwolf copumpkin spinza dansmith_btc Happzz |
12:47:22 | tepper.freenode.net: | Users on #bitcoin-wizards: Fistful_of_coins artifexd _2539 michagogo lnovy tromp bbrittain weex gribble nanotube a5m0 irc88 EasyAt_ Transisto grishnakh__ altoz Kretchfoop Emcy jaekwon CryptOprah Muis samson_ Hunger-- wizkid057 nuke1989 BrainOverfl0w Sangheili artilectinc Guest42039 aburan28 wumpus jrayhawk_ jasx zwischenzug shesek firepacket dgenr8 arowser go1111111 zenojis LarsLarsen BigBitz Adohgg drawingthesun berndj [d__d] jcorgan yoleaux Iriez hollandais hguux |
12:47:22 | tepper.freenode.net: | Users on #bitcoin-wizards: livegnik stonecoldpat Dyaheon MRL-Relay mappum jbenet [Derek] zibbo_ kanzure petertodd optimator [\\\] warren pi07r K1773R Eliel HM gmaxwell amiller_ crescendo cfields btc_ kgk bobke iddo comboy NikolaiToryzin coryfields LaptopZZ Meeh poggy_ UukGoblin danneu catcow TD-Linux [Tristan] helo smooth otoburb gwillen ryan-c mmozeiko roasbeef pajarillo sl01 Keefe Gnosis ahmed_vegas Logicwax so epscy BlueMatt starsoccer midnightmagic Graet kinlo |
12:47:22 | tepper.freenode.net: | Users on #bitcoin-wizards: pigeons lianj Apocalyptic mr_burdell fluffypony SomeoneWeird forrestv Anduck Taek42 sipa [nsh] DoctorBTC harrow throughnothing Alanius abc56889 lechuga_ burcin phedny @ChanServ asoltys |
13:10:26 | Aquent_: | Aquent_ is now known as Aquent |
13:30:43 | Guyver2: | Guyver2 has left #bitcoin-wizards |
13:40:19 | onefox: | hello |
13:40:41 | onefox: | has someone here expierens with micropayment channels ? |
13:46:49 | hearn: | hey |
13:46:50 | hearn: | yeah |
13:46:53 | hearn: | what's the question? |
13:50:59 | hearn: | onefox: poke |
13:51:31 | onefox: | ah sry in bitcoinj |
13:51:36 | onefox: | the nLockTime is set to one day but can i make it shorter, like 2 hours or so ? |
13:52:18 | onefox: | the time if a channel is not closed by the server and the client want his funds back |
13:52:31 | onefox: | https://bitcoinj.github.io/working-with-micropayments |
13:54:42 | hearn: | yes it is configurable these days |
13:54:42 | hearn: | probably i need to update the docs |
13:57:11 | onefox: | great, and if i start this channle and the server is vanished will the client get the hole funds back or only the remaing and the other will as in the channle definited to the server ? |
13:59:21 | Taek42: | onefox using a time period of 2 hours would not be a good idea, because block times can vary a lot |
13:59:46 | hearn: | onefox: i think the docs go into this |
14:00:15 | hearn: | onefox: the client will get all the funds in the channel back if the server disappears. obviously this is supposed to be a rare event, which is why 24 hours is the default. |
14:00:50 | hearn: | onefox: the implementation imposes a minimum and i think 2 hours may be it. but it may be higher, i forgot. |
14:01:23 | onefox: | ah okey its also on the servers concern that he close the channel so he can get his part of the funds |
14:01:31 | onefox: | i guess ^^ |
14:02:30 | hearn: | yeah |
14:02:30 | hearn: | exactly. |
14:02:46 | hearn: | the server really really wants to close the channel properly. the refunds are there in case something goes wrong, that's all. |
14:02:59 | onefox: | i assume that the 2 hours can only be reduced if the block time is small like in dogecoin for example. |
14:03:12 | onefox: | or in other altcoins |
14:03:21 | hearn: | i don't know. i've never thought about that case. btw bitcoinj has a #bitcoinj irc channel if you want to discuss the details of the code there |
14:03:26 | hearn: | this channel is more meant for research |
14:04:02 | onefox: | yes i was there but i didn't got a responce in 3 hours .. so i checked some more channels out ;) |
14:04:12 | onefox: | bitcoindev pointed me here |
14:04:43 | hearn: | oh, you were? |
14:04:43 | hearn: | well normally i'm around there on weekdays CET |
14:04:44 | hearn: | usually from around noon onwards |
14:05:00 | hearn: | let's move this discussion there |
14:40:56 | amtri: | kur |
14:41:01 | Happzz: | Happzz has left #bitcoin-wizards |
15:41:58 | kanzure: | .to brisque is there a document that has a list of inaccuracies in that unmentionable book? |
15:41:58 | yoleaux: | kanzure: I'll pass your message to brisque. |
16:57:30 | Aquent: | Aquent is now known as bullwhale |
17:35:49 | bullwhale: | bullwhale is now known as Aquent |
18:01:34 | gwillen: | gwillen is now known as Guest11330 |
18:18:18 | Guest11330: | Guest11330 is now known as gwillen |
18:54:25 | skyraider7: | skyraider7 has left #bitcoin-wizards |
19:40:38 | justanotheruser: | justanotheruser is now known as midoriseki |
19:40:50 | midoriseki: | midoriseki is now known as justanotheruser |
20:02:09 | phantomcircuit: | anybody have an opinion on bitgo? |
20:04:22 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
20:04:30 | hearn: | it seems to have been reasonably well designed, but i only ever spent five mins playing with it. the guy who created it is an ex googler, one of the guys behind spdy |
20:05:53 | Emcy: | wassat |
20:06:04 | phantomcircuit: | Emcy, multisig wallet |
20:06:20 | phantomcircuit: | appear to be pushing to outsource policy enforcement essentially |
20:06:41 | Emcy: | ??? |
20:09:26 | phantomcircuit: | Emcy, 2/3 multisig |
20:09:30 | phantomcircuit: | they have a key |
20:09:35 | phantomcircuit: | you have a key and a backup key |
20:09:47 | phantomcircuit: | they have policy rules for their key to sign |
20:10:07 | Emcy: | such as |
20:10:07 | phantomcircuit: | a genuinely interesting project |
20:10:36 | phantomcircuit: | Emcy, business logic stuff like daily limits |
20:11:00 | hearn: | they can also do 2-factor via sms iirc |
20:11:05 | hearn: | there are a few projects like that out there now |
20:11:14 | hearn: | it makes a ton of sense. sort of half way between just a password and a trezor |
20:11:35 | Emcy: | at least someone is doing something with multisig |
20:12:13 | phantomcircuit: | hearn, it's better than a trezor for a business since you can push (some) of the business logic there |
20:12:15 | hearn: | there are people doing things with multisig |
20:12:22 | hearn: | phantomcircuit: right for online systems, yes |
20:12:28 | phantomcircuit: | otherwise you're just hoping your controller isn't stealing |
21:20:40 | ucerron: | is it possible to build a sidechain with colored coins? |
21:27:39 | Luke-Jr: | ucerron: yes |
21:27:55 | ucerron: | are there any implementations out there already? |
21:28:08 | Luke-Jr: | assuming you mean sidechain that has coloured coins, not creating a sidechain out of coloured coin constructs |
21:28:18 | Luke-Jr: | ucerron: there are no implementations of sidechains at all yet |
21:28:40 | ucerron: | what about treechains? |
21:29:01 | Luke-Jr: | you'd have to ask petertodd on that, I think |
21:29:08 | Luke-Jr: | AFAIK he's the only one working on those |
21:29:15 | ucerron: | viacoin right? |
21:29:23 | Luke-Jr: | that would be getting off-topic |
21:40:21 | Taek42: | I could be wrong, but I'm pretty sure that tree chains aren't very close to being implemented |
22:35:18 | Taek42: | https://bitcointalk.org/index.php?topic=817991.0 |
22:36:02 | Taek42: | tried to design a system where not every node needs to see every transaction, yet you can still make reasonable assumptions about network security if you can assume that the majority of hashing power on the network is honest |
22:45:18 | Luke-Jr: | Taek42: it seems to be built on some false premises |
22:46:57 | Luke-Jr: | Taek42: also, excluding transactions from your blocks is not dishonest |
22:47:04 | Taek42: | hmm. which ones? |
22:48:20 | Luke-Jr: | "To preserve security, child blockchains are randomly assembled from nodes, and each node is placed in exactly one child blockchain." <-- consensus systems cannot have random |
22:49:42 | Taek42: | oh. I should discuss that more then. |
22:50:01 | Taek42: | "Random" is achieved by taking the hash of the previous root block |
22:50:03 | Luke-Jr: | Taek42: I don't see how this helps scale at all |
22:50:24 | Luke-Jr: | Taek42: the hash isn't random; miners can withhold blocks with hashes they dislike |
22:50:31 | Taek42: | It's possible to manipulate that random number, but it's expensive |
22:50:32 | Luke-Jr: | and I'm not sure this system disincentivises that |
22:51:40 | Taek42: | yeah the incentive model needs to be fleshed out a bit more thoroughly as wel. It's possible that it doesn't fully disincentivize block withholding |
22:52:22 | Luke-Jr: | Taek42: anyhow, with this, every node needs to watch every child blockchain for their transactions |
22:52:34 | Luke-Jr: | and to know if those blocks are valid, they need to check every transaction in them |
22:52:42 | Luke-Jr: | otherwise they're trusting the miners |
22:52:58 | Taek42: | They only need to check the child nodes that have transactions they are interested in |
22:53:07 | Taek42: | not all of them |
23:00:38 | sipa: | how do they know that the inputs in those child nodes themselves are valid? |
23:00:48 | sipa: | by recursing further? |
23:05:47 | Taek42: | Everyone has a complete copy of the root blockchain, which is used to define who gets to mine on child blockchains |
23:06:12 | sipa: | you're not answering my question |
23:06:18 | Taek42: | child blockchains could potentially be completely internal ecosystems, not ever trading externally |
23:06:22 | Taek42: | *getting there |
23:06:50 | Taek42: | if you did want them to trade externally, you'd probably do it through the root blockchain |
23:07:04 | Taek42: | which means you would end up with with 'black' inputs, inputs that you never verify |
23:07:36 | Taek42: | but because hosts are randomly scattered throughout the network, you can believe that the inputs are honest |
23:07:52 | Taek42: | *as long as you believe that the majority of the hashing power is honest, which you can't necessarily verify |
23:08:49 | sipa: | that sounds a lot like sidechains :) |
23:10:13 | Taek42: | yeah I guess they are a lot more similar than I originally realized |
23:10:57 | sipa: | the hardest part is how to prove to the root chain that the transfers within one of the child chains were done correctly |
23:11:15 | sipa: | because if the root chain has to validate all child chains to assure itself of that, you have not gained anything |
23:12:10 | Taek42: | well, the idea is that you don't prove it at all. Instead you just rely on your random dispersion of hosts, and that a dishonest child blockchain will eventually be overtaken by an honest fork |
23:12:34 | Taek42: | Not being 100% sure is a sacrifice that you have to make if you want the scaling property |
23:12:43 | Taek42: | at least, as far as I understand |
23:13:00 | Taek42: | But I would argue that being 99.999999% sure is good enough |
23:13:30 | Taek42: | Especially if you are 100% sure about your own personal childchain that you watch. |
23:16:19 | sipa: | 'eventually' is not enough |
23:16:38 | sipa: | you need to have that assurance before you accept a ttransfer from a childchain to the root chain |
23:16:52 | sipa: | or risk inflation of your currency |
23:17:48 | Taek42: | well, if you know that there are 21 million total coins, and you know that each child blockchain has X or Y, you never let the child spend more than their aggregate sum |
23:18:13 | Taek42: | so the worst thing that happens is some child builds a dishonest blockchain as the longest fork and it doesn't turn around for a very long time |
23:18:41 | Taek42: | this is sounding increasingly like sidechains though :P |
23:23:10 | Taek42: | I guess the static consensus part though would make it significantly different |
23:42:14 | manaka: | https://www.reddit.com/r/Bitcoin/comments/2is4us/whats_wrong_with_counterparty/ in this post vitalik says colorecoins p2ptrade has no way of enforcing orders. i 'm not sure what he means |
23:45:25 | kanzure: | protocol can't force bitcoin spends. so there's some "escrow period" after which if the transaction was never made, the other side of the transaction gets reverted. |
23:46:07 | kanzure: | s/reverted/de-escrowed |
23:50:58 | manaka: | the escrow period gives a chance for all nodes to communicate. otherwise double spending could occur correct? |