| 00:00:16 | bsm117532: | There is no distributed timestamp server in bitcoin. |
| 00:01:24 | phantomcircuit: | bsm117532, there sort of is |
| 00:01:39 | bsm117532: | I'd say it the other way, bitcoin *is* a (very poor) distributed timestamp server. |
| 00:02:06 | bsm117532: | but it doesn't use one external to itself. timestamps come from node clocks. |
| 00:02:45 | moa: | it is very distributed timestamp server ... best at what it does |
| 00:03:47 | bsm117532: | A DAG (or chain) allows you to time/normal order transactions without actually using a clock. |
| 00:04:44 | bsm117532: | I'd rather see one of two things: (1) no clocks at all in the consensus or (2) push the limits on clocks to get NTP-level resolution. |
| 00:05:53 | bsm117532: | But these arbitrary rules like 2-week retargets, 100 blocks to spend coinbases, etc. are totally arbitrary and are attempting to solve a different problem, that should probably be solved in a better way. |
| 00:05:55 | moa: | well the 'clock' is the sequential ordering of transactions innto hashed blocks, the node timestamps are not the 'clock' |
| 00:06:47 | bsm117532: | The only clock that matters is: did transaction A come in a block before transaction B? And the only way time actually comes into that is the retarget calculation, which uses the timestamps in the blocks. |
| 00:07:17 | bsm117532: | Which could be entirely fudged... |
| 00:07:25 | moa: | not really |
| 00:07:38 | bsm117532: | Up to yet more arbitrary limits, they can. |
| 00:08:28 | moa: | except it has never been done |
| 00:09:18 | bsm117532: | You haven't been paying attention to the altcoins, I see... ;-) (Also, never been done != can't be done) |
| 00:09:44 | moa: | i witnessed the first timewarp attack ... on namecoin |
| 00:10:31 | moa: | :) |
| 00:10:34 | moa: | ;) |
| 00:10:58 | bsm117532: | Anyway I'm getting off topic. Screwing with difficulty adjustments is a separate topic from using a DAG instead of a chain. ;-) |
| 00:11:41 | moa: | arguably DAG might be off-topic unless you have a concrete proposal |
| 00:12:14 | moa: | seems like lots of loose chain tips to tidy up |
| 00:12:55 | bsm117532: | moa: See the above paper. ;-) I was reluctant to bring it up until I found this paper... http://fc15.ifca.ai/preproceedings/paper_101.pdf |
| 01:57:48 | DrWat: | DrWat is now known as DrWat|ZZZzzz |
| 02:10:25 | PRab_: | PRab_ is now known as PRab |
| 08:05:19 | sendak.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:19 | sendak.freenode.net: | Users on #bitcoin-wizards: andy-logbot dEBRUYNE Pan0ram1x orik hashtagg_ RoboTeddy cbeams kobud Mably jhogan42_ CoinMuncher priidu arubi b_lumenkraft jgarzik unlord zooko` [7] PRab Dr-G fanquake melvster d1ggy DougieBot5000 adam3us justanotheruser spinza ebfull dasource tcrypt nullbyte Cory DrWat|ZZZzzz cluckj forrestv mkarrer gielbier cryptowest_ satwo afk11 devrandom amiller_ runeks__ GAit Starduster_ kanzure jaromil waxwing kefkius throughnothing jaekwon maaku Graet |
| 08:05:19 | sendak.freenode.net: | Users on #bitcoin-wizards: Eliel veox indolering K1773R Keefe petertodd jcorgan larraboj ryan-c jessepollak hashtag_ MoALTz_ gribble tromp mr_burdell gnusha Iriez tromp_ andytoshi d9b4bef9 luigi1111w wiz bliljerk101 aakselrod starsoccer thrasher` dgenr8 Zouppen cfields Apocalyptic Madars Xzibit17 JonTitor prodatalab_ harrow chester` bosma grandmaster antgreen helo jonasschnelli copumpkin sadoshi Tjopper p15 nubbins` c0rw1n btcdrak go1111111 yorick weex SwedFTP |
| 08:05:19 | sendak.freenode.net: | Users on #bitcoin-wizards: PaulCapestany Hunger- lmacken dc17523be3 sqt face HM Luke-Jr luny yrashk artifexd kumavis adams_ platinuum pollux-bts otoburb a5m0 vonzipper catlasshrugged huseby midnightmagic BlueMatt GreenIsMyPepper warren TD-Linux mariorz binaryatrocity hguux___ fenn wizkid057 rustyn ajweiss LeMiner airbreather Tiraspol SubCreative Adlai Anduck iddo sneak poggy raizor Chillum nsh kyuupichan Logicwax phantomcircuit EasyAt lechuga_ luigi1111 isis nanotube |
| 08:05:19 | sendak.freenode.net: | Users on #bitcoin-wizards: yoleaux gmaxwell berndj gavinandresen dignork AdrianG s1w livegnik optimator fluffypony Meeh cursive dansmith_btc morcos guruvan BananaLotus bedeho heath roasbeef_ Fistful_of_Coins comboy_ stonecoldpat afdudley espes__ pigeons eric sipa warptangent phedny so STRML michagogo null sl01 lnovy [d__d] catcow Muis coryfields_ kinlo wumpus gwillen nickler Alanius sdaftuar null_radix epscy Taek Krellan Oizopower BrainOverfl0w MRL-Relay azariah btc___ |
| 08:05:19 | sendak.freenode.net: | Users on #bitcoin-wizards: @ChanServ brand0 davout NeatBasis CryptOprah leakypat jbenet mappum |
| 09:51:43 | lmatteis: | hello. has anybody read this paper on a concept they refer to as Proof Of Bandwidth https://www.petsymposium.org/2014/papers/Ghosh.pdf |
| 09:51:54 | lmatteis: | i'm unsure i grasp the concept entirely |
| 09:52:22 | lmatteis: | that is, with bitcoin, i can independently verify the work done; i simply check the hash |
| 09:52:37 | lmatteis: | with bandwidth, how is that possible? |
| 09:53:14 | gmaxwell: | I got the author on HN |
| 09:53:37 | gmaxwell: | basically: the system provides no strong security, at leats not in a sense that would be reconizable to us. |
| 09:53:42 | gmaxwell: | lemme see if I can find the thread. |
| 09:54:49 | gmaxwell: | lmatteis: https://news.ycombinator.com/item?id=7850492 |
| 09:56:23 | lmatteis: | gmaxwell: thanks |
| 09:57:10 | gmaxwell: | thanks for asking a question with a simple cache hit for an answer! |
| 09:57:40 | lmatteis: | cache of your mind? :) |
| 09:58:31 | gmaxwell: | I see so many things its sometimes a crapshoot if I remember reviewing and responding to something previously. |
| 10:00:02 | lmatteis: | i'm looking for a subject for my BSc thesis - have you ever thought about decentralized name resolutions? i've had this thought for a couple of weeks (perhaps subject of my thesis) where peers collectively compete to obtain a name (instead of first one first get typical scenario of DNS) |
| 10:00:18 | lmatteis: | or namecoin |
| 10:01:04 | lmatteis: | however, i need the *competing* part to be useful for the network. and a proof of bandwidth would; peers would be incentivezed to share bandwidth in order to maintain their DNS |
| 10:02:13 | gmaxwell: | well we've talked in here about "the other obvious mechenism" there are two obvious modes for allocation of names, first come first serve; and a more continious auction. The latter could be argued to produce "better" resource allocation, but I think we all know it wouldn't esp since it would mean links would change owners out from under the people referring to them... but it would be interesting |
| 10:02:19 | gmaxwell: | to have a TLD working that way... maybe would actually be good for very generic names. |
| 10:02:59 | lmatteis: | well most users would resort to pub keys.. and all links would be that way |
| 10:03:05 | lmatteis: | only humans need the name part |
| 10:03:13 | gmaxwell: | e.g. "sex.market" would make sense perhaps, while "godhatesfags.markets" would end up owned by gay rights groups; which probably doesn't satisify any reasonable definition of efficient allocation. :) |
| 10:04:08 | lmatteis: | the idea is that if they contribute to the network enough, then they should be entitled to that name |
| 10:04:47 | lmatteis: | so ebay.com would want to share as much bandwitdh as possible to maintain its DNS |
| 10:04:53 | lmatteis: | and sorry, it's name (not DNS) |
| 10:04:57 | lmatteis: | *its |
| 10:05:33 | gmaxwell: | thats interesting, I don't think I've seen anyone suggesting that; and it's not obvious to me how it could be done (in a decenteralized totally consensus way) |
| 10:06:33 | lmatteis: | seems more democratic to me rather than a first come first serve |
| 10:06:39 | lmatteis: | especially in p2p systems |
| 10:06:42 | fluffypony: | lmatteis: I think the root problem is that a lot of these papers talk about "proof of" something without actually showing how they intend to "prove" it with some degree of mathematical certainty |
| 10:07:44 | gmaxwell: | lmatteis: e.g. do I just set up my own resolver and query the crap out of it for companyihate.communist so that their 'fair share' goes through the roof, and I drive them off their name? |
| 10:08:55 | lmatteis: | right :/ |
| 10:10:56 | gmaxwell: | First come first serve is clearly bad in lots of ways (squatting for one); but it might be like democracy, which is often "dysfunction, inefficient, and unfair, but less so than the alternatives" |
| 10:12:16 | fluffypony: | there's a great comment by herzmeister I read the other day |
| 10:12:21 | fluffypony: | https://bitcointalk.org/index.php?topic=1007155.msg10938907#msg10938907 |
| 10:12:33 | fluffypony: | it was in response to some comment about "proof of activity" - |
| 10:12:34 | fluffypony: | "Except it isn't a "proof". Proof-of-activity, proof-of-resource, proof-of-storage or similar are all misnomers. There can't be "proof" of these things, all of these can be forged; only spent CPU power can algorithmically be proven because it boils down to pure physical entropy at the end of the day. Also MaidSafe use the term proof-of-resource but in reality their security mechanism is a node-ranking system which does introduce a |
| 10:12:34 | fluffypony: | degree of trust." |
| 10:14:57 | gmaxwell: | Part of the problem is that the blackbox abstraction's we need to deal with the complexity of the world fail us. If your proof-of-x were actually that, perhaps you'd have the properties you want. But "proof of X" is name, not a mathmatical simplification of what it actually is, not its 'true name'. |
| 10:15:46 | gmaxwell: | Don't worry we'll soon solve all these problems with proof-of-integrity, proof-of-competence, and proof-of-conscientious-research |
| 10:16:08 | lmatteis: | eheh |
| 10:16:51 | fluffypony: | proof-of-competence would be great |
| 10:17:01 | gmaxwell: | it's probably no good without the others! |
| 10:17:58 | gmaxwell: | It's like the superhuman AI in a box, in the nightmares of the lesswrongers, ... you'd rather it not be so smart. If it's smart then you'll never notice as it stabs you in the back. Dumber would be less helpful; but also less dangerous. :) |
| 10:20:33 | lmatteis: | but i mean, couldn't PoW be used for the naming scheme? all the PoW does is it reaches consensus. perhaps the consensus can be about "user X shared N gb" rather than transactions |
| 10:21:33 | lmatteis: | but i guess transactions are simple to verify (just look at your local db) while "user X shared N gb" it's almost impossible to verify |
| 10:23:58 | Luke-Jr: | technically proof-of-work can be faked to. with significant luck. <.< |
| 10:24:07 | Luke-Jr: | too* |
| 10:24:19 | lmatteis: | (sorry, just brainstorming) |
| 10:25:26 | lmatteis: | what if, to verify that "user X shared N gb" you need an approval from Y amount of different peers |
| 10:25:42 | lmatteis: | with different IPs :) |
| 10:26:00 | lmatteis: | or! different peers that performed a PoW, so they can't collude |
| 10:27:03 | lmatteis: | so (i) an initial PoW to reach consensus on something and (ii) another PoW to prove that the something is true |
| 10:27:14 | lmatteis: | BAM |
| 10:27:33 | fluffypony: | IP addresses are a poor identifier as they can easily be faked / acquired |
| 10:27:42 | lmatteis: | right, therefore 2nd PoW |
| 10:29:03 | fluffypony: | ok so let's simplify it |
| 10:29:09 | fluffypony: | let's say we want to do "proof of storage" |
| 10:29:37 | fluffypony: | so I have a 20mb "block" that is stored by 4 other peers and I want to verify that they have it every day |
| 10:29:45 | fluffypony: | so every day I send a challenge-response to them based on a hash of that |
| 10:29:57 | fluffypony: | hashed with some random salt, of course |
| 10:30:04 | fluffypony: | and they do the same for me |
| 10:30:43 | fluffypony: | but I can just lie and say that the response is wrong |
| 10:31:06 | fluffypony: | or I can have a bunch of false nodes claiming to store that block and serving up false responses |
| 10:31:14 | lmatteis: | you simply ask the peer "have you stored 20mb?", he alone says yes, but he might be lying. so you ask other 30 peers if that's true. they can't all be lying because to generate their "yes" answer they worked a little in CPU time |
| 10:31:27 | lmatteis: | so it's more than i trust many peers kinda thing |
| 10:31:32 | lmatteis: | rather than technical TRUE |
| 10:31:38 | fluffypony: | ok so then you spread the load to like 100 peers |
| 10:31:51 | lmatteis: | because,as we discussed, you can't prove bandwidth/storage |
| 10:32:00 | fluffypony: | so instead of 20mb of data taking up 20mb it now takes up 2gb |
| 10:32:20 | fluffypony: | and requires a bunch of challenge-response bandwidth to verify it every day |
| 10:33:01 | lmatteis: | and wasting quadratic CPU power than what bitcoin is now lol |
| 10:33:14 | fluffypony: | but your 20mb will be "safe"! :-P |
| 10:34:13 | lmatteis: | perhaps for small resources it could work. think of a P2P web with html files |
| 10:34:23 | lmatteis: | but again, it's a really hard problem |
| 10:34:30 | fluffypony: | ok so a p2p web |
| 10:34:42 | fluffypony: | it's fine for *nodes that have that data* to verify each other |
| 10:35:04 | fluffypony: | but then when another peer wants to "browse" they have to receive the same data from N nodes to make sure they have the real data |
| 10:36:37 | lmatteis: | yeah |
| 10:39:15 | gmaxwell: | fluffypony: safe? hm? I'm just proxying your requests to bob. The information I'm not storing at all is totally safe with me. |
| 10:39:28 | fluffypony: | gmaxwell: hence the inverted commas |
| 10:40:33 | fluffypony: | this is easily solved Ethereum-style, just layer complexity until the unholy mess of broken cryptography appears to work...or Darkcoin-style, just create an over-incentivised central cabal |
| 10:40:43 | gmaxwell: | lmatteis: everyone just gives bob half their income, bob keeps the only copy. Win win. :) |
| 11:01:26 | bosma: | bosma is now known as Guest53730 |