01:06:26 | rusty: | amiller: I'm enjoying your Research Perspectives paper. Nicely done! |
01:06:48 | amiller: | ty rusty |
01:36:21 | rusty: | amiller: surprised you didn't mention the downsides of merge mining; ISTR some paper bringing up that it lowers the cost of a goldfinger attack (was Elgius vs CoiledCoin merge mined?) |
01:37:24 | amiller: | hm, we mentioned the coiledcoin story in a footnote, and didn't say anything about the downside of merge mining, thats a good point |
01:40:49 | rusty: | amiller: yes, I followed the coiledcoin reference with some interest, since I'd not heard that before. Thanks! |
01:41:19 | amiller: | oh, yeah i see what you meant, yes the coiledcoin vs eligius is a perfect illustration of that so it shouldn't be hard to make that point |
01:43:07 | rusty: | amiller: you repeat the 7tps number, but not sure that's accurate. Eyeballing charts gives around ~700 transactions in a ~1/3MB block, implying 2100 transactions in 1MB -> 3.5 TPS. |
01:52:01 | rusty: | amiller: I would verify that properly, but I was stupid enough to choose btrfs for my test system's root fs, and now of course it won't boot. |
01:57:51 | rusty: | amiller: [98] was genuinely chuckle-worthy. |
02:00:45 | justanotheruser: | amiller: even worse, I don't think the pool was used |
02:00:55 | amiller: | ? |
02:01:07 | justanotheruser: | IIRC, it was just the hardware he owned |
02:01:20 | amiller: | oh |
02:01:31 | amiller: | well, that seems more fair in a way |
02:01:56 | justanotheruser: | It also demonstrates even more strongly the downside of merged mining since only a subset of eligius was needed |
02:21:55 | rusty: | amiller: typo in Appendix X. "ADS protocols (e.g., Merkle trees) a protocols allowing a verifier ". s/ a / are /. |
02:41:51 | zooko`: | Hi rusty! Nice to see you here. |
02:41:56 | zooko`: | zooko` is now known as zooko |
02:42:04 | zooko: | I enjoyed the LWN article about your coin. |
02:42:47 | rusty: | zooko: thanks.... it's kind of fun to give a talk on all the ways gmaxwell is smarter than me :) |
02:42:55 | zooko: | :-) |
02:43:02 | zooko: | Sounds like a fun topic. :-) |
03:01:50 | fanquake_: | fanquake_ is now known as fanquake |
03:26:17 | amiller: | cool https://lwn.net/Articles/630805/ i hadnt seen it: Pettycoin and sidechaining |
03:28:53 | amiller: | hahahaha these slides |
03:54:13 | jcorgan: | wait...just read on the Ethereum blog: "So one of the major things that needed sorting for the next release is the proof-of-work algorithm that we’ll use." Is this thing a forever moving target? |
03:55:18 | kanzure: | maybe it's a typo :-) |
03:56:30 | justanotheruser: | man, it was supposed to be released three months ago and they still don't have a pow |
03:57:21 | jcorgan: | to be fair the blog entry said they release Proof-of-Concept VII and VIII |
03:57:26 | jcorgan: | released* |
03:58:35 | rusty: | amiller: recommend the video, actually: https://www.youtube.com/watch?v=qq2EvH4eGLk . |
03:59:03 | kanzure: | .title |
03:59:05 | yoleaux: | Pettycoin: Towards 1.0 - YouTube |
03:59:19 | amiller: | jcorgan, it's a constantly moving target but it's been "basically" settled for at least a couple months now.. |
04:00:08 | justanotheruser: | the great thing about crypto proof of concepts is "working" doesn't mean anything |
04:00:54 | amiller: | justanotheruser, yeah.... the only proof is a *proof* (and that isn't a proof either) |
04:01:46 | justanotheruser: | my GPG proof of concept writes random letters after messages and accepts all messages as correctly signed |
04:01:55 | jcorgan: | it's probably off-topic here. i'm just sort of mystified by their dev process. if it were a commercial dev effort under sane engineering mgmt it would have been scrapped months ago i think. |
04:02:31 | kanzure: | i have been wondering about plausible "shutdown" scenarios and how they should handle that in an elegant way |
04:02:43 | justanotheruser: | shutdown? |
04:02:44 | kanzure: | perhaps if they decided they don't have anything, they should simply start contributing to bitcoin more directly? |
04:03:00 | kanzure: | yeah, i mean if they didn't want to keep all their crazy promises- what are the things they could do and still save face? |
04:03:12 | jcorgan: | i long ago stopped crying over how much excess energy goes into altcoins and spirals down the drain |
04:03:46 | justanotheruser: | kanzure: they will release a half-finished program |
04:04:00 | justanotheruser: | I wonder what their burn rate is |
04:06:56 | jcorgan: | the blog kind of reads like a high-school programming club |
04:11:15 | kanzure: | this is a fun query: site:math.stackexchange.com intitle:"intuitive explanation" |
04:23:10 | justanotheruser: | /win 21 |
05:24:04 | maaku: | rusty: the "approximately 7tps" number is assuming the absolutely smallest transaction possible |
05:24:21 | maaku: | obviously real transactions can be arbitrarily larger... |
05:25:25 | StephenM347: | And it also assumes 1MB blocks, but I think even larger blocks tend to be around 750 kb |
05:26:47 | StephenM347: | https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L51 |
06:07:43 | adam3us1: | rusty: did you see this? http://lightning.network/lightning-network.pdf |
06:08:21 | rusty: | adam3us1: is on my reading list.... you just bumped it up :) |
06:09:40 | rusty: | adam3us1: was there more than just the slides anywhere? |
06:10:26 | rusty: | * rusty finds draft whitepaper... |
06:10:35 | adam3us1: | rusty: joseph gave a presentation at the sf bitcoin meetup, i think the video should go online within a few weeks. yes that too |
06:12:27 | bramc: | There's a draft paper but I have yet to read it and don't know if it's okay to redistribute |
06:16:26 | smooth: | http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf |
06:17:18 | smooth: | both are linked from http://lightning.network |
07:38:52 | fluffypony: | justanotheruser: they'll release a half-finished program and then layer complexity on top of it to "fix" it...till they run out of money |
07:43:33 | Taek: | and then they'll raise $40m more b/c people believe in them |
07:44:09 | justanotheruser: | No way they'll raise another 40m |
07:44:26 | justanotheruser: | the might get arrested for an illegal IPO before then |
07:45:02 | fluffypony: | lol |
08:37:45 | dc17523be3: | re: lightning network, section 9: Use Casaes :D |
08:39:23 | fluffypony: | dc17523be3: casa as in "home", es as in "is" |
08:39:53 | fluffypony: | so "Home Use Is"...or how Manuel from Fawlty Towers would write "home uses" |
08:50:37 | bramc: | argh, there's an annoying withholding attack. If rewards are given to the top two, then a pool which has number 3 and either 1 or 2 can get more than their fair share by withholding |
08:59:44 | bramc: | Looks like it needs n=3 or 4 to get around that |
09:05:16 | verne.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 |
09:05:16 | verne.freenode.net: | Users on #bitcoin-wizards: andy-logbot lclc_ rusty d1ggy Dr-G oujh CoinMuncher wallet42 gribble Mably vmatekole coryfields p15 hktud0 CodeShark paveljanik bramc shesek coiner damethos prodatalab dgenr8 devrandom brisque luny` Pan0ram1x SubCreative dc17523be3 Logicwax hashtagg_ helo melvster bosma waxwing arubi PaulCapestany Hunger- xabbix nuke__ adam3us1 go1111111 justanotheruser burcin runeks gonedrk OneFixt sdaftuar weex_ adlai kyletorpey espes__ null_radix bedeho |
09:05:16 | verne.freenode.net: | Users on #bitcoin-wizards: cryptowest copumpkin Cory gmaxwell flower PRab amincd Emcy c0rw1n hashtag_ huseby jaekwon_ GreenIsMyPepper sneak ebfull SwedFTP bepo MoALTz_ LarsLarsen epscy nanotube gavinandresen tromp cluckj Starduster binaryatrocity spinza andytoshi bliljerk101 tromp__ wizkid057 starsoccer comboy nsh Taek iddo EasyAt maaku btcdrak NikolaiToryzin s1w Visheate crescendo livegnik asoltys_ optimator fluffypony Meeh cursive yoleaux dansmith_btc [d__d] berndj |
09:05:17 | verne.freenode.net: | Users on #bitcoin-wizards: Luke-Jr morcos nickler Fistful_of_Coins dardasaba sl01 isis gwillen BlueMatt face airbreather dasource smooth phantomcircuit ajweiss Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo forrestv Muis platinuum Oizopower BananaLotus Keefe catlasshrugged JonTitor petertodd kanzure eric mappum jbenet wiz grubles midnightmagic heath gnusha warren Adrian_G Iriez lechuga_ dignork kinlo jessepollak ahmed_ Graet ryan-c Eliel veox |
09:05:17 | verne.freenode.net: | Users on #bitcoin-wizards: amiller warptangent indolering K1773R TD-Linux leakypat CryptOprah Apocalyptic guruvan Anduck paperbot fenn harrow a5m0 d9b4bef9 DoctorBTC mr_burdell NeatBasis davout Alanius brand0 @ChanServ throughnothing btc___ HM2 azariah MRL-Relay otoburb hguux__ so phedny bbrittain jaromil jcorgan wumpus BrainOverfl0w roasbeef |
09:39:48 | brisque: | jcorgan: as far as I can tell their mining algorithm hasn't been defined by more than some hand waving and a small code base that's still getting major design changes fairly frequently. it seems to be at least partly justified by the community as "oh well we will be PoS soon". |
09:42:00 | brisque: | jcorgan: if you look into the material it doesn't seem all that particularly well thought out as a system. the reward for mining is alarmingly low if you take their IPO price to be somewhat indicative of its actual value (probably not sane, but there's no other point of reference). |
10:03:27 | Starduster: | Starduster has left #bitcoin-wizards |
11:22:45 | brisque: | jcorgan: actually ignore that, I missed that they made a blog post in the last few hours which at least partially scrapped their Dagger Hashimoto algorithm as well. "a swift audit of Vitalik and Matt’s initial algorithm by Tim Hughes .... showed major flaws. With his help, they were able to work together to devise a substantially more watertight algorithm" |
11:23:29 | brisque: | ".. , we are confident to say, should make the job of developing an FPGA/ASIC sufficiently difficult, especially given our determination to switch to a proof-of-stake system within the next 6-12 months" |
11:24:11 | jcorgan: | that's the entry i had just read |
11:25:29 | brisque: | yes, failure on my part. |
11:28:02 | jcorgan: | meanwhile, plain old stodgy boring mainstream non-hipster bitcoin goes on :) |
11:32:47 | fluffypony: | with it's power-hungry PoW |
11:33:00 | fluffypony: | but don't worry, I hear it's switching to X11 soon :-P |
11:37:59 | brisque: | in my mind at least, they haven't answered the question why they're even attempting to be hardware resistant. |
11:43:06 | jcorgan: | it seems a rather whiny reaction to the industrialization of bitcoin mining, and the fact that you can't "get rich" making free internet moneys with a CPU or botnet |
12:40:04 | adam3us: | adam3us has left #bitcoin-wizards |
12:44:59 | adam3us: | brisque: isnt it against the social contract to replace mining with PoS. there was a mining supply curve and premine allocation before the "investment"/ICO. you'd think a PoS would change the economics .. give more coins to those who already have coins (good for ICO buyers in a short-termist thinking) but maybe bad for them in that everyone else gets annoyed and dumps. if/when that happens wont there be unhappy "investors". |
12:46:17 | adam3us: | brisque: i guess they did have lawyers so given the investor had no representation it might be a bit rumpelstiltskin such that they can change the allocation, mining supply, premine, ownership etc at will. |
12:47:02 | brisque: | adam3us: I would have thought so. they've added in something called "the bomb" to their genesis block. some hardcoded contract which creates infinite inflation if anybody decides to continue the proof of work system past where the proof of stake one forks off. |
12:47:31 | brisque: | adam3us: it's an odd expectation that they think proof of stake isn't possible now, but that they will have figured it out in 6-12 months, too. all evidence to the contrary at the moment. |
12:48:43 | adam3us: | brisque: well also proof of stake has problems day 0, even if a non-grindable PoS was found, with bitcoin satoshi would own 100% :) |
12:49:51 | adam3us: | brisque: so probably they need a bit of PoW just to hand out the non-premined coins. well i suppose they already handed out the premined coins, so then they wouldnt need PoW and could just cancel the mining concept period if they chose. then if no one sells they own a fixed % of coins perpetually as they win in proportion to their stake |
12:50:49 | adam3us: | brisque: thats more mastercoin like though just with some NPV-zero pricing inflation (where your % ownership in the coin stock stays constant but your number of nominal coins increases). |
13:00:22 | brisque: | adam3us: I read it as a limitation of their knowledge of proof of stake, rather than distribution problems. for ethereum in particular, they already have a non-lumped distribution due to their IPO. |
13:01:36 | nickler: | To the people interested in Ethereum vulnerabilities: An attacker can generate a transaction with negative amount s.t. her balance is actually increased. https://github.com/jonasnick/eth-neg-value-tx |
13:02:25 | brisque: | * brisque snickers |
13:02:55 | fluffypony: | oh well, you know, there's that |
13:10:24 | adam3us: | brisque: i guess my point is whats the point of a npv-zero activity. just as well premine, distribute and call it done. a rational player should see that changing your number of nominal coins with ownership % held constant is ownership-neutral. |
13:11:32 | adam3us: | brisque: so then its maybe more like a negative incentive to force you to participate in PoS based transaction validation. dont participate and your % ownership is reduced via inflation. |
13:22:01 | adam3us: | brisque: i think one cant say that about PoW mining with ASICs as there is an investment risk and capital cost. |
13:23:05 | brisque: | adam3us: FPGAs, not so much. the only investment is a big bottle of port and some VHDL. |
13:24:21 | brisque: | in a lot of ways programable logic is preferable over etching your design in silicon. you can make incremental "fuck it" designs, where as with a ASIC you can't really do a half ass job and patch it up later. |
13:24:54 | jcorgan: | brisque: whisky, not port |
13:36:53 | brisque: | nickler: nice catch. not sure if that's a laugh or cry situation. |
13:46:52 | adam3us: | brisque: with the assumption being that fpgas are resellable or reusable for other things, which asic miners are not. |
13:47:24 | nickler: | brisque: neither, it's a situation worth 5 btc |
13:47:28 | adam3us: | brisque: otherwise fpga's cost money too. and use more power per hash. |
13:48:40 | brisque: | adam3us: yes, I made the comment based on the assumption that people already have them (and they do). for some period of time you were actually better off with smaller process size FPGA than the available Bitcoin ASICs. |
13:50:00 | adam3us: | brisque: you have to wonder if the energy efficiency delta between fpga & asics could be narrowed if there was ongoing demand for faster, more energy efficient fpgas |
13:53:37 | brisque: | adam3us: maybe, I don't know a heap about that particular industry. there's 16nm FPGA available now I think. |
13:55:47 | adam3us: | brisque: apparently there are some people with fpgas that rush to implement the latest new PoW varianets and mine alt-coins to flip on cryptsy for bitcoin |
13:55:55 | brisque: | adam3us: probably not competitive with bitcoin asics still. the ability to chain them in series gets rid of a lot of the cost of making bitcoin mining hardware, that is you lose all the big bulky VRMs and massive resistive losses trying to push hundreds of amps at 0.6v around a copper clad board. |
13:57:16 | brisque: | adam3us: I believe it's the other way around. altcoins are designed specifically for FPGA mining, and then an altcoin is build around that algorithm. |
13:57:58 | fluffypony: | under the guise of it being "ASIC proof" |
13:58:09 | fluffypony: | meanwhile the dev, if you'll excuse the pun, is coining it |
15:43:22 | brisque: | fluffypony: well you can find lots of instances of altcoins claiming that they do things with they most certainly do not. most if not all of them with "unique" features are generally undesirable or broken in concept, execution, or both. |
15:49:26 | brisque: | Ethereum has posted some more information about their launch scheme, they'll actually be launching the network 3 times under increasingly goofy names, "frontier", "homestead" and "metropolis", somewhat alarmingly with differing consensus rules but all the same block chain. |
15:53:12 | brisque: | actually there'll be five stages (two goofy names as yet unknown). some have reduced block rewards, some have centralised "checkpoints", some method of a centralised authority undoing blocks. that's going to be a nightmare to deal with in terms of legacy validation. |
15:54:26 | jgarzik: | introduces some legal liability too |
16:08:10 | adam3us: | brisque: wut? how does that even make sense :) i was thinking they'd have to freeze parameters on launch! social contract = which way the wind is blowing today? |
16:10:19 | fluffypony: | what social contract |
16:10:35 | fluffypony: | Darkcoin published their emission curve formula in their whitepaper |
16:10:41 | fluffypony: | so I graphed it against reality |
16:10:44 | fluffypony: | http://i.imgur.com/nAHt0T9.png |
16:10:49 | fluffypony: | http://i.imgur.com/qr8Yh5T.png |
16:11:13 | fluffypony: | "social contract" is meaningless to most of the perceived leaders in that space |
16:11:19 | fluffypony: | /rant |
16:12:25 | adam3us: | fluffypony: bbut if the social contract is repeatedly changed by human choice.. what does it even mean. conflict of interest will arise and shape the human changes. central control is needed. the users could revolt and reject change. etc. |
16:13:19 | fluffypony: | good point |
16:13:21 | adam3us: | fluffypony: it maybe lack of distributed system / adversarial thinking. implicit trust of self as arbiter of what is best and right. |
16:13:28 | fluffypony: | we need centralised control |
16:13:41 | fluffypony: | let's call them "checkpointers" because then it sounds decentralised |
16:14:00 | fluffypony: | and we'll use...uh...voting, yes, voting...because democracy = freedom |
16:14:08 | adam3us: | fluffypony: i mean they end up by design, or later need installing central control to effect these planned or unplanned changes. (like stellar! oops, and centralised 100%) |
16:14:30 | adam3us: | fluffypony: ah now we're taking the piss :) ok gotcha. |
16:14:41 | fluffypony: | :-P |
16:16:03 | brisque: | I was mainly thinking about the stability of the system more than anything else. seemingly their cake is dry enough both from that standpoint that they believe they need a centralisation crutch to hold it together, and their efforts at this seem to make it even crumblier. I don't quite follow reducing the mining reward at the beginning, for example, it just seems to complicate the codebase unnecessarily and add lots of fun edge cases. |
16:17:02 | adam3us: | brisque: you know you've failed when someone takes all the coins via algo defect and offers to give them back if you fix it. |
16:17:57 | adam3us: | brisque: they enjoy complexity i think. |
16:18:02 | brisque: | adam3us: I'm not quite sure I follow |
16:18:46 | adam3us: | brisque: no serious point. just the funniest fail in an alt, when someone took possession of most of the coins due to a defect of some kind and wouldnt give them back until they fixed the defect. |
16:19:01 | adam3us: | brisque: forget which alt that was. |
16:20:17 | jcorgan: | adam3us: the older and more experienced we get, the more we shun unnecessary complexity. they have a long way to go in that regard. |
16:20:34 | kanzure: | screw that, i'll be young forever |
16:22:55 | fluffypony: | I agree with adam3us |
16:22:56 | fluffypony: | in fact |
16:23:11 | fluffypony: | the more complex it is the more of a cult following it attracts |
16:23:19 | fluffypony: | because they seem to thrive on a "dev worship" complex |
16:23:45 | fluffypony: | ignoring any suggestion that maybe the underlying decisions / architecture could possibly be flawed with lots of hand-waving and "dev is a genius" commentary |
16:24:32 | kanzure: | oh i wouldn't say that, i think they would be ready to drop their kindness towards developers quite quickly |
16:25:10 | fluffypony: | it depends on if they can, individually, offload their bag fast enough |
16:25:37 | jcorgan: | fluffypony: again, my observation that the whole thing is reminiscent of a high school science club |
16:26:01 | fluffypony: | nice observation, jcorgan |
16:27:06 | fluffypony: | I've latched on to something andytoshi said the other day about the amount of "amateur cryptography" in that space, I also think it's a great way of describing it |
16:27:45 | fluffypony: | it's like NASA entrusting the next shuttle launch to the local model rocket club (except somehow not as dignified) |
16:28:34 | jcorgan: | the unfortunate aspect imho is that there are some talented people in that community that with guidance and peer review/encouragement could make solid contributions to what we're doing |
16:29:34 | brisque: | it's possible you can attribute this behaviour to the fact that there's a lot of people involved that all think things should be done in a certain way. the committee ends with "we'll do all of it" rather than making an authoritative decision as to the direction and execution. |
16:29:50 | fluffypony: | * fluffypony ponders |
16:31:23 | adam3us: | i dont think most of it would be happening without the "to the moon" pot of gold in mind. |
16:31:36 | skittylx: | ^ |
16:31:40 | fluffypony: | yes |
16:32:50 | fluffypony: | I don't think there's ever been a FOSS environment, that I can recall anyway, that was so indelibly tied to wealth |
16:32:55 | fluffypony: | you can't scam people by cloning mysql |
16:34:08 | jcorgan: | well, i could be wrong, but i predict it will all end in tears for them. hopefully we can absorb some of the devs, who in their disillusionment, become willing to learn from it |
16:34:38 | brisque: | fluffypony: you'll also notice that developing actual bitcoin software is almost entirely unprofitable for everyone. |
16:35:28 | fluffypony: | brisque: oh I know - it's the same with Monero, donations are sparse and demands are many |
16:35:49 | fluffypony: | especially from "investors" that think they're somehow paying us money because they bought something on an exchange |
16:35:59 | skittylx: | brisque: no profit, not without breaking a social cintract some how. |
16:36:07 | skittylx: | contract* |
17:49:03 | Muis: | what would be the easiest way to make a client that supports multiple chains? |
17:49:20 | Muis: | for example, to have both mainnet and testnet, I have to run two daemons |
17:49:36 | brisque: | Muis: OT #bitcoin |
17:50:12 | Muis: | brisque: im looking for a way to simulate treechains, it has not so much to do with bitcoin itself |
17:51:51 | Muis: | if I run each chain as a seperate daemon, they do not share their peer-list.. I want to know if there other disadvantages, or that it makes no sense to combine them |
18:00:03 | brisque: | Muis: still off topic really. they can't possibly share peers if they're on different networks, so that doesn't make a whole lot of sense anyway. |
18:11:33 | Muis: | brisque: if they have on average at least 10% of their networks in common for example, why wouldnt it make sense to share peers? |
18:12:22 | Muis: | 1 in 10 peers would carry more than one network they are interested in |
18:12:44 | brisque: | the network magic is different. you literally can not connect one to the other. |
18:13:15 | maaku: | Muis: there is no addresses in common between separate networks |
18:13:20 | maaku: | the question doesn't make sense |
18:13:51 | Muis: | you have one main network |
18:14:03 | Muis: | each transaction on the main network forms the genesis block/tx of a new network |
18:14:34 | Muis: | and each client may choose to follow some of these 'branches' |
18:14:41 | pigeons: | it would be a bad assumption that a peer on one net is a member of some other network unless you learn this from p2p on the other network, dns seeding of other network, etc |
18:14:53 | Muis: | but since most of them have 0 seeders/peers, it wouldnt not make sense to have different ports/networks |
18:14:59 | kanzure: | what are you actually trying to do? |
18:15:12 | maaku: | pigeons: no it goes beyond that. remember that the port number is part of the peer description. you can't have two networks on the same ip:port |
18:15:18 | Muis: | im trying to decentralize a forum |
18:15:24 | kanzure: | what does that mean |
18:15:31 | maaku: | Muis: I suspect that is where your problem lies |
18:15:32 | Muis: | each transaction on the main-net is a topic |
18:15:40 | kanzure: | why? |
18:15:48 | fluffypony: | Muis: this is an excellent idea - in fact, since a particular IP address on the Internet may server HTTP, or HTTPS, or SSH, or FTP, or whatever, then we should all share the connections where necessary |
18:15:52 | fluffypony: | we could do it via a stack of some sort |
18:15:56 | fluffypony: | a TCP/IP stack |
18:16:06 | Muis: | and for each topic a new chain is started with comments |
18:16:12 | pigeons: | i see maaku thanks |
18:16:31 | Muis: | and people who follow the main chain |
18:16:38 | Muis: | can choose to follow some of these side-chains |
18:16:46 | brisque: | fluffypony: careful with the snark, multiplexing is very useful sometimes. |
18:16:48 | kanzure: | you might be interested in this thing called usenet |
18:16:51 | kanzure: | it has a very interesting architecture |
18:16:55 | maaku: | Muis: a block chain is absolutely the wrong tool for this |
18:16:57 | Muis: | yes I familar with it |
18:17:05 | fluffypony: | brisque: as maaku said ^^ |
18:17:08 | Muis: | I want to bring usenet to the blockchain (or vice versa) |
18:17:18 | kanzure: | it would be more efficient to use usenet itself |
18:17:38 | Muis: | no |
18:17:46 | Muis: | its just for text, not binaries |
18:17:53 | brisque: | * brisque blinks |
18:17:59 | brisque: | usenet is for text. |
18:18:09 | Muis: | usenet is for both |
18:18:21 | brisque: | alt.binaries.* is a hack which stuffs binaries into posts. |
18:18:37 | Muis: | however |
18:18:55 | Muis: | if you compare each usenet-group to a network/sidechain in bitcoin |
18:19:20 | Muis: | how would I be able to realise something like I described, or would I have to write the code myself? |
18:19:40 | maaku: | Muis: "I want to bring usenet to the blockchain" <-- WHY? this makes no sense. |
18:19:42 | kanzure: | how would you square peg round hole? |
18:19:49 | maaku: | and this should probably be on #bitcoin |
18:20:18 | kanzure: | if we look at the distribution of round holes we find that square pegs are normally distributed |
18:20:22 | brisque: | Muis: I think you'd find it extremely hard to justify why this data should be in a block chain to begin with. it's the wrong tool for the task. |
18:20:49 | brisque: | kanzure: maybe we can encode binaries using a combination of round pegs in square holes, and square pegs in round holes. |
18:21:01 | kanzure: | brisque: right, some sort of cam/gear system |
18:24:29 | Muis: | brisque: I dont see why its the wrong tool for the task? |
18:25:03 | Muis: | an usenet-server and a bitcoin-daemon just exchange messages sorted by time |
18:25:41 | brisque: | Muis: conversely, can you explain why it is the right tool for the task? it's slow, expensive and inefficient, it's got to have good justification to overcome that. |
18:27:56 | instagibbs: | Muis: what problem are you trying to solve? |
18:33:43 | Muis: | instagibbs: I just need a distributed database for a project, and it seems easy to use bitcoin as a base |
18:34:02 | Muis: | unless any of you knows a better alternative? |
18:34:05 | Luke-Jr: | bitcoin is not a database |
18:34:09 | Luke-Jr: | try LevelDB |
18:34:15 | Luke-Jr: | that's what Bitcoin nodes use for their databases |
18:34:25 | Muis: | LevelDB is not distributed (in a peer 2 peer way) |
18:34:39 | Luke-Jr: | sure, but at least it's a database |
18:35:01 | Muis: | the blockchain is a database too |
18:35:04 | Luke-Jr: | no, it isn't. |
18:35:25 | Muis: | so how would you call it? |
18:35:27 | brisque: | it's closer to a database than say, a strawberry, but not by much. |
18:35:43 | instagibbs: | it's got data |
18:35:47 | instagibbs: | and a coinbase |
18:36:01 | instagibbs: | seriously though, if you need a distributed database, just google that term |
18:36:10 | Muis: | i did |
18:36:15 | Muis: | many times over the years |
18:36:22 | adlai: | it's a "database", but much more expensive to maintain than 'centralized' databases (or most other DHT protocols), and for this expense, you only earn consensus on the latest version |
18:36:34 | Luke-Jr: | Muis: Bitcoin's a consensus system, nothing like a database |
18:36:46 | instagibbs: | unless you're worried about someone "Double-spending" a file it's a complete waste of time and energy |
18:37:27 | Muis: | the people who can insert data in the chain, and the people who can read data from the chain needs to be seperated |
18:37:31 | justanotheruser: | Muis: the blockchain is a proof that the database is the database everyone else is using |
18:37:36 | fluffypony: | Muis |
18:37:37 | fluffypony: | seriously |
18:37:38 | Luke-Jr: | Muis: DHTs work for that just fine |
18:37:49 | fluffypony: | if you want to host a distributed forum just use Tahoe LAFS |
18:37:52 | brisque: | brisque has left #bitcoin-wizards |
18:37:52 | Muis: | and they can be seperated by transferring of 'coins', so double spending is applicable |
18:38:13 | fluffypony: | zooko: is your blog still hosted on a Tahoe LAFS backend? |
18:38:30 | justanotheruser: | when you have a blockhammer everything looks like a chainail |
18:38:38 | fluffypony: | justanotheruser: quite |
18:38:39 | Muis: | fluffypony: I know about Tahoe LAFS, but its not distributed like Bitcoin? the peers are all run by yourself? |
18:39:06 | fluffypony: | Muis: volunteers would run the peers, just like volunteers would have to run your usenetbastardchain |
18:39:36 | Muis: | true |
18:39:59 | Muis: | it was long time ago I looked at it, maybe I should research it again |
18:40:19 | justanotheruser: | if you want to force everyone who has some data to have all the data you can do it through means other than a blockchain |
18:40:27 | Muis: | but I believe availability was not guarantueed |
18:40:30 | justanotheruser: | but that probably isn't an ideal property |
18:40:42 | Muis: | with a blockchain, its always 100% intact as long as there is at least 1 peer left |
18:40:55 | kanzure: | that is not true of a blockchain |
18:40:58 | Muis: | with Tahoe LAFS, if there is only 1 peer left, the data is corrupt I think |
18:41:19 | instagibbs: | in bitcoin 1 peer can just say whatever it likes to bootstrappers |
18:41:20 | adlai: | the blockchain alone doesn't guarantee that there isn't a longer fork which you've not seen yet |
18:41:23 | fluffypony: | Muis: of course, if you're distributing partial data among peers that stands to reason |
18:41:58 | Muis: | fluffypony: i need all the data to be available even if there is only 1 peer |
18:42:07 | Luke-Jr: | Muis: bitcoin does not do that |
18:42:12 | fluffypony: | but then that one peer could just lie |
18:42:18 | fluffypony: | and ignore data changes |
18:42:37 | fluffypony: | "consensus" implies more than one peer agreeing with each other |
18:42:43 | fluffypony: | if you only have one peer then you're talking to yourself |
18:42:55 | Muis: | Luke-Jr: If I create a bitcoin-clone, why would I need more than 1 or 2 peers to make it work? |
18:43:08 | kanzure: | Muis: what is bitcoin? |
18:43:12 | Muis: | yes I ment 2 peers |
18:43:18 | Muis: | or 3 :) but not more |
18:43:21 | justanotheruser: | Muis: if you're the only source of information then you might as well just have a centralized database |
18:43:35 | justanotheruser: | #bitcoin is probably better for this |
18:43:43 | Muis: | justanotheruser: maybe I dont want to reveal the publisher of the information |
18:43:50 | Muis: | maybe I want to publish wiki-leaks like this |
18:43:51 | Luke-Jr: | Muis: are you sure you don't want git-annex? |
18:44:13 | justanotheruser: | oh the old luke git-eroo |
18:44:16 | Muis: | Luke: i will google that |
18:44:45 | kanzure: | when they say use #bitcoin they mean you should type "/join #bitcoin" and leave this channel |
18:45:05 | Muis: | it has nothing to do with Bitcoin |
18:45:19 | Luke-Jr: | right, maybe #bitcoin-offtopic is best |
18:49:03 | Luke-Jr: | hm, new VU440 FPGA can apparently fit ten Cortex A9 processors |
19:02:49 | amiller: | tahoe lafs can be volunteer-run but it's not really ideal that way |
19:03:36 | amiller: | its really best for either a) a club where the members know each other and kind of enforce participation out of band, or b) where a system administrator goes and sets up a computer at several different locaitons |
19:33:07 | brisque: | .title http://dualec.org/DualECTLS.pdf |
19:33:08 | yoleaux: | brisque: Sorry, that doesn't appear to be an HTML page. |
19:33:31 | brisque: | "On the Practical Exploitability of Dual EC in TLS Implementations" |
19:49:28 | nsh: | nice |
20:04:23 | waxwing__: | waxwing__ is now known as waxwing |
20:19:22 | bramc: | It turns out that withholding attacks inherently kill collaborative mining schemes |
20:20:12 | bramc: | So I'm back to working on simpler tricks |
20:43:58 | nsh: | can't witholding attacks be eliminated by tweaking the network protocol so you can request blocks in ranges and detect, mark as potentially hostile nodes that break contiguity? |
20:45:51 | justanotheruser: | nsh: How do you expect us to come into consensus on which nodes are malicious, let alone label blocks by node? |
20:46:07 | nsh: | yeah i don't know. magic presumably |
20:46:27 | nsh: | or tit-for-tat |
20:46:33 | nsh: | which is the closest we have to working magic afaik |
20:46:43 | justanotheruser: | I don't see how tit for tat is relevant |
20:47:34 | nsh: | might not be. i'm not claiming to have deep insights here |
20:47:42 | nsh: | or any at all :) |
20:48:46 | bramc: | nsh, I'm talking about collaborative mining schemes built into a mining protocol at the base level, not schemes for adding collaboration onto the winner-take-all mining rewards bitcoin has today |
20:51:17 | Eliel: | bramc: have you considered a simple tit for tat model for collaborative mining? That is, if someone presents you a share (not quite a block, but most likely required a lot of attempts to find) that would've paid you if it was a block, you then seek to return the favor. |
20:51:34 | bramc: | Eliel, this is something completely different |
20:52:07 | bramc: | the purpose of the collaboration on mining isn't to have fairness, it's to make it so that someone mining a fork falls behind more reliably |
20:54:02 | Eliel: | bramc: please consider what I just suggested, it could work as a base for something like that since the collaboration process itself creates an interesting web of PoW structures. |
20:55:51 | Eliel: | bramc: plus, it's actually possible to do with bitcoin, right now without a change to blockchain. It's just that no-one has implemented something like this. |
20:56:12 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
21:03:27 | bramc: | Eliel, That is, again, totally irrelevant to what I'm working on |
21:09:09 | Eliel: | bramc: if the majority of mining was done in the kind of collborative way I described, it'd make it impossible to do stealth fork attempts because they'd be obvious and thus could be ignored. Non-stealth forks would, however be possible, but it'd very fast become clear which part of the fork has the majority hashpower behind it and I'd expect economic reasons to lead to fast convergence before the next block is found. |
22:48:30 | kanzure: | is this an appropriate overview of withholding? http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ |
22:52:31 | brisque: | slightly panicked, but I don't see anything wrong with it. |
22:55:38 | brisque: | you can be malicious and defend your pool against possible malice by just proxying suspicious clients to someone elses pool. |
23:00:40 | phantomcircuit: | brisque, ha that's clever |
23:00:42 | justanotheruser: | kanzure: I'm not sure which withholding you're referring to |
23:00:51 | phantomcircuit: | potentially legally questionable |
23:00:55 | phantomcircuit: | but clever non the less |
23:00:58 | phantomcircuit: | none* |
23:02:26 | justanotheruser: | the article is clearly about decreasing the profitability of pools, but there is another block withholding attack |
23:02:57 | justanotheruser: | Is that big article even necessary? you could probably explain that form of block withholding in one IRC message |
23:05:33 | brisque: | phantomcircuit: that's the nice thing about stratum (from the legally questionable side), it's for all purposes just a dumb hose you can fire at anything you please. |
23:14:53 | maaku: | phantomcircuit: forward to p2pool? then you're only destroying the commons |
23:18:10 | gmaxwell: | justanotheruser: the argument its making is that its not a guarenteed loss to the attacker, which is the newer and surprising result. |
23:26:59 | justanotheruser: | mining pools usually optomize for profitability... |