| 00:06:18 | sirius_: | sirius_ is now known as sirius-m |
| 01:20:00 | phantomcircuit: | gmaxwell, well isn't that fun |
| 01:25:18 | jgarzik: | gmaxwell, shit |
| 01:25:30 | jgarzik: | gmaxwell, me & gavin have admin on SF. and the mailing lists, as you mention. |
| 01:25:52 | gmaxwell: | not anymore. :P |
| 01:31:28 | jgarzik: | gmaxwell, gavinandresen: bitcoin-security archives are now public |
| 01:38:51 | gmaxwell: | jgarzik: yep, was mentioned in #bitcoin-dev a few hours ago. |
| 01:39:10 | gmaxwell: | I made the comment that it vindicated the decision to keep some things in gpg email vs the list. |
| 01:43:55 | jgarzik: | gmaxwell, Well sure. I just figured that was standard logic anyway. Even closed lists leak. Just degrees of risk. |
| 01:43:55 | gmaxwell: | yep |
| 01:43:55 | jgarzik: | Fedora & kernel do the same |
| 01:46:03 | phantomcircuit: | gmaxwell, is it actually public or just theoretically public? |
| 01:46:30 | gmaxwell: | you can follow the links and read the archive. |
| 01:46:34 | mr_burdell: | looks public to me |
| 01:49:44 | phantomcircuit: | oh i see |
| 03:07:30 | andytoshi: | fyi i think the "tweaked ecdsa" i was looking for is (r, s), r = g^k s = k^-1(H^2 + (H + r)x) |
| 03:09:19 | andytoshi: | that is basically a totally new signature so i can't say anything about its security (especially with its cousin ecdsa having no concrete notion of security) but i believe it is secure against single reuse of k values |
| 03:13:46 | gmaxwell: | H is the message? x is the private key? |
| 03:14:18 | gmaxwell: | "quadratic DSA" |
| 03:28:07 | andytoshi: | gmaxwell: yup |
| 03:28:14 | andytoshi: | on all counts |
| 03:29:12 | andytoshi: | the hope is i can adapt these techniques to brent's thing ... which does have a security proof that i can adapt ... and maybe generalize it. atm purely an academic game :) |
| 03:30:44 | gmaxwell: | good game mentally, though It's not obvious to me what it would be useful for. |
| 03:34:16 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 03:39:50 | Pan0ram1x: | Pan0ram1x is now known as Guest14609 |
| 03:40:47 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
| 03:44:12 | quackgyver_: | quackgyver_ is now known as quackgyver |
| 03:57:53 | andytoshi: | i think, brent wants a way to parameterize "how careless you can be" with your nonces |
| 03:58:02 | andytoshi: | or more directly, i think he's just testing me |
| 03:59:46 | gmaxwell: | hashcash regulated email |
| 04:45:37 | Taek42: | not sure if there is a better channel for this, but does anyone want to help me understand Byzantine Paxos/pbft? There are a few steps I'm confused about. |
| 05:03:15 | jgarzik: | paxos isn't often discussed here. dunno why. |
| 05:03:56 | gmaxwell: | gmaxwell is now known as Guest35992 |
| 05:04:24 | Taek42: | probably because Bitcoin consensus has little to do with paxos |
| 05:04:49 | Taek42: | I only came here because I'm not sure where else one would look for help in understanding something like paxos |
| 05:04:55 | Guest35992: | yea, we care about consensus in a different model. |
| 05:05:35 | Guest35992: | damnit |
| 05:06:04 | Guest35992: | well nickserv won't give me my name back, in any case. I've since swapped out all paxos, but perhaps if you ask your questions and idle around it'll pique someone's interest. |
| 05:06:28 | Taek42: | The filecoin.io dev thinks he can build consensus out of pbft. I don't understand it well enough to discredit the idea, but it doesn't seem like a reasonable goal |
| 05:07:53 | Guest35992: | there are many tools to build a consenus, but _decentarlized consensus_ -- where there is no party admitting members (otherwise, "he who controlls the voting roles controls the vote") is kind of a specialized beast. |
| 05:08:35 | Guest35992: | (a provably impossible beast, unless you adopt special assumptions) |
| 05:09:08 | Taek42: | I think the idea is that if you can force nodes/voters to do proof-of-storage on some volume of data, then you can have a decentralized gateway that is safe from attack |
| 05:09:27 | Taek42: | as long as you keep forcing them to do proof-of-storage during each voting round |
| 05:12:49 | Taek42: | my question is, if you have 10,000 voters doing pbft, what happens to your message volume and overhead? Is it reasonable to assume that 10,000 decentralized servers (with a full 1/3 dishonest/malicious nodes) could perform pbft? |
| 05:15:31 | Guest35992: | Say I store all the data (to avoid having to talk about unsoundness related to a particular "proof of storage" approach), what prevents me from minting a trillion identites and overwhelming any classical consensus security model robustness assumptions? |
| 05:16:03 | Guest35992: | Taek42: my vague recollection is that byzantine paxos was quadratic with a big constant factor too. |
| 05:16:34 | Taek42: | If you've got all of the data, I don't think anything would stop you from doing a wholesale sybil attack. |
| 05:18:03 | Taek42: | One option (switching away from how filecoin works) would be to give each piece of data to one machine/identity, and use erasure coding to defend against things going offline |
| 05:18:16 | Taek42: | once all of the data has been passed out, nobody else is allowed to join until there's more data |
| 05:18:56 | Guest35992: | right, but the proofs themselves leak data, not to mention retrevial. |
| 05:19:28 | Taek42: | why is leaking data a problem? |
| 05:19:42 | Taek42: | (assuming it's encrypted anyway) |
| 05:19:43 | Guest35992: | lets you obtain all of it so you can do the admissions attacks. |
| 05:19:48 | Guest35992: | (or insertion). I don't think any of these things have even tried to tender a defense against the CSPRNG attack. |
| 05:20:20 | Guest35992: | (CSPRNG attack is where an attacker stores a lot of data in the system, the data appears random but is just an encrypted counter... so they have greatly reduced cost for 'storing' it) |
| 05:21:02 | Taek42: | okay so bear with me for a moment while I build this up. I think I have a good solution but it'll take a bit to explain |
| 05:21:39 | Taek42: | So, data is delegated, in the sense that when you join the network, you're given an explicit set of data that you store |
| 05:21:59 | Taek42: | this data is randomly chosen from around the network, shuffling hosts data as needed to preserve the randomness property |
| 05:22:29 | Taek42: | since you don't control the data you are storing, your effectiveness with a CSPRNG attack is reduced |
| 05:22:58 | Taek42: | furthermore, data is expensive to keep on the network. So creating a ton of data isn't going to fly because you're going to need to pay everyone who's storing the data at full cost |
| 05:23:46 | Guest35992: | So? byzantine. :) |
| 05:24:12 | Taek42: | what do you mean by that? |
| 05:24:58 | Guest35992: | The attacker will do something which is mildly costly to break the system. A byzantine attacker is not rational, they're not only going to attack in ways that are directly profitable. |
| 05:25:06 | Guest35992: | Guest35992 is now known as gmaxwell |
| 05:26:05 | Taek42: | yeah I guess you'd need to prove that the cost of a CSPRNG attack is unreasonable - an attacker would not be able to sustain the cost for long enough to complete the sybil attack |
| 05:26:13 | Taek42: | that might be harder |
| 05:26:15 | gmaxwell: | in any case. Why are you not able to grind your location? if you don't like your location. Try again. Also, if your goal was to store all the data, ISTM that your location isn't relevant in terms of making sure you're storing your easily stored data. |
| 05:26:48 | gmaxwell: | Exactly, wrt what the bar should be for using an economic defense. :) |
| 05:27:44 | Taek42: | preventing location grinding: |
| 05:28:02 | Taek42: | whenever you join the network you introduce extra turbulence |
| 05:28:17 | Taek42: | so, you pop into a random place, but you also pop other nodes into random places |
| 05:28:59 | Taek42: | you can set a turbulence bound to insure that by joining the network, you are popping your own nodes into storing different data just as fast as you are getting your nodes to store your preferred data |
| 05:29:21 | gmaxwell: | well obviously everyone can't completely change positions when you join, or you can create enormous bandwidth by just joining a lot. :) |
| 05:29:37 | Taek42: | well yes that's an additional problem |
| 05:29:59 | gmaxwell: | yea, if you can assume things like the whole topo can be changed with every operation, I feel like that might have interesting properties. |
| 05:30:04 | gmaxwell: | Are you familar with path-oram? |
| 05:30:20 | Taek42: | potentially solved by forcing an attacker to pay for the bandwidth burden they introduce to the network |
| 05:30:34 | Taek42: | the logic being that it doesn't matter how big the burden is if the attacker is willing to pay for it |
| 05:30:44 | Taek42: | the downside being that now non-attackers also have to pay that burden |
| 05:31:03 | Taek42: | I am not familiar with path-oram |
| 05:31:06 | gmaxwell: | 'pay' keep in mind if you're talking about pay within the system payment for the system doesn't really have meaning.. (e.g. why you can't replace mining with burning bitcoin without huge problems) |
| 05:31:54 | Taek42: | ^ I'm not sure what you mean by that |
| 05:32:48 | gmaxwell: | Ah, I'd come up with a design a while back that retrospectively I thought would be robsust in many ways that most of the fad file stuff isn't... though perhaps with undesirable performance. The core of the idea was to use active secure multiparty computation to do all the reads and writes, and use path-oram to store the data. So that none of the partipants would have any knoweldge about what was being stored or retrieved. (you can ... |
| 05:32:54 | gmaxwell: | ... google path oram) |
| 05:34:03 | gmaxwell: | Taek42: if you have a consensus system, you usually cannot pay for it using the thing its consensus-ing over... you end up with a cyclic relationship. Things like I can make a shadow network and 'pay' in both the shadow network and the real one... so the scarce resource was not really scarce at all. |
| 05:34:27 | gmaxwell: | because the scarceness was just a product of the consensus, which I'm in the process of screwing up. |
| 05:36:00 | Taek42: | hmm. If we assume that you haven't yet screwed up consensus though, and that you need to pay-in-advance, then at least you need to aquire some volume of the resource to complete your attack |
| 05:36:15 | Taek42: | if you succeed it really won't matter, but it's at least a barrirer |
| 05:36:34 | Taek42: | but I see the point |
| 05:38:14 | Taek42: | If you have a large file based cryptocurrency, could you reasonably establish that no attacker would be able to store a large percent of it? |
| 05:38:34 | Taek42: | large meaning >50% |
| 05:48:15 | gmaxwell: | storage isn't like power costs, it amoritizes well.. also has nicer 'volume' scaling (think enormous tape libraries. :P). So maybe. (but the CSPRNG attack would potentially frustrate an effort at a security proof there) |
| 05:49:49 | Taek42: | yeah. I don't think I've given the CSPRNG attack enough thought, especially when I don't have a proper economic ceiling for storing the data. |
| 05:53:25 | Taek42: | you could probably reduce the risk by setting a limit on network growth, say doubling every 3 months or something |
| 05:56:46 | gmaxwell: | well if the system is to be sybil secure, you should be thinking about patterns like "you are a newcomer to the network, and two peers present very different views of the network to you. How do you decide between them". E.g. "limit on growth" may fail in that model, since an attacker will just simulate a different history. |
| 05:59:47 | Taek42: | presumably you'd have some trusted source giving you the current state of the network, where trusted is some combination of authorities using the network like exchanges. That's definitely less secure though than something like Bitcoin, where you just calculate depth |
| 06:01:59 | Taek42: | are there other solutions in literature to the newcomer problem? |
| 06:06:19 | gmaxwell: | no, generally this is provably unsolvable! |
| 06:06:30 | kanzure: | if you are okay with trusting sources then why bother with everything else in the first place? |
| 06:06:45 | kanzure: | your problem just became 1000x easier and more possible |
| 06:06:45 | gmaxwell: | and yea, what kanzure said. :) |
| 06:07:03 | gmaxwell: | and also boring, but on the other hand your performance and security are much better in that model. |
| 06:07:22 | gmaxwell: | (part of the reason that bitcoin is so remarkable, and also was dismissed by so many people for so long...) |
| 06:15:21 | Dr-G2: | Dr-G2 is now known as Dr-G |
| 06:20:05 | Taek42: | newcomer solution: |
| 06:20:38 | Taek42: | you have some universally known 'starting point', containing a network and a set of nodes with public keys |
| 06:20:57 | sirius-m: | sirius-m has left #bitcoin-wizards |
| 06:21:06 | Taek42: | you assume that some proportion (perhaps a majority) are honest and will never turn dishonest |
| 06:21:20 | gmaxwell: | then just have them keep the complete ledger too (E.g. n of m of them) |
| 06:21:51 | Taek42: | each time the network reconfigures, the nodes sign off on the new configuration, the majority wins |
| 06:21:57 | gmaxwell: | the system is federated, but ultimately dependant on trusting a quourum of those guys. (presumably 1/2+1 since you likely can't do better if you care about holdup) |
| 06:22:11 | Taek42: | if some node signs off on two configurations, all votes are discounted |
| 06:22:21 | Taek42: | you don't need this original set to stick around |
| 06:22:31 | Taek42: | you just need to be aware of what the original set was |
| 06:23:03 | Taek42: | then, when presented with a series of reconfigurations, you can always pick out the honest configuration by the one with the most signatures (assuming that you receive the honest configuration, which is also a requirement of Bitcoin) |
| 06:23:30 | kanzure: | no |
| 06:23:41 | Taek42: | where's the problem? |
| 06:26:36 | gmaxwell: | Taek42: if the original group ever becomes dishonest (e.g. lose control of their keys once they're long worthless) tada, an alternative history can arise. |
| 06:29:30 | Taek42: | is that the only issue? Assuming 'universally known' is fair, because even in Bitcoin, the protocol itself has to be 'known'. |
| 06:30:50 | Taek42: | You can reduce the risk of the original group being able to create alternative histories by updating the universally known set as the network grows, similar to BIPs. |
| 06:31:31 | Taek42: | there's always a risk that the most recent snapshot will corrupt, but it's a lot better than needing to ask a set of trusted sources for the current network state |
| 06:31:32 | gmaxwell: | 'known' but it's transparent (with assumptions about software/math being reviewable) there is no hidden honesty variable. |
| 06:31:44 | gmaxwell: | and software can't change its hidden honest variable out from under you in the future. |
| 06:32:09 | Taek42: | yeah, makes sense |
| 06:32:58 | gmaxwell: | if you 'update' that step you need some centeralized process to tell you that its the right one. WRT bips' they've never changed the network in an incompatible way. The very first release of bitcoin should, more or less sync the whole blockchain if presented it... though it'll be insanely slow and prone to getting stuck due to bugs at larger scale. |
| 06:44:55 | Taek42: | I realized that using a starting point has a branching-history vulnerability anyway. Say you have a secure starting point, and then two signed reconfigurations. One has 2 signatures and the other only has 1 signature. So the network follows the history with 2 signatures. But then, at a later date, the 2 keys corrupt, and they sign some alternate route and present that to newcomers. Now newcomers will reject the history chosen by |
| 06:44:55 | Taek42: | the network, because the 2 keys are guilty of signing multiple paths |
| 12:12:47 | morgan.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:12:47 | morgan.freenode.net: | Users on #bitcoin-wizards: andy-logbot 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_ jbenet davidlatapie rs0 nanotube bbrittain SomeoneWeird lechuga_ abc56889 Iriez weex sl01 digitalmagus7 BlueMatt berndj-blackout asoltys Guest50253 mmozeiko epscy crescendo helo zling_____ Anduck LarsLarsen1 maaku CodeShark midnightmagic |
| 12:12:47 | morgan.freenode.net: | Users on #bitcoin-wizards: bobke [\\\] cfields pigeons K1773R harrow forrestv fierbuq tromp_ zibbo Hunger- azariah4 Fistful_of_coins artifexd Muis warren michagogo smooth Keefe jgarzik btc DoctorBTC CryptOprah_ postpre realzies otoburb HM_ BrainOverfl0w nuke1989 gwillen phantomcircuit Starduster BigBitz EasyAt spinza kanzure starsoccer Graftec nickler mr_burdell Adohgg sipa Graet grandmaster2 ryan-c grubles Eliel Emcy pi07r wiretapped jaromil grishnakh__ koshii altoz |
| 12:12:47 | morgan.freenode.net: | Users on #bitcoin-wizards: tromp samson_ Dyaheon espes__ SDCDev tacotime oujh roasbeef Transisto Logicwax go1111111 drawingthesun torsthaldo dgenr8 copumpkin Meeh Dr-G Aquent OneFixt_ quackgyver jaekwon1 xenogis Luke-Jr [7] Guest14609 HaltingState waxwing Burrito Alanius throughnothing Krellan_ pen pajarillo jchp mappppum Taek42 gmaxwell mortale justanotheruser Ursium_ mkarrer Sangheili melvster rfreeman_w nsh- lclc ebfull AaronvanW CoinMuncher wallet42 devrandom comboy |
| 12:12:47 | morgan.freenode.net: | Users on #bitcoin-wizards: OX3 benten hearn Guyver2 tjopper adam3us tucenaber shesek [Derek] vfor kmels fanquake nsh |
| 12:12:47 | morgan.freenode.net: | [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp |
| 14:22:23 | drawingthesun: | drawingthesun has left #bitcoin-wizards |
| 14:35:49 | bsm117532: | So I've been tasked with creating an alt-coin, and I am loth to duplicate some of the jokers I've seen in the alt-coin world. Therefore I wonder what people might think of this proposal: |
| 14:36:07 | bsm117532: | What if we make a direct clone of bitcoin and maintain a private blockchain? This will allow me to follow and contribute to bitcoin while also contributing to this new coin. The coin, initially will not have any coinbase reward and the only nodes/miners will be run by the company issuing it. |
| 14:36:17 | bsm117532: | Its value will be pegged to BTC or some other asset like USD. Atsome point in the future we could choose to "release" the coin from its peg, add a coinbase reward, and recruit miners. |
| 14:36:27 | bsm117532: | By establishing a market for the coin first (while having a peg to BTC) we hope to avoid the speculation & pump/dump that plagues altcoins, since they have no inherent value. |
| 14:36:40 | bsm117532: | Thoughts? |
| 14:36:46 | andytoshi: | bsm117532: -wizards is not just crypto :) |
| 14:37:46 | bsm117532: | FWIW, I'm going to try to convince them to use BTC directly rather than issuing a coin. But if they disagree and they pay me to make a coin...I'll make a coin. :-/ |
| 14:38:11 | andytoshi: | so, it is more or less "obvious" how to maintain a private chain .. you probably want a different p2p architecture, should probably clean up the script system, etc ... so i'd not start with bitcoin |
| 14:38:14 | helo: | it sounds like you should just run a full node |
| 14:38:28 | andytoshi: | have you thougth about how to do this peg? |
| 14:38:39 | helo: | it's the only way you can have something that is pegged to bitcoin |
| 14:38:40 | bsm117532: | Yes, we'll run a full node and it will be private, not connecting to any other nodes. |
| 14:39:05 | bsm117532: | The coin will also not appear on exchanges. (initially -- unless peg was released) |
| 14:39:40 | bsm117532: | andytoshi: how to do the peg...seems simple to me, we're just using our blockchain as a ledger. But perhaps you have thoughts? |
| 14:39:40 | helo: | how will it differ meaningfully enough to incentivise people to trade their bitcoin for it? |
| 14:39:41 | andytoshi: | so you'd have a forked bitcoin blockchain? that's very dangerous, if any data crosses over it'll confuse the other chain |
| 14:39:45 | sipa: | first of all: why do you want your own coin, if it's intended to be pegged? |
| 14:40:08 | bsm117532: | andytoshi: data will not cross over. We will not connect to other nodes. |
| 14:40:21 | andytoshi: | and also seems like it'd require you to do PoW, which is very wasteful for a private chain |
| 14:40:42 | bsm117532: | Well one CPU churning PoW is not so bad. |
| 14:40:43 | andytoshi: | bsm117532: "we will prevent these networks from ever talking to each other" is not a security mechanism ;) |
| 14:41:05 | andytoshi: | esp if you want the private one to be accessible to anybody |
| 14:41:14 | bsm117532: | At the outset, this is fully centralized, and trusted. The goal is that at some point in the future we could release it as a crypto coin. Therefore it makes sense to start with a blockchain. |
| 14:41:28 | sipa: | you need no PoW in that case |
| 14:41:30 | helo: | regarding pegging, you'd essentially be issuing not-bitcoin at bitcoin prices. nobody will want to pay that much for not-bitcoin unless they are assured they can trade it back for bitcoin. |
| 14:41:37 | sipa: | just make sure that nobody can construct a block but you |
| 14:41:49 | bsm117532: | andytoshi: "networks not talking to each other" is not intended as a security mechanism. It's a totally separate blockchain and there is no reason for them to communicate. |
| 14:41:49 | andytoshi: | bsm117532: so, here is how to do pegging which has the same trust model you are describing |
| 14:42:07 | andytoshi: | bsm117532: create your separate blockchain using digital signatures from your bosses instead of PoW |
| 14:42:15 | bsm117532: | sipa: Yes, we could do away with PoW and just sign blocks centrally. |
| 14:42:17 | andytoshi: | bsm117532: have users of the altchain watch bitcoin |
| 14:42:44 | andytoshi: | bsm117532: if bitcoin users send coins to a multisig address owned by your bosses, this is a "transfer" and allows them to activate coins on the private chain |
| 14:43:04 | bsm117532: | helo: We would operate a centralized exchange (and hold reserves) and do the BTC<->other exchanging. It's BTC in all but name. |
| 14:43:09 | andytoshi: | bsm117532: to "transfer" back, they send the coin on the altchain to your bosses, and they sign a tx on bitcoin moving the coins there |
| 14:44:06 | andytoshi: | s/moving the coins there/moving the multisig-locked bitcoins to a bitcoin address owned by the user/ |
| 14:44:19 | helo: | that is a sensible approach andytoshi! |
| 14:44:26 | bsm117532: | andytoshi: That works. |
| 14:44:32 | helo: | bsm117532: but why would someone want your coin instead of bitcoin? |
| 14:44:57 | bsm117532: | Because it's a "rewards" coin. It's handed out like airmiles. So users will already have some. |
| 14:45:06 | andytoshi: | bsm117532: helo: note that the trust model is not very good ... the private chain operators can block transfers back to bitcoin, and they can censor txes on the altchain itself |
| 14:45:08 | sipa: | then why the pegging? |
| 14:45:12 | sipa: | and why a blockchain? |
| 14:45:16 | andytoshi: | but it's the same trust model as bsm117532 's original proposal ;) |
| 14:45:24 | bsm117532: | sipa: the pegging is to avoid speculator behavior of altcoins. |
| 14:45:45 | sipa: | but if it's pegged, why don't you just pay out bitcoin? |
| 14:45:48 | bsm117532: | sipa: a blockchain is so that at some point in the future, it could become an alt-coin with more legitimacy (and more transaction volume) than alt-coins have now. |
| 14:46:01 | bsm117532: | sipa: We could, and I'm going to argue that to the owners. But I may fail. |
| 14:46:12 | helo: | you're giving people free bitcoin by giving them the free rewards coin |
| 14:46:22 | helo: | they'll all cash it out immediately for bitcoin |
| 14:46:25 | bsm117532: | Well nothing is free. The money comes from somewhere. |
| 14:46:42 | sipa: | if it's pegged, and the altcoin has no actual technical advantages, you're much better off just giving out BTC |
| 14:46:53 | bsm117532: | helo: How many people know enough about bitcoin to do that? And if your reward is $3, how many people will bother? |
| 14:47:20 | helo: | a lot more than will know/bother with your coin ;) |
| 14:47:21 | bsm117532: | sipa: I kind of agree regarding using BTC instead, but that's a hard sell with the owners. They've got their hearts sold on a coin. |
| 14:47:59 | sipa: | if you unpeg it, it may become too valuable to use as a rewards mechanism (and become just a speculative coin itself), or too valueless and just not worth bothering with |
| 14:47:59 | gavinandresen: | bsm117532: be sure to get paid in advance. Not in their coin.... |
| 14:48:05 | bsm117532: | I have. :-P |
| 14:48:30 | sipa: | seriously, altcoins and pegging are useful, but only if you use them for useful things |
| 14:48:44 | sipa: | this just sounds like "we want our own coin!!!1111! such cool!!" |
| 14:48:55 | gavinandresen: | Then as long as you're ok with having a 'worked on a spectacularly unsuccessful project' on your resume…. meh |
| 14:50:01 | bsm117532: | gavinandresen: Hopefully a step to something successful. And if I can help them to be successful and not scammy, I'll do it. |
| 14:50:46 | bsm117532: | andytoshi: Regarding your description above, you said multi-sig. I assume a 2-of-2 multi-sig where one is our company and the other is the customer? |
| 14:51:10 | sipa: | bsm117532: you can't let the original sender of the coin participate in the multisig |
| 14:51:13 | bsm117532: | gavinandresen: Like I said, I'm going to lobby for BTC rewards instead. |
| 14:51:21 | bsm117532: | sipa: ok then why multi-sig at all? |
| 14:51:34 | sipa: | bsm117532: to not have a single trusted party - but a group of trusted parties |
| 14:51:41 | bsm117532: | Ok, sure... |
| 14:51:53 | sipa: | if you let the original sender participate, he gets to control who can move coins back |
| 14:51:54 | bsm117532: | Was just wondering if there was something deeper to that point. |
| 14:51:57 | sipa: | which makes no sense |
| 14:52:23 | bsm117532: | Yep. |
| 14:53:01 | bsm117532: | If we do this right, it could create a lot of users for BTC, and give BTC to a lot of new users who would then have to figure out how to spend it. |
| 14:53:17 | andytoshi: | bsm117532: no, all the multisig signers would be part of the private chain corp, as sipa says |
| 14:53:30 | bsm117532: | Yep, gotcha. |
| 14:53:30 | andytoshi: | but you'd want a few of them on separate system for redundancy/security |
| 14:53:40 | helo: | bsm117532: be sure to explain that nobody will trust your bosses compared to trusting bitcoin, so there is likely to be a vast majority of participants that just cash it out for bitcoin as soon as possible. so it will cost them the value in bitcoin, and the development cost of their coin that nobody may ever actually want. |
| 14:54:10 | helo: | as opposed to just costing them the value in bitcoin if they give bitcoin rewards |
| 14:54:26 | bsm117532: | helo: Yes we need to have that discussion too. "rewards points" are usually a form of vendor lock-in, and they're not thinking of it that way. |
| 14:55:26 | helo: | if there ever was a rumor that it was going to become unpegged, there would be a massive panic by everyone with rewardcoin (lets call it) and there would be a run on your bitcoin reserves |
| 14:55:53 | bsm117532: | That's fine, we'll hold full reserves. |
| 14:56:12 | sipa: | but will your customers trust you to hold full reserves? |
| 14:56:19 | sipa: | whether you do or not is not actually relevant |
| 14:56:30 | wallet421: | wallet421 is now known as wallet42 |
| 14:56:40 | bsm117532: | There is no way to do what they want to do without having a fairly centralized system. So yes, customers will have to trust. |
| 14:56:45 | helo: | then your users would be left with bitcoin, and you would be left with your worthless rewardcoin that nobody wants |
| 14:58:12 | bsm117532: | Doesn't matter if it's 1:1. |
| 15:02:12 | helo: | you won't find anyone that will give you bitcoin for the rewardcoin you have. at that point you would be out of bitcoin, and would have to buy more bitcoin to issue any more rewardcoin. |
| 15:02:59 | bsm117532: | rewardcoin is tied to a market, and certain things can only be bought with rewardcoin (or BTC). |
| 15:03:18 | bsm117532: | Gotta run but if anyone has further responses, I'll read them in an hour or two. Thanks! |
| 15:22:57 | Starduster_: | Starduster_ is now known as Starduster |
| 15:29:47 | Eliel: | bsm117532: ok, so they want to create an "airmiles" system where the airmiles ledger, while centralized, is public and has an open API. Meaning that third parties can easily interface with the system. Also, by the sound of it, it'll also be pseudonymous, like bitcoin. No user registration needed (although, you could trivially require that). |
| 15:31:03 | Eliel: | I suspect authorities will want to slam you with KYC/AML duties and responsibilities reasonably fast if it takes off. |
| 15:31:57 | Eliel: | and unlike bitcoin, they will apply to the entire system. (with bitcoin that's just plain impossible) |
| 15:34:04 | Eliel: | If you want to launch the thing as an altcoin, I suspect it'll have to happen before you're saddled with KYC/AML. Otherwise it could be seen as a breach of reponsibilities. |
| 15:40:19 | Eliel: | if you start with mostly decentralized altcoin from the beginning and only leave creating and destroying coins requiring centralized keys, preferably multisig. You can probably avoid that. |
| 15:41:47 | Eliel: | that's the only centralized feature you really need to peg the coin to bitcoin. the control of new coins. |
| 16:01:30 | Ursium: | Ursium has left #bitcoin-wizards |
| 16:10:09 | jgarzik: | gmaxwell, petertodd, I'm thinking about restarting https://github.com/jgarzik/dirc When I last touched the project, it was a fully functional single-node IRC server, intended to be a proxy for a "better layer" which provides encryption and auth |
| 16:10:29 | jgarzik: | time to add that layer, I think |
| 16:10:59 | jgarzik: | IRC is ultimately a shim, but one that gets everyone working ASAP |
| 16:11:29 | jgarzik: | One possible auth criteria is proving you have an unspent output, to join the network |
| 16:11:56 | jgarzik: | "control at least 0.1 BTC" to connect or somesuch |
| 16:30:33 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 17:05:16 | tjopper: | tjopper has left #bitcoin-wizards |
| 17:14:47 | Eliel: | jgarzik: bitcoin-only encrypted decentralized irc-network :D I somehow like the sound of that. |
| 17:44:17 | petertodd: | jgarzik: I think your choice of javascript makes you a bad person, incapable of love, but other than that sounds exciting! |
| 17:54:28 | bsm117532: | Eliel: thanks for your comments! For other reasons users will be authorized and identified (not pseudonymous) so we're planning on KYC/AML from the beginning. Crypto-anarchy, while nice, doesn't serve most business plans. :-/ |
| 17:55:06 | sipa: | bsm117532: so you need a central clearinghouse? |
| 17:55:27 | bsm117532: | Define central clearinghouse... |
| 17:55:34 | sipa: | to prevent authorized users from sending coins to unauthorized ones |
| 17:55:37 | bsm117532: | Users will be identified, and blocks signed by the company. |
| 17:55:58 | bsm117532: | Yes, then, there is a clearinghouse. |
| 17:56:10 | sipa: | right, the central miner |
| 17:56:30 | bsm117532: | Yes. Idea is that at some point in the future, some of these restrictions could be removed. |
| 17:56:50 | bsm117532: | But "printing money" as part of a business plan is not good for a lot of reasons... |
| 17:56:57 | bsm117532: | So I'm trying to find a reasonable way to handle this. |
| 18:01:29 | andytoshi: | if you use the signer-based peg mechanism and don't print any money, the business will be forced to lock a bunch of bitcoins beforehand to move them to the new chain |
| 18:01:37 | andytoshi: | then it is publically verifiable that they have the reserves |
| 18:02:29 | andytoshi: | well, "will be forced" is a bit strong, obviously as the central miner if they want to print money by having floating outputs, they can do it.. |
| 18:09:40 | Eliel: | I'm pretty sure it'd be quite a stupid move to print money in that kind of a system. Especially since it's possible to hold the reserve so it's publicly visible. |
| 18:51:18 | zackary-truthcoi: | There is a grow popularity in the idea that blockchains should be able to have secrets. |
| 18:51:20 | zackary-truthcoi: | Perhaps I don't understand the revelation principle right. It seems to me that blockchains without secrets are just as powerful as blockchains with secrets. |
| 18:51:22 | zackary-truthcoi: | http://en.wikipedia.org/wiki/Revelation_principle |
| 18:51:24 | zackary-truthcoi: | http://bitcoinmagazine.com/10055/cryptographic-code-obfuscation-decentralized-autonomous-organizations-huge-leap-forward/ |
| 19:07:12 | rdponticelli: | bsm117532: Somebody asked me a while ago for a system alike. After the little thought I gave at the matter, I was leaning to believe that a ripple like system was more apt to the task than a bitcoin alike one... |
| 19:08:38 | bsm117532: | rdponticelli: I'm not that familiar with Ripple. What are the relevant aspects you're thinking about there? |
| 19:09:45 | rdponticelli: | The matter is: everything has to be under the control of the issuers |
| 19:10:33 | rdponticelli: | So, bitcoin is a waste as is designed for decentralization and trustlessness |
| 19:11:33 | rdponticelli: | Ripple, instead is more centraliced, and would allow the issuers to issue a whole lot of units of accounts |
| 19:11:59 | rdponticelli: | The ledger doesn't require pow |
| 19:13:14 | rdponticelli: | But as I said, I give it a little thought, I'm more interested in bitcoin's properties |
| 19:15:52 | bsm117532: | Thanks rdponticelli, I'll take a look. (And Stellar too) |
| 19:42:19 | jgarzik: | rdponticelli, IMO there is room for a "managed coin" -- a crypto-currency whose money supply is provably managed by the central bank |
| 19:43:07 | bsm117532: | I think so too. |
| 19:43:24 | bsm117532: | Looking at Ripple, I'm not really sure what to do with it. It looks like a security nightmare waiting to happen. |
| 19:43:54 | bsm117532: | It doesn't use PoW but does have centralization, and a lot of wishy washy arguments about nodes not wanting to destabilize the network. |
| 19:44:11 | bsm117532: | That, and it's too small to have had any serious attacks. |
| 19:44:47 | bsm117532: | And it appears to have way worse scaling problems than BTC, despite a way faster consensus time. (maybe because of) |
| 19:45:16 | phantomcircuit: | rdponticelli, Ripple(tm) is a straight up con, a scam, a flim flam |
| 19:47:49 | rdponticelli: | Yeah, probably it's a scam, I was just saying that a system designed to reach consensus without pow was what was needed for that use case |
| 19:48:10 | phantomcircuit: | rdponticelli, nobody has yet produced such a system |
| 19:48:17 | phantomcircuit: | ripple has no consensus mechanism |
| 19:48:22 | phantomcircuit: | it has centralized validators |
| 19:48:30 | bsm117532: | phantomcircuit: can you outline an attack? |
| 19:48:39 | rdponticelli: | Which is was needed for bsm117532 use case |
| 19:49:12 | bsm117532: | Well, ripple has "centralized validators" outside the control of Ripple. Sooo.... |
| 19:49:33 | bsm117532: | It's only centralized by hopes and wishes and unicorns. |
| 19:49:38 | phantomcircuit: | bsm117532, no they do not |
| 19:49:41 | phantomcircuit: | they claim they do |
| 19:49:44 | phantomcircuit: | but they're lying |
| 19:49:46 | bsm117532: | I can run a Ripple node. |
| 19:49:55 | phantomcircuit: | no you cannot run a validator |
| 19:50:09 | phantomcircuit: | you can run a ripple centralized chain backup node |
| 19:50:21 | phantomcircuit: | but that has no effect on validation |
| 19:50:24 | bsm117532: | Then why would anyone run a node? |
| 19:50:33 | phantomcircuit: | because they think it's like a bitcoin node |
| 19:50:38 | phantomcircuit: | which is why ripple released them |
| 19:50:45 | phantomcircuit: | it's an intentional and malicious redirect |
| 19:50:50 | bsm117532: | So, trickery, since there is no mining? |
| 19:50:59 | sipa: | it does not guarantee consensus; it's just a decentralized system that will work as long as long nodes agree |
| 19:51:13 | maaku: | ah phantomcircuit, you are assuming they don't believe their own rhetoric |
| 19:51:33 | sipa: | i think they do believe it |
| 19:51:34 | bsm117532: | Most people in this space do believe their rhetoric. There is little correlation to being right. |
| 19:51:52 | phantomcircuit: | maaku, the people actually working on it might, the people who are in charge certainly do not |
| 19:52:30 | phantomcircuit: | maaku, im confident that it was from the start for the money people a straight up con |
| 19:57:24 | maaku: | ah yes well I shared a stage with chris larson at one point in time, where he tried to correct me that ripple was not a mechanism for issuing credit |
| 19:57:31 | maaku: | interpret that as you will |
| 19:57:33 | helo: | we promise, we thought we were doing a bitcoin! computers are hard, judge :( |
| 20:13:05 | rdponticelli: | IMHO, this use case, and the central bank one can do it with centraliced, trusted consensus. A distributed system implementing it would add nice properties like transparency and quick third party verification. |
| 20:19:18 | bsm117532: | Yes, if you have to accept centralization, do simple centralization, not this byzantine shit of Ripple, BitShares, etc. |
| 20:35:53 | wallet421: | wallet421 is now known as wallet42 |
| 20:56:51 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 21:48:11 | a5m0: | i'm assuming this is still relevant? http://www.reddit.com/r/Bitcoin/comments/27rsv8/confirmed_blockchaininfo_shared_coin_is_broken/ |
| 21:48:41 | a5m0: | i did a test on their wallet-api function that still has a "shared" option, set it to true and blockchain.info totally just ate the coins |
| 21:49:09 | a5m0: | so it seems like they're not actually running /anything/ that provides anything useful for coinmixing |
| 21:52:50 | grubles: | "and preferably not one tied to an inconvenient to use alt-coin." <- which altcoin is referred to here? |
| 22:09:15 | Luke-Jr: | a5m0: never was? |
| 22:09:51 | a5m0: | never was functional or never was relevant? |
| 22:52:17 | andytoshi: | a5m0: neither |
| 22:53:11 | andytoshi: | a5m0: bc.i is user-hostile, everything they control is automatically insecure and therefore uninteresting |
| 23:13:29 | andytoshi: | omfg https://bitcointalk.org/index.php?topic=776359 |
| 23:18:59 | phantomcircuit: | andytoshi, lol |