| 00:00:19 | akrmn: | gmaxwell: Yes but eventually there will be the incentive for fees |
| 00:00:29 | akrmn: | And I think it can be softforked |
| 00:00:57 | akrmn: | Either header only with 1 MB limit (compatible with old clients) or full block with no limit |
| 00:01:25 | Luke-Jr: | akrmn: nobody would ever mine >1 MB blocks this way. |
| 00:02:00 | akrmn: | ok thanks for your opinions. Just thinking of the possibilities :) |
| 00:02:20 | akrmn: | someone will have to do the math eventually |
| 00:03:28 | akrmn: | but ya what I want to do is so no one mines more than 1 MB blocks (99% of the time) |
| 00:04:45 | akrmn: | and still give the "pro big blocks people" the freedom they desire |
| 00:05:05 | Luke-Jr: | akrmn: did you see gmaxwell's suggestion? http://www.reddit.com/r/Bitcoin/comments/38937n/idea_make_the_difficulty_target_scale_with_block/crta20m |
| 00:09:16 | akrmn: | If the point is just to limit the UTXO size, then I don't think that's good enough, but I will read more carefully |
| 00:10:08 | Luke-Jr: | it's too bad there's no obvious way to punish miners if UTXOs don't get spent ever |
| 00:10:13 | akrmn: | I think we need on average 1 MB with some rare and not too big variations around it |
| 00:10:19 | Luke-Jr: | (of course, then the problem becomes "how do miners guess if they will?") |
| 00:10:42 | Luke-Jr: | akrmn: Bitcoin can't handle average 1 MB today. |
| 00:10:46 | akrmn: | I'm the guy who proposed the "subchains" idea btw. |
| 00:11:08 | akrmn: | My idea is log(n) storage and verification complexity for each participant |
| 00:11:23 | akrmn: | so even O(n) storage is bad in my view |
| 00:13:50 | akrmn: | (well assuming you don't count all the headers in the storage measurement) |
| 00:15:06 | Luke-Jr: | also, even if bigger blocks cost more, if it puts your competition out of mining, then you eventually get the difficulty to drop for you |
| 00:15:15 | Luke-Jr: | so I'm not so sure how well that idea works |
| 00:16:49 | akrmn: | ya it's not so crucial for the system, but it can give some more flexibilty. Needs some calculations though. |
| 00:36:43 | HostFat: | luke-jr what is your opinion about my idea instead? |
| 00:36:54 | HostFat: | did you read it? |
| 00:39:28 | akrmn: | but one way to look at it (my idea) is that as computers get faster in the future, a 10 MB block for example, may be tiny and no different from a header when calculating the SHA256 sum, but I have to see the details of how the SHA algorithm works in order to understand. |
| 00:40:18 | Luke-Jr: | HostFat: which one? |
| 00:40:23 | HostFat: | https://www.reddit.com/r/Bitcoin/comments/38aqt6/nodes_should_prefer_smaller_blocks/ |
| 00:40:36 | Luke-Jr: | HostFat: that creates some serious problems |
| 00:40:59 | Luke-Jr: | akrmn: the hashing is never done on computers.. |
| 00:41:30 | frankenm_: | seems easy to collusion HostFat, sorry i havent really looked at this in depth |
| 00:41:58 | Luke-Jr: | don't even need collusion. Just make empty blocks all the time, and you will always win. |
| 00:42:23 | frankenm_: | frankenm_ is now known as frankenmint |
| 00:44:19 | HostFat: | hmm, they just win if more blocks are found contemporary ... anyway, I see the problem, I'm not sure that it work perfectly ... but it can be a good idea when the bitcoin mining bonus will be lower then the sum of fees |
| 00:47:22 | HostFat: | I think that this problem can be fixed easily, "nodes will not accept blocks that are lower than the sum of tx that they know" |
| 00:47:56 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 00:49:55 | gmaxwell: | "Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong." |
| 01:11:33 | bsm117532: | One of my favorite quotes... |
| 01:23:58 | Luke-Jr: | HostFat: now you're breaking consensus. |
| 01:24:42 | Luke-Jr: | HostFat: as well as breaking miners' rights and the hope of ever filtering spam (which is necessary for the blockchain to function) |
| 01:25:33 | HostFat: | you are right |
| 01:25:51 | justanotheruser: | 4 |
| 01:26:15 | Luke-Jr: | justanotheruser: *4=10 |
| 01:26:30 | justanotheruser: | what |
| 01:26:43 | justanotheruser: | oh right, your tonal stuff |
| 03:09:01 | Taek: | wrt the patented research ideas, it was suggested in #mit-dci by wumpus and petertodd that it might be worth boycotting patented papers |
| 03:10:12 | Taek: | especially if the paper has good ideas, you might find ways to build on those ideas and then find your own work subject to patent litigation |
| 03:10:40 | gmaxwell: | Taek: unfortunately thats not how patents work in the US. |
| 03:10:59 | gmaxwell: | unless you just mean intentionally not building on patented things; which is prudent. |
| 03:11:08 | Taek: | I do mean the latter |
| 03:11:57 | Taek: | when you read a good idea, you can't help but incorporate it into the other things you are working on |
| 03:12:42 | Taek: | I was also thinking that by refusing to acknowledge patented work, you provide an active disincentive for some researchers whose goals include recognition |
| 03:15:10 | gmaxwell: | unfortunately you can't tell from papers; there is no obligation to disclose (and often people don't); the authors might not even know at publication time, since at least for US patents you can begin the entire process up to a year after publishing. |
| 03:15:59 | gmaxwell: | some venues may have requirements to disclose patent information, we could certantly encourage venus to adopt such rules. |
| 03:17:14 | gmaxwell: | Oh also, it may eventually be useful to distinguish patent terms, for example if someone gets patents assigns them to a 501(c)(3) and offers them under permissive protective licenses; would you shun those too? |
| 03:18:09 | Taek: | personally, I'm on the MIT/Apache side of things: information / invention should be as unrestricted as possible |
| 03:18:20 | Taek: | but I acknowledge that some things are a lot better than others |
| 03:19:16 | Taek: | There is a 'Linux Defenders' group that makes defensive publications related to linux technologies, I'm wondering if it would be worth organizing something similar for Bitcoin |
| 03:19:30 | Taek: | (not that I am volunteering) |
| 03:21:27 | zooko: | In theory that organization -- the Open Invention Network -- could define Bitcoin as being part of linux, and then all of its current members would be obligated not to patent-sue anyone for their use of Bitcoin |
| 03:21:37 | zooko: | or else they would get kicked out of the club. |
| 03:21:40 | zooko: | I think that's how it works. |
| 03:22:10 | zooko: | The process would be that someone, ideally someone influential/authoritative/famous begs Open Invention Network to define Linux as including Bitcoin. |
| 03:45:44 | Sub|afk: | Sub|afk is now known as SubCreative |
| 05:03:00 | Jaamg: | * Jaamg thinks that it should not be possible to patent money |
| 05:19:30 | Jaamg: | in general I'm an "agnostic" on this subject; maybe there are things where patenting is justified or maybe not, but it should not be possiblt to patent money. it's like patenting game theory |
| 05:39:17 | maaku: | * maaku thinks it should not be possible to patent |
| 05:41:55 | Jaamg: | you may be right, i have never really given a good thought on the subject |
| 05:42:32 | moa: | a gentleperson's agreement on attribution would be good start for a civil society |
| 05:45:25 | dgenr8: | * dgenr8 plans to patent his DNA, then sue his children |
| 05:45:50 | moa: | for half? |
| 05:46:07 | dgenr8: | mo' children, mo' better |
| 05:47:02 | dgenr8: | suppose there was a patch to not bother downloading a block past 5MB, unless it were built on to some degree. evil? |
| 05:48:05 | dgenr8: | oh, and hard fork has eliminated blocksize limit (forgot that part) |
| 05:48:40 | maaku: | dgenr8: ah but in great irony you are liable for them until they reach age of majority, at which point your patent would have expired. you'd be suing yourself ;) |
| 05:49:56 | dgenr8: | clever choice of jurisdiction notwithstanding i presume |
| 06:15:51 | dgenr8: | the conclusions of Houy http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519 are not very convincing as they ignore the possibility of changes in the economic value of the block reward (read exchange rate atm) |
| 06:18:27 | dgenr8: | in practice, that change was +infinity between halvings 0-1, and might be 10x between halvings 1-2 (enough to cover more than 3 halvings) |
| 06:26:39 | Jaamg: | "I confess that I prefer true but imperfect knowledge, even if it leaves much indetermined and unpredictable, to a pretence of exact knowledge that is likely to be false." - F.A. Hayek |
| 06:30:24 | Jaamg: | this kind of modelling of tx fee economics can potentially lead into much harm, but i understand why it's interesting |
| 06:33:43 | Jaamg: | http://www.nobelprize.org/nobel_prizes/economic-sciences/laureates/1974/hayek-lecture.html |
| 06:43:54 | moa: | anybody have insights as to why bitcoin-xt is not a git fork of bitcoin core https://github.com/bitcoinxt/bitcoinxt? |
| 07:28:46 | bramc: | Macroeconomic concerns are irrelevant to Bitcoin as it exists today. It's a completely normal commodity driven by microeconomic principles. |
| 07:31:50 | Jaamg: | bramc: depends what you mean; BTC/USD market price can maybe be assumed "completely normal commodity driven by microeconomics principles" |
| 07:32:26 | phantomcircuit: | bramc, er that's not exactly true |
| 07:32:36 | Jaamg: | but if we try to create formal model for tx fee economics, imho we have a great risk to fall into pretence of knowledge |
| 07:33:37 | bramc: | phantomcircuit, Okay 'completely normal' is probably inaccurate. It's deeply weird in many ways. But the pricing mechanisms are all ordinary supply and demand. |
| 07:36:20 | phantomcircuit: | lol so that paper is basically showing that there has to be blocksize pressure in order for bitcoin to survive |
| 07:36:33 | phantomcircuit: | and seems to be reasonable |
| 08:05:15 | kornbluth.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 | kornbluth.freenode.net: | Users on #bitcoin-wizards: andy-logbot artiefoo SubCreative dabos dEBRUYNE dc17523be3 gill3s adam3us antanst RoboTedd_ [d__d] Mably hktud0 d1ggy priidu p15 paveljanik cosmo b_lumenkraft melvster Emcy Relos waxwing felipelalli akrmn wallet42 harrow [7] akstunt600 droidr rht__ Dr-G2 moa prodatalab tromp__ metamarc justanotheruser wumpus DougieBot5000 STRML Starduster gielbier jmcn spinza qawap iNFiNiTY__ bosma Aaaaand-its-go__ palexander LeMiner Madars Adlai gmaxwell |
| 08:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: a5m0 theymos Jouke c0rw1n mikolalysenko kumavis runeks adams__ Muis artifexd dasource go1111111 lclc mengine superobserver Luke-Jr rustyn wizkid057 stonecoldpat null_radix robogoat hulkhogan_ Cory yrashk mariorz btcdrak CryptoGoon platinuum Oizopower CryptOprah catcow yorick amiller koshii Meeh davout jessepollak huseby espes GreenIsMyPepper elastoma pollux-bts Logicwax PaulCapestany fript tromp sneak CodeShark mountaingoat dgenr8 helo |
| 08:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: cryptowe- veox mm_1 luny ttttemp lnovy jbenet vonzipper sadoshi copumpkin phantomcircuit michagogo bedeho ebfull PRab yoleaux EasyAt comboy stevenroose pigeons kinlo gwillen sl01 Tiraspol kyuupichan gavinandresen nickler Iriez cdecker Keefe jrayhawk K1773R luigi1111 Apocalyptic prosodyContext ggreer Hunger- Pan0ram1x isis HM bsm117532 harrigan andytoshi scoria brand0 larraboj OneFixt mappum weex gnusha nsh triazo jonasschnelli berndj |
| 08:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: leakypat tucenaber Taek iddo epscy wiz lmacken cfields Krellan coryfields catlasshrugged Alanius kanzure bliljerk_ azariah warptangent sparetire TD-Linux crescend1 Zouppen _whitelogger binaryatrocity heath BananaLotus maaku optimator Eliel narwh4l mr_burdell throughnothing_ fluffypony Fistful_of_Coins Jaamg xabbix smooth dignork Sqt poggy livegnik petertodd richardus nephyrin phedny so afdudley SwedFTP guruvan ajweiss nanotube forrestv |
| 08:05:15 | kornbluth.freenode.net: | Users on #bitcoin-wizards: warren Xzibit17 sdaftuar eric roasbeef morcos merlincorey [ace] sturles jaromil Graet indolering ryan-c gribble d9b4bef9 starsoccer otoburb midnightmagic BlueMatt Anduck AdrianG @ChanServ BrainOverfl0w |
| 08:06:45 | Tiraspol: | * Tiraspol slaps andy-logbot around a bit with a large trout |
| 08:27:04 | Jaamg: | It is really going to suck if bitcoin ends up being a scheme where we religiously try to keep avg block size / max block size at some "optimum" level so that "bitcoin survives". It will be perpetual political conflict on whether the max block size should be higher or lower (and by how much). |
| 08:29:07 | Jaamg: | in the mean time too small blockchain hinders adoption. When we reach the limit, not everybody get their txs through, no matter how much they pay. It will not be "pay more and we process your tx", it will be "go away" |
| 08:29:37 | gmaxwell: | gmaxwell has left #bitcoin-wizards |
| 08:37:51 | Jaamg: | i agree that there must be a safety mechanism for exploiting bloat. i also agree that there must be a mechanism to keep blockchain secure even after the subsidized era. i agree that max block size can be a solutin for the former but i disagree that it can be a solution to the latter |
| 08:50:14 | pgokeeffe: | pgokeeffe is now known as kef |
| 08:50:43 | kef: | kef is now known as Guest60337 |
| 08:51:28 | Guest60337: | Guest60337 is now known as pgokeeffe |
| 08:58:22 | phantomcircuit: | in the mean time too small blockchain hinders adoption. When we reach the limit, not everybody get their txs through, no matter how much they pay. |
| 08:58:23 | phantomcircuit: | wat |
| 08:58:29 | phantomcircuit: | that's not how it will work |
| 08:59:09 | Jaamg: | phantomcircuit: yes it does. if we have 101 people trying to make a tx and only room for 100 tx, not everybody are going to get their tx through |
| 08:59:36 | Jaamg: | sorry that the expression was really messed up, as you can probably see, english is not my 1st language |
| 09:00:09 | Taek: | jaamg: that's true, not everyone will get a txn through. But someone is going to give before the others. It it's worth $1 million to you, you're probably okay. It's probably not worth $1m to everyone else |
| 09:00:27 | Jaamg: | Taek: yes, it will not be "go away" for everybody |
| 09:02:11 | Jaamg: | but since so many people must "go away" the marginal tx fee probably approaches 0 (or whatever is the minimum that the miners process) |
| 09:02:24 | Jaamg: | i have no formal proof of this, just a gut feeling |
| 09:03:14 | Jaamg: | it is hard to imagine that there is a long line of people waiting so that somebody gets priced out and they can take his place |
| 09:03:26 | Jaamg: | *so that when |
| 09:03:46 | Jaamg: | -and |
| 09:09:00 | phantomcircuit: | Jaamg, yeah and? that's a fundamental property of a global consensus system |
| 09:09:12 | phantomcircuit: | there is limited throughput |
| 09:09:14 | phantomcircuit: | infact |
| 09:09:19 | phantomcircuit: | 1MB is probably too large |
| 09:09:56 | phantomcircuit: | (good thing we're not even close to 1MB yet!) |
| 09:10:22 | Jaamg: | phantomcircuit: not sure if sarcastic |
| 09:10:38 | phantomcircuit: | Jaamg, why would any of that be sarcastic |
| 09:11:41 | Jaamg: | phantomcircuit: well, i see no point in having max block size other than prevent exploits |
| 09:13:23 | phantomcircuit: | Jaamg, care to elaborate on what you understand the potential exploits to be? (im curious about this view point) |
| 09:14:09 | Jaamg: | phantomcircuit: low cost to bloat blockchain with meaningless txs |
| 09:14:23 | Jaamg: | maybe there is something else |
| 09:14:25 | Jaamg: | isk |
| 09:14:27 | Jaamg: | idk |
| 09:16:05 | phantomcircuit: | Jaamg, ok so yeah that's true |
| 09:16:37 | phantomcircuit: | Jaamg, but now go one deeper, why is the blockchain full of meaningless transactions a problem? |
| 09:18:03 | Jaamg: | phantomcircuit: there is a risk involved in a situation if we lose the property "anybody can be a full node" |
| 09:18:25 | phantomcircuit: | Jaamg, right great |
| 09:18:59 | phantomcircuit: | Jaamg, now consider, what happens if there are actually an enormous number of legitimate users |
| 09:19:09 | phantomcircuit: | in other words replace blockchain bloat with blockchain use |
| 09:19:15 | phantomcircuit: | does that change the risk at all? |
| 09:20:00 | Jaamg: | phantomcircuit: yea, then we face a difficult situation where we must either tell some of the people to go away or take the previously described risk |
| 09:22:04 | phantomcircuit: | Jaamg, the risk is still the same |
| 09:22:11 | Jaamg: | phantomcircuit: yes it is |
| 09:35:48 | Jaamg: | phantomcircuit: can you tell why the blocksize should be smaller than 1MB? you said it wasn't sarcasm |
| 09:36:07 | Jaamg: | max blocksize that is |
| 09:36:21 | fluffypony: | because the average bandwidth available in places like South Africa (where I live) is like 128kbps |
| 09:36:36 | Jaamg: | fluffypony: you can't process 1MB blocks? :p |
| 09:36:54 | fluffypony: | I'm on a 10mbps line at home, I'm not representative of the general populous |
| 09:36:58 | phantomcircuit: | Jaamg, empirical measures of decentralization all show declines |
| 09:37:11 | phantomcircuit: | the total number of nodes which are reachable has dropped from 8k to 5.3k |
| 09:37:24 | phantomcircuit: | many more people are using reduced security clients |
| 09:37:58 | phantomcircuit: | most of the available headroom to optimize bitcoind has already been squeezed out of it |
| 09:38:27 | phantomcircuit: | (excluding the very nice performance benefits of using libsecp256k1 to verify... but we cant do that yet since the openssl code is consensus critical) |
| 09:39:53 | Jaamg: | phantomcircuit: correlation does not imply causality. is there a proof that those 2.7k nodes have quit because of avg block sizes getting higher? i think more feasible explanation would be that they were home miners who quit after the difficulty got too high |
| 09:42:16 | Jaamg: | phantomcircuit: do you expect the number of full nodes to rise if max block size is lowered to, say 750kb? |
| 09:44:03 | phantomcircuit: | Jaamg, whenever i ask someone why they dont run bitcoin core as their wallet |
| 09:44:14 | phantomcircuit: | the response is that it's too slow 99% of the time |
| 09:44:35 | phantomcircuit: | the remaining 1% is features that were explicitly not implemented because they're considered not safe |
| 09:46:36 | p15_: | how elastic is that though, even if it were 10x faster maybe they'd still think it was too slow |
| 09:48:35 | phantomcircuit: | p15_, see that is a good question |
| 09:48:48 | phantomcircuit: | p15_, i genuinely dont know |
| 09:49:00 | phantomcircuit: | p15_, i can however say for sure that making it slower will make it worse |
| 09:49:23 | phantomcircuit: | i cant say that making it faster will necessarily make it much better |
| 10:12:40 | jrayhawk: | and even half of the rural U.S. population is at sub-broadband speeds, making tens of gigabytes of blockchain synchronization an onerous requirement for verifiable transactions. |
| 11:11:17 | midnightmagic: | a combined spv initial operation during the sync process would likely eliminate that: "it works while the sync is happening" |
| 13:29:41 | hulkhogan_: | /window splitv |
| 13:36:46 | fluffypony: | hulkhogan_: thank you for signing up for Cat Facts! You will now receive fun daily facts about CATS! >o< |
| 13:38:06 | hulkhogan_: | thanks... just what i needed :) |
| 13:39:34 | fluffypony: | https://medium.com/@Ledger/exploring-java-card-for-bitcoin-applications-faf02a2908d6 |
| 13:39:38 | fluffypony: | that's impressive |
| 13:39:44 | b_lumenkraft: | fluffypony: where can i get these cat facts? |
| 13:40:13 | fluffypony: | b_lumenkraft: you don't find cat facts, they find you |
| 13:40:22 | b_lumenkraft: | :) |
| 13:53:14 | eudoxia: | http://webcache.googleusercontent.com/search?q=cache:SntyF7_-eogJ:www.thestrangeloop.com/2015/urbit-a-clean-slate-functional-stack.html+&cd=1&hl=en&ct=clnk |
| 13:53:19 | eudoxia: | ugh wrong window |
| 14:45:53 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 15:17:36 | dabura667: | https://github.com/bitpay/copay/blob/master/public/views/create.html#L109 |
| 15:17:36 | dabura667: | This string says "Create x-of-y wallet" |
| 15:17:36 | dabura667: | but in Japanese localization I need to change the order |
| 15:17:36 | dabura667: | to "x-of-y wallet create" |
| 15:17:36 | dabura667: | but the way the string is formatted it is not possible currently |
| 15:17:36 | dabura667: | without having separate html file for Japanese. |
| 15:17:36 | dabura667: | "Create %d of %d wallet" %(cosigners, copayers) type format is possible? |
| 15:17:37 | dabura667: | if this was translated I could move the %d in the po file for translation |
| 15:26:35 | wallet421: | wallet421 is now known as wallet42 |
| 15:27:27 | jae: | jae is now known as Guest71002 |
| 15:51:01 | moarrr: | moarrr has left #bitcoin-wizards |
| 16:37:55 | wallet421: | wallet421 is now known as wallet42 |
| 16:42:22 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 16:54:36 | thesnark: | thesnark is now known as narwh4l |
| 16:56:28 | dgenr8: | phantomcircuit: if Houy's assumptions were reasonable, bitcoin would have died already, since no fixed fee and no capacity pressure until 2015-09. |
| 17:00:09 | dgenr8: | phantomcircuit: instead, hashing grew exponentially and i think we can agree exchange rate figures heavily into miner decisions |
| 17:01:25 | jae: | jae is now known as Guest25695 |
| 17:04:05 | dgenr8: | no capacity pressure until 2014-09, sorry http://i.imgur.com/5Gfh9CW.png |
| 17:08:02 | wallet421: | wallet421 is now known as wallet42 |
| 17:26:09 | bosma_: | bosma_ is now known as bosma |
| 17:38:05 | wallet42: | wallet42 is now known as Guest38207 |
| 17:38:05 | wallet421: | wallet421 is now known as wallet42 |
| 17:55:32 | narwh4l: | How do you all feel about proof of burn? I'm writing contracts for counterparty but proof of burn seems destructive to me. |
| 17:56:22 | narwh4l: | Also, if you don't like proof of burn an alternative to counterparty would be wonderful if you know of one |
| 18:00:22 | kanzure: | narwh4l: there's openassets, omniwallet, colour, just.. lots.. |
| 18:00:55 | narwh4l: | kanzure: do you have a favorite? |
| 18:01:30 | kanzure: | so far i have been intrigued the most by sidechain stuff |
| 18:04:32 | narwh4l: | kanzure: so no clear winners? a link to practical sidechain doc would be immensely appreciated |
| 18:08:45 | temujin: | narwh41: there is no existing side-chain implementation |
| 18:09:01 | temujin: | if you want to do something you can test on main/testnet right now, go with open assets or counterParty |
| 18:09:25 | temujin: | this might be biased, but it's a good overview of the protocols: http://blog.coinprism.com/comparison-coinprism-counterparty-mastercoin/ |
| 18:10:32 | narwh4l: | temujin: Great comparison sheet, even if it is biased |
| 18:10:38 | narwh4l: | thank you |
| 18:11:36 | temujin: | if you're interested in the counter-points to this, i believe there is a reddit thread... i can't find it right now though |
| 18:11:49 | temujin: | fwiw counterParty has the best documentation by far |
| 18:12:30 | narwh4l: | temujin: counterparty definitely seems to have it all together, proof of burn just makes my stomach turn a little |
| 18:13:14 | temujin: | i believe the idea is that it gives the tokens some value which can be used to trade against other assets on the counterParty network |
| 18:13:30 | temujin: | in a similar way that Bitcoins themselves have value because it costs resources to mine |
| 18:14:02 | temujin: | also, as a method of distribution of initial tokens, it makes sense because the developers/early contributors took equal risk with everyone else involved |
| 18:14:11 | temujin: | (as a function of burnt BTC) |
| 18:15:17 | narwh4l: | temujin: I understand why it gives value to xcp, I just hate the notion of making BTC useless. |
| 18:17:09 | temujin: | it's an uncomfortable thought but in practice it makes no difference, right? |
| 18:17:32 | narwh4l: | * narwh4l shrugs |
| 18:17:33 | narwh4l: | I guess |
| 18:17:42 | temujin: | even if 99% of all Bitcoins were burned, we could simply extend the decimal place further and trade with the remaining coins |
| 18:18:19 | temujin: | perhaps there's an argument to be made for concentration of wealth, but that's separate from the notion of destroying Bitcoins |
| 18:18:41 | narwh4l: | * narwh4l shuts up and carries on |
| 20:20:39 | Relos: | has this been looked into: https://twitter.com/NickSzabo4/status/606531393007558656 ? |
| 20:21:47 | kanzure: | .tw |
| 20:21:48 | yoleaux: | Great computer science paper on reducing the advantages of fast internet connectivity in Bitcoin: GHOST http://eprint.iacr.org/2013/881.pdf (@NickSzabo4) |
| 20:21:57 | maaku: | Relos: that paper is years old |
| 20:22:10 | maaku: | and yes it has been looked into and has issues |
| 22:30:33 | droidr: | +m? |
| 22:30:39 | droidr: | ok |
| 22:34:54 | pigeons: | pigeons is now known as Guest18168 |
| 22:43:17 | otoburb: | otoburb is now known as Guest78969 |