01:02:37wallet42:wallet42 is now known as Guest26574
01:02:37wallet421:wallet421 is now known as wallet42
01:18:32dgenr8:justanotheruser: A miner has to believe that about 5% will delay, to rationally give up on including double-spends worth .03 BTC
01:18:39dgenr8:justanotheruser: (He does have to believe that 62% will delay a block, to decide not to build on it)
01:18:46dgenr8:justanotheruser: If 5% start to delay - regardless of the cost to themselves - rationally everyone will exclude double-spends
01:19:04dgenr8:justanotheruser: This lowers the cost of delaying to 0, since now nothing has to be delayed
01:19:06dgenr8: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:46nsh:* nsh shakes head
01:39:26tobyai:tobyai has left #bitcoin-wizards
01:56:53_2539_:_2539_ is now known as _2539
02:32:03tobyai:tobyai has left #bitcoin-wizards
02:40:20dgenr8:this is something everyone wants for the network, it's just been difficult to find a way to get there.
03:30:57justanotheruser: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:24Luke-Jr:dgenr8: excluding double-spends is ridiculous
03:58:48Luke-Jr:dgenr8: you realise all you're saying is "kill fungibility"?
03:59:00Luke-Jr:all of a sudden those UTXOs are no longer spendable ever
04:01:26dgenr8:Luke-Jr: the first spend can be confirmed, and it can be replaced after Tmax (say 120 minutes)
04:01:35Luke-Jr:dgenr8: there is no first spend
04:03:24Luke-Jr:"first" requires ordering. which is what miners do.
04:22:29penny:penny is now known as Guest54360
04:22:34dgenr8: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:26dgenr8:justanotheruser: delaying allows miners to incentivize other miners, at some possible risk to themselves, but without breaking bitcoin.
04:56:32dgenr8:i think it can work if the overall goal is shared widely (as with deprecating empty blocks)
04:57:04dgenr8:in the particular case of double-spend protection, it is admittedly dependent on a change to all nodes, to relay double spends
04:57:18Luke-Jr:dgenr8: it does assume global ordering, because if there is any significant penalty, no miner will touch it
04:57:45Luke-Jr:dgenr8: I don't recall you finding a way to sanely relay double spends yet?
04:58:57justanotheruser:dgenr8: How do you define a delay? Miners consider the block invalid for 1 minute?
04:59:44dgenr8:justanotheruser: until 1 block is mined on top of it
05:00:50Luke-Jr:that's even worse than a delay
05:01:08justanotheruser: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:17Luke-Jr:now instead of 6 blocks to confirm, you have to wait 10
05:01:50justanotheruser:why would I mine on the old block if there is a new block that my fork would have to beat?
05:02:00Luke-Jr:and yes, it does in fact break bitcoin because you can no longer double spend
05:02:46dgenr8:justanotheruser: you may be the only one building on it
05:02:57justanotheruser:dgenr8: maybe, but if I do build on it then my block is valid
05:03:44dgenr8:yes, but as we discussed earlier, the incentive is aimed at the guy who risked the delay
05:04:10justanotheruser: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:24dgenr8:they will win in that setup
05:04:31dgenr8:that is the crux of it though
05:04:38justanotheruser:they will win a good amount of the time
05:04:58justanotheruser:but their return per hash will be less than mine
05:05:44justanotheruser: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:33dgenr8:Luke-Jr: having your block delayed is a significant penalty, so you may think twice about touching a double-spend
05:08:20Luke-Jr:dgenr8: what you're talking about isn't a delay, it's a 51% attack
05:08:58dgenr8:Luke-Jr: No, it's a 6.9% incentivization. Do read through it if you have time.
05:10:02Luke-Jr:sorry, already wasting enough time on discussing stupid ideas
05:11:22dgenr8:Luke-Jr: thanks for discussing it
05:12:23Luke-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:24dgenr8:Luke-Jr: i don't think anybody else is as committed to mining double-spends as you are
05:15:46Luke-Jr:dgenr8: try petertodd
05:16:46Luke-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:46dgenr8: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:18Luke-Jr:which is all irrelevant
05:39:15OP_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:28dgenr8:the green boxes here http://respends.thinlink.com are where miner included the first one seen by my node, despite higher fees
05:42:44OP_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:57OP_NULL:is there a reason that website only has two columns for alternate transactions?
05:46:37dgenr8:tx1 includes the whole cohort that is invalidated by tx2. different inputs, and all dependent txes
05:46:44OP_NULL:you have tx1, tx2, what prevents somebody from spending an output in 50 different ways?
05:48:37dgenr8: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:54dgenr8:actually the reason for that is because the bitcoind branch its running tracks only one tx2 per coin
05:52:25OP_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:13dgenr8:cool, then repeat it a thousand times and you'd learn a lot ;)
05:54:19Luke-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:03Luke-Jr:so your statistics are irrelevant
05:55:23dgenr8:satoshi was attacking bitcoin pretty hard then. he really wanted to prevent double-spends
05:55:37dgenr8:he called this a "2.0 problem" btw
05:56:12OP_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:38Luke-Jr:(also, the statistics just demonstrate miner laziness more than anything)
05:58:49dgenr8:OP_NULL: what i explored is how well nodes will agree on ordering after a long time relative to tx propagation.
05:59:57Luke-Jr:nodes are very good on agreeing on ordering when nobody is trying to double spend.
06:00:18Luke-Jr:and no, today's "attempts" that I've seen do not count as trying.
06:01:20dgenr8:well that 18BTC one is outside 2h anyway
06:02:20phantomcircuit:Luke-Jr, would you like to see a zero mining power attempt
06:02:29phantomcircuit:i'll do it against myself for kicks
06:03:10Luke-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:18phantomcircuit:i'd have to start up the log all the things server though
06:03:25phantomcircuit:which generates like 8GB/day of log files
06:04:02OP_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:41phantomcircuit:Luke-Jr, and that's deduplicated with compression
06:05:59phantomcircuit:it would probably be more now actually since it would get spv client connections with unique bloom filters
06:06:59dgenr8:OP_NULL: what I mean is, if two txes are transmitted 30s apart, only .09% of nodes will disagree with the majority
06:09:28OP_NULL:dgenr8: where does that number come from?
06:09:55Luke-Jr:dgenr8: a real double spend transmits the "second" spend first.
06:10:54dgenr8: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:12OP_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:53OP_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:48dgenr8: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:50OP_NULL:with the block slowing rule you could abuse that to cause certain pools blocks to often be orphaned.
06:18:20dgenr8:block slowing rule?
06:18:44OP_NULL:the thing you proposed.
06:19:24dgenr8:you mean the pools that like to include double-spends aged > 30s?
06:20:08OP_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:11dgenr8:you mean the dust rate-limiter?
06:23:38OP_NULL:there's a free transaction limiter. dust is rejected outright.
06:24:00dgenr8:how could that be used selectively?
06:25:10OP_NULL:different versions have different defaults, some have user altered configurations.
06:25:56dgenr8:i see. good point. justanotheruser: going to sleep on your last comment.
06:51:48OP_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:24OP_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:13artifexd_:artifexd_ is now known as artifexd
07:17:48goddammitwhytim:goddammitwhytim is now known as jbenet
08:15:35petertodd:gmaxwell: good idea, that merkle tree looks fine to me
08:22:14petertodd:gmaxwell: there's a few other options too, but the IETF makes for a good reference
09:05:18verne.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:18verne.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:18verne.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:19verne.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:19verne.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:27lclc: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:55lclc: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:03lclc:any idea how to prevent this?
10:26:46kumavis:kumavis is now known as Nekokamisama
10:26:53Nekokamisama:Nekokamisama is now known as kumavis
10:28:08justanotheruser: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:41petertodd: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:28lclc:justanotheruser: 1) it seemed so, but ok. was just an example
10:29:35lclc:ok, so no simple solution for this yet
10:30:31petertodd:lclc: mastercoin/counterparty style embedded consensus works, subject to cost and censorship resistance tradeoffs
10:30:57justanotheruser: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:10petertodd: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:57lclc:petertodd: interesting, thanks. Have to read up on how they do it
10:32:33petertodd: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:26lclc:petertodd: I will, thanks. Will read a bit more first so I can ask the right questions :)
10:34:37petertodd:lclc: ha, thanks!
12:08:47RichiH:[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:07NewLiberty: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:39sipa:yes, of course
12:17:59sipa:but atomic swaps don't change the amount of currency in each chain, they just move ownership in both
12:22:38NewLiberty:Right, it has a different purpose of course.
12:23:56sipa:also, see appendix c of http://blockstream.com/sidechains.pdf
12:28:29NewLiberty: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:50sipa:by SPV, you mean the peg mechanism?
12:30:24sipa:speed and fees
12:30:38NewLiberty: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:53NewLiberty:this by contrast ought never fail
12:32:32NewLiberty: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:25NewLiberty: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:10NewLiberty:So exchanging via atomic swap may be 1.01:1 instead of 1:1
12:53:23sipa:maybe yes
12:55:48justanotheruser: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:21justanotheruser: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:44justanotheruser: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:52petertodd: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:49petertodd: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:30petertodd: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:00petertodd: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:46justanotheruser: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:11petertodd:justanotheruser: you don't need global consensus
13:15:03petertodd: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:16justanotheruser:petertodd: You don't need consensus within the currency?
13:16:18petertodd: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:50petertodd:justanotheruser: not in the sense of "every one has every transaction" that I think your thinking of
13:17:19justanotheruser:petertodd: but if there needs to be a way to know whether a transaction is valid doesn't there?
13:17:23petertodd:justanotheruser: mastercoin and counterparty are badly designed in this respect, but you don't have to go that route
13:17:45petertodd:justanotheruser: yes, but imagine, for example, fi "whether a transaction is there" depends on whether or not a bitcoin txout was spent
13:19:15justanotheruser:petertodd: miners can check whether that txout being spent causes a transaction "to be there"?
13:19:35petertodd:justanotheruser: only if they have the data to know what that txout actually means - that can be hidden from them
13:19:46petertodd:justanotheruser: again, look up adam back's thoughts on encrypted blockchains
13:19:55justanotheruser:okay, will do
13:20:30justanotheruser:also, how do you justify forming tx so they increase the size of utxo forever?
13:20:51petertodd:justanotheruser: you don't have to implement it that way, but even then, not my problem
13:21:23justanotheruser:petertodd: okay, but then miners for sure can tell which tx aren't formed like a regular bitcoin tx.
13:21:49justanotheruser:or are meant to be bitcoin tx
13:21:56petertodd:justanotheruser: nope! lots of ways to steganographically hide data in transactions
13:22:50petertodd: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:40justanotheruser:petertodd: are you then saying that the pkh should be formed so it conveys some information about the state of this altcoin?
13:24:11petertodd: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:35justanotheruser:does colored coins add to the utxo permenantly?
13:26:12petertodd:justanotheruser: doesn't have to; not much does
13:26:29petertodd:why are you fixated on "adding to the utxo set" anyway?
13:29:47justanotheruser: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:40petertodd:justanotheruser: "interesting problem"? it's been done, multiple times. (e.g. mastercoin/counterparty/etc.)
13:30:47petertodd:justanotheruser: it's a trivial problem
13:31:06justanotheruser:petertodd: afaik, neither do thta
13:31:06petertodd:justanotheruser: er, so, those aren't "unknown to miners"
13:31:12petertodd:justanotheruser: *er sorry
13:31:26petertodd:justanotheruser: but anyway, the unknown to miners criteria isn't a big deal
13:31:33justanotheruser:it is trivial to do one or the other
13:32:04petertodd:justanotheruser: I've got a colored coin library that'll meet both criteria
13:32:33petertodd:justanotheruser: not public yet; paid work for a client who wants a first-to-market advantage...
13:34:24petertodd: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:53petertodd:justanotheruser: once you publish you can reveal the key to whomever you're trying to give some asset too.
13:35:06petertodd:justanotheruser: an even more generic mechanism - albeit a bit impractical - is to use timelock crypto
13:42:09justanotheruser:petertodd: the adam back stuff is in the wizards logs? What keywords should I grep?
13:50:09lclc:petertodd: will the library be FOSS?
13:51:03justanotheruser:is there purpose to trustless coloredcoins (if you want to call them trustless) if you have to trust the author?
13:51:41kanzure:yes there is general utility in having a global anti-replay oracle
13:57:43justanotheruser: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:06Pan0ram1x:Pan0ram1x is now known as Guest17458
16:48:23SDCDev:SDCDev is now known as wheat_
16:48:46wheat_:wheat_ is now known as sdcdev
17:15:12Luke-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:09Luke-Jr:lclc: also note petertodd's idea of "best-practice" is in fact "worst possible practice"
17:21:03justanotheruser:Luke-Jr: his best practices optomize (are best practices for) for the altcoin, not bitcoin
17:21:27justanotheruser:in other words, the best practices for altcoins are probably harmful to bitcoin
17:24:23Luke-Jr:justanotheruser: even then, they're not best practices.
17:24:39Luke-Jr:real best practices for an altcoin are at the very least honest.
17:25:03justanotheruser:I don't know what you mean by that
17:25:36Luke-Jr:I mean his idea of "best practices" are inherently dishonest and not ideal for an altcoin anyway.
17:25:46justanotheruser:what is dishonest?
17:25:55Luke-Jr:forcing others to do things against their will
17:26:17heath:has there been a change in protocol in response to this: http://ifca.ai/fc14/papers/fc14_submission_82.pdf
17:26:18justanotheruser:I would disagree that altcoins care about that in general then :P
17:26:52Luke-Jr:heath: no, it wasn't a real problem
17:27:20heath:Luke-Jr: was their a conversation on github about this?
17:27:31heath:i'm curious how this was debunked
17:27:32Luke-Jr:justanotheruser: just because there's a lack of honest altcoins doesn't mean it's not a best practice :p
17:27:43Luke-Jr:justanotheruser: none of the exchanges implement best practices, for example
17:27:55Luke-Jr:heath: more likely on IRC
17:28:13justanotheruser:Luke-Jr: "best" defined by altcoiners tends to be properties that benefit them and disregard bitcoin full nodes
17:28:39hearn:a best practice, by definition, is something that is practised
17:28:50hearn:if nobody implements it then it may be a good idea, but it's not (yet) a best practice
17:29:01Luke-Jr:justanotheruser: only if you go by majority which is obviously scamcoiners
17:29:07Luke-Jr:hearn: fair enough
17:29:37heath:i've heard two complaints recently about bitcoin:
17:29:42heath:1. the infrastructure is being built by volunteers, and so it is not sustainable :: mike hearn
17:29:47heath:- "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:52heath:- dispute mediation & risk analysis services may be needed
17:29:57heath: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:26Luke-Jr:heath: 1 is being mostly resolved; 2 is nonsense
17:30:29justanotheruser:heath: pretty much every committed committer is being paid to develop right now
17:31:12hearn:heath: random article on the internet you can't find may not be the most reliable source in the world ;)
17:31:22hearn:heath: you're probably thinking of the how-will-fees-work-post-inflation stuff
17:31:26justanotheruser:wladmir is paid by the bitcoin foundation and everyone else either has stake in or is being paid by blockstream iirc
17:32:06justanotheruser:heath: 2 is probably referring to ,,(bc,wiki tragedy commons)
17:32:09Luke-Jr:justanotheruser: I think Diapolo is currently left out
17:32:42justanotheruser: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:03Luke-Jr:justanotheruser: if the GUI is considered critical :p
17:33:49hearn:foundation employs three developers right now: wladimir, gavin and cory
17:34:18hearn: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:24justanotheruser:Luke-Jr: I'm not sure if it is especially after libbitcoinconsensus is done.
17:35:22sipa:justanotheruser: i don't see how the GUI being critical has anything to do with that?
17:37:25justanotheruser: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:55sipa:i don't consider the Qt GUI particularly relevant, whether libconsensus is there or not
17:39:15justanotheruser: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:25hearn:how to fund end user wallets is still an open question
17:39:42justanotheruser:these GUIs can't have bitcoin consensus just plugged in until the library is done.
17:39:56sipa:i don't see why a GUI wallet needs consensus code at all
17:40:19tacotime:yeah, node-wallet-gui is generally antiquated
17:40:26tacotime:we're trying to steer away from it at monero
17:40:36sipa:i hope everyone is
17:41:05justanotheruser:sipa: well it is nice to not have to run two programs especially if you're a new user.
17:41:32sipa:it is to not have to run a full node especially if you're a new user
17:42:04sipa: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:18sipa:in either case, the wallet can be an entirely separate codebase from the consensus code
17:42:18tacotime: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:30justanotheruser:true. Either way, there are a myriad of GUIs that can run in front of bitcoind.
17:44:46lclc:Luke-Jr: interesting idea (paying small house edge to miners), thanks!
17:45:48Luke-Jr:sipa: I consider the Qt GUI somewhat important (though not critical) since all the other wallet GUIs suck :P
17:46:02sipa:imho, all wallet guis suck, including qt :)
17:46:03Luke-Jr:even after it's split
17:46:14Luke-Jr:pfft, I like it :P
17:46:21Luke-Jr:otoh, I'm also patching it so I like it <.<
17:46:23sipa:ok, please don't stop using it then :)
17:46:40justanotheruser:Luke-Jr: would you like electrum if it properly represented bitcoin?
17:47:09Luke-Jr:justanotheruser: probably not, it'd still be ugly
17:47:40hearn:it's getting a lot easier to make pretty wallet frontends these days
17:47:47hearn:i'm sure there will be plenty more in future
17:47:56hearn:a wallet to suit every man's personal taste (also women's)
17:48:03Luke-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:29Luke-Jr:hearn: yeah, hopefully at some point there will be an easy to use SPV library
17:48:45Luke-Jr:that wallets can just link to and throw their own behaviour/GUI on top of
17:48:48hearn:ouch :)
17:49:03hearn:that's pretty much what bitcoinj already is. you can make a wallet gui with it in about 30 minutes
17:49:13Luke-Jr:I don't even consider Java when I think of things :P
17:49:22hearn:you can write them in lots of languages, so that's ok
17:49:33hearn:python, ruby, javascript, a lisp, functional languages ....
17:49:34Luke-Jr:hearn: without a Java runtime?
17:49:55justanotheruser:hearn: can't bitcoinj also be used to make a full node?
17:49:59hearn: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:08hearn:it can be bundled with apps quite easily
17:50:15Luke-Jr:exactly, that's why I don't use GTK or Ruby software either :P
17:50:21hearn:justanotheruser: it doesn't listen on the network so no
17:50:31Luke-Jr:* Luke-Jr ponders if BitcoinJ would build with GCJ
17:50:58hearn: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:12hearn:gcj does not eliminate the need for a runtime, of course
17:51:24Luke-Jr:GCJ elimiates JIT stuff
17:51:52Luke-Jr:I think
17:52:02hearn:yeah. though the end result is not necessarily better.
17:52:23hearn:you just don't like JITCs on principle?
17:52:45Luke-Jr:pretty much
17:53:03Luke-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:21Luke-Jr:(part of using Gentoo is so I can build everything with debug-friendly CFLAGS)
17:53:51hearn: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:51Luke-Jr:I suppose GDB extensions could be made to fix that too, but meh
17:54:18hearn: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:00hearn: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:56:07Luke-Jr:same CLI interface? ;)
17:57:13hearn:there is, actually
17:57:19hearn:it's called jdb
17:57:33hearn: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:33Luke-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:44lclc:lclc is now known as lclc_bnc
21:28:58maaku:maaku is now known as Guest53081
22:42:13MRL-Relay:[surae] you know, poisson processes always seemed fishy to me
23:01:50gandalf:are there any storj like projects built with multisginatures transactions on bitcoin?