| 00:07:54 | jae: | jae is now known as Guest47087 |
| 01:49:07 | berndj: | berndj is now known as Guest55081 |
| 04:54:42 | Tiraspol3: | Tiraspol3 is now known as Tiraspol |
| 08:05:16 | sinisalo.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:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: andy-logbot priidu antanst Mably p15 ebfull nullbyte p15x hktud0 arubi_ Tiraspol larraboj Cory TheSeven moa grandmaster williamdunne justanotheruser Dr-G2 berndj-blackout CodeShark felipelalli d1ggy_ brand0 GAit nickler dgenr8 cluckj jmcn Sub|afk u7654dec adlai metamarc PRab sparetire_ LeMiner helo DrWatto bosma yrashk vonzipper cfields jonasschnelli nsh GreenIsMyPepper Krellan_ Luke-Jr prodatalab stevenroose Taek coryfields amiller- Meeh |
| 08:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: deego mkarrer_ sadoshi hashtag Emcy catlasshrugged cryptowest_ Alanius null_radix kanzure_ gavinand1esen amincd OneFixt Logicwax copumpkin airbreather dansmith_ DougieBot5000 antgreen luny stonecoldpat bliljerk_ gielbier go1111111 melvster bedeho2 waxwing azariah harrow tromp_ ttttemp s23ioj234i isis aakselrod scoria andytoshi warptangent MoALTz harrigan Madars PaulCapestany rustyn sparetire davout comboy TD-Linux yorick crescend1 |
| 08:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: dardasaba___ veox mm_1 theymos Zouppen huseby sipa cdecker hulkhogan_ _whitelogger wumpus HM binaryatrocity heath BananaLotus ir2ivps5 wiz maaku face_ michagogo Apocalyptic kyuupichan [d__d] NeatBasis optimator Eliel gnusha tromp spinza narwh4l lmatteis wizkid057 koshii leakypat mr_burdell throughnothing_ mengine sneak lmacken elastoma btcdrak fluffypony Fistful_of_Coins yoleaux Jaamg se3000 xabbix iddo mariorz epscy catcow a5m0_ smooth |
| 08:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: dignork pollux-bts runeks CryptoGoon Sqt poggy jbenet platinuum adams__ livegnik K1773R petertodd richardus nephyrin phedny so phantomcircuit afdudley pigeons SwedFTP guruvan lnovy ajweiss nanotube forrestv artifexd mappum mikolalysenko Muis warren weex_ Xzibit17 sdaftuar eric roasbeef s1w CryptOprah morcos EasyAt Iriez merlincorey [ace] sturles jaromil Graet indolering Keefe ryan-c jessepollak gribble d9b4bef9 starsoccer kumavis otoburb |
| 08:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: midnightmagic BlueMatt Anduck luigi1111 AdrianG BrainOverfl0w @ChanServ Oizopower gwillen kinlo sl01 STRML espes__ |
| 11:30:07 | d1ggy_: | d1ggy_ is now known as d1ggy |
| 13:32:34 | berndj-blackout: | berndj-blackout is now known as berndj |
| 14:00:16 | Pasha: | Pasha is now known as Cory |
| 16:23:39 | Taek: | One of the big things I don't like about merged mining + sidechains is that the security model is much weaker if your chain isn't funding the majority of the mining |
| 16:24:22 | Taek: | And one of the problems with larger blocks is that validating becomes expensive |
| 16:25:09 | Taek: | One of the ways to approach this problem is to have 20 parallel utxo sets in the blockchain |
| 16:25:18 | Taek: | each set permitted 1mb of transactions in each block |
| 16:25:38 | Taek: | and some form of sidechains implementation to move coins between the utxo sets |
| 16:26:07 | Taek: | You end up with 20mb as the maximum blockchain size, but people can now hold all of their coins in only 1 of the 20 sets |
| 16:26:21 | Taek: | and then they can validate that set and ignore all of the others |
| 16:26:39 | Taek: | The improvement to merge mining comes in from a new consensus rule |
| 16:27:26 | Taek: | once a valid set of transactions is in a 20mb block, it can't be reorg'd unless you completely reorg the whole system |
| 16:27:46 | Taek: | so, instead of 20 blockchains, it's just 1 blockchain, but with 20 utxo sets |
| 16:28:05 | Taek: | Since you are only validating 1 set, there's a chance that the other sets have invalid transactions |
| 16:28:37 | Taek: | if a block appears that has invalid transactions for your utxo set, you just ignore the transactions for that set |
| 16:28:44 | Taek: | but the block as a whole is still valid |
| 16:29:33 | Taek: | this makes SPV trickier to implement, but I think it's still possible to have SPV nodes (you might need an additional consensus rule about miners committing to which prior blocks have been valid) |
| 16:30:21 | Taek: | There might be a way to improve on everyone needing to d/l the 20mb blocks as well |
| 16:30:27 | zooko: | Hiya Taek! Nice to meet you IRL. |
| 16:30:47 | Taek: | hey zooko! I enjoyed chatting |
| 16:31:28 | Taek: | The only reason that you need to d/l the whole block is to be certain that none of the data is being withheld |
| 16:31:49 | Taek: | as the security model breaks if someone can hide a valid portion of the chain |
| 16:32:37 | Taek: | Previous discussions with gmaxwell suggest that there might be ways to avoid needing to download the entire 20mb block while still having high certainty that no data is being withheld |
| 16:57:35 | Taek: | I'm curious if the above idea is something worth putting on the mailing list |
| 17:45:02 | zooko: | https://leastauthority.com/blog/a_bug_in_libsnark.html |
| 17:58:21 | Luke-Jr: | zooko: so is this a Zerocash softfork? (was Zerocash actually released in some form?) |
| 18:27:39 | kanzure_: | kanzure_ is now known as kanzure |
| 18:54:58 | theymos: | Taek: That's a bit like tree chains, isn't it? |
| 18:56:15 | theymos: | Taek: I'm also not confident that merge-mined sidechains will be particularly useful if any big Bitcoin pool can destroy them at will almost for free. |
| 18:56:58 | kanzure: | well they are giving up the opportunity to mine for other things during that time |
| 18:57:07 | kanzure: | i mean during the time that they are attacking |
| 18:57:14 | kanzure: | (depending on how weak the target is) |
| 18:58:12 | Taek: | it's not a huge sacrifice though, b/c they are still getting the rewards from the majority chain. It's even more significant if they can merge-mine many chains at once. |
| 18:58:36 | Taek: | then their only opportunity cost is the reward on the chain they are attacking |
| 19:02:59 | kanzure: | they only get the rewards from the majority chain if they are actively mining |
| 19:03:26 | kanzure: | oh merge-mining an attack? hm |
| 19:03:39 | Taek: | right |
| 19:05:04 | Taek: | especially if you're including behaviors like bribes, a coin with a very small reward doesn't require much of a bribe to convince a pool to attack-mine or just not mine. |
| 19:08:16 | Taek: | that ceases to be a problem in my 'merged block' scheme, because reorging any set of transactions requires reorging every set of transactions - you lose out on the rewards of the majority chain as well as the rewards on the minority chain |
| 19:17:06 | theymos: | Instead of doing PoW on sidechains, I wonder if you could do something like this: After creating a new sidechain block without any PoW, broadcast or mine a transaction on the Bitcoin network with an OP_RETURN output containing some sidechain-identifying leading info and the sidechain block hash. The real next block in the sidechain is the first such transaction listed in a Bitcoin block. The Bit |
| 19:17:06 | theymos: | coin network already keeps track of ordering, so don't allow reorgs on the sidechain without reorgs on the Bitcoin chain. |
| 19:19:17 | Taek: | what is the sidechain identifying leading info? That is very important |
| 19:19:43 | Taek: | If it's just a hash, someone could hide a different reorg in the bitcoin chain, and then reveal it |
| 19:20:13 | Taek: | if there's some identifying prefix, someone could release a prefix followed by a nonsense hash, and you have to figure out how to choose which entries to ignore |
| 19:21:31 | theymos: | Ah, good point. |
| 19:23:09 | theymos: | Maybe this particular idea doesn't work then, but I feel like if possible it'd be better to do sidechain-type stuff without any additional PoW (including merged mining) by attaching sidechain stuff more tightly to Bitcoin blocks, in this general vein. |
| 19:32:53 | wallet42: | wallet42 is now known as Guest69714 |
| 19:32:53 | wallet421: | wallet421 is now known as wallet42 |
| 19:48:01 | fluffypony: | theymos: that's basically what we're going to do be doing with some of the Monero daughter-chains, no coinbase and more tightly coupled to the mainchain, with nodes being able to advertise what additional chains they serve |
| 19:48:35 | fluffypony: | but then it's less of an "anyone can make a chain!" thing, and more of a "hallowed be thy blessed other-chains" |
| 21:12:04 | Luke-Jr: | fluffypony: Monero daughter-chains for Bitcoin, or within Monero? |
| 21:13:12 | Luke-Jr: | theymos: also to consider, what if it's an invalid sidechain block |
| 21:22:19 | fluffypony: | Luke-Jr: within Monero |