| 00:07:50 | maaku: | maaku is now known as Guest89882 |
| 04:55:14 | lecook: | anyone else excited about ethereum? |
| 05:09:58 | dsnrk: | no. |
| 05:12:22 | gmaxwell: | Maybe not squarely bitcoin related, but likely of interest to people here: https://en.bitcoin.it/wiki/User:Gmaxwell/visual_fingerprint_comparison |
| 05:18:13 | gmaxwell: | dsnrk: ^ you might find that interesting, I think you'd shared a link about how laughably awful the openssh picture thing is. I think this is substantially better in all the ways the ssh thing is bad. |
| 05:18:56 | Luke-Jr: | lecook: there's nothing exciting about ethereum |
| 05:19:26 | lecook: | really? |
| 05:20:05 | Luke-Jr: | gmaxwell: I think the openssh one is better. |
| 05:20:08 | lecook: | block time speed is lower, quasi turing complete states, not sure how their transactions fees are done. |
| 05:20:23 | dsnrk: | what does turing complete get you? |
| 05:20:44 | Luke-Jr: | lecook: let me rephrase: there's nothing exciting about a bunch of competent programmers who haven't taken the time to properly learn Bitcoin, trying to reinvent it from scratch for no reason |
| 05:20:46 | gmaxwell: | Luke-Jr: the openssh one is actively bad. Its very easy to grind for one that will pass for the user as 'similar' |
| 05:20:46 | lecook: | haha |
| 05:20:48 | dsnrk: | lower block speed just means weaker blocks and higher overhead. |
| 05:21:23 | Luke-Jr: | lecook: there is nothing good about shorter block times or turing completeness; Bitcoin *intentionally* has neither of these for good reasons |
| 05:21:33 | Luke-Jr: | gmaxwell: those two examples look identical to me |
| 05:21:41 | Luke-Jr: | gmaxwell: bunch of garbage on the screen, both of them |
| 05:21:53 | gmaxwell: | Luke-Jr: you're supposted to compare the highlighted portions. |
| 05:22:02 | dsnrk: | gmaxwell: I don't mind that too much at all. |
| 05:22:03 | Luke-Jr: | I don't see any highlighting.. |
| 05:22:15 | gmaxwell: | Luke-Jr: the asterisks |
| 05:22:35 | lecook: | so litecoin's scrypt is weaker than the pow bitcoin uses? |
| 05:22:38 | gmaxwell: | (ideally they'be be bold characters) |
| 05:22:46 | dsnrk: | lecook: why do you think it is stronger? |
| 05:22:50 | Luke-Jr: | gmaxwell: almost easier to just compare the whole thing :/ |
| 05:22:57 | Luke-Jr: | lecook: yes |
| 05:23:12 | lecook: | i thought ethereum's algorithm was different and they could offer same security |
| 05:23:20 | gmaxwell: | Luke-Jr: it would probably take you 5 minutes to carefully compare the whole thing. |
| 05:23:51 | dsnrk: | lecook: they haven't said really what broken PoW scheme they are going for. "asic proof" is a fallacy though. |
| 05:24:06 | Luke-Jr: | lecook: nope, worse almost certainly |
| 05:24:19 | lecook: | man you seem confident |
| 05:24:23 | Luke-Jr: | lecook: of course, as dsnrk says, we can't specifically say *why* it's worse until they decide on one.. |
| 05:24:26 | gmaxwell: | Luke-Jr: you only need to compare the three highlighted 'hexagons' to get >100 bit security, and can ignore all the rest. |
| 05:24:34 | Luke-Jr: | lecook: because I know how Bitcoin works and why it works that way |
| 05:24:39 | lecook: | i was skeptical about ethereum since turing completeness requires infinite amounts of memory |
| 05:24:47 | gmaxwell: | lecook: it's not ruting complete. |
| 05:24:50 | lecook: | tracking each and every state |
| 05:24:52 | gmaxwell: | er turning. |
| 05:24:52 | lecook: | i know |
| 05:24:57 | dsnrk: | did you do no research at all? they limit opcodes to solve the halting problem. |
| 05:25:24 | gwillen: | gmaxwell: I'm curious why a hex grid rather than a rectangular one |
| 05:25:34 | lecook: | sorry dsnrk didn't do much research |
| 05:25:36 | gwillen: | gmaxwell: I also note that you probably lose about 7 bits per hexagon due to people won't notice case mismatches |
| 05:25:56 | gmaxwell: | Which means that it has the same computational expressiveness as bitcoin script (well, as script would have not for some of the disabled opcode), though the existance of loops will make some code smaller— sadly they often make static analysis completely intractable. |
| 05:25:56 | lecook: | they frigging solved the halting problem? jebuz! |
| 05:26:05 | dsnrk: | lecook: right well, it's pretty much the same as bitcoin. they have a basic stack machine, and limit the size of scripts in order to prevent them executing forever. |
| 05:26:26 | Luke-Jr: | dsnrk forgot quotes around "solve" |
| 05:26:34 | lecook: | haha |
| 05:26:40 | gmaxwell: | gwillen: perhaps, the characters excluded are case differences in (almost?) every case.. since the visual similarity data actually reflects that. |
| 05:26:44 | dsnrk: | Luke-Jr: whoops. |
| 05:26:57 | gwillen: | gmaxwell: ahh, okay, that saves some bits then |
| 05:27:24 | gmaxwell: | this would be more obvious if my starting charset had numbers, but I don't currently have similarity data including numbers. |
| 05:27:28 | gwillen: | gmaxwell: the way I compare is verbal, not visual, so case is less salient as a difference than difference in shape |
| 05:27:36 | Luke-Jr: | lecook: if you want to get excited, go read up on BlockStream and daughter-chains (often confusingly called "side-chains") |
| 05:27:46 | lecook: | ah yes |
| 05:27:54 | lecook: | haven't been successful at finding new information |
| 05:27:58 | lecook: | and no i'm not excited |
| 05:28:07 | lecook: | my friends are |
| 05:28:10 | lecook: | it was troubling |
| 05:28:32 | Luke-Jr: | lecook: daughter-chains basically means someone can fork Ethereum and use it with real bitcoins instead of ether altcoin nonsense |
| 05:28:37 | gmaxwell: | gwillen: hm, wouldn't be hard to include that in a bias measure. |
| 05:28:47 | lecook: | so like merged mining? |
| 05:28:49 | gmaxwell: | er distinace measure. |
| 05:28:50 | dsnrk: | Luke-Jr: sounds like daughter chains need a $20.5M USD IPO scam to get the excitement up. |
| 05:28:57 | lecook: | how would the economics of it work? |
| 05:29:03 | Luke-Jr: | lecook: and it has real bitcoin developers such as gmaxwell and myself to-be-working on it |
| 05:29:24 | Luke-Jr: | lecook: merged mining will be optional |
| 05:29:29 | lecook: | i'd love to collaborate (programming mule not much of designing the protocol) |
| 05:30:00 | lecook: | btw all these talks about new blockchains is there any work being done for offchain related technology? |
| 05:30:38 | lecook: | offchain related tech might really be useful for bitcoin to compete with m pesa |
| 05:30:49 | dsnrk: | offchain transactions is an oxymoron. |
| 05:31:00 | lecook: | it's not fully decentralized |
| 05:31:17 | lecook: | oops i read open transactions. |
| 05:31:30 | gmaxwell: | dsnrk: it's not an oxymoron. |
| 05:31:39 | Luke-Jr: | lecook: a daughter-chain can be argued to be "off-chain" |
| 05:32:43 | dsnrk: | gmaxwell: it's possible I've missed something big, but normally "off chain transactions" is talking about a trusted party handling them, no? |
| 05:33:07 | gmaxwell: | dsnrk: there are a multitude of different ways of potentially transacting without using the blockchain for every step of the way— they have varrious security and scalablity tradeoffs. Some are totally trustless. |
| 05:33:09 | lecook: | i don't understand open transactions voting pools very well or how it's gonna stop nodes to collude with one another |
| 05:33:17 | Luke-Jr: | dsnrk: it doesn't have to be, but it can be that too |
| 05:33:29 | lecook: | not really dsnrk |
| 05:33:33 | Luke-Jr: | dsnrk: it's a pretty 'catchall' term |
| 05:33:48 | lecook: | i'm working on a voting pool offchain system |
| 05:34:19 | lecook: | where every node needs to provide a guarantee in order to be a member of the pool. |
| 05:34:24 | gmaxwell: | dsnrk: e.g. in the federated model you can have N of M hopefully non-colluding servers that are signing things. So yea, there is a risk (they collude, all get hacked, etc). But there is also a huge payoff: infinite scalablity, better privacy, instantaniousness, etc. |
| 05:34:51 | gmaxwell: | dsnrk: another kind off off-chain transaction is a micropayment channel. |
| 05:36:04 | dsnrk: | gmaxwell: mm alright, I wasn't aware of the term being used for that. I've only seen it used in daft schemes that try to make offline (ie, isolated from all other communication) transactions possible. which they aren't because you can't know the state of the outputs you're being told are worth a certain value. |
| 05:36:06 | lecook: | gmaxwell has anyone implemented your proof of reserve yet? |
| 05:36:09 | gmaxwell: | dsnrk: where I open an inverse credit account with someone, E.g. setup X btc that I can pay to them. And then slowly release it a chunk at a time, and a transaction only happens if the channel times out or the X BTC is all transfered. You can build a network of these reverse-credit channels, and incrementally release along it so that the trusted amount in flight is always small. |
| 05:36:29 | gmaxwell: | lecook: yes, there are several sites running varrious variations of it. I'd say to look at iwilcox' page for a list but its down at the moment. |
| 05:36:29 | lecook: | sounds like ripple |
| 05:36:42 | lecook: | yess it's frigging down |
| 05:36:53 | lecook: | peter todd linked me to his own version on reddit |
| 05:36:55 | gmaxwell: | lecook: it's what original ripple could have become before opencoin bought the name and mostly undermined the goodness of it. |
| 05:37:14 | dsnrk: | and then ditched it to relaunch it under a different name \o/ |
| 05:37:26 | lecook: | stellar |
| 05:38:26 | gmaxwell: | dsnrk: and yea, so tamper resistant hardware is another kind of "off chain" transaction, again with its own perks (can work offline!) and limitations (evil hardware vendors can do naughty things). The othercoin stuff uses multisig such that the mfgr cannot rip people off unilaterally, they have to collude with someone who'd handled the token in question. |
| 05:39:08 | lecook: | can't hardware allow for offline transactions? |
| 05:39:32 | lecook: | damn time to go to bed |
| 05:39:41 | gmaxwell: | thats what I just said. |
| 05:41:25 | dsnrk: | gmaxwell: I don't really mind the m-of-n signature oracle thing, but ripple sort of burnt that concept a little bit |
| 05:42:04 | dsnrk: | or I totally misunderstood ripple. either one. |
| 05:42:22 | gmaxwell: | well ripple has been more or less completely non-transparent about it... e.g. pretending it was a vulnerability that didn't exist, and not doing anything to secure against it. |
| 05:42:38 | lecook: | how did they get a bank to accept ripple? |
| 05:42:57 | gmaxwell: | Banks consider poor security a feature. :P |
| 05:44:28 | justanotheruser: | Is is possible to implement coin covenants that doesn't make every covenant script massive? |
| 05:44:32 | gmaxwell: | gwillen: if I eliminated case differences I could use uppercase to do the suggested highlighed locations. |
| 05:44:55 | justanotheruser: | s/coin covenants/coin covenants in a way that |
| 05:45:12 | gmaxwell: | justanotheruser: if a script language were setup for it, yes. |
| 05:46:20 | lecook: | is open transactions implementing your proof of funds gmaxwell? |
| 05:46:30 | gwillen: | gmaxwell: oh, yeah, clever |
| 05:46:39 | justanotheruser: | gmaxwell: right, but you will always have to specify the constraints of the outputs and/or inputs which would make the script a few kb I assume |
| 05:47:26 | justanotheruser: | actually, it could probably done in a few dozen bytes if it was a small constraint |
| 05:47:45 | gmaxwell: | justanotheruser: hm? no. I mean it just takes a few bytes to specify grabbing a particular output and compare it to something. |
| 05:47:48 | gmaxwell: | right. |
| 05:49:57 | justanotheruser: | hmm PUSH (some value signifying all outputs) PUSH (some value signifying must be tonal) OP_COVENANT |
| 05:50:41 | justanotheruser: | "some value signifying must be tonal" is pretty static though |
| 05:51:02 | justanotheruser: | probably will be some common constraints that are more useful that could be static though |
| 05:52:51 | lecook: | is blockstream the company behind side chains? |
| 05:53:23 | Luke-Jr: | justanotheruser: that'd mess up change a bit. :P |
| 05:54:13 | justanotheruser: | Luke-Jr: no tonal change? :O |
| 05:54:19 | Luke-Jr: | justanotheruser: … |
| 05:54:46 | justanotheruser: | Luke-Jr: if the script is viral, the redeemed output would also be tonal |
| 05:55:57 | justanotheruser: | so it should divide fine if thats what your ellipsis is concerned with |
| 05:56:22 | gmaxwell: | lecook: if you're looking for sidechains information what you want to read is http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/20140316225819.GA19846%40netbook.cypherspace.org/#msg32108143 and the linked resorces, also the responses in that thread. |
| 05:57:05 | gmaxwell: | justanotheruser: OP_COVENANT makes nooo sense at all. |
| 05:57:44 | lecook: | thank you gmaxwell |
| 05:58:48 | gmaxwell: | justanotheruser: you would just have a push that grabs the scriptpubkey of the output, substrs it, push the pubkey from the input, substr and compare or the like. |
| 05:58:49 | justanotheruser: | gmaxwell: maybe not in that syntax, but if you want a script that verifies that outputs act in a certain way, would that not be useful? |
| 05:59:30 | gmaxwell: | no it wouldn't be useful, access to the outputs would be useful. Then you can check it. |
| 06:00:51 | justanotheruser: | gmaxwell: that makes a lot more sense |
| 06:01:00 | justanotheruser: | so just an opcode that pushes the outputs? |
| 06:01:46 | justanotheruser: | or atleast a certain part of the output |
| 06:02:02 | gmaxwell: | or something along those lines. |
| 06:02:48 | justanotheruser: | yeah, OP_COVENANT is a very unnecessary abstraction |
| 06:05:29 | Luke-Jr: | gmaxwell: is MPL like GPL or LGPL? |
| 06:06:37 | Luke-Jr: | bleh, LGPLish |
| 06:11:52 | gmaxwell: | Luke-Jr: yea, mpl 2.0 is a weak copyleft with a apache 2.0 like patent grant, structured to be gpl compatible. |
| 06:12:54 | gmaxwell: | (you can effectively 'upgrade' MPL licensed works to GPL when you combine the MPL licensed code with GPL licensed code) |
| 06:31:14 | lecook: | would voting pools require a dht to keep track of every pool member? |
| 06:32:07 | gmaxwell: | lecook: no clue on implementation details— I certantly wouldn't do that... there can only be a fairly modest number of pool members, I would just configure them directly. |
| 06:33:20 | lecook: | what if they provide a guarantee? let's say the i set up a node put 5 btc in it and i can't store more thn 5 btc in that node. |
| 06:33:46 | lecook: | if i run everyone who deposits onto my node gets refunded. |
| 06:33:51 | lecook: | or get hacked |
| 06:35:57 | lecook: | do you think this idea could work or it's a really bad idea lol |
| 11:00:20 | TheGreatSupaDupa: | I'm sorry, but I don't want to be an Emperor - that's not my business. I don't want to rule or conquer anyone. I should like to help everyone, if possible -- Jew, gentile, black man, white. We all want to help one another; human beings are like that. We want to live by each other's happiness, not by each other's misery. We don't want to hate and despise one another. In this world |
| 11:00:20 | TheGreatSupaDupa: | there's room for everyone and the good earth is rich and can provide for everyone. |
| 11:00:20 | TheGreatSupaDupa: | The way of life can be free and beautiful. |
| 11:00:20 | TheGreatSupaDupa: | But we have lost the way. |
| 11:00:20 | TheGreatSupaDupa: | Greed has poisoned men's souls, has barricaded the world with hate, has goose-stepped us into misery and bloodshed. We have developed speed but we have shut ourselves in. Machinery that gives abundance has left us in want. Our knowledge has made us cynical, our cleverness hard and unkind. We think too much and feel too little. More than machinery, we need humanity. More than cleverness, |
| 11:00:21 | TheGreatSupaDupa: | we need kindness and gentleness. Without these qualities, life will be violent and all will be lost. |
| 11:00:21 | TheGreatSupaDupa: | The aeroplane and the radio have brought us closer together. The very nature of these inventions cries out for the goodness in men, cries out for universal brotherhood for the unity of us all. Even now my voice is reaching millions throughout the world, millions of despairing men, women, and little children, victims of a system that makes men torture and imprison innocent people. |
| 11:00:22 | TheGreatSupaDupa: | To those who can hear me I say, "Do not despair." The misery that is now upon us is but the passing of greed, the bitterness of men who fear the way of human progress. The hate of men will pass and dictators die; and the power they took from the people will return to the people and so long as men die, liberty will never perish. |
| 11:00:22 | TheGreatSupaDupa: | Soldiers: Don't give yourselves to brutes, men who despise you, enslave you, who regiment your lives, tell you what to do, what to think and what to feel; who drill you, diet you, treat you like cattle, use you as cannon fodder. Don't give yourselves to these unnatural men, machine men, with machine minds and machine hearts! You are not machines! You are not cattle! You are men! You |
| 11:00:23 | TheGreatSupaDupa: | have the love of humanity in your hearts. You don't hate; only the unloved hate, the unloved and the unnatural. |
| 11:00:23 | TheGreatSupaDupa: | Soldiers: Don't fight for slavery! Fight for liberty! In the seventeenth chapter of Saint Luke it is written, "the kingdom of God is within man" -- not one man, nor a group of men, but in all men, in you, you the people have the power, the power to create machines, the power to create happiness. You the people have the power to make this life free and beautiful, to make this life a |
| 11:00:24 | TheGreatSupaDupa: | wonderful adventure. |
| 11:00:24 | TheGreatSupaDupa: | Then, in the name of democracy, let us use that power! Let us all unite!! Let us fight for a new world, a decent world that will give men a chance to work, that will give you the future and old age a security. By the promise of these things, brutes have risen to power, but they lie! They do not fulfill their promise; they never will. Dictators free themselves, but they enslave the |
| 11:00:25 | TheGreatSupaDupa: | people!! Now, let us fight to fulfill that promise!! Let us fight to free the world, to do away with national barriers, to do away with greed, with hate and intolerance. Let us fight for a world of reason, a world where science and progress will lead to all men's happiness. |
| 11:01:42 | sipa: | sipa has kicked TheGreatSupaDupa from #bitcoin-wizards |
| 11:01:54 | _ingsoc: | Why are you quoting Charlie Chaplin? |
| 11:02:00 | _ingsoc: | Nvm. |
| 12:22:10 | Emcy: | thats a nice speech but why here |
| 12:23:57 | pigeons: | Emcy: that guy is known to have issues and enjoy being a nuisance |
| 12:26:10 | Emcy: | that really is a very nice speech; what a juxtaposition with the bloodsoaked 20th century and beyond |
| 12:32:55 | pigeons: | good movie |
| 12:57:56 | jgarzik: | jgarzik is now known as home_jg |
| 15:22:10 | nsh-: | nsh- is now known as nsh |
| 16:41:09 | topynate: | has there been any lasting interest in script extensions like OP_CHECKLOCKTIMEVERIFY? |
| 16:42:05 | topynate: | i'd really like to start working on contracts using time-locked refunds, but currently it looks like the only option is to wait for all sources of transaction malleability to be removed |
| 16:54:59 | andytoshi: | topynate: ?? OP_CHECKLOCKTIMEVERIFY is implicit |
| 16:55:55 | andytoshi: | if you want to chain transactions without fear of malleability, the extension to bitcoin you need is a way to address txouts while only referring to signed data |
| 17:00:59 | topynate: | that would be more general, i guess? but a timelock opcode would be enough for refund transactions/payment channel. |
| 17:01:36 | topynate: | it would take away the need to create a refund transaction referring to an unconfirmed prior transaction |
| 17:05:47 | topynate: | andytoshi: i was referring specifically to this patch: https://people.xiph.org/~greg/OP_CHECKLOCKTIMEVERIFY.patch |
| 17:06:30 | andytoshi: | o.O firefox defaults to opening .patch files with notepad |
| 17:06:32 | andytoshi: | and i'm on linux |
| 17:06:40 | andytoshi: | w/e, i've got wine... |
| 17:08:07 | andytoshi: | ah, i see what you mean topynate, sorry for misunderstanding |
| 17:09:13 | andytoshi: | i think the answer is still no re "is there any lasting interest" :) |
| 17:09:26 | topynate: | oh well :( |
| 17:10:37 | topynate: | i think that's a shame, i've been thinking about the current strategy of methodically removing all malleability, and that seems both harder and less reliable. |
| 17:10:54 | topynate: | how can you be sure that you removed _all_ malleability? |
| 17:11:25 | andytoshi: | topynate: well, with ECDSA we probably can't...with bitcoin script it would require a tremendous effort |
| 17:11:43 | andytoshi: | so probably the answer is "overhauling script with malleability in mind, and also using schnorr signatures everywhere" |
| 17:12:52 | andytoshi: | for now, if you could put some low-value things out there which depend on malleability being impossible (e.g. using probablistic transactions to tip on comment websites), that'd do some work toward incentivizing people to shake out additional malleabilities.. |
| 17:15:53 | topynate: | hah, interesting idea. reduce transaction fees by giving out lottery tickets |
| 17:17:04 | topynate: | but i don't want to just use contracts with low value-at-risk, where it isn't worth using a '0day malleability exploit' |
| 17:18:33 | andytoshi: | i think for now you're SOL :/ introduce trust or wait for sidechains to become a thing so you can use coins with a non-malleable script |
| 17:19:14 | andytoshi: | (not that there's one today, when people have no problems making altcoins, so i guess sidechains won't really help..) |
| 20:43:42 | nejucomo1: | nejucomo1 is now known as nejucomo |
| 21:13:10 | Guest89882: | Guest89882 is now known as maaku |
| 22:03:09 | jcrubino: | jcrubino has left #bitcoin-wizards |
| 23:03:36 | jwilkins_: | jwilkins_ is now known as polyclef |
| 23:56:02 | fanquake_: | fanquake_ is now known as fanquake |