| 05:26:23 | xcthulhu: | So has anybody else noticed that anywhere between 0% and 33% of the bonded stake in Tendermint doesn’t matter at all? |
| 05:31:32 | justanotheruser: | xcthulhu: want to elaborate |
| 05:32:42 | xcthulhu: | Sure. So the simplest case is you just have 2 guys, a majority shareholder and a minority holder. If the majority holder has 67% of the stake or more, the minority holder doesn’t matter. |
| 05:33:32 | justanotheruser: | If you're assuming a majority holder then yeah. |
| 05:33:38 | justanotheruser: | Same with bitcoin and 50% isn't it? |
| 05:34:02 | xcthulhu: | Well, in bitcoin every last watt contributes |
| 05:34:39 | justanotheruser: | what if there are 5 holders not colluding with 67% evenly distributed? |
| 05:34:58 | xcthulhu: | On the other hand, in Tendermint, you’ll have a distribution of bonded stakes resembling a poorly designed voting system. |
| 05:35:00 | justanotheruser: | in the case that someone has 50%, each watt doesn't contribute |
| 05:35:51 | xcthulhu: | Right, so that’s just the simplest case. To sort of understand a more complex case, it’s worth looking at something like the European union from 1958 to 1973 to see what can go wrong. |
| 05:36:12 | xcthulhu: | http://en.wikipedia.org/wiki/Voting_in_the_Council_of_the_European_Union#Treaty_of_Rome_.281958.E2.80.931973.29 |
| 05:36:37 | xcthulhu: | In this particular voting system, no party had a majority. |
| 05:37:20 | xcthulhu: | However, if you look at every possible voting configuration, you’d see that Luxembourg’s single vote actually never actually could change the outcome |
| 05:38:03 | xcthulhu: | (assuming a majority vote) |
| 05:40:29 | xcthulhu: | Something roughly analgous in Tendermint would be if you had 3 parties - 2 majority holders of roughly similar size constituting >67% of the bonded stake and a minority holder with the rest |
| 05:41:56 | justanotheruser: | why assume 3 parties? |
| 05:42:23 | xcthulhu: | It’s just a simple concrete example to pump intuition. |
| 05:42:51 | justanotheruser: | but does it work without the assumption that two parties will control 2/3 of stake? |
| 05:43:18 | xcthulhu: | In general, I’d expect a Pareto distribution of wealth corresponding to a Gini coefficient between .95 and .99. |
| 05:43:50 | justanotheruser: | I think there are much stronger arguments against tendermint |
| 05:43:50 | xcthulhu: | Even with a nice Gini coefficient of .8, 20% of the stake just won’t matter |
| 05:45:01 | xcthulhu: | I’m vaguely curious, but the fact that voting power is not linearly proportional to stake is pretty damning. |
| 05:45:58 | xcthulhu: | And that combinatorically a substantial portion of the stake is pointless just makes it decentralization theatre. |
| 05:46:10 | xcthulhu: | What’s a better argument? |
| 05:46:45 | justanotheruser: | the cost of rewriting history |
| 05:47:47 | xcthulhu: | It’s probably easy. |
| 05:49:58 | xcthulhu: | I mean, I know Ethereum is thinking of using Tendermint. I know from insider information that 80% of the stake is wrapped up in just 12 individuals. I’m sure they could fork it whatever way they want if they can coordinate. |
| 05:51:37 | justanotheruser: | 12 "individuals" could probably keep "themselves" in power |
| 05:53:15 | xcthulhu: | Well, yes. The other 20% of the stake doesn’t matter from a combinatoric perspective. |
| 05:56:10 | xcthulhu: | It’s not really different than a corporation, just less honest. |
| 05:58:47 | Taek: | modern corporations are bound by jurisdictional national laws |
| 05:59:09 | Taek: | which I would argue offers more protection to the average user |
| 06:00:21 | xcthulhu: | Yup. They have regulations and everything. There’s nothing stopping the majority stakeholders from being absolutely cutthroat. |
| 06:05:50 | xcthulhu: | (in tendermint) |
| 08:05:20 | barjavel.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:20 | barjavel.freenode.net: | Users on #bitcoin-wizards: andy-logbot bit2017 Mably p15_ p15x shesek luktgf cbeams cornus_ammonis xcthulhu damethos hktud0 moa Crowley2k lclc b_lumenkraft airbreather d1ggy zooko` TheSeven PRab ryanxcharles nessence Cory Dr-G totalanni phaeni PaulCapestany unlord_ satwo jeremyrubin justanotheruser melvster NewLiberty thufir hulkhogan42o Rynomster K1773R cluckj kgk sparetire LeMiner hashtagg tjader kefkius BananaLotus guruvan yuleBOOL warren CoinMuncher jtimon c0rw1n |
| 08:05:20 | barjavel.freenode.net: | Users on #bitcoin-wizards: grandmaster dgenr8 xapp Alanius brand0 Tjopper1 Pan0ram1x poggy ajweiss nuke1989 Zouppen Krellan stonecoldpat phedny so aakselrod Guest4827 s1w lechuga__ devrandom EasyAt_ yorick afdudley fenn mm_0 Taek lnovy [d__d] dc17523be3 arubi cdecker gielbier jmaurice leakypat Tiraspol Starduster Emcy sipa platinuum koshii MoALTz luny isis smooth sneak SubCreative Madars sadoshi tromp_ throughnothing_ amiller harrigan_ sparetire_ rustyn gmaxwell maaku |
| 08:05:21 | barjavel.freenode.net: | Users on #bitcoin-wizards: waxwing Xzibit17 adams_ forrestv Transisto richardus adlai Fistful_of_coins go1111111 prodatalab kanzure spinza maraoz morcos sdaftuar andytoshi helo Iriez copumpkin bedeho face Kwelstr nsh GAit cfields_ wumpus mappum jbenet NeatBasisW dasource btcdrak CodeShark dardasaba ebfull mkarrer_ luigi1111w binaryatrocity bliljerk101 jonasschnelli merlincorey [ace] eric a5m0 nephyrin null_radix crescendo Sqt mikolalysenko sturles GreenIsMyPepper |
| 08:05:21 | barjavel.freenode.net: | Users on #bitcoin-wizards: harrow vonzipper berndj manan19 comboy realcr jaromil catlasshrugged_ Apocalyptic cryptowest_ runeks__ Graet veox indolering Keefe petertodd jcorgan larraboj ryan-c jessepollak gribble tromp mr_burdell gnusha d9b4bef9 starsoccer weex SwedFTP Hunger- lmacken Luke-Jr yrashk artifexd kumavis otoburb huseby midnightmagic BlueMatt TD-Linux mariorz hguux___ wizkid057 Anduck kyuupichan Logicwax phantomcircuit luigi1111 nanotube yoleaux gavinandresen |
| 08:05:21 | barjavel.freenode.net: | Users on #bitcoin-wizards: AdrianG BrainOverfl0w MRL-Relay azariah @ChanServ davout CryptOprah Oizopower epscy nickler gwillen kinlo coryfields_ Muis catcow sl01 null michagogo STRML warptangent pigeons espes__ roasbeef_ heath dansmith_btc cursive Meeh fluffypony optimator livegnik |
| 09:13:04 | fluffypony: | so Bankymoon are presenting, they want to use smart contracts for handling utilities payments, so they're "working closely with Ethereum" |
| 09:13:31 | bedeho: | say what? |
| 09:14:02 | bedeho: | fluffypony@Monero ? |
| 09:14:55 | Luke-Jr: | * Luke-Jr wonders how smart contracts are relevant to utility payments |
| 09:15:03 | fluffypony: | bedeho: I'm at the Bitcoin Africa conference |
| 09:15:41 | fluffypony: | which has mostly been hilarious |
| 09:15:54 | Luke-Jr: | that sounds like a typical bitcoin conference |
| 09:15:57 | bedeho: | hehehehe |
| 09:16:09 | justanotheruser: | fluffypony: what country is this in? |
| 09:16:13 | bedeho: | Never been to a bitcoin conference, but yes, I can imagine |
| 09:16:14 | fluffypony: | with comments like "Vitalik is one of the smartest people I've ever met" (Micah Winkelspecht) you can't go wrong |
| 09:16:16 | fluffypony: | justanotheruser: Cape Town, South Africa |
| 09:16:18 | justanotheruser: | oh should read more.... |
| 09:16:51 | fluffypony: | oh, and BitPesa who are "powered by blockchain technology", which is code for "we use Bitcoin for remittance" |
| 09:16:57 | justanotheruser: | to be fair, vitalik is very smart, he is only 19 or something |
| 09:17:01 | Luke-Jr: | justanotheruser: lol, it wasn't an entirely unfair question - there are multiple countries in Africa :p |
| 09:18:12 | fluffypony: | justanotheruser: sure, but his inability to acknowledge his own weaknesses / failings / misnomers means that people take his word as gospel, and that means he's just smart enough to be dangerous |
| 09:18:41 | justanotheruser: | yep, it's really sad, I don't want investors to lose millions in ethereum, nor do I want him to go to jail, but both seem probable |
| 09:20:14 | fluffypony: | someone asked me yesterday why he doesn't contribute to Bitcoin, and I said it's because his ideas were very kindly rejected initially, and instead of him refining them he decided that the rejection was personal / political |
| 09:20:26 | bedeho: | I have yet to see a single compelling use case which Ethereum enables. If there was, someone would have already built it as a separate chain by now... |
| 09:21:01 | fluffypony: | bedeho: I'm almost tempted to fork BTC, add a loop operator to Bitcoin script, and then call it Bit-thereum |
| 09:21:25 | bedeho: | fluffypony : lol, yeah |
| 09:22:05 | bedeho: | well I think counterparty already has implemented ethereum on top of bitcoin, so not really clear what the point of ethereum is now really, even with the lack of use cases aside |
| 09:23:23 | fluffypony: | oh yes I remember |
| 09:23:40 | bedeho: | I think you also need some concept of storage, so you also have to add some data store operators |
| 09:23:44 | fluffypony: | but bedeho, lolthereum has 8 second blocks, and DPOS! |
| 09:23:52 | bedeho: | :D |
| 09:23:58 | justanotheruser: | bedeho: the use case tends to boil down to slightly fancier scripts from what I've seen |
| 09:24:27 | fluffypony: | plus didn't they create a new language called Snake or something? |
| 09:24:31 | fluffypony: | Satan? |
| 09:24:34 | bedeho: | LOL |
| 09:24:35 | fluffypony: | oh - Serpent |
| 09:24:53 | bedeho: | yeah, I think that is what counterparty ported |
| 09:24:56 | justanotheruser: | someone told me that creating multisig with bitcoin was too hard and ethereum was going to make it easy :/ |
| 09:25:11 | fluffypony: | * fluffypony twitches |
| 09:25:59 | bedeho: | wow, yeah, well there are some wacky ethereum fans out there. It doenst seem like everyone understands that ethereum actually does not increase the space possible blockchain based apps in any way. |
| 09:27:06 | fluffypony: | if they ever actually launch and gain some usage I can't wait for the first antivirus scanners for Ethereum |
| 09:27:06 | bedeho: | I guess you could say it reduces development cost, which may make development more economically feasible, but in terms of our "production possibilities fronteer", we have not moved. |
| 09:27:43 | bedeho: | why antivirus? |
| 09:28:01 | fluffypony: | for all the dodgy "blockchain apps" people are going to write |
| 09:29:28 | bedeho: | I think they all run in a VM, so in so far as that is secure, I dont htink that will be an issue |
| 09:34:02 | fluffypony: | bedeho: do they have a threat model they've published? |
| 09:34:42 | bedeho: | I dont think there is any formal security analysis of anything in ethereum, but to be fair, neither is there in bitcoin. |
| 09:35:18 | bedeho: | They do have a pretty solid formal description of the system itself though, written by the lead dev Gavin Wood |
| 09:36:23 | justanotheruser: | fluffypony: an antivirus sounds like a consensus breaking tool |
| 09:37:35 | fluffypony: | bedeho: that's true; although Bitcoin has the advantage of 5.5 years of development from people who know how to think adversarially, plus it's survived a number of interesting and brutal attacks |
| 09:38:01 | fluffypony: | lolthereum has to be secure out the gate because of the vested interest in it |
| 09:39:32 | bedeho: | what do you mean? |
| 09:41:23 | fluffypony: | bedeho: I mean that Bitcoin was being hammered when it was relatively worthless and driven entirely by unpaid volunteers, Ethereum raised money and is driven by paid staff, which means it has expectations to go along with it |
| 09:41:56 | bedeho: | I see, yes, it there is a lot of expectation invested, agree |
| 09:41:59 | fluffypony: | when yup |
| 09:42:33 | fluffypony: | so that block 74638 attack (when 1.84 trillion BTC were created) was in mid-2010, afair |
| 09:42:54 | fluffypony: | when there wasn't this hyperfocus on Bitcoin |
| 09:43:32 | fluffypony: | if Ethereum has an attack/bug happen on the same level there will be "investors" up in arms |
| 09:44:14 | bedeho: | true |
| 09:46:45 | bedeho: | but I think they have said they will redo the whole thing for a 2.0 release, then with a new consensus (dagger/slasher/dpos/asic resistant/pos/non-wastefull/block tree chain) system, so I guess they could just hard fork it back to a good state then. |
| 09:47:03 | bedeho: | It was never clear to me how that transition was supposed to happen |
| 09:47:26 | fluffypony: | STAKECHAINS |
| 09:47:32 | fluffypony: | stake ALL of the chains! |
| 09:49:05 | Luke-Jr: | I prefer steak. |
| 09:52:24 | fluffypony: | Luke-Jr: delegated proof of steak? |
| 09:52:51 | Luke-Jr: | fluffypony: as long as I still get to be the one to eat it |
| 09:53:38 | sipa: | is it hashed steak? |
| 09:54:16 | fluffypony: | sipa: diced |
| 09:55:53 | Luke-Jr: | hm, I think I've only ever tried broiled. |
| 10:00:13 | fluffypony: | Proof of Broil? |
| 10:03:20 | moa: | shish kebobs all around for ethereum guys if it flops out of the gate |
| 10:03:44 | MRL-Relay: | [smooth] steak on a stake? |
| 10:06:22 | fluffypony: | lol |
| 10:06:28 | fluffypony: | invest in cows now! |
| 10:23:03 | fluffypony: | hah hah |
| 10:23:12 | fluffypony: | so this one guy had a slide on the Byzantine Generals problem |
| 10:23:16 | fluffypony: | and how Bitcoin solves it |
| 10:23:31 | fluffypony: | and how the Byzantine Generals problem is about component failure in a system |
| 10:24:23 | wallet42: | wallet42 is now known as Guest33608 |
| 10:24:23 | wallet421: | wallet421 is now known as wallet42 |
| 10:24:59 | fluffypony: | so I tweeted that he's confusing the Byzantine Generals problem with BFT, so he said I must come find him so he can explain it to me |
| 12:39:28 | zooko`: | zooko` is now known as zooko |
| 12:41:26 | Mably_: | Mably_ is now known as Mably |
| 13:14:05 | kanzure: | "How to explain zero knowledge protocols to other people's children" http://pages.cs.wisc.edu/~mkowalcz/628.pdf |
| 13:15:02 | mm_0: | mm_0 is now known as mm_1 |
| 13:15:15 | binaryatrocity: | yay UW Wisconsin! |
| 13:15:57 | kanzure: | you are leaking identifying information |
| 13:17:46 | binaryatrocity: | * binaryatrocity shrugs. |
| 13:21:59 | zooko: | https://medium.com/@jinglan/how-to-explain-zero-knowledge-protocols-to-your-average-child-eb49feb4a41d |
| 13:25:16 | thufir: | I am me, come at me. :) |
| 13:47:01 | bedeho: | Has anyone had a chance to look at the lightning network proposal? Does it actually go as far towards solving scalability as it appears? |
| 14:34:07 | mm_1: | mm_1 is now known as mm_0 |
| 15:40:05 | dgenr8: | lightning network is a lot of complexity surrounding a simple idea - trusted third party. if traditional 3rd parties start handling BTC, it's unnecessary |
| 15:41:12 | sipa: | well sure, and if we'd just trust a credit card provider we wouldn't need bitcoin :) |
| 15:42:47 | thufir: | you just need a concensus network that is 'good enough', who's state gets stamped by bitcoin every 10 minutes. |
| 15:44:15 | sipa: | if lightning ends up being viable to implement, i think its advantages are huge |
| 15:44:31 | dgenr8: | sipa: it's implicit in LN that bitcoin alone cannot solve some problems. LN is not better than bitcoin, and it's also not better than traditional third parties |
| 15:44:40 | thufir: | interesting. do you have a link? I have not heard of it previously. |
| 15:44:42 | sipa: | no, it's in between |
| 15:45:21 | sipa: | it has more overhead than a fully centralized bookkeeper, but it has much smaller counterparty risk |
| 15:45:35 | sipa: | and it's much more scalable than the bitcoin blockchain |
| 15:45:55 | thufir: | so advocate, give me your best link, so i don't have to read about it on wikipedia or something |
| 15:46:04 | sipa: | lightning.network |
| 15:46:15 | sipa: | :) |
| 15:46:19 | sipa: | that's a url |
| 15:46:30 | thufir: | hehe thanks, i was wondering :) |
| 15:46:36 | sipa: | i do believe there are more readable explanations |
| 15:47:13 | dgenr8: | sipa: counterparty risk hasn't been, and isn't the problem in these use cases |
| 15:47:48 | dgenr8: | sipa: we don't have to debate it. when established third parties support BTC we'll see |
| 15:48:01 | thufir: | (read the abstract so far): absolutely. if maleiabilty were fixed, and it could be if people realized how important that would be as in what possibilities are enabled for it. |
| 15:48:23 | sipa: | dgenr8: large third parties handling other people's money create a systemic risk |
| 15:48:34 | sipa: | dgenr8: you may find that risk tolerable, but you have to be aware of it |
| 15:48:38 | thufir: | i mean, malleability fixed, = multiple simple micro-transaction solutions that are provably viable. |
| 15:49:00 | sipa: | dgenr8: in practice, very few people are or are ware of that problem |
| 15:49:23 | sipa: | dgenr8: until mtgox disappears, or their bank needs government intervention |
| 15:50:32 | sipa: | dgenr8: then suddenly they demand that others fix the mistake they made in the first place by trusting those providers |
| 15:50:39 | thufir: | well, i will have to read this later as I am not able at the moment to read a 22 page paper and give it the attention this paper seems to deserve. by later I mean tomorrow is my #1 task. Thanks! |
| 15:50:51 | sipa: | dgenr8: i'm not saying that trust third parties don't have a place in the world - i think they are inevitable |
| 15:50:56 | dgenr8: | LN tries too hard to look like it removes the third party. the main risk reduction is smaller balances held there |
| 15:51:26 | sipa: | dgenr8: well in LN there is no third party - just counterparty risk, as you're interacting directly with others |
| 15:51:37 | thufir: | exactly, if the cost of attack is greater than the few cents per attack you could get in return, then it is 'good enough' |
| 15:51:42 | sipa: | though there is no real difference in trust - just in systemic risk |
| 15:52:12 | sipa: | (systemic risk is the result of eventually a large number of users trusting the same party, rather than random other parties) |
| 15:52:45 | thufir: | well put |
| 15:53:06 | sipa: | but from a single user's perspective, you're absolutely right: it decreases the amount at risk |
| 15:53:18 | dgenr8: | systemic problems haven't come from payment processors failing, but rather institutions that hold large balances |
| 15:53:30 | sipa: | yes? |
| 15:53:33 | sipa: | exactly? |
| 15:53:36 | thufir: | :) |
| 15:53:44 | thufir: | if there is no system worth attacking.... :) |
| 15:54:09 | dgenr8: | LN doesn't compete with banking, but payment processing |
| 15:54:24 | sipa: | same thing |
| 15:54:32 | sipa: | a party that holds balances for another |
| 15:54:39 | thufir: | ...then there is no point, and thus no* risk :) [* = very little, "good enough"] |
| 15:54:44 | sipa: | in order to increase scalability or convenience |
| 15:54:46 | dgenr8: | my cc card company holds no balance from me |
| 15:55:22 | sipa: | your bank does, and your cc company can only work because they trust your bank |
| 15:55:32 | sipa: | not because they trust you |
| 15:55:37 | dgenr8: | LN only works because it trusts the cosigner of the coins |
| 15:55:52 | dgenr8: | the merchant trusts the cosigner |
| 15:56:16 | sipa: | i think you're talking about something else :) |
| 15:57:17 | dgenr8: | wat? if the merchant accepted bitcoin, LN would be unnecessary. LN is all about paying with a special thing that is not just bitcoin |
| 15:57:42 | sipa: | LN allows parties that trust eachother for low amounts to transact directly with eachother, and then settle balances on the blockchain, rather than individual transactions |
| 15:57:43 | thufir: | my uneducated guess: it is a special thing that is not bitcoin but is "BACKED BY BITCOIN" |
| 15:57:52 | dgenr8: | backed by bitpay |
| 15:57:55 | sipa: | huh |
| 15:58:04 | sipa: | i think you are really talking about something else |
| 15:58:16 | thufir: | if it is a valid solution that bitpay nor anyone can control it |
| 15:58:19 | thufir: | that=than |
| 15:58:47 | sipa: | (though i'll admit that i have a lot of reading to do still too, so i'll shut up now) |
| 15:59:56 | dgenr8: | by my reading the merchant accepts the payment precisely because it came from a trusted cosigner. greenaddress is the simpler example |
| 15:59:58 | thufir: | well thanks for the pdf. its my mission to achieve the same. |
| 16:00:14 | sipa: | dgenr8: afaik there is no merchant involved; just a sender and a receiver |
| 16:00:24 | dgenr8: | merchant=receiver |
| 16:01:27 | sipa: | ok, no cosigner then |
| 16:02:05 | CoinMuncher2: | dgenr8: you need to read it again. There is no trusted third party co-signer: the two parties in the payment channel ARE the co-signers. And you get your coins back after a timeout if the other side disappears. |
| 16:02:07 | sipa: | LN is about being able to combine multiple transactions, and only settle their balance on chain |
| 16:02:34 | sipa: | sort of payment channels, but between more than 2 parties, and bidirectionally |
| 16:02:42 | thufir: | So why isn't everyone who can working on just fixing malliability? |
| 16:03:59 | CoinMuncher2: | It is being worked on. Will be fixed soon. |
| 16:04:18 | dgenr8: | apologies... then I really need to read up on how this can make things instant somehow (which it can't). really i apologize for the confused commentary above which applies to the other bitpay idea |
| 16:04:24 | mm_0: | mm_0 is now known as mm_1 |
| 16:04:59 | thufir: | for clarity: this = ? |
| 16:05:09 | dgenr8: | LN |
| 16:05:42 | sipa: | dgenr8: do you know how payment channels work? (the real ones, described by satoshi and implemented in BitcoinJ; not the thing by bitpay_ |
| 16:05:43 | thufir: | i can't read the paper yet but from the abstract and my guess, it is a mater of stringing together unconfirmed transactions, malliability needs to be fixed to enable that |
| 16:06:32 | thufir: | transactions are instant, so that is how they are now instant :) |
| 16:06:47 | Taek: | I don't think malleability affects payment channels |
| 16:07:09 | sipa: | dgenr8: you first put a bunch of funds in escrow, which are returned to you after some time, and wait for that crediting to go on the blockchain |
| 16:07:27 | thufir: | it prevents stringing together unconfirmed transactions which is how many microtransaction / payment channels things would be implemented |
| 16:07:40 | sipa: | dgenr8: now you can renegotiate the transaction which uses those escrowed funds, to not go entirely back to you, but go partially to a receiver |
| 16:07:45 | dgenr8: | sure, the key word being "wait" |
| 16:08:02 | sipa: | right, but that's just setup time |
| 16:08:09 | dgenr8: | "just"? |
| 16:08:15 | sipa: | the renegotiation can happen every millisecond |
| 16:08:37 | dgenr8: | i can pay somebody i've never met before instantly with LN? |
| 16:08:52 | sipa: | i can't say - i don't know LN well enough yet |
| 16:08:59 | sipa: | i'm described the simple version - payment channels |
| 16:09:12 | thufir: | simple: the escrowed funds is what allows you to make off chain promises. how ever many separate such ones you have is how many concurrent such promises you can make every 10 minutes. then you can reuse the existing escrows from my theory. |
| 16:09:22 | sipa: | payment channels only work for sending many small payments from one specific party to another |
| 16:09:35 | sipa: | and require a slow setup, but are infinitely scalable after that, and instant |
| 16:09:58 | sipa: | the reason is that it's "instant", is that it reduces the counterparty risk to one single micropayment |
| 16:09:58 | dgenr8: | i am familiar with payment channels (though you would rightly question my credibility given the above) and don't see how they enable anything to be instant between random parties |
| 16:10:08 | sipa: | they're not actually instant |
| 16:10:16 | sipa: | they're just extremely low value risk |
| 16:10:43 | sipa: | as you send money in very small increments - which the other party can steal - but they can only steal one increment, not the total |
| 16:10:52 | sipa: | but the incrementing itself is instant |
| 16:11:04 | thufir: | tit for tat math, nice |
| 16:11:12 | Taek: | degenr8: this can be solved with a middleman. If I've never met you, but you have payment channels to sipa and I have payment channels to sipa, then we can tunnel our payments through him and do a transaction |
| 16:11:37 | thufir: | hense lightening "NETWORK" :) |
| 16:11:45 | sipa: | thufir: unfortunately, i belive that design is broken by malleability :) |
| 16:11:50 | sipa: | eh, Taek |
| 16:11:52 | thufir: | EXACTLY!!! FIX IT :) |
| 16:11:56 | dgenr8: | Taek: that is the idea I was originally arguing against. if receiver trusts sipa, they might as well trust Discover |
| 16:11:58 | thufir: | hehe |
| 16:12:17 | sipa: | dgenr8: the system is healthier if not everyone needs to trust the same party |
| 16:12:30 | sipa: | which ends up accumulating many funds |
| 16:12:31 | dgenr8: | that doesn't argue for new technology |
| 16:12:41 | sipa: | it does |
| 16:12:56 | thufir: | you must accept the point sipa keeps rasising. you are missing it it seems. the meaning of 'systemic' risk |
| 16:12:56 | sipa: | sorry, need to go now |
| 16:12:59 | Taek: | The middleman can steal at most the 1 payment. If we do 10,000 transactions of 0.1c each, the middleman can't take very much because the first time he does we'll pick a new middleman |
| 16:13:21 | Taek: | that's a bit better than discover |
| 16:13:31 | thufir: | exactly my understanding. |
| 16:13:46 | thufir: | now imagine a simple system of reputation |
| 16:13:57 | thufir: | that middle man, is throwing out his trust worth 1 penny!?!? :) |
| 16:14:08 | thufir: | BOOM solved :) |
| 16:14:11 | sipa: | sipa has left #bitcoin-wizards |
| 16:14:15 | Taek: | but... exit scams! |
| 16:14:33 | thufir: | not familiar with that term.. |
| 16:14:56 | Taek: | oh. It was mostly a joke. An exit scam is when someone in a reputation system cashes out their reputation by scamming a bunch of people |
| 16:15:18 | thufir: | LOL, that is funny :) |
| 16:15:21 | Taek: | If you're planning on getting out of the business anyway, you may as well abuse the reputation you've built up |
| 16:15:30 | thufir: | for a penny? :) that is the point |
| 16:15:39 | thufir: | the solution |
| 16:17:07 | dgenr8: | counterparty risk hasn't been and isn't the problem for payments. the problem is you need 1,233 stickers on the door indicating which cosigners you trust |
| 16:17:31 | thufir: | dgenr8: abstracted and automated away by the "network" |
| 16:17:41 | dgenr8: | now you're back to big trusted party |
| 16:18:13 | thufir: | i disagree. there is no big trusted party, unless you mean the open source code |
| 16:19:07 | thufir: | the code does the work of displaying those stickers, paying through those whos stickers are displayed, etc.. |
| 16:21:10 | Taek: | dgenr8: it's not the type of thing you would use at a merchant |
| 16:21:20 | Taek: | you can't buy a cup of coffee 1c at a time, you have to buy the whole thing |
| 16:21:34 | Taek: | you'd more use it in a situation like paying for a download |
| 16:22:07 | dgenr8: | Taek: as an incremental improvement on payment channels i have no quarrel with it |
| 16:22:28 | Taek: | also, keeping track of 1200 different middlemen that you trust is easier when it's your phone doing it and you + merchant can compare lists computationally |
| 16:22:54 | Taek: | though most likely you would end up with someone like Coinbase handling most of the txns |
| 16:23:22 | dgenr8: | bitcoin transactions permeate the entire world in 2 seconds, but are confirmed only every 10 minutes, with huge variability. speeding up confidence is an attractive engineering problem in that environment |
| 16:23:23 | thufir: | no |
| 16:23:25 | thufir: | not coinbase |
| 16:23:27 | thufir: | MORPHIS :) |
| 16:24:14 | thufir: | (ie: distributed code) |
| 16:25:45 | Taek: | was that a joke or is morphis a real thing? I wasn't able to find any information on it |
| 16:26:40 | thufir: | it is real as in 4 months into full time development, and due before september this year |
| 16:27:17 | Taek: | also: I don't understand why malleability would affect payment channels. I don't know enough about LN, but I don't see how malleability would interrupt the more traditional payment channel process |
| 16:27:28 | Taek: | (can you link me to some morphis stuff?) |
| 16:27:45 | thufir: | stringing together unconfirmed transactions is broken by malleability |
| 16:27:53 | thufir: | morph.is |
| 16:28:11 | thufir: | :) a little lacking at the moment |
| 16:29:20 | thufir: | Iriez: if you can put one of those txs in the block chain but with a different id then you broke the string of unconfirmed ones the payee was hoping to put in there |
| 16:29:35 | thufir: | autocomplete fail, delte iriez |
| 16:29:50 | Taek: | thufir: it's not a problem because the first transaction enters the blockchain before the second transaction is created |
| 16:30:14 | Taek: | it's only a problem when you're stringing transactions together before the parent is put into the blockchain |
| 16:30:25 | thufir: | the goal is to never have the string hit the chain (or only in probabililstic circumstances) thus reducing the load on the block chain |
| 16:30:56 | thufir: | ok, maybe you are saying something deeper than i though, i will think on it, thank you for mentioning that as I never saw that before! |
| 16:33:06 | thufir: | well, i don't understand anything that would make what you are saying true. how could not then the second tx reaching the chain with a different id not break it |
| 16:33:31 | Taek: | the first transaction doesn't reference the second transaction in any way |
| 16:34:15 | thufir: | but if i depend on the third being valid, but the second gets made invalid.. |
| 16:34:20 | Taek: | The second transaction is going to have some arbitrary value depending on how many micropayments were made |
| 16:34:36 | thufir: | hmmmmmm |
| 16:34:49 | Taek: | There's only 2 transactions that ever make it into the blockchain |
| 16:35:06 | Taek: | the "third" transaction actually replaces the second entirely, the second is thrown out |
| 16:35:16 | thufir: | so as payer i can invalidate the last one I issued and planned on issuing |
| 16:35:56 | thufir: | ah interesting, so then as payee i can use the previous one to that which is worth a few cents less but not yet invalidated? a race then still? |
| 16:36:17 | Taek: | validation requires both signatures |
| 16:36:31 | Taek: | the merchant will not sign the transaction until they are ready to cash out |
| 16:36:39 | Taek: | so the payee can't do any race stuff |
| 16:36:43 | thufir: | but they are already signed, the payee is just changing one of the signagures with the ECC signature malleability vunerability |
| 16:36:44 | fluffypony: | hah hah |
| 16:36:54 | fluffypony: | I got banned from attending the Bitcoin Africa conference in future |
| 16:36:57 | fluffypony: | https://twitter.com/bitcoinconf_za/status/589080080300773376 |
| 16:37:00 | fluffypony: | .title |
| 16:37:01 | yoleaux: | Bitcoin Conference auf Twitter: "#BitcoinAfrica15 does not condone any statements made by @fluffyponyza. He will not be allowed attending any of our future events." |
| 16:37:14 | thufir: | LOL |
| 16:37:20 | Taek: | what did you do? |
| 16:37:22 | thufir: | well, be more careful |
| 16:37:37 | thufir: | as in plan better, not hold back ;) |
| 16:37:42 | fluffypony: | Taek: I Tweeted when people made idiotic statements |
| 16:38:19 | Taek: | thufir: they are not already signed. Only the payee has signed the transaction, the merchant has the transaction and can complete it whenever, but will not complete it until they are ready to cash out |
| 16:38:34 | thufir: | you don't want to be divisive because people are conditioned to react emotionally and would normally be allies (they are) but you trigger one of their emotions and now they thing you are enemies |
| 16:39:28 | CoinMuncher2: | fluffypony: we need more people like you at conferences and presentations at meetups. |
| 16:39:44 | thufir: | Taek: ooh, i am following, right, the payee can't beat you to it cause he doesn't have your sig yet |
| 16:39:51 | Taek: | correct |
| 16:40:20 | fluffypony: | CoinMuncher2: there would be far fewer slides on how Bitcoin "solves" the Byzantine Generals problem;) |
| 16:40:21 | thufir: | eff'n awesome! |
| 16:40:35 | thufir: | de facto! |
| 16:41:26 | mm_1: | mm_1 is now known as mm_0 |
| 16:41:46 | thufir: | we can use it as a viable solution, until we win. you can do that without being dependent on it. |
| 16:43:23 | mm_0: | mm_0 is now known as mm_1 |
| 16:43:41 | CoinMuncher2: | fluffypony: Well I guess it's not progress if that space gets filled up with trustless Ripple plugs and PoS incarnations... |
| 16:46:13 | fluffypony: | indeed |
| 16:48:38 | nsh: | any references at all for this Lightning Network malarkey? |
| 16:48:49 | thufir: | http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf |
| 16:48:50 | fluffypony: | nsh: you mean the whitepaper? |
| 16:48:56 | nsh: | yeah sure |
| 16:48:58 | fluffypony: | thufir got there ahead of me |
| 16:49:04 | thufir: | heh, its my life :) |
| 16:49:23 | nsh: | ty, ty |
| 16:53:29 | Taek: | The incentives for miners sharing transactions aren't perfect |
| 16:53:46 | Taek: | for example, if a miner gets a high-fee transaction, there's incentive for the miner to hoard that transaction for themselves |
| 16:53:55 | thufir: | ah yes |
| 16:54:16 | CoinMuncher2: | that's why we have full nodes as well. |
| 16:54:25 | CoinMuncher2: | or even non-full nodes actually. |
| 16:54:55 | Taek: | What if miners had a bounty program for transactions? |
| 16:55:16 | thufir: | who here realizes the property that is bitcoin which is that the "solution" it provides is not what is coded... what is coded is a timestamping mechanism and some coins or whatever (necessary for incentive etc)... but the result is an emergent property of that code |
| 16:55:16 | Taek: | The value of a transaction to a miner can be determined by some equation |
| 16:55:46 | helo: | if someone is paying a high fee, presumably they really want their tx to be mined, and will make sure it makes it to a lot of miners |
| 16:55:52 | Taek: | (fee * liklihood of finding a block - opportunity cost) |
| 16:55:59 | thufir: | when you combine bitcoin with the next piece, you get an emergent property which is bitcoin 2.0 |
| 16:56:10 | Taek: | helo: right but that requires that person to be well connected |
| 16:56:26 | thufir: | Taek: that is the next peice! |
| 16:56:33 | Taek: | instead you might be able to give your transaction to a few well connected bounty-hunters who will give your transaction to all the miners |
| 16:56:41 | Taek: | and you don't have to worry about knowing who the miners are |
| 16:57:38 | thufir: | yes. imagine that bounty hunters was an automated network |
| 16:57:56 | helo: | the network as a whole is supposed to basically do that |
| 16:58:06 | helo: | it is easy to be well connected, i think |
| 16:58:14 | thufir: | perhaps the two will merge, it will be more elegant that way, but perhaps it wont. it doesn't have to |
| 16:58:18 | helo: | and if you are, then multiple miners are highly likely to see your tx |
| 16:58:58 | Taek: | helo: it does seem to work pretty well as-is. If the cost of being a node rises substantially things might change. |
| 16:59:32 | helo: | i guess there are some targeted attack scenarios where someone may not know they aren't well connected... but a greedy miner that benefits isn't likely to be attempting isolation attacks to get all the fees |
| 16:59:43 | thufir: | helo: (physical) mesh net is coming. connectivity won't be an issue for perpetuality |
| 17:02:41 | thufir: | did anyone else see the paper about the RF solution using constructive/deconstructive interfearance to enable near infinite nodes in a limited space (can be separated by just inches with existing tech) to each use the FULL bandwidth as if it were only them and their peer talking? |
| 17:03:10 | helo: | i am pretty likely to be well connected because i use tor + ipv4 |
| 17:03:24 | helo: | it would be quite a task to control both, i think |
| 17:03:25 | thufir: | please link for me, i lost it in my pile, but regardless, think on what i just said. that is revolutionary |
| 17:03:43 | thufir: | yes, so imagine that the future trends towards even more connectivity |
| 17:04:10 | helo: | tor + ipv4 + satellite + localmesh |
| 17:04:22 | thufir: | bingo :) |
| 17:24:21 | thufir: | tech I was talking about, for those interested.. it is revolutionary and meshnet is coming: http://spectrum.ieee.org/tech-talk/telecom/wireless/5g-service-on-your-4g-phone |
| 17:24:37 | thufir: | "pCell" |
| 17:25:23 | thufir: | Each pocket could use the full bandwidth of spectrum available to the network, making the capacity of the system “effectively unlimited,” |
| 17:28:22 | thufir: | (sorry, I will stop here :)...: That’s where things get interesting. Say, for example, you play a YouTube video. The pCell data center would request the video from Google’s servers, and then stream it to your phone through those 10 antennas. But here’s the key innovation: No one antenna would send the complete stream or even part of the stream. Instead, the data center would use the positions of the antennas and the channel characteristi |
| 17:28:22 | thufir: | the system, such as multipath and fading, to calculate 10 unique waveforms, each transmitted by a different antenna. Although illegible when they leave the antennas, these waveforms would add up to the desired signal at your phone, exploiting interference rather than trying to avoid it. |
| 17:32:53 | thufir: | as that shows, and satoshi showed, physics/math is on our side :) |
| 17:42:30 | instagibbs: | I think talk about pcell might be off-topic, but just wanted to point out that all the antennae have to be collaborating with the full original data. This is done somewhere with back-end servers. Not quite a mesh network. That said it's pretty clear we have quite some ceiling left with wireless tech. Now back to more bitcoin-wizardry. |
| 17:47:05 | thufir: | :) agreed, and agreed. :) |
| 17:47:23 | thufir: | (not about the off topic thing though ;) |
| 17:55:41 | mm_1: | mm_1 is now known as mm_0 |
| 18:17:22 | mm_0: | mm_0 is now known as mm_1 |
| 18:21:57 | mm_1: | mm_1 is now known as mm_0 |
| 20:26:59 | mm_0: | mm_0 is now known as mm_1 |
| 20:35:22 | btcdrak: | btcdrak has left #bitcoin-wizards |
| 21:36:06 | belcher_: | belcher_ is now known as belcher |
| 21:52:15 | totalanni: | totalanni is now known as total123 |
| 21:52:19 | total123: | total123 is now known as totalanni |
| 21:56:15 | totalanni: | totalanni has left #bitcoin-wizards |
| 21:59:37 | mm_1: | mm_1 is now known as mm_0 |
| 22:08:37 | mm_0: | mm_0 is now known as mm_1 |
| 22:31:02 | rustyn_: | rustyn_ is now known as rustyn |
| 22:33:37 | jcorgan: | thufir: i'm familiar with the tech in that article. it's pretty hyped up; the comments do a good job of stripping it down to size. the fundamental theory underlying it is sound but it has enormous practical difficulties with scaling up to a useful size. |
| 22:35:57 | gmaxwell: | dgenr8: you're completely incorrect about lightning; It is not a simple "trusted third party". The other parties in lightning cannot steal or seize your funds, they can't perpetually hold them. That is a stark difference; your comparison to traditional third parties is very far off the mark. |
| 22:36:52 | gmaxwell: | (ah, catching up, I see other people corrected this already; don't mind me) |
| 22:37:21 | thufir: | jcorgan: cool, I was interested mostly for why instagibbs mentioned: it just shows that wireless tech likely can go way beyond what people thought was the limit. |
| 22:38:21 | thufir: | i was mentioning it to show that mesh net is coming, the physics are there to allow unlimited bandwith likely.. in time of course :() |
| 22:38:49 | jcorgan: | that tech is not mesh, however |
| 22:39:28 | thufir: | right, but it shows that physics of RF is going to allow orders of magnitude all the way to possibly infinity more than what we can do now, thus, mesh net will be more than doable beyond what most people imagine |
| 22:41:33 | jcorgan: | i'm, sorry, i think you have a misunderstanding of what the article was discussing. the "orders of magnitude and possibly infinity" were part of the hype, not the tech |
| 22:41:49 | thufir: | i never read that article until today. i orignally read the paper |
| 22:41:53 | ajweiss: | yeah when i saw infinite scaling i was bothered |
| 22:42:10 | thufir: | potentially infinite |
| 22:42:55 | thufir: | think blackhole. clearly you can fit a lot of information in a small space. :) potentially ^near infinite |
| 22:43:22 | thufir: | thus my original point being that the future is trending towards more connectivity capability |
| 22:43:32 | ajweiss: | ok fine. even exponential scaling sounds ridiculous. |
| 22:44:12 | thufir: | hehe, just remember. satoshi showed us that ridiculuous is possible with math/physics.. it is rediculous because we didn't discover it yet. |
| 22:44:23 | jcorgan: | i actually helped design and write their first proof of concept implementation. even in theory it does not accomplish what you think it accomplishes. |
| 22:44:36 | thufir: | bitcoin? or pCell? |
| 22:44:40 | jcorgan: | pCell |
| 22:45:05 | gmaxwell: | thufir: uh. So usually when something 'infinte' or 'exponential' is going on, it's only possible with some relatively strong assumption. If you don't know what that assumption is, you're missing some of the most important parts of the story. |
| 22:45:18 | thufir: | well i am a ex-physicist (programming was more interesting as it is more what is needed to change the world), and the theory, as you said, is sound |
| 22:45:56 | gmaxwell: | thufir: This holds for Bitcoin-- Bitcoin works only under certian assumptions, users running nodes (assumes the cost of doing so falls below a threshold where we suffer commons failure), that the majority of hashpower is honest, that the participants aren't partitioned.. etc. |
| 22:46:38 | thufir: | not following you at all. so yes, the tech will only work with a xyz, bbn and whatever. luckilly those are what it was designed for as that is where we are. |
| 22:47:20 | thufir: | it is really quite simple concept, the constructive interference. |
| 22:48:29 | zooko: | zooko has left #bitcoin-wizards |
| 22:48:30 | gmaxwell: | yes, but it is not magic. (MIMO is relatively well understood; I've written a MI-reciever myself; making it pratical is hard) It's also not "infinite" anything. |
| 22:49:09 | gmaxwell: | The seperate paths are not linearly independant, so there is crosstalk; and the channel estimation is limited by SNR, and of course the channel is constantly changing so you can't integrate your estimation forever. |
| 22:49:21 | thufir: | is it orders of magnitude more than what would otherwise be possible (with existing tech)? yes. then by how much? well, irrelivent to my original point. |
| 22:49:31 | jcorgan: | ^^^ and more |
| 22:49:52 | gmaxwell: | Then once you have all this one hop bandwidth; you still need to transport it someplace, and building networks with high bisection bandwidth is not magically cheap. :) |
| 22:50:37 | thufir: | transport it to next hop with separate antenna array |
| 22:51:34 | thufir: | things get cheaper :) eventually it will be commoditized and avaiilble from hong kong for less price than the shipping seems possible. |
| 22:52:09 | ajweiss: | it'd be fun to try and build an auditory installation where you walk around a bunch of low volume speakers in a room |
| 22:53:03 | jcorgan: | ajweiss: it relies on a continuous stream of channel state information being sent back to a central processor |
| 22:53:15 | gmaxwell: | Sensitivity to clock stability gums things up... narrow band or near end QRP overwhelming your reciever leaving the desired signal burried in intermod... lots of very real and significant differences. Sure yea, it's magic compared to non-cohearent approaches where more antennas is limited to a sqrt(n) gain or whatever. But in practice its just some number of dB.. yea "order of magnitude" sure, |
| 22:53:21 | gmaxwell: | but you can also gain a couple orders of magnitude just with a good antenna. "This tech lets a crappy, poorly placed antenna-array work almost as good as a well placed antenna" is also true but much less exciting. |
| 22:53:27 | gmaxwell: | ajweiss: google term: wave field synthesis. |
| 22:54:41 | thufir: | not sure why you are so negative. the theory is sound and more than what you say. it is a window into what is to come, which will certainly be more interesting that pCell 1.0 |
| 22:54:46 | jcorgan: | it also requires as many transmit antennas as their are user receivers |
| 22:55:36 | thufir: | so you need one array for each peer you peer with. a mesh net does not need many, really just 3 (peers) per site. |
| 22:56:23 | Eliel: | * Eliel suspects gmaxwell has seen at least one tragedy that occurred due to someone thinking a tech is better than it actually was. |
| 22:57:10 | thufir: | sure, if you put all your eggs in one basket, etc. but what i have been saying is this is an example of what is to come. pCell inc. isn't what i'm talking about. |
| 22:57:35 | gmaxwell: | lots of excellent technology gets ignored or abandoned because some hyped thing managed to move its limitations into a form that laymen or suits (or even the engineers) don't (yet) understand; I think it causes a lot of cumulative harm to mankind. |
| 22:57:54 | mm_1: | mm_1 is now known as mm_0 |
| 22:58:23 | dgenr8: | gmaxwell: the "lightning" part of LN is described in Appendix A, which itself states plainly "Low latency clearing is possible when having a trusted 3rd party service." |
| 22:58:24 | thufir: | well when it comes to physics I am the inverse of those. |
| 23:05:08 | thufir: | it also allows properly placed antenna-array to do what with a well placed antenna is impossible. impossible to possible is certainly interesting to me :) |
| 23:07:31 | GreenIsMyPepper: | dgenr8: The paper describes trustless payment networks. Appendix A refers to a trusted version of it, only Appendix A has custodial trust. |
| 23:11:30 | dgenr8: | gmaxwell: to claim LN is was merely a ttp would be completely incorrect. i claim only that it achieves no improvement whatsoever in clearing speed of arbitrary trustless payments, and that the speed achieved by involving a ttp is very comparable to a traditional ttp like Discover |
| 23:11:32 | GreenIsMyPepper: | dgenr8: Trustless payments are instant and in nearly every instance funds are transferred instantly. In trustless network failures, the *timeouts* are not instant. |
| 23:12:33 | GreenIsMyPepper: | Settlement is instant if the clearing is sucessful. It is only with clearing failures that may have some timeout period if the obligation is not rerouted. |
| 23:13:14 | dgenr8: | GreenIsMyPepper: are you the author? |
| 23:16:30 | GreenIsMyPepper: | Yes (still need to change my nick). It's being rewritten to clear up these kinds of miscommunication... |
| 23:18:12 | GreenIsMyPepper: | if you have other questions/concerns I'd be happy to field them (heading out in 15 minutes, but I'll reply to /msgs) |
| 23:18:23 | thufir: | GreenIsMyPepper: oh awesome. i read your abstract, reading with high attention is my #1 task for tomorrow. |
| 23:18:23 | kanzure: | is this the most recent http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf |
| 23:18:48 | thufir: | i am 4 months full time dev into coding an implementation |
| 23:19:02 | GreenIsMyPepper: | kanzure, thufir: i'll have a newer version up next week |
| 23:19:24 | dgenr8: | in the best case, how quickly can LN enable a payee to trust a payment that I transmit at time t=0? |
| 23:19:40 | GreenIsMyPepper: | using relative confirmations (relative checklocktimeverify) as a default example too |
| 23:20:05 | GreenIsMyPepper: | dgenr8: best case is it is fully committed in milliseconds if all parties are geographically close |
| 23:20:26 | dgenr8: | the tx I sent is not confirmed. why does payee trust it? |
| 23:20:30 | GreenIsMyPepper: | dgenr8: worst case for sender is n days pre-defined with the timeout |
| 23:20:44 | thufir: | nice! based upon the abstract i read and the discussion in this channel, your theory is on the right path! seems to exactly (theory, don't know details until i read your paper) my thinking of the best way. |
| 23:20:59 | thufir: | exactly ^match |
| 23:21:00 | GreenIsMyPepper: | payee trusts it because they are capable of redeeming it by broadcasting to the blockchain at any time (they have the preimage to the hash) |
| 23:21:18 | dgenr8: | how did they get the preimage? |
| 23:21:46 | GreenIsMyPepper: | the recipient generates it (as an example in the paper, there may be other configurations) |
| 23:21:58 | thufir: | GreenIsMyPepper: what changes to bitcoin protocol does your proposal neccesitate? just the timelock thing? |
| 23:22:11 | kanzure: | malleability bip62 things |
| 23:22:21 | gmaxwell: | dgenr8: thats not so, it (and micropayment channels in general) actually do allow fast payments without non-trivial funds loss risk! |
| 23:22:30 | thufir: | hehe, as i said: FIX IT! :) so many provable viable solutions depend on just that! |
| 23:22:39 | gmaxwell: | ugh ignorance. |
| 23:22:46 | kanzure: | thufir: huh? i was answerying your question. |
| 23:22:51 | dgenr8: | gmaxwell: you ignored the word "arbitrary" |
| 23:22:52 | GreenIsMyPepper: | the biggest impediment is resolving malleability in a specific way, you need to be able to generate a spend on a transaction BEFORE the transaction can be broadcast-able on the blockchain |
| 23:22:55 | thufir: | kanzure: yes, thanks, was just being ffunny |
| 23:23:23 | GreenIsMyPepper: | (still not sure whether dgenr8 is concern trolling, but I'm giving him the beneifit of the doubt because that draft is unnecssarily complicated) |
| 23:23:24 | kanzure: | GreenIsMyPepper: "simple! just enumerate and sign all possible transaction variants. duh." |
| 23:23:28 | gmaxwell: | The lightning stuff has multiple layers with different requirements, the full vision requires supporting a special kind of safe malleability that needs a new checksig operator. |
| 23:23:50 | gmaxwell: | The lighter versions are not really aided by BIP62. |
| 23:23:54 | kanzure: | ah |
| 23:24:14 | thufir: | well in 4 years i'll be a math major so to fix malleiability, but maybe you guys can do it before that. |
| 23:24:23 | thufir: | ^grad |
| 23:24:23 | dgenr8: | GreenIsMyPepper: what stops me from double-spending my payment? |
| 23:24:27 | kanzure: | haivng a major doesn't mean things are fixed |
| 23:24:42 | thufir: | right, but it means i am a cryptographer and working on solving it |
| 23:24:48 | gmaxwell: | Malleability is an intentional _feature_ of bitcoin, not a bug that can just be 'fixed', -- unwanted malleability is a limitation, or malleability having consequences like invalidating respends is a limitation; both of which are interesting to improve. |
| 23:24:53 | kanzure: | thufir: that's an argument from authority |
| 23:24:58 | GreenIsMyPepper: | right now, bitcoin can't spend off exisiting transactions without making it broadcast-able on the blockchain. it's sort of if you wanted to create a contract and put funds into escrow, it's impossible to draft a contract before cutting a check to some unknown contract (weird!) |
| 23:25:56 | thufir: | if rsa sigs were used instead of ecc (yes then keys would be gigantic, and cracked soon as prime number patterns are found, etc), but that is not point.. if it were not ecc but rsa then it would be only one possible sig and no problem right? |
| 23:26:19 | GreenIsMyPepper: | dgenr8: the system is reliant upon double-spending, actually. older versions are "invalidated" by creating penalties. if an old one is broadcast, the other party gets (effectively) ALL the money in the channel |
| 23:26:50 | thufir: | or, what is the feature that the malleability intended to give us that we have now? |
| 23:26:55 | dgenr8: | GreenIsMyPepper: when I asked how recipient (aka payee) gets the preimage, you said "recipient generates it." was that right? because you lost me there |
| 23:27:21 | gmaxwell: | thufir: intentional malleability is what makes things like lighthouse possible. |
| 23:27:40 | GreenIsMyPepper: | thufir: you need to SPEND a transaction before it it signed, that is not possible today, even if you changed crypto algorithms, because a component of the txid being spent is the signature |
| 23:28:50 | GreenIsMyPepper: | which is why it's sort of like being unable to draft a contract before funding the escrow |
| 23:28:51 | gmaxwell: | thufir: "as prime number patterns are found" is technojibberish. What you're referring to is a unique signature; RSA can give you a unique signature if you choose the right padding scheme.. there are other ways to get a unique signature (e.g. hash signatures are usually unique, BLS is unique). But a unique signature is not necessary or sufficient to prevent unwanted malleability. |
| 23:29:20 | thufir: | not jibberish.. it is what makes rsa weaker with such discoveries |
| 23:29:57 | thufir: | but i am vagly understanding what you are saying about the signing including the spend, thus the algo is not the problem |
| 23:30:28 | dgenr8: | GreenIsMyPepper: the system may rely on double-spending in some way. but i'm asking specifically about the funding transaction itself, where I actually pull money out of my wallet. why can't I double-spend that? |
| 23:31:00 | Apocalyptic: | not jibberish.. it is what makes rsa weaker with such discoveries // even assuming you mean we have a quick way to enumerate prime numbers, it doesn't yield a reasonable factoring algorithm |
| 23:31:36 | GreenIsMyPepper: | thufir: If we both agree to both fund transaction F, and create a 2-of-2 output refund tx R, we cannot make R before F. in order to make R one or both of us will be able to broadcast F on the blockchain without creating R. in that case money can be locked up forever with hostile counterparties. |
| 23:31:44 | thufir: | Apocalyptic: do you not see that such discoveries have been made and continue to be made and each one decreases the amount of work needed to factor thus meaning a larger key is needed for the same strength for that point in time? |
| 23:31:48 | gmaxwell: | thufir: There is no 'prime number patterns' to factoring advances. (Also, factoring and discrete log are very closely related problems; it's incorrect to regard their security as completely independant of each other... state of the art discrete log solvers for some EC groups look _very_ much like the number field sieve.) |
| 23:31:52 | GreenIsMyPepper: | that is the case because to make R, we must get the txid of F (which contains the signatures!) |
| 23:32:37 | thufir: | gmaxwell: yes, not saying ecc is immune to such patterns as well. i would assume they are going to be found just as with primes and we will have to find the next tech when ecc keys become unwieildly as well |
| 23:32:49 | GreenIsMyPepper: | dgenr8: You can double spend that until it enters into the blockchain. The funding transaction is actually committed to the bitcoin blockchain. Once it does, the channel is open and you can begin to do instant transactions. |
| 23:33:06 | Tiraspol: | Tiraspol is now known as bloodz |
| 23:33:09 | dgenr8: | GreenIsMyPepper: fine, I rest my case |
| 23:33:10 | Apocalyptic: | I still don't get what you mean by "prime number patterns", can you be more explicit and formal ? |
| 23:33:34 | GreenIsMyPepper: | dgenr8: therefore, you shouldn't tust the funding transaction (and thereby the payment channel) as open UNTIL the funding transaction enters into the blockchain. |
| 23:33:50 | GreenIsMyPepper: | dgenr8: if the funding transaction is double-spent, no one has lost money because the payment channel has never opened in the first place. |
| 23:34:01 | thufir: | patterns in math are found. then no longer do you have to calculate as blindly to the more optimal algorithms. use the pattern to simply essentially. |
| 23:34:31 | bloodz: | bloodz is now known as Tiraspol |
| 23:34:56 | gmaxwell: | thufir: FWIW, it's been on the order of ~20 years since the last non-trivial algorithimic improvement to the asymtopic complexity in factoring; the need to increase key sizes has mostly been driven by basic engineering improvements (faster algorithims; proposed hardware designs) in that time. There has been a lot more recent progress on ECDLP (though only in special groups). |
| 23:35:23 | dgenr8: | GreenIsMyPepper: neither has an arbitrary payment been made at "lightning" speed |
| 23:35:25 | thufir: | first part not true at all. your second part is true/ |
| 23:35:27 | Apocalyptic: | so much for formality I guess |
| 23:35:58 | GreenIsMyPepper: | dgenr8: it's lightning AFTER the funding transaction is committed (enters into the blockchain). it's like saying "Credit cards aren't instant because it takes 5 days for the bank company to mail you the credit card" |
| 23:36:05 | thufir: | it is the patterns that will make it no work at all. the enginnering is only small improvements compared to new math. |
| 23:36:33 | thufir: | anyways, back to LN :) |
| 23:36:39 | Apocalyptic: | gmaxwell, I suspect he hasn't a clue about what he's talking about |
| 23:36:44 | gmaxwell: | Apocalyptic: correct. |
| 23:36:56 | thufir: | well you have both proved yourselves ignorant then |
| 23:37:13 | dgenr8: | GreenIsMyPepper: yes, it's very much like that |
| 23:38:05 | thufir: | GreenIsMyPepper: when you said the 2-of-2 output example. you are saying this is current bitcoin. What does your paper purpose to do instead? |
| 23:38:18 | GreenIsMyPepper: | thufir: not sign the input txids |
| 23:38:49 | thufir: | ah.. what changes then are needed for that? |
| 23:38:54 | GreenIsMyPepper: | thufir: that way you can generate spends from a hypothetical funding transaction before signing that funding transaction, so long as the output of the funding transaction uses unique output addresses |
| 23:39:06 | thufir: | ah.. nice |
| 23:39:46 | GreenIsMyPepper: | I'm in favor of a scary name, like SIGHASH_DANGEROUSLYPROMISCUOUS :^) |
| 23:40:21 | thufir: | Would peter todd's midstate proposal work for that? |
| 23:40:34 | GreenIsMyPepper: | mistate proposal? is there a link? |
| 23:40:50 | gmaxwell: | thufir: Your antagonism is really misplaced here, and not really welcome-- You're arm waving. The last asymtopic advance in factoring for RSA number is the general number field sieve which is decades old. |
| 23:40:51 | thufir: | umm. not yet, afaik :( |
| 23:41:26 | thufir: | gmaxwell: you are obsessed with attacking something that i mentioned as a way to describe the actual question i was asking. not sure why the negativity from you or obsession with fighting me on a point that was not the topic |
| 23:41:37 | kanzure: | that's not negativity |
| 23:41:55 | kanzure: | correcting someone who is wrong is not negativity |
| 23:42:00 | gmaxwell: | (I mean,... I have 512 bit RSA numbers I factored almost a decade ago using GNFS...) |
| 23:42:17 | thufir: | it is an open question. many mathematicians would agree and also disagree with you. lets stay on topic |
| 23:42:30 | gmaxwell: | thufir: it's not a big deal, but if you're going to tell me that I'm wrong and insult me, it helps to actually be correct, and you certantly should expect a correction on it. |
| 23:42:33 | kanzure: | prime numbers are on-topic |
| 23:42:50 | gmaxwell: | Or in general the security of cryptographic constructs is on-topic. |
| 23:43:01 | thufir: | i am sorry for responding to Apocalyptics insult with the word ignorance that included you then, my appology |
| 23:43:17 | kanzure: | wasn't there a recent prime number sieve on arxiv |
| 23:43:26 | kanzure: | .g site:arxiv.org prime number field sieve |
| 23:43:26 | yoleaux: | http://arxiv.org/abs/1408.0718 |
| 23:43:44 | thufir: | if you are going to tell me I am wrong then the same. it is an open problem, neighter of us are confirmed correct, and it is not what we were talkinga bout which is LN |
| 23:43:45 | kanzure: | hmm not that one |
| 23:43:57 | kanzure: | wasn't your question a matter of historical fact |
| 23:44:08 | kanzure: | s/question/statement |
| 23:44:18 | gmaxwell: | It was a matter of historical fact, AFAICT. About why people are driving for larger RSA key sizes. |
| 23:44:22 | thufir: | no, i was asking: is it ECC SIG algo that is the issue, ie, RSA would not have the problem.. that question has been answered |
| 23:45:33 | Apocalyptic: | thufir, you made a claim, was corrected by gmaxwell but keep on insisting that you're correct, failing to mention any reference whatsoever or define your terms |
| 23:45:34 | gmaxwell: | My understanding is that thufir proposed that RSA was 'weak' and people were driving for larger key sizes because of more 'patterns in prime numbers' being found; None of the relevant algorithims for factoring RSA numbers can fairly be described as 'patterns in prime numbers', and new algorithims have not been driving industrial practice to the best of my ability to determine. |
| 23:46:02 | gmaxwell: | thufir: I did also point out that unique signatures were not a necessary or sufficient criteria for any kind of malleability concern. |
| 23:46:08 | dgenr8: | GreenIsMyPepper: regarding capacity, good luck with TBLN. so far i'm in the "build out as much core capacity as safely possible, and let the fee market sort the rest out". but only so far ;) |
| 23:46:09 | thufir: | in your opinion, which is wrong in mine and many mathematicians. it is an open problem. give it a rest, my ... |
| 23:46:23 | thufir: | gmaxwell: thanks, that is more constructive response |
| 23:47:00 | gmaxwell: | thufir: It's not a matter of opinion, feel free to go point to the supposed advances you're referring to. I've also been directly involved in pushing for larger minimum key sizes (e.g. when I was at mozilla), and I think I understand my own motivations! |
| 23:48:02 | thufir: | great, open problem, i'm no longer listening to your non-constructive input. it is irrelivent. obviously you are a fanboy of rsa or something and i have hit a nerve, my appologies, nothing against rsa okay? |
| 23:48:49 | gmaxwell: | thufir: No, I'm not a fan of RSA. I'm a fan of informed statements though; and a non-fan of techwunder armwaving. |
| 23:49:01 | thufir: | so then you are disqualified. thanks |
| 23:49:49 | thufir: | GreenIsMyPepper: were you at all saying that the intended malleability feature is actually needed for your proposal? |
| 23:50:00 | gmaxwell: | Your comments have repeadly been of the form "strong opinion BECAUSE MAGIC" and you've responded adversarily to attempts to decide or demystify the magic. It's your own perogative if you want to behave that way, but this is the wrong venue for that. |
| 23:50:15 | thufir: | that didnt' contribute. ignored |
| 23:50:30 | kanzure: | "anything that makes me question something is wrong"? |
| 23:50:56 | gmaxwell: | thufir: Whats your goal in here? I'm having trouble constructing a rational mental model for your antagonizing me, you realize what result this is going to have-- right? |
| 23:51:08 | kanzure: | but yeah i'd have to agree, this is not a good place to make handwaving statements (except in jest or humor) |
| 23:51:30 | gmaxwell: | well you can make them, but be prepared to see them dissected ruthlessly. :) |
| 23:51:34 | kanzure: | (or unless clearly bounded) |
| 23:51:37 | thufir: | not sure what value you are if this is the way you act, so no loss to ignore you. you included kanzure. although you had almost redeemed yourself since we last spoke |
| 23:52:05 | gmaxwell: | gmaxwell has kicked thufir from #bitcoin-wizards |
| 23:52:15 | kanzure: | very strange conversation |
| 23:52:18 | copumpkin: | indeed |
| 23:52:22 | gmaxwell: | sorry for the drama there. |
| 23:52:22 | kanzure: | * kanzure goes off to flip some bits |
| 23:52:23 | copumpkin: | * copumpkin puts popcorn back |
| 23:52:33 | ajweiss: | what was he even trying to argue? |
| 23:52:57 | kanzure: | poor thinking and reasoning |
| 23:53:05 | copumpkin: | * copumpkin gets ready for joinfloods and the usual crap that comes with banning someone in this community |
| 23:53:12 | kanzure: | arguments to authority |
| 23:53:16 | kanzure: | s/to/of |
| 23:53:37 | gmaxwell: | better to just move on, if anyone is unhappy about that; feel free to yell at me in private (I will not think badily of you for it) |
| 23:53:46 | copumpkin: | seems good |
| 23:53:57 | copumpkin: | * copumpkin crawls back into his ready hole |
| 23:54:07 | copumpkin: | err, that sounds bad |
| 23:54:18 | kanzure: | s/ready/reading |
| 23:54:28 | copumpkin: | that's what I intended |