| 00:36:06 | heath: | petertodd: still wanting to play with your smartcolors library |
| 00:36:21 | heath: | petertodd: good news! i might be able to annoy you about this in person next week! :P |
| 00:52:04 | MRL-Relay: | [surae] so, I think I have developed a method of testing whether recent block arrival times have been manipulated (either by user computers having an incorrect time set, or by dishonest manipulation) |
| 00:52:25 | MRL-Relay: | [surae] and from this method, it's (relatively) easy to develop a "momentum" term in difficulty adjustment |
| 00:53:17 | MRL-Relay: | [surae] so that if block arrival times are, say, 20% off of a true Poisson process, you end up with about 81.8% the difficulty adjustment that you would normally make by assuming no manipulation occurred |
| 00:53:54 | MRL-Relay: | [surae] with bitcoin, this isn't a huge deal because of the 2 week adjustment period, but for coins with rapid adjustment periods like Monero, this can prevent manipulation by multipools and whatnot |
| 00:54:36 | MRL-Relay: | [surae] the real interesting part about this is that a Poisson process has the same sample variance and squared sample mean of inter-arrival times... |
| 00:55:32 | MRL-Relay: | [surae] and blocks *should* arrive on the network in a Poisson process, but folks can issue whatever timestamp they like; the difference between squared sample mean and sample variance is a metric (not in the strict sense) between the observed process and a true poisson process with the target arrival rate |
| 00:57:35 | MRL-Relay: | [surae] so using the difference between these two, you can develop a momentum term in difficulty adjustment that says "okay, if the process doesn't exhibit a lot of poisson-icity, don't adjust difficulty very much because the observations have been manipulated; if the process is very poisson-ic (ha) then go ahead and adjust difficulty like normal |
| 01:02:33 | petertodd: | heath: oh yeah, I did say that - added |
| 04:41:49 | heath: | petertodd: thanks :) |
| 04:42:51 | kanzure: | heath: no fair |
| 08:05:15 | wolfe.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:15 | wolfe.freenode.net: | Users on #bitcoin-wizards: andy-logbot go1111111 grandmaster hktud0 nuke_ prodatalab__ toffoo HM dgenr8 Dr-G moleccc Emcy justanotheruser hashtag LeMiner adams_ bramc SubCreative Adlai MoALTz_ gabridome DougieBot5000 waxwing RoboTeddy Hybridsole AdrianG mkarrer devrandom roasbeef spinza d1ggy dc17523be3 OneFixt JonTitor jcorgan p15 afk11 antgreen` brisque paveljanik fanquake koshii_ p15x Tiraspol GAit PaulCapestany harrow tromp_ Pan0ram1x cluckj Starduster shesek |
| 08:05:15 | wolfe.freenode.net: | Users on #bitcoin-wizards: Transisto [d__d] DoctorBTC Luke-Jr realcr binaryatrocity kyuupichan SDCDev NikolaiToryzin espes__ luny antgreen ahmed_ huseby face betarigs_admin melvster airbreather Visheate phedny dignork s1w yorick amiller_ petertodd iddo_ kanzure arubi Iriez michagogo yrashk catcow Muis cfields Zouppen sneak coryfields_ stevenroose alferz gribble Cory LarsLarsen cryptowest_ ajweiss berndj kinlo Logicwax midnightmagic crescendo wizkid057 bosma otoburb wumpus |
| 08:05:15 | wolfe.freenode.net: | Users on #bitcoin-wizards: jaekwon GreenIsMyPepper phantomcircuit BlueMatt jaromil Apocalyptic gwillen dasource bbrittain fenn prepost tromp eordano nickler Alanius PRab BananaLotus guruvan ryan-c lnovy ebfull sdaftuar veorq helo Hunger- xabbix runeks null_radix gmaxwell SwedFTP epscy nanotube andytoshi bliljerk101 starsoccer comboy nsh Taek EasyAt maaku BrainOverfl0w so hguux__ MRL-Relay azariah btc___ throughnothing @ChanServ brand0 davout NeatBasis mr_burdell d9b4bef9 |
| 08:05:15 | wolfe.freenode.net: | Users on #bitcoin-wizards: a5m0 Anduck CryptOprah leakypat TD-Linux K1773R indolering warptangent veox Eliel Graet jessepollak lechuga_ warren gnusha heath wiz jbenet mappum eric catlasshrugged Keefe Oizopower platinuum Krellan mariorz kumavis artifexd Xzibit17 smooth isis dardasaba Fistful_of_Coins morcos dansmith_btc yoleaux cursive Meeh fluffypony optimator livegnik |
| 09:06:39 | brisque: | "Ethereum's Proof-Of-Stake, (almost) unlimited supply, big transactions, 3-12 secs confirmation times are great for a decentralized platform." |
| 09:07:35 | justanotheruser: | source |
| 09:07:45 | brisque: | http://redd.it/2z01xq |
| 09:11:03 | smooth: | i thought ethereum's supply was actually unlimited |
| 09:11:20 | smooth: | although i have no idea how what they're going to do with that when they switch to pos |
| 09:13:54 | brisque: | "when they switch to PoS" is an odd statement. they've essentially designed the system to hinge around the fact that they will be able to, when all evidence currently points to the contrary. |
| 09:15:10 | smooth: | which evidence? |
| 09:15:12 | justanotheruser: | my thoughts are that cryptocurrency has way too many people interested technically who aren't interested in actually reading technical materials. |
| 09:15:53 | justanotheruser: | Leads them to think conceptually that PoS can work without thinking about possible attacks. |
| 09:16:30 | brisque: | smooth: there's been lots of attempts at proof of stake published by Ethereum, generally with show stopping flaws, their recent conclusion to that was that it is only possible with "weak subjectivity", ie phone a friend consensus. |
| 09:17:07 | smooth: | brisque: oh sure, but that doesn't mean they won't do it, like every other pos coin. Plus, they don't seem to have a clearly defined pow solution either |
| 09:17:21 | smooth: | i would not be totally shocked if they never launch at all |
| 09:19:44 | brisque: | smooth: they do now, sort of. it's in rapid flux and seems to be largely undocumented, but they've laid out their concept. it's "memory hard" to "prevent" hardware based miners, and uses an ungodly amount of memory, the amount of which increases every period. |
| 09:22:32 | smooth: | brisque: by clearly defined i meant: 1) documented, and 2) not in rapid flux |
| 09:23:07 | brisque: | yeah. you're not getting that apparently. |
| 09:23:21 | brisque: | it's completely changed in the last month since I looked at it, even the name |
| 09:23:22 | brisque: | https://github.com/ethereum/wiki/wiki/Ethash |
| 09:24:11 | brisque: | looks like they've realised that an ever growing data set is silly, that's no longer mentioned. |
| 09:24:37 | brisque: | oh wait, yeah it's still there. "The dataset grows linearly with time." |
| 09:24:39 | justanotheruser: | neat, that page is a tree of links to other hashing algorithms |
| 09:25:13 | smooth: | "This spec is REVISION 23. Whenever you substantively (ie. not clarifications) update the algorithm, please update the revision number in this sentence" |
| 09:25:37 | fluffypony: | looks pretty well documented to me here: https://archive.org/details/EtherealVerses |
| 09:25:52 | fluffypony: | unclehashtelehash |
| 09:28:03 | smooth: | check back next week for revision 43 |
| 09:29:10 | fluffypony: | tested in production (tm) |
| 14:06:23 | brisque: | brisque has left #bitcoin-wizards |
| 14:06:39 | MRL-Relay: | [tacotime] linearly with time |
| 14:06:40 | MRL-Relay: | [tacotime] sigh |
| 14:06:47 | MRL-Relay: | [tacotime] i guess they learned nothing from boolberry |
| 14:07:56 | MRL-Relay: | [tacotime] brisque: i think they're going to find that when they hit real world use of their 6s block time they're going to find much more interesting problems to solve than proof of stake, personally |
| 14:11:39 | justanotheruser: | umm, does MRL not let you connect to the internet except through their relay? |
| 14:12:28 | MRL-Relay: | [tacotime] justanotheruser: The issue is more that FreeNode doesn't let you connect directly via Tor. |
| 14:12:42 | justanotheruser: | oh, so you have a tor relay. neat |
| 14:14:04 | MRL-Relay: | [tacotime] Previously it was Tor --> tunnel --> FreeNode but this is easier because I don't need my own tunnel anymore. :P Just a freenode annoyance unfortunately. |
| 14:30:47 | fluffypony: | justanotheruser: it's relayed to a channel on a private network that does allow Tor connections |
| 16:05:24 | bliljerk101: | Anyone here familiar with price of anarchy? |
| 17:15:43 | kanzure: | bliljerk101: i am familiar with it (although sometimes as "price of malice") http://diyhpl.us/~bryan/papers2/incentives/ |
| 17:16:00 | kanzure: | http://diyhpl.us/~bryan/papers2/incentives/The%20price%20of%20malice:%20a%20game-theoretic%20framework%20for%20malicious%20behavior%20in%20distributed%20systems.pdf |
| 17:23:47 | bliljerk101: | kanzure I have been thinking about how one might go about calculating an exact Price of Anarchy for a bid-ask market. It may be uncomputable, because if it weren't then that might suggest there is a singular optimal trading strategy that would be used by every high frequency trading firm, and thus make an army of PhD's unemployed. |
| 17:37:23 | kanzure: | i'm not sure what the phd thing has to do with any of that... there are many armies of unemployed phds. |
| 17:51:02 | bliljerk101: | kanzure :) I don't think you understand the problem then.. no worries. |
| 17:58:12 | bliljerk101: | i've run this by three professors who are familiar with POA, including a professor at cambridge. only one of which so far has been able to suggest an answer. if by some chance you can calculate a POA of a bid-ask market, there will probably only be a handful of people who will actually understand it. but i think it's important. |
| 20:02:46 | Muis: | i am wondering |
| 20:03:01 | Muis: | why is pow not done over the chain itself? |
| 20:03:20 | Muis: | for example that you dont need to find a hash for the header of the current block |
| 20:03:38 | Muis: | but that you need to find a hash over the total contents of block X (random block in the past) |
| 20:04:05 | Muis: | so that miners proof they have fast access to each block? |
| 20:20:18 | instagibbs: | Muis: because headers-only syncing/spv would break. |
| 20:20:32 | instagibbs: | also this is more #bitcoin |
| 20:25:32 | Muis: | instagibbs: I ment more: why is there no alt-coin who does this? is it a stupid idea |
| 20:26:25 | Muis: | if the only reason is: because it would cause a hardfork, then it seems a good idea |
| 20:27:16 | Muis: | and SPV shouldnt have to break I think? |
| 20:27:40 | instagibbs: | you can't verify the chain without having the full blockchain, so yes it would |
| 20:27:51 | instagibbs: | you wouldnt know if someone was spoofing a legit chain unless you grab those blocks |
| 20:27:54 | Muis: | SPV clients dont verify the whole chain? |
| 20:28:46 | instagibbs: | ok, you really should read some more. Try: https://bitcoin.org/en/developer-guide#block-chain-overview |
| 20:28:48 | Crowley2k: | ^ nope.. |
| 20:29:10 | instagibbs: | and again these are #bitcoin questions. generally OT unless you've already done necessary research |
| 20:29:32 | Muis: | instagibbs: then you should read: https://bitslog.wordpress.com/2014/06/19/theoretical-and-practical-nonoutsourceable-puzzles/ and see how SPV clients can verify the difficulty very easily |
| 20:30:27 | Muis: | "Peers can send only (x,r,h) to SPV nodes, where x = H( r || b ), so they can verify the PoW. " |
| 20:31:01 | instagibbs: | you seem to have basic confusion about what SPV in Bitcoin does. I'd suggest you read up on it. |
| 20:31:10 | Muis: | no? |
| 20:31:17 | Muis: | lol, i've written a SPV client myself |
| 20:32:14 | Muis: | SPV clients put trust in the difficulty, thats not equal to verifying the full chain |
| 20:33:49 | instagibbs: | Oh I see the confusion. I meant my statement as a question, you meant yours as a statement. |
| 20:35:11 | instagibbs: | I was speaking to your hyptothetical |
| 20:35:36 | Muis: | I dont follow you |
| 20:36:09 | instagibbs: | clogging up space here. Anyways, generally these PoW mods have some fatal flaw, such as not being progress-free, or subtly encouraging centralization |
| 20:36:51 | instagibbs: | and generally do nothing to stop private mining, so people would just do that. You don't want to kill pools if only other people will mine completely centralized. |
| 20:37:27 | Muis: | private mining? |
| 20:38:00 | instagibbs: | as opposed to public |
| 20:38:58 | Muis: | why is that bad, and why dont you want to kill pools? |
| 20:39:46 | instagibbs: | If you kill pools, than only people who can handle the variance will mine. Large capital investments would be required to even think about recouping investment. |
| 20:40:44 | Muis: | but if you split the block-reward from 1 big reward, to a reward-per-share scheme (kinda like P2Pool), then the variance is not that big for solo miners |
| 20:47:08 | maaku: | maaku is now known as Guest39256 |
| 21:07:48 | Guest39256: | Guest39256 is now known as maaku |
| 21:39:47 | arubi_: | arubi_ is now known as arubi |
| 22:05:13 | muricula: | muricula has left #bitcoin-wizards |