| 01:02:37 | wallet42: | wallet42 is now known as Guest26574 |
| 01:02:37 | wallet421: | wallet421 is now known as wallet42 |
| 01:18:32 | dgenr8: | justanotheruser: A miner has to believe that about 5% will delay, to rationally give up on including double-spends worth .03 BTC |
| 01:18:39 | dgenr8: | justanotheruser: (He does have to believe that 62% will delay a block, to decide not to build on it) |
| 01:18:46 | dgenr8: | justanotheruser: If 5% start to delay - regardless of the cost to themselves - rationally everyone will exclude double-spends |
| 01:19:04 | dgenr8: | justanotheruser: This lowers the cost of delaying to 0, since now nothing has to be delayed |
| 01:19:06 | dgenr8: | justanotheruser: Now, everyone is willing to delay, and it should be easy to convince 62% to do so, which then takes you straight to 100% |
| 01:36:46 | nsh: | * nsh shakes head |
| 01:39:26 | tobyai: | tobyai has left #bitcoin-wizards |
| 01:56:53 | _2539_: | _2539_ is now known as _2539 |
| 02:32:03 | tobyai: | tobyai has left #bitcoin-wizards |
| 02:40:20 | dgenr8: | this is something everyone wants for the network, it's just been difficult to find a way to get there. |
| 03:30:57 | justanotheruser: | dgenr8: Forcing reorgs is expensive for miners and dangerous for the network. I don't see how incentivizing miners to do this is a realistic solution. |
| 03:58:24 | Luke-Jr: | dgenr8: excluding double-spends is ridiculous |
| 03:58:48 | Luke-Jr: | dgenr8: you realise all you're saying is "kill fungibility"? |
| 03:59:00 | Luke-Jr: | all of a sudden those UTXOs are no longer spendable ever |
| 04:01:26 | dgenr8: | Luke-Jr: the first spend can be confirmed, and it can be replaced after Tmax (say 120 minutes) |
| 04:01:35 | Luke-Jr: | dgenr8: there is no first spend |
| 04:03:24 | Luke-Jr: | "first" requires ordering. which is what miners do. |
| 04:22:29 | penny: | penny is now known as Guest54360 |
| 04:22:34 | dgenr8: | This does not assume global ordering. It shows that local ordering creates the desired results, if you include a big (relative to propagation times) safety margin |
| 04:56:26 | dgenr8: | justanotheruser: delaying allows miners to incentivize other miners, at some possible risk to themselves, but without breaking bitcoin. |
| 04:56:32 | dgenr8: | i think it can work if the overall goal is shared widely (as with deprecating empty blocks) |
| 04:57:04 | dgenr8: | in the particular case of double-spend protection, it is admittedly dependent on a change to all nodes, to relay double spends |
| 04:57:18 | Luke-Jr: | dgenr8: it does assume global ordering, because if there is any significant penalty, no miner will touch it |
| 04:57:45 | Luke-Jr: | dgenr8: I don't recall you finding a way to sanely relay double spends yet? |
| 04:58:57 | justanotheruser: | dgenr8: How do you define a delay? Miners consider the block invalid for 1 minute? |
| 04:59:44 | dgenr8: | justanotheruser: until 1 block is mined on top of it |
| 05:00:46 | Luke-Jr: | lol |
| 05:00:50 | Luke-Jr: | that's even worse than a delay |
| 05:01:08 | justanotheruser: | dgenr8: ok, so I just have to mine a block on top of it... not sure what disincentive there is to do that |
| 05:01:17 | Luke-Jr: | now instead of 6 blocks to confirm, you have to wait 10 |
| 05:01:50 | justanotheruser: | why would I mine on the old block if there is a new block that my fork would have to beat? |
| 05:02:00 | Luke-Jr: | and yes, it does in fact break bitcoin because you can no longer double spend |
| 05:02:46 | dgenr8: | justanotheruser: you may be the only one building on it |
| 05:02:57 | justanotheruser: | dgenr8: maybe, but if I do build on it then my block is valid |
| 05:03:44 | dgenr8: | yes, but as we discussed earlier, the incentive is aimed at the guy who risked the delay |
| 05:04:10 | justanotheruser: | the rest of the network is at a disadvantage, they are 99% trying to make 2 blocks in the time I am trying to make 1 block. |
| 05:04:24 | dgenr8: | they will win in that setup |
| 05:04:31 | dgenr8: | that is the crux of it though |
| 05:04:38 | justanotheruser: | they will win a good amount of the time |
| 05:04:58 | justanotheruser: | but their return per hash will be less than mine |
| 05:05:44 | justanotheruser: | so the smart miners will follow what the 1% is doing and mine on top of the delayed block, effectively removing the delay |
| 05:07:33 | dgenr8: | Luke-Jr: having your block delayed is a significant penalty, so you may think twice about touching a double-spend |
| 05:08:20 | Luke-Jr: | dgenr8: what you're talking about isn't a delay, it's a 51% attack |
| 05:08:58 | dgenr8: | Luke-Jr: No, it's a 6.9% incentivization. Do read through it if you have time. |
| 05:10:02 | Luke-Jr: | sorry, already wasting enough time on discussing stupid ideas |
| 05:11:22 | dgenr8: | Luke-Jr: thanks for discussing it |
| 05:12:23 | Luke-Jr: | the nice thing about your idea is that as long as the majority of miners are sane, they don't even *have* to try to 51% the idiots - it's just automatic :D |
| 05:15:24 | dgenr8: | Luke-Jr: i don't think anybody else is as committed to mining double-spends as you are |
| 05:15:46 | Luke-Jr: | dgenr8: try petertodd |
| 05:16:46 | Luke-Jr: | anyhow, my point was that miners don't have to be committed to keeping Bitcoin usable - resistance to your proposal is the default/automatic |
| 05:23:46 | dgenr8: | these are folks who are worried about a few seconds of block propagation time. and my data shows they aren't interested in including double-spends anyway. |
| 05:29:18 | Luke-Jr: | which is all irrelevant |
| 05:39:15 | OP_NULL: | dgenr8: "aren't interested in including double spends" is a weird phrase. cex.io's pool were rather keen on it for a certain portion of time. what are you using to distinguish a "double spend"? |
| 05:40:28 | dgenr8: | the green boxes here http://respends.thinlink.com are where miner included the first one seen by my node, despite higher fees |
| 05:42:44 | OP_NULL: | what you saw first isn't always what the miner saw first though. what you think is an unsuccessful double spend could really be a successful one. |
| 05:43:32 | dgenr8: | sure |
| 05:43:57 | OP_NULL: | is there a reason that website only has two columns for alternate transactions? |
| 05:45:54 | dgenr8: | alternate? |
| 05:46:37 | dgenr8: | tx1 includes the whole cohort that is invalidated by tx2. different inputs, and all dependent txes |
| 05:46:44 | OP_NULL: | you have tx1, tx2, what prevents somebody from spending an output in 50 different ways? |
| 05:48:37 | dgenr8: | another tx2 will get another row. so there can be duplication in the tx1's. adding the amount colums may be misleading. it doesn't seem to happen that much though. |
| 05:50:54 | dgenr8: | actually the reason for that is because the bitcoind branch its running tracks only one tx2 per coin |
| 05:52:25 | OP_NULL: | I toyed with the idea of pushing a unique transaction to every node in the network and seeing which one ended up in a block. |
| 05:53:13 | dgenr8: | cool, then repeat it a thousand times and you'd learn a lot ;) |
| 05:54:19 | Luke-Jr: | "not interested in double spends" does not mean the miners are willing to attack Bitcoin in order to try to prevent them |
| 05:55:03 | Luke-Jr: | so your statistics are irrelevant |
| 05:55:23 | dgenr8: | satoshi was attacking bitcoin pretty hard then. he really wanted to prevent double-spends |
| 05:55:37 | dgenr8: | he called this a "2.0 problem" btw |
| 05:56:12 | OP_NULL: | part of the point is that miners are just as blind as to what constitutes a double spend as everybody else. if you could evaluate what was canon there's be no need for a block chain in the first place. |
| 05:56:38 | Luke-Jr: | (also, the statistics just demonstrate miner laziness more than anything) |
| 05:58:49 | dgenr8: | OP_NULL: what i explored is how well nodes will agree on ordering after a long time relative to tx propagation. |
| 05:59:57 | Luke-Jr: | nodes are very good on agreeing on ordering when nobody is trying to double spend. |
| 06:00:18 | Luke-Jr: | and no, today's "attempts" that I've seen do not count as trying. |
| 06:01:20 | dgenr8: | well that 18BTC one is outside 2h anyway |
| 06:02:20 | phantomcircuit: | Luke-Jr, would you like to see a zero mining power attempt |
| 06:02:29 | phantomcircuit: | i'll do it against myself for kicks |
| 06:03:10 | Luke-Jr: | phantomcircuit: I don't particularly care to see it in practice, but maybe dgenr8 would since he seems to think he can stop them |
| 06:03:18 | phantomcircuit: | i'd have to start up the log all the things server though |
| 06:03:25 | phantomcircuit: | which generates like 8GB/day of log files |
| 06:03:41 | Luke-Jr: | lol |
| 06:04:02 | OP_NULL: | dgenr8: I read that, but I'm not really convinved. not only because I don't think there's more than 2 degrees of separation between most nodes. |
| 06:04:41 | phantomcircuit: | Luke-Jr, and that's deduplicated with compression |
| 06:05:59 | phantomcircuit: | it would probably be more now actually since it would get spv client connections with unique bloom filters |
| 06:06:59 | dgenr8: | OP_NULL: what I mean is, if two txes are transmitted 30s apart, only .09% of nodes will disagree with the majority |
| 06:09:28 | OP_NULL: | dgenr8: where does that number come from? |
| 06:09:55 | Luke-Jr: | dgenr8: a real double spend transmits the "second" spend first. |
| 06:10:54 | dgenr8: | OP_NULL: the bitcoinstats numbers are well modeled by a lognormal distribution. then i computed a derived distribution for the difference of two of those. |
| 06:14:12 | OP_NULL: | dgenr8: things get stickier if you are up against somebody doing it intentionally. you can abuse pool rules and relay rules to tweak those values to your advantage. |
| 06:14:53 | OP_NULL: | if the target is running 0.8 and most pools are running 0.9, you can pevent them from ever seeing a particular transaction by abusing the dust relay defaults in the two versions. |
| 06:15:48 | dgenr8: | yeah, there's not much you can do to make your tx go faster. you can make it slow though. which will make nodes see it as pretty late. |
| 06:17:50 | OP_NULL: | with the block slowing rule you could abuse that to cause certain pools blocks to often be orphaned. |
| 06:18:20 | dgenr8: | block slowing rule? |
| 06:18:44 | OP_NULL: | the thing you proposed. |
| 06:19:24 | dgenr8: | you mean the pools that like to include double-spends aged > 30s? |
| 06:20:08 | OP_NULL: | no, you could prevent a pool from seeing a transaction at all by abusing dust rules, and then their block would likely be orphaned as a result. |
| 06:23:11 | dgenr8: | you mean the dust rate-limiter? |
| 06:23:38 | OP_NULL: | there's a free transaction limiter. dust is rejected outright. |
| 06:24:00 | dgenr8: | how could that be used selectively? |
| 06:25:10 | OP_NULL: | different versions have different defaults, some have user altered configurations. |
| 06:25:56 | dgenr8: | i see. good point. justanotheruser: going to sleep on your last comment. |
| 06:51:48 | OP_NULL: | dgenr8: the more I think about it, the worse that rule becomes for the miners. there's an obvious incentive for them to subvert that rule either by private peering or alternate networks. |
| 06:52:24 | OP_NULL: | you can also do an easy finney attack with it too. if I’m "holding" a block and I know that peer X hasn’t seen it yet, I can send them a transaction that spends an output already spent in my held block. they won’t see any double spends because all of their peers think it’s spending an invalid output. |
| 07:15:13 | artifexd_: | artifexd_ is now known as artifexd |
| 07:17:48 | goddammitwhytim: | goddammitwhytim is now known as jbenet |
| 08:15:35 | petertodd: | gmaxwell: good idea, that merkle tree looks fine to me |
| 08:22:14 | petertodd: | gmaxwell: there's a few other options too, but the IETF makes for a good reference |
| 09:05:18 | 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:18 | verne.freenode.net: | Users on #bitcoin-wizards: andy-logbot luny` AaronvanW koshii coinheavy damethos vmatekole kyletorpey cbeams todaystomorrow jbenet artifexd OX3 MoALTz otoburb TheSeven null_radix PRab atgreen Guest54360 chris200_ Dr-G2 Greed PaulCapestany EasyAt CryptOprah BlueMatt kumavis spinza _2539 fanquake wallet42 HaltingState citizen11 tacotime zwischenzug starsoccer pi07r phawk justanotheruser Hunger- SDCDev Aquent waxwing Starduster HM SubCreative mortale bosma maaku Adlai ebfull |
| 09:05:18 | verne.freenode.net: | Users on #bitcoin-wizards: devrandom kefkius BananaLotus wizkid057 warptangent Guest64179 prepost hollandais go1111111 super3 Cory Meeh Nightwolf shesek bbrittain comboy dgenr8 epscy zenojis paperbot rasengan altoz fluffypony grandmaster2 K1773R gnusha fenn kanzure heath stonecoldpat copumpkin LarsLarsen Logicwax jaromil weex helo Alanius c0rw1n samson_ tromp_ Keefe Iriez Eliel jrayhawk crescendo Baz___ lnovy Luke-Jr coutts Fistful_of_Coins CodeShark DoctorBTC Grishnakh |
| 09:05:19 | verne.freenode.net: | Users on #bitcoin-wizards: iddo Emcy gmaxwell Flyer33 [\\\] bobke_ sneak napedia huseby GnarSith Anduck phedny iambernie MRL-Relay berndj phantomcircuit mmozeiko midnightmagic sl01 nsh Muis arowser sipa poggy NikolaiToryzin cfields coryfields mappum Taek optimator_ andytoshi BrainOverfl0w fds4345 gazab BigBitz Apocalyptic emsid throughnothing warren gavinandresen dansmith_btc AdrianG mr_burdell zibbo_ tromp SomeoneWeird kgk firepacket Dyaheon myeagleflies wumpus pigeons |
| 09:05:19 | verne.freenode.net: | Users on #bitcoin-wizards: nanotube asoltys gribble Krellan kinlo a5m0 [d__d] LaptopZZ espes__ Graet livegnik hguux petertodd smooth @gwillen michagogo yoleaux amiller btc_ @ChanServ lechuga_ abc56889 harrow so ahmed_ Gnosis pajarillo roasbeef ryan-c [Tristan] TD-Linux catcow danneu |
| 10:25:27 | lclc: | If I have a sidechain that provides additional tx / contract features, has no own coin, and I'd like to secure this sidechain with merged-mining, I have the problem that the only incentive to mine my sidechain is tx fees. So if not all the big pools take part there, it could easily be destroyed by a bigger pool (as happenend in past with merged mining) |
| 10:25:55 | lclc: | e.g. I make a sidechain with gambling, and Luke-Jr doesn't like gambling, so he will kill my sidechain with eligius |
| 10:26:03 | lclc: | any idea how to prevent this? |
| 10:26:46 | kumavis: | kumavis is now known as Nekokamisama |
| 10:26:53 | Nekokamisama: | Nekokamisama is now known as kumavis |
| 10:28:08 | justanotheruser: | lclc: 1) Luke-Jr doesn't dislike gambling 2) You need most miners merged mining your sidechain for it to be secure. If only 10% of the network is mining it (and they're all honest miners), 11% of the network needs to collude to attack it |
| 10:28:41 | petertodd: | lclc: that's a fundemental flaw of sidechains; two-way pegs give the attackers incentives even if they don't care about your chain |
| 10:29:28 | lclc: | justanotheruser: 1) it seemed so, but ok. was just an example |
| 10:29:35 | lclc: | ok, so no simple solution for this yet |
| 10:30:31 | petertodd: | lclc: mastercoin/counterparty style embedded consensus works, subject to cost and censorship resistance tradeoffs |
| 10:30:57 | justanotheruser: | lclc: the benefits of helping the sidechain have to be great enough so not enough miners are incenvized to attack the network that an attack is likely. |
| 10:31:10 | petertodd: | lclc: (though if you go down that route, you can do *much* better than msc/xcp has done from a tech point of view) |
| 10:31:57 | lclc: | petertodd: interesting, thanks. Have to read up on how they do it |
| 10:32:33 | petertodd: | lclc: if you're serious about this, send me an email and I'll give you an outline of the best-practice options available right now; basically you should use a structure similar to colored coins if you can help it |
| 10:34:26 | lclc: | petertodd: I will, thanks. Will read a bit more first so I can ask the right questions :) |
| 10:34:37 | petertodd: | lclc: ha, thanks! |
| 12:08:47 | RichiH: | [Global Notice] The GNOME foundation has been forced to defend its trademark against Groupon. This goes beyond just GNOME; this is about the FLOSS community showing the corporate world that our trademarks will be defended; not just by specific victims, but by all of us. Our stance can be found at http://blog.freenode.net/2014/11/helping-gnome-defend-its-trademark/ while GNOME's can be found at http://www.gnome.org/groupon/ |
| 12:17:07 | NewLiberty: | Is there any reason that a Side Chain could not make use of atomic swaps as well as SPV with its own Main Chain, if the side chain supports the necessary scripting? |
| 12:17:39 | sipa: | yes, of course |
| 12:17:59 | sipa: | but atomic swaps don't change the amount of currency in each chain, they just move ownership in both |
| 12:22:38 | NewLiberty: | Right, it has a different purpose of course. |
| 12:23:56 | sipa: | also, see appendix c of http://blockstream.com/sidechains.pdf |
| 12:28:29 | NewLiberty: | The presumption is that if atomic swap, or even an exchange would be faster, there may be some premium on speed over the confirmation process of SPV |
| 12:29:50 | sipa: | by SPV, you mean the peg mechanism? |
| 12:30:24 | sipa: | speed and fees |
| 12:30:38 | NewLiberty: | yeah, but I don't like the use of the word peg for this. Pegs always fail in the real world, so bad connotations |
| 12:30:53 | NewLiberty: | this by contrast ought never fail |
| 12:32:32 | NewLiberty: | fast coins tend to be worth more than slow, localbitcoin pricing is proof enough of that. I'm looking for any pernicious economic effects. |
| 12:35:25 | NewLiberty: | For example, there is some economic incentive to SPV coins from the Main Chain and then exchange them at a premium to take advantage of the fast coin advantage. This could cause more Side Chain coins to be created than are useful for any popular side chain. Step 6: profit |
| 12:38:10 | NewLiberty: | So exchanging via atomic swap may be 1.01:1 instead of 1:1 |
| 12:53:23 | sipa: | maybe yes |
| 12:55:48 | justanotheruser: | petertodd: don't you think at most these tx should have their merkle root put into a tx rather than 1 tx per bitcoin tx? |
| 13:00:21 | justanotheruser: | with merged mining there is an attack risk substituted for a censorship risk and additional space in the main chain. With your "put the tx in an OP_RETURN tx" (which I assume what you mean by best practices), you could just put the whole merkle root in the blockchain. |
| 13:03:44 | justanotheruser: | And if we're just putting the hash of the tx in the blockchain rather than the full tx that opens you up to, AFAICS, trivial doublespends and conflicting tx. I suppose you would need to put the full tx in a bitcoin tx for security unless your consensus is via putting altcoin block hashes in bitcoin tx and have some selection algorithm choosing the winner. |
| 13:06:52 | petertodd: | justanotheruser: I wrote about such a system over a year ago in this very channel; look for "zookeyv". Problem is what constitutes "best practice" depends on how timely your consensus needs to be, and schemes that rely on publishing commitments rather than the data itself don't acheive consensus in a timely fashion. |
| 13:07:49 | petertodd: | justanotheruser: also, keep in mind when I say "publish data" that data can be made to be indistinguishable from a standard bitcoin transaction to an external observer, making censorship very difficult, if not impossible. (same ideas as behind adam back's thoughts on indistinguishable transactions) |
| 13:08:30 | petertodd: | NewLiberty: sidechain pegging can fail, as you can steal the coins locked up in the peg, so it's quite an appropriate word... |
| 13:12:00 | petertodd: | justanotheruser: the basic issue is always "whats the incentives to publish data?" and "can a powerful attacker reorganize the chain?" - equally, ask yourself "why aren't hashes good enough for Bitcoin itself?" |
| 13:12:46 | justanotheruser: | petertodd: I don't see how it can be made indistinguishable. A miner could check whether the tx also led to a confirmation on this altcoin using a modified altcoin client. |
| 13:13:11 | petertodd: | justanotheruser: you don't need global consensus |
| 13:15:03 | petertodd: | justanotheruser: equally, sometimes the global consensus can be indistinguishable - for instance zerocash has a list of revealed nonces, well that list can include nonces "revealed" for reasons other than the zerocash protocol (IIRC - been a few months since I looked into this in detail) |
| 13:16:16 | justanotheruser: | petertodd: You don't need consensus within the currency? |
| 13:16:18 | petertodd: | justanotheruser: anyway, the thing with censorship, is that you only need a small % of miners deciding to attack your sidechain to make it insecure, while with censorship you need a 50% majority to make it useless - a much, much more secure ssytem |
| 13:16:50 | petertodd: | justanotheruser: not in the sense of "every one has every transaction" that I think your thinking of |
| 13:17:19 | justanotheruser: | petertodd: but if there needs to be a way to know whether a transaction is valid doesn't there? |
| 13:17:23 | petertodd: | justanotheruser: mastercoin and counterparty are badly designed in this respect, but you don't have to go that route |
| 13:17:45 | petertodd: | justanotheruser: yes, but imagine, for example, fi "whether a transaction is there" depends on whether or not a bitcoin txout was spent |
| 13:19:15 | justanotheruser: | petertodd: miners can check whether that txout being spent causes a transaction "to be there"? |
| 13:19:35 | petertodd: | justanotheruser: only if they have the data to know what that txout actually means - that can be hidden from them |
| 13:19:46 | petertodd: | justanotheruser: again, look up adam back's thoughts on encrypted blockchains |
| 13:19:55 | justanotheruser: | okay, will do |
| 13:20:30 | justanotheruser: | also, how do you justify forming tx so they increase the size of utxo forever? |
| 13:20:51 | petertodd: | justanotheruser: you don't have to implement it that way, but even then, not my problem |
| 13:21:23 | justanotheruser: | petertodd: okay, but then miners for sure can tell which tx aren't formed like a regular bitcoin tx. |
| 13:21:49 | justanotheruser: | or are meant to be bitcoin tx |
| 13:21:56 | petertodd: | justanotheruser: nope! lots of ways to steganographically hide data in transactions |
| 13:22:50 | petertodd: | justanotheruser: anyway, like I say, even if miners are trying to censor you, and you don't take any precations, you need a greater % of miners trying to censor you to be attacked then you do % to attack you succesfully in a sidechain system |
| 13:23:40 | justanotheruser: | petertodd: are you then saying that the pkh should be formed so it conveys some information about the state of this altcoin? |
| 13:24:11 | petertodd: | justanotheruser: that's one way to do it, but really, it depends on exactly what you're trying to do; colored coins has it really simple for instance |
| 13:25:35 | justanotheruser: | does colored coins add to the utxo permenantly? |
| 13:26:12 | petertodd: | justanotheruser: doesn't have to; not much does |
| 13:26:29 | petertodd: | why are you fixated on "adding to the utxo set" anyway? |
| 13:29:47 | justanotheruser: | petertodd: ignoring the fact that it makes running a full node more difficult, I think putting altcoin tx information into the blockchain in a way that is unknown to miners (censorship resistant), and not adding to the utxo set permenantly is an interesting problem. |
| 13:30:40 | petertodd: | justanotheruser: "interesting problem"? it's been done, multiple times. (e.g. mastercoin/counterparty/etc.) |
| 13:30:47 | petertodd: | justanotheruser: it's a trivial problem |
| 13:31:06 | justanotheruser: | petertodd: afaik, neither do thta |
| 13:31:06 | petertodd: | justanotheruser: er, so, those aren't "unknown to miners" |
| 13:31:12 | petertodd: | justanotheruser: *er sorry |
| 13:31:26 | petertodd: | justanotheruser: but anyway, the unknown to miners criteria isn't a big deal |
| 13:31:33 | justanotheruser: | it is trivial to do one or the other |
| 13:32:04 | petertodd: | justanotheruser: I've got a colored coin library that'll meet both criteria |
| 13:32:14 | justanotheruser: | link? |
| 13:32:33 | petertodd: | justanotheruser: not public yet; paid work for a client who wants a first-to-market advantage... |
| 13:34:24 | petertodd: | justanotheruser: for more general stuff like I said adam back has worked on this stuff; basically you just need to do things like commit in advance to the encryption key you'll use for the next state in the protocol, which constrains how you'll publish, preventing double spends, yet means the information is unknown to miners so they can't censor it |
| 13:34:53 | petertodd: | justanotheruser: once you publish you can reveal the key to whomever you're trying to give some asset too. |
| 13:35:06 | petertodd: | justanotheruser: an even more generic mechanism - albeit a bit impractical - is to use timelock crypto |
| 13:42:09 | justanotheruser: | petertodd: the adam back stuff is in the wizards logs? What keywords should I grep? |
| 13:50:09 | lclc: | petertodd: will the library be FOSS? |
| 13:51:03 | justanotheruser: | is there purpose to trustless coloredcoins (if you want to call them trustless) if you have to trust the author? |
| 13:51:41 | kanzure: | yes there is general utility in having a global anti-replay oracle |
| 13:57:43 | justanotheruser: | I guess it doesn't have to be FOSS, but at least open source in order to not have to trust the author. |
| 14:01:06 | Pan0ram1x: | Pan0ram1x is now known as Guest17458 |
| 16:48:23 | SDCDev: | SDCDev is now known as wheat_ |
| 16:48:46 | wheat_: | wheat_ is now known as sdcdev |
| 17:15:12 | Luke-Jr: | lclc: I'd suggest giving a small house edge to the miner in your particular case - although you should also seriously consider whether doing so would make miners somehow liable in anti-gambling jurisdictions :/ |
| 17:16:09 | Luke-Jr: | lclc: also note petertodd's idea of "best-practice" is in fact "worst possible practice" |
| 17:21:03 | justanotheruser: | Luke-Jr: his best practices optomize (are best practices for) for the altcoin, not bitcoin |
| 17:21:27 | justanotheruser: | in other words, the best practices for altcoins are probably harmful to bitcoin |
| 17:24:23 | Luke-Jr: | justanotheruser: even then, they're not best practices. |
| 17:24:39 | Luke-Jr: | real best practices for an altcoin are at the very least honest. |
| 17:25:03 | justanotheruser: | I don't know what you mean by that |
| 17:25:36 | Luke-Jr: | I mean his idea of "best practices" are inherently dishonest and not ideal for an altcoin anyway. |
| 17:25:46 | justanotheruser: | what is dishonest? |
| 17:25:55 | Luke-Jr: | forcing others to do things against their will |
| 17:26:17 | heath: | has there been a change in protocol in response to this: http://ifca.ai/fc14/papers/fc14_submission_82.pdf |
| 17:26:18 | justanotheruser: | I would disagree that altcoins care about that in general then :P |
| 17:26:52 | Luke-Jr: | heath: no, it wasn't a real problem |
| 17:27:20 | heath: | Luke-Jr: was their a conversation on github about this? |
| 17:27:31 | heath: | i'm curious how this was debunked |
| 17:27:32 | Luke-Jr: | justanotheruser: just because there's a lack of honest altcoins doesn't mean it's not a best practice :p |
| 17:27:43 | Luke-Jr: | justanotheruser: none of the exchanges implement best practices, for example |
| 17:27:55 | Luke-Jr: | heath: more likely on IRC |
| 17:28:13 | justanotheruser: | Luke-Jr: "best" defined by altcoiners tends to be properties that benefit them and disregard bitcoin full nodes |
| 17:28:39 | hearn: | a best practice, by definition, is something that is practised |
| 17:28:50 | hearn: | if nobody implements it then it may be a good idea, but it's not (yet) a best practice |
| 17:29:01 | Luke-Jr: | justanotheruser: only if you go by majority which is obviously scamcoiners |
| 17:29:07 | Luke-Jr: | hearn: fair enough |
| 17:29:37 | heath: | i've heard two complaints recently about bitcoin: |
| 17:29:42 | heath: | 1. the infrastructure is being built by volunteers, and so it is not sustainable :: mike hearn |
| 17:29:47 | heath: | - "you can't have a large spanning financial infrastructure which is held together by chewing gum, sticky tape, and people who work on it when they have time and they feel like it." |
| 17:29:52 | heath: | - dispute mediation & risk analysis services may be needed |
| 17:29:57 | heath: | 2. when there are no more bitcoins to mine, miners may have incentives to only mine the largest transactions ::random article on the internet i can't find |
| 17:30:26 | Luke-Jr: | heath: 1 is being mostly resolved; 2 is nonsense |
| 17:30:29 | justanotheruser: | heath: pretty much every committed committer is being paid to develop right now |
| 17:31:12 | hearn: | heath: random article on the internet you can't find may not be the most reliable source in the world ;) |
| 17:31:22 | hearn: | heath: you're probably thinking of the how-will-fees-work-post-inflation stuff |
| 17:31:26 | justanotheruser: | wladmir is paid by the bitcoin foundation and everyone else either has stake in or is being paid by blockstream iirc |
| 17:32:06 | justanotheruser: | heath: 2 is probably referring to ,,(bc,wiki tragedy commons) |
| 17:32:09 | Luke-Jr: | justanotheruser: I think Diapolo is currently left out |
| 17:32:42 | justanotheruser: | Luke-Jr: no offense to him, but is he a critical dev? I know he has a ton of commits, but iirc, he only works on the GUI. |
| 17:33:03 | Luke-Jr: | justanotheruser: if the GUI is considered critical :p |
| 17:33:49 | hearn: | foundation employs three developers right now: wladimir, gavin and cory |
| 17:34:18 | hearn: | blockstream now employs a few more, sipa at least seems to be doing full bitcoin stuff right now, though they have other projects too i guess |
| 17:34:24 | justanotheruser: | Luke-Jr: I'm not sure if it is especially after libbitcoinconsensus is done. |
| 17:35:22 | sipa: | justanotheruser: i don't see how the GUI being critical has anything to do with that? |
| 17:37:25 | justanotheruser: | sipa: There are many clients with GUIs already (including SPV clients and btcd). While GUIs may be critical, the -Qt GUI development stopping wouldn't be a problem. |
| 17:37:40 | justanotheruser: | s/stopping/slowing |
| 17:37:55 | sipa: | i don't consider the Qt GUI particularly relevant, whether libconsensus is there or not |
| 17:39:15 | justanotheruser: | well the original discussion was about the QT GUI. The GUI may be critical, but his development may not be critical enough to require pay since there are many GUIs that are being developed. |
| 17:39:25 | hearn: | how to fund end user wallets is still an open question |
| 17:39:42 | justanotheruser: | these GUIs can't have bitcoin consensus just plugged in until the library is done. |
| 17:39:56 | sipa: | i don't see why a GUI wallet needs consensus code at all |
| 17:40:19 | tacotime: | yeah, node-wallet-gui is generally antiquated |
| 17:40:26 | tacotime: | we're trying to steer away from it at monero |
| 17:40:36 | sipa: | i hope everyone is |
| 17:41:05 | justanotheruser: | sipa: well it is nice to not have to run two programs especially if you're a new user. |
| 17:41:32 | sipa: | it is to not have to run a full node especially if you're a new user |
| 17:41:37 | sipa: | *nice |
| 17:42:04 | sipa: | justanotheruser: i'm talking about a situation where you either run a full node in the background if you need one, or connect to other nodes if you don't (SPV) |
| 17:42:18 | sipa: | in either case, the wallet can be an entirely separate codebase from the consensus code |
| 17:42:18 | tacotime: | it's harder with monero because there's no easy way to make a utxo set due to ring signatures, but we're working on software development models where the user can run a pseudo-daemon that is easy to set up, and just pulls blocks and stores outputs rather than acts as a full node. |
| 17:42:30 | justanotheruser: | true. Either way, there are a myriad of GUIs that can run in front of bitcoind. |
| 17:44:46 | lclc: | Luke-Jr: interesting idea (paying small house edge to miners), thanks! |
| 17:45:48 | Luke-Jr: | sipa: I consider the Qt GUI somewhat important (though not critical) since all the other wallet GUIs suck :P |
| 17:46:02 | sipa: | imho, all wallet guis suck, including qt :) |
| 17:46:03 | Luke-Jr: | even after it's split |
| 17:46:14 | Luke-Jr: | pfft, I like it :P |
| 17:46:21 | Luke-Jr: | otoh, I'm also patching it so I like it <.< |
| 17:46:23 | sipa: | ok, please don't stop using it then :) |
| 17:46:40 | justanotheruser: | Luke-Jr: would you like electrum if it properly represented bitcoin? |
| 17:47:09 | Luke-Jr: | justanotheruser: probably not, it'd still be ugly |
| 17:47:24 | hearn: | hah |
| 17:47:40 | hearn: | it's getting a lot easier to make pretty wallet frontends these days |
| 17:47:47 | hearn: | i'm sure there will be plenty more in future |
| 17:47:56 | hearn: | a wallet to suit every man's personal taste (also women's) |
| 17:48:03 | Luke-Jr: | justanotheruser: if it implemented HD wallets correctly, it might get close enough to be an easy 15 minute fork to clean up though XD |
| 17:48:29 | Luke-Jr: | hearn: yeah, hopefully at some point there will be an easy to use SPV library |
| 17:48:45 | Luke-Jr: | that wallets can just link to and throw their own behaviour/GUI on top of |
| 17:48:48 | hearn: | ouch :) |
| 17:48:52 | Luke-Jr: | ? |
| 17:49:02 | sipa: | lol |
| 17:49:03 | hearn: | that's pretty much what bitcoinj already is. you can make a wallet gui with it in about 30 minutes |
| 17:49:03 | Luke-Jr: | oh |
| 17:49:13 | Luke-Jr: | I don't even consider Java when I think of things :P |
| 17:49:22 | hearn: | you can write them in lots of languages, so that's ok |
| 17:49:33 | hearn: | python, ruby, javascript, a lisp, functional languages .... |
| 17:49:34 | Luke-Jr: | hearn: without a Java runtime? |
| 17:49:55 | justanotheruser: | hearn: can't bitcoinj also be used to make a full node? |
| 17:49:59 | hearn: | nope, you need the jvm. not sure why that'd be an issue though. it's just a big runtime library, like qt |
| 17:50:08 | hearn: | it can be bundled with apps quite easily |
| 17:50:15 | Luke-Jr: | exactly, that's why I don't use GTK or Ruby software either :P |
| 17:50:21 | hearn: | justanotheruser: it doesn't listen on the network so no |
| 17:50:31 | Luke-Jr: | * Luke-Jr ponders if BitcoinJ would build with GCJ |
| 17:50:58 | hearn: | GCJ is pretty old. you can use it with a tool called avian, that builds a single native binary (it's actually a small jvm that has the java compiled into the elf) |
| 17:51:12 | hearn: | gcj does not eliminate the need for a runtime, of course |
| 17:51:24 | Luke-Jr: | GCJ elimiates JIT stuff |
| 17:51:52 | Luke-Jr: | I think |
| 17:52:02 | hearn: | yeah. though the end result is not necessarily better. |
| 17:52:23 | hearn: | you just don't like JITCs on principle? |
| 17:52:45 | Luke-Jr: | pretty much |
| 17:53:03 | Luke-Jr: | even if you managed to get memory use reasonable and CPU time eliminated, it'd still be a pain to debug stuff |
| 17:53:21 | Luke-Jr: | (part of using Gentoo is so I can build everything with debug-friendly CFLAGS) |
| 17:53:51 | hearn: | i guess it depends what you define as reasonable, but memory usage and startup time aren't a big deal these days, unless you're running on a 486 with 16mb of ram or something :) |
| 17:53:51 | Luke-Jr: | I suppose GDB extensions could be made to fix that too, but meh |
| 17:54:18 | hearn: | anything jvm based is a LOT easier to debug than anything C based though. you should try it some time. the debuggers can navigate the entire object graph easily, it's a lot more robust than gdb |
| 17:55:00 | hearn: | indeed that's one of the advantages ... you get good debuggers. most platforms or interpreted environments don't have that. also better heap profilers, cpu profilers, etc. |
| 17:55:43 | Luke-Jr: | hm |
| 17:56:07 | Luke-Jr: | same CLI interface? ;) |
| 17:57:13 | hearn: | there is, actually |
| 17:57:19 | hearn: | it's called jdb |
| 17:57:33 | hearn: | though i never use it. it's easier to visualise what's happening when you have a gui debugger and can see the code, jump around, explore it etc |
| 17:58:33 | Luke-Jr: | once upon a time I used insight, but RedHat seems to have abandoned it. it was nice to be able to use CLI while having visualisations |
| 19:16:44 | lclc: | lclc is now known as lclc_bnc |
| 21:28:58 | maaku: | maaku is now known as Guest53081 |
| 22:42:13 | MRL-Relay: | [surae] you know, poisson processes always seemed fishy to me |
| 23:01:50 | gandalf: | are there any storj like projects built with multisginatures transactions on bitcoin? |