00:05:16coryfields:coryfields is now known as cfields
00:56:07Ademan:kanzure: I suppose if by some miracle neither of the two chains contain any conflicting information (double spends) you could have a type of block with two parents. The only case I can think of when this is interesting, would be resolving a fork, but I guess the coinbase transactions would definitely be conflicting. Assuming the fork is shorter than 100 blocks though, none of the coinbase coins could have been spent, so
00:56:36Ademan:I'm not sure how interesting/useful it would be though
00:57:40nsh_:well, if it's neither interesting, nor useful, it might well be art
01:07:28kanzure:nsh_: harsh definition of art :)
01:37:08super3:tacotime_, you there?
01:37:16tacotime_:yeah, what's up?
01:39:45tacotime_:* tacotime_ spent all day working on code to hash genesis blocks and feels like a noob. also kind of brain dead.
01:40:01tacotime_:first day really coding in about four years though, guess i should have expected it.
02:04:19sipa:tacotime_: #bitcoin-dev please
02:04:47tacotime_:sipa: mea culpa
03:48:45artifexd:artifexd is now known as artifexd_afk
03:59:34justusranvier:What's the story of transaction 4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2?
04:00:43justusranvier:Is it an example of the 1-conf attack mentioned in the rationale of BIP16?
04:05:54[BNC]dansmith:[BNC]dansmith is now known as dansmith_btc
04:10:44phrackage_:phrackage_ is now known as phrackage
04:33:20petertodd:lol, forked webbtc.com yet again with codeseparator
04:37:24petertodd:pity, coinbase is lucky eligus's pushtxn is down and I'm too lazy to fire up a !IsStandard() node
04:39:50petertodd:ah, there you go: drop_signatures() in bitcoin-ruby doesn't drop OP_CODESEPARATOR's
04:40:28petertodd:also looks like drop_signatures() is wrong too, and it's wrong in a way that's going to be kinda hard for them to fix
05:03:36just[dead]:just[dead] is now known as justanotheruser
05:13:54tacotime:tacotime is now known as tt_zzz
05:27:15gmaxwell:[OT but fun; but dear god if this man finds bitcoin he will burst into flames]
05:30:04gmaxwell:(his other articles are also fantastic, including the one on byzantine consensus)
05:45:11midnightmagic:gmaxwell: THANK YOU for the awesome paper. Excellent.
05:46:25midnightmagic:"bicoastal liberal elites" ha ha
05:49:33justanotheruser:Does anyone have a link regarding the Bitmessage flood using GPU?
05:59:08Ademan:haha selectors, then geolocation, then releases the antichrist... got it!
06:18:09gmaxwell:I'm a little unhappy that I'm being left alone to deal with anonymity on bitcoin talk and he's attacking me personally in his usual innaty.
06:25:50jcorgan:oh, that guy
06:27:27gmaxwell:somewhat annoyingly, I PMed him and made it clear that he was being over the top uncivil and if he didn't edit his posts to tone it down I was going to punt him. And he actually did. So now it's mostly the pompust stupidy dissolving everything in sight.
07:23:16lagarde:gmaxwell: care to offer a theory on why CJ is getting so much more attention that CS? I'm surprised, thought it would the other way around.
07:34:24maaku:lagarde: CJ is more generally useful - e.g. hiding regular payment transactions
07:34:45maaku:or colored coin exchanges, or matched donations, etc.
07:35:09maaku:CS is pretty much only good for mixing or cross-chain atomic swaps, as far as I can tell
07:35:41gmaxwell:they do different things too, CJ screwes up analysis (if used widely) while CS hides from it.
07:36:23gmaxwell:CS does exactly what a 'centeralized mixer' does (when used on a single chain) but in a more secure way. The people who want that are mostly happy using the centeralized things right now (fools).
07:36:40gmaxwell:I think both are useful techniques.
07:37:15gmaxwell:CJ also has the possiblity of no one but you actually knowing for sure which output is yours, which is neat.
07:37:27gmaxwell:and cannot be achieved in any two party protocol.
07:39:02maaku:gmaxwell: the anonymity set of CS is limited by the size of the output and the number of other people doing CS-like transactions at the same time, no?
07:40:21gmaxwell:maaku: size but CJ is size limited too. ... and CS looks like 2 of 2 multisig ... maybe just a regular transaction if someone manages to get 2-of-2 threshold ECDSA working.
07:41:06lagarde:maaku: I would think so. Though standard denominations would muddy the waters a bit. But you'd need more widespread usage of 20f2 transactions to avoid getting tagged as a swapper.
07:41:37gmaxwell:right. CS does something else thats of note, which is that it lets you hide your contract terms.
07:42:33gmaxwell:e.g. you can use the same protocol transformation to do any two party contract more privately in the case where everyone plays nicely... esp combined with true 2-of-2 threshold crypto, that might get you some nice compression.
07:42:54lagarde:It seems to me that CS is a superset of CJ. More complex implementation. But achieves more anonymity AND privacy than CJ.
07:43:17gmaxwell:lagarde: I still don't agree there. They do different things to the transaction graph.
07:43:45gmaxwell:also CS requires at least two transactions that you wouldn't have done otherwise, while CJ can be done with 0 marginal transactions.
07:44:04gmaxwell:meaning it might be much easier to get CJ participants esp for casual use.
07:44:39gmaxwell:there is also the detail that at the moment you can't implement CS fully securely, due to malleability.
07:45:03lagarde:yes that part makes sense. Though if it was just as easy for an end user to participate in a CS or CJ I am trying to understand why you would choose CJ
07:45:04gmaxwell:(your refunds can get nuked and leave you vunerable to extortion)
07:45:22jtimon:mhmm, I wasn't aware of the malleability problem with CS
07:45:25gmaxwell:(also in general CS is much more DOS attack abuse vulnerable)
07:45:39gmaxwell:jtimon: anything that depends on a precomputed refund has potential issues.
07:46:34lagarde:assume for a moment that all those problems are solved for both systems and is equally easy to use either for an end user. What could you gain from CJ that you couldn't from CS?
07:46:41gmaxwell:(e.g. dos attack: I go to swap with you, we establish the escrow. oops you vanish)
07:47:07gmaxwell:(now your coins are stuck until the escrow times out... vs CJ where you could retry ten times per second)
07:47:33gmaxwell:lagarde: hah, well you can't just wave away details like that. They matter.
07:48:12jtimon:gmaxwell, so regular cross-chain is vulnerable too...
07:50:05gmaxwell:Anything that depends on a refund. (I actually did point this out in both the CS thread, and in many other places where refunds are mentioned)
07:50:52jtimon:* jtimon realises that he needs to learn more malleability
07:51:12jtimon:I was convinced that it wasn't really a big deal at all
07:51:25jtimon:just had much noise around it
07:51:51jtimon:s/more about
07:52:40gmaxwell:IMO really the only big deal about it is that it breaks refunds.
07:53:23gmaxwell:if you go find the old github pull req where there was a debate about doing anything at all about it, I suspect I mostly argued on the basis of refunds and unconfirmed transactions.
07:55:41lagarde:Need to do more study on malleability as well. Don't understand how it can break refunds.
07:58:00gmaxwell:lagarde: someone changes your payment into the escrow, the precomputed refund transaction which was spending the original txid is no longer valid.
07:59:49jtimon:thanks, gmaxwell, going to sleep now, but I'll read your latest comments on coinswap and probably come back with more answers
08:00:24Ademan:heh, apparently I'm not the only one looking into coinswap, I don't recall what motivated me originally
08:03:33maaku:when doing a pow "skip list", why not commit links to *every* previous block?
08:03:55gmaxwell:makes the commitments big.
08:04:31maaku:well, presumably you'd use an incremental hash tree
08:04:39gmaxwell:isn't needed to get log() asymptotic complexity in any cas.e
08:05:17gmaxwell:But because you'd make that hashtree bigger your nodes along the way is bigger.. there is probably some optimum sparcity that results in the smallest average proofs.
08:06:01maaku:ok but it doesn't break the security of the model, right?
08:06:45maaku:to let the miner choose whatever back-link commitments they want, so long as they are revealed for validation
08:07:33gmaxwell:yea no just maybe efficiency.
08:08:33maaku:i was trying to figure out if restrictions on that (e.g. deterministic selection of back links) should be enforced or not
08:09:00maaku:it's obviously cleaner if you can just leave that to the miner
08:16:06petertodd:gmaxwell, maaku: MMR's can trade-off commitment size vs. age fairly easily if you do a linear top-level linking chain
08:17:09petertodd:gmaxwell, maaku: heck, if you were willing to recompute the !@#$ damn tree every time and do it all "backwards" you could get a consistent proof-size/age tradeoff
09:09:48warren:Does anyone know if the TradeFortress fiasco was resolved with most people paid back?
09:35:04justanotheruser:justanotheruser is now known as just[dead]
09:55:35TD:warren: afaik he just disappeared
10:02:22warren:TD: thanks
10:02:30warren:it's hard to follow all the drama
10:19:39TD:too many bitbanks and too many people using them
12:55:50lagarde:Can someone point me to good explanation of tx input sequence no. and tx locktime? (other than the bitcoind source). I think locktime is as simple as transaction won't be accepted until lt block. But I'm interested in the conditions under which either param will render a tx accepted or rejected.
12:56:32lagarde:sorry meant to post this in #bitcoin-dev
13:49:00tt_zzz:tt_zzz is now known as tacotime_
13:49:14tacotime_:tacotime_ is now known as msg
13:49:31msg:msg is now known as tacotime_
15:22:52jgarzik:gmaxwell, (off-topic) https://plus.google.com/106514939597919545192/posts/BWYPBaouPMj
15:57:26artifexd_afk:artifexd_afk is now known as aritfexd
16:06:50petertodd:warren. TD: inputs.io? a slim majority of the funds were paid back from cold storage
16:15:14comboy:jgarzik: awesome video
16:18:37maaku:petertodd gmaxwell: this is a commitment scheme that should be biased to accessing the most recent outputs with the smallest proofs, and being incremental updatable per block
16:18:40maaku:i need to whiteboard an MMR structure and see if it'll work
16:21:59petertodd:maaku: does it actually need to be biased to most recent outputs? when I looked at MMR again for that, I realized that the complexity over a sparse merkle tree might not be worth it as recent outputs are likely in a partial utxo set and don't need proofs - but I dunno what exactly you are doing
16:23:16maaku:petertodd: we are looking at commiting (part of?) the block history to each block, effectively making a skip list for short spv proofs
16:23:54maaku:so when you get a lucky bloc that is 64*work-required, you can skip straight back up to 64 blocks (modulo difficulty adjustments, etc.)
16:23:56petertodd:maaku: yeah, if you're actually going to use the proofs recently then they probably make sense
16:24:06petertodd:ah, yeah, gmaxwell was telling me about that
16:24:28maaku:but yes, you would expect most blocks to have a small lucky factor, so at best the only link you can use is the most recent or 2nd most recent
16:25:23petertodd:when you say "skip", do you intend to enforce this in the way the proofs are structured?
16:25:40maaku:enforce which property?
16:25:56petertodd:enforce the property that work changes how far back you can skip
16:26:53maaku:the block contains - potentially - links back to every prior block all the way to genesis, and validators have to make sure these links are correct
16:27:52petertodd:hmm, see, I wonder whether or not the existence of short links that don't follow the "lucky pow" logic will encourage people to use them at risk to security
16:28:20petertodd:worth thinking about exactly where and how that could break down, and if it breaking down doesn't matter in some applications
16:28:36maaku:although when using the structure, you can only trust links up to the lucky factor of the block
16:28:39maaku:ugh, lag
16:29:18petertodd:yes, like I say "you can only trust" doesn't mean much to 95% of application developers who will just do what's easy and won't understand the subtle logic behind why it's done that way
16:29:40petertodd:OTOH... you don't know how lucky you are until you find the pow! so that's probably unavoidable
16:30:37maaku:yeah the point is that you commit to information which points back further than the work required
16:31:15maaku:so it's kinda hard to avoid that, although you could make the structure non-deterministic by salting and selectively reveal when you do find a block
16:32:01maaku:but the performance of that makes it a non-option if you want to commit to the entire block history, which is at least an option I'd like to explore
16:32:14petertodd:which makes the proofs bigger so... meh, don't bother :)
16:32:42sipa:petertodd: are you talking about SPV level validation or full validation?
16:33:06sipa:for SPV proofs you only reveal one link back from each block, and it itself proves the necessary POW
16:33:19maaku:petertodd: well, every now and then you get blocks like 282405, which would let you link back to every other prior block
16:33:20petertodd:so, a MMR will give you shorter proofs for recent history, OTOH the difference isn't actually all that big you know - it can only save a dozen or so steps as the length of the proof is log
16:33:58sipa:maaku: for multiple links back, you can already bias them towards encoding shorter links shorter
16:34:10sipa:by using a non-balances merkle tree for the links
16:34:32petertodd:sipa: well remember my thinking is that the difference between SPV and full is far too sharp and needs to be more blurry
16:34:59maaku:sipa: yes, but i'd like to explore the option of an incrementally updated non-balanced merkle tree that includes *all* blocks
16:35:18sipa:oh, you're not talking about the skip list anymore?
16:35:27maaku:sipa: skip list to the extreme
16:35:40sipa:got it
16:36:35maaku:at least as a comparison against the currrent default we're assuming, which is the miner arbitrarily chooses links back in a way he feels will increase connectivity
16:36:53sipa:it can probably be made deterministic
16:36:55petertodd:maaku: you are familiar with the sparse merkle tree format with truncated proofs where you just commit to a 2^64 or so binary radix tree, mostly empty, and then add elements to that tree with index == block #, or tx #. you can then skip the full 64-element proof by just proving the tip of the highest actually filled part of the tree
16:37:07sipa:and there's probably a provably optimal strategy
16:37:08petertodd:maaku: see, MMR improves on that situation, but not that much
16:37:22maaku:sipa: yes, it certainly can be made deterministic
16:37:32petertodd:maaku: one issue with arbitrarily chosen links is finding paths through that crazy forrest isn't necessarily trivial
16:37:38maaku:although i wonder too if there is some other application which benefits from block header commitments
16:38:49maaku:petertodd: yes, but what we want is the most recent couple of blocks to have a short path
16:39:08maaku:and i'm not sure how to do that while keeping the good properties of a sparse merkle tree / mmr
16:41:02maaku:maybe a heap over aggregate work, or something like that
16:41:23petertodd:maaku: I know, I don't think you can, also when you think about it, the actual increase in total proof size, even for a sparse-merkle-tree, is a small linear increase (~2x or 3x or something) I'm doubtful it's worth the complexity
16:41:53petertodd:maaku: remember that your real-world proofs for things like transactions already has a bunch of steps just getting to the blockheader in the first place
16:42:21maaku:petertodd: ?? don't you need 64 hashses to show the path through a sparse merkle tree?
16:43:16petertodd:maaku: no! for instance if I have 2^24 blocks, I actually only need to 24 hashes because I can show a part of the tree other than the very tip, provided that the tree is ordered sequentially
16:44:34petertodd:maaku: MMR's actually don't improve on that situation very much; I'm not sure they're really worth the extra complexity
16:46:29just[dead]:just[dead] is now known as justanotheruser
16:48:14maaku:hrm... i think a merkle heap would be the ideal structure here
16:48:19petertodd:merkle heap?
16:50:28maaku:well, a merklized heap structure
16:51:16petertodd:yeah, could work
16:53:48justanotheruser:maaku: how could you have a heap merkle tree? The above value is just determined by hashing the children, right?
16:54:10maaku:justanotheruser: yes
16:54:19maaku:the above hash
16:54:21maaku:not value
16:54:34maaku:just replace pointers by hashes
16:54:49justanotheruser:I see
17:00:44maaku:you can make any structure a merkle structure just by replacing pointers by hashes
17:01:03maaku:well, any acyclic structure
17:02:16sipa:someone should propose an april 1st BIP to change the block chain from a merkle-linked-list into a merkle-circular-linked-list
17:02:28sipa:"mining difficulty is expected to go up significantly"
17:02:57c0rw1n:could that conceivably be a good idea?
17:03:25petertodd:c0rw1n: depends on whether or not you work for JPMorgan
17:03:41c0rw1n:i mean, hard limit the number of blocks, and roll them around
17:03:43petertodd:c0rw1n: it *is* a legit PoW... but with truncated hashes!
17:03:53sipa:c0rw1n: no
17:03:59wumpus:lol sipa
17:04:02petertodd:c0rw1n: not at all - a hard limit makes it possible to get into
17:04:21petertodd:*get into end the world scenarios where someone rewrites the chain, permanently, with less than the total amount of work done
17:04:52justanotheruser:The april 1st update should include pizza blocks
17:05:32tacotime_:10,000 bitcoin blocks every may 18th
17:05:50justanotheruser:ugh... reindexing takes forever
17:05:53c0rw1n:hm ok. i had thought of using a looping chain to store offers, so i wouldn't need the old blocks after they're solved, but keeping a merkle root of their history could be nice for proving built history.
17:06:11sipa:justanotheruser: #bitcoin-dev
17:06:38c0rw1n:(if that makes no sense, that's because i'm being an idiot. it happens. often.)
17:06:47justanotheruser:sipa: will that help me, or is that commend just off topic?
17:07:00petertodd:justanotheruser: unless you have a new moon math datastructure to fix that for us it's not ontopic here
17:07:05sipa:justanotheruser: this channel is not about bitcoin, but post-bitcoin-ideas
17:07:46justanotheruser:Bitcoin should save where it left off reindexing so I don't have to restart if my computer shuts down!
17:07:55sipa:#bitcoin-dev, please
17:08:10justanotheruser:Sorry, I meant that as an idea
17:08:12tacotime_:I think soon I should take some time off to work on a bigger wiki of "ideas people want to do with cryptocurrencies" and list the benefits/consequences/limitation known.
17:08:30sipa:justanotheruser: if it's an idea for bitcoin, #bitcoin-dev
17:08:37tacotime_:Just to keep track of everything, as there's a lot of different stuff floating around.
17:08:42petertodd:tacotime_: please do, so I can stop threatening to write a book :P
17:08:46justanotheruser:sipa: oh, my mistake
17:08:46c0rw1n:tacotime_: that could possibly same me infinity time
17:09:06tacotime_:Haha, sure thing. I think it will save everyone a lot of time.
17:09:21petertodd:tacotime_: quite seriously I'd be happy to review it
17:09:37maaku:ok I *think* the merklized priority search tree is exactly what we're looking for
17:09:50maaku:it's a combination of binary search tree and heap
17:10:08petertodd:tacotime_: i'd also suggest you do it semi-wiki style, via a git repo and pull-reqs for first-time contributors - lets keep the quality up, or at least until we give up on that approach :P
17:10:21tacotime_:petertodd: thanks, good to know as I'll inevitably misunderstand some of the more complex things.
17:10:31maaku:the root node is the maximal node, and left and right branches evenly split the remaining nodes
17:10:34tacotime_:petertodd: Sure.
17:11:06tacotime_:And maybe get a softfork wishlist up too for things like minor bugs in scripts
17:11:25petertodd:tacotime_: true! we have the hardfork wishlist, but not the softfork one
17:11:50petertodd:tacotime_: have you seen the new bitcoin/bips repo?
17:12:03tacotime_:yeah, it's really nice looking, that's you right?
17:12:36petertodd:tacotime_: yup, I really like that approach from a decentralization perspective too, and I suspect it's enough friction to keep out spam and other junk
17:12:58petertodd:tacotime_: note that github now has in-browser editing of repos
17:13:18tacotime_:petertodd: yeah, i'd hate to make something nice and have it spammed by people suggesting 200 variants of the kimoto gravity well
17:13:20tacotime_:ah cool
17:13:39petertodd:tacotime_: for sure, and when we tell them to piss off, that can also include "hey! hit the fork button"
17:14:00tacotime_:petertodd: haha true :)
17:16:24rastapopuloto:rastapopuloto has left #bitcoin-wizards
17:27:07Emcy:hmm anyone heard of twister?
17:27:54petertodd:Emcy: yes, it's madness
17:27:56Emcy:it seems like it takes that approach of take all the individual technologies and throw then in a big pot and simmer
17:28:23Emcy:petertodd does it not work then?
17:28:46petertodd:Emcy: so basically we've got some nice ice-cream, a chocolate cake, cereal, steak, and lobster all simmering away, sounds tasty right?
17:29:09petertodd:Emcy: thrown in some bananas and other fruits for good measure
17:29:31Emcy:but hwats if its actually tasty
17:29:49petertodd:well, I can assure you it's not :P
17:30:14petertodd:big thing with twister is it just doesn't have enough pow to be secure, so they ended up going to centralized checkpoints instead
17:30:33Emcy:well thats no good
17:30:47petertodd:indeed, dumb project
17:31:01Emcy:bitcoin still uses checkpoints tho
17:31:09petertodd:only as a anti-dos measure
17:31:23petertodd:that we've been updating checkpoints about once per release sends a *very* bad message
17:32:04TD:* TD shrugs
17:32:05petertodd:do you understand why checkpoints are an anti-dos measure?
17:32:15TD:i don't think it sends a bad message. it says "defence in depth"
17:32:26TD:sure, it shouldn't actually be necessary, but it can't really hurt either
17:32:29Emcy:stops huge hilarious reorgs
17:32:59petertodd:Emcy: *no*, checkpoints are needing for initial sync, because otherwise an attacker can flood you with low PoW blocks
17:33:22petertodd:Emcy: in the event of a huge reorg checkpoints make things worse by making everyone inconsisent as they won't all be at the same checkpoint
17:33:24TD:that could be resolved in other ways
17:33:56petertodd:Emcy: of course, better sync algorithms don't need checkpoints... but having looked into writing one, the checkpoint way is much easier :)
17:35:03TD:i continue to be amazed by how many people pick up a block chain and suddenly everything looks like a nail
17:35:12justanotheruser:justanotheruser is now known as just[dead]
17:36:13Emcy:TD block chains are exciting
17:36:29Emcy:petertodd how long has fixing p2p been on the todo list
17:36:41petertodd:Emcy: forever?
17:36:55Emcy:i dont know why other things have taken precedence
17:37:11Emcy:things mostly related to 'growing bitcoin' it seems
17:37:32Emcy:why build your dream home on sandy foundations
17:37:41petertodd:Emcy: what fixes to apply is a political decision is part of the problem
17:38:19TD:i think "lack of people writing code" is a far bigger constraint than politics
17:38:21petertodd:Emcy: well, to their credit a big part of why mastercoin hired me is to fix bitcoin
17:38:44TD:there is only one person doing serious work on the p2p/consensus/etc parts of bitcoin core (gavin)
17:38:55Emcy:about as political as architectural concerns re: foundations in building projects, as in my anology
17:39:12just[dead]:just[dead] is now known as justanotheruser
17:39:28Emcy:what is mastercoin and why did they hire you
17:41:52petertodd:Emcy: mastercoin is one of those btc 2.0 problems that aims to create layers of financial stuff on top of the blockchain - a very new and untested idea
17:41:52petertodd:Emcy: they hired me because they're dependent on the existence of a blockchain, currently bitcoin, although they could switch
17:41:52petertodd:Emcy: http://mastercointalk.org/index.php?topic=155.msg466#msg466
17:42:43petertodd:Emcy: anyway, if you want a good example of politics screwing stuff up, look at the fee estimation code, which could have been deployed safely had it been restricted to only change fees within some small range for the first version while we shook out the bugs
17:43:18petertodd:Emcy: which in turn would have made the current fee drop less dangerous
17:50:54zooko`:zooko` is now known as zooko
17:52:05TD:fee estimation isn't even merged yet
17:52:27TD:to claim that was screwed up by "politics" is dumb. claim it's screwed up once it's actually got past the review stage and is in a shipped release
17:52:36orperelman:TD - I personally feel bitcoin companies need to hire core dev's to code to do core coding like bitpay is doing with Jeff which is great stuff.
17:52:46TD:jeff is mostly working on bitcore, from what i understand
17:52:53TD:note bitcore != bitcoin core, confusingly enough :)
17:53:06petertodd:TD: it didn't get merged because it was dangerous, and it was dangerous because there were no safety limits put on it
17:53:08orperelman:yea - I meant bitcoin core notbitcore my bad
17:53:18orperelman:gave wrong example :)
17:53:22TD:it didn't get merged because it's not finished yet. gavin merged a big change i made to it, into his personal tree, only today
17:53:48TD:orperelman: sure i understand what you meant. just pointing out that most of what jeff is coding is currently stuff only used by bitpay (though this may change in future)
17:54:15Emcy:TD that i take as true, the core team doesnt have enough people or resources
17:54:15Emcy:though i though gavin was finishing up the payment protocol, and then doing the fees market? Not scalability and foundation stuff
17:54:15Emcy:er by foundation stuff i mean low level p2p engineering
17:54:26TD:fees *is* low level p2p engineering :)
17:54:32orperelman:yes I agree with you on that one mike.
17:54:35petertodd:and that's an example where finished == the full gavin vision of how it'd work rather than the much simplier thing I and others thought should be done of add in some estiamtion so it can be used to scale min_relay limits
17:54:44TD:and the payment protocol was needed to enable lots of other things, so it's good that this is finally getting done
17:55:02petertodd:Emcy: fess is highly political because people aren't willing to accept it's actually a market
17:55:15TD:* TD goes back to doing actual work instead of wasting time on trolls
17:55:18orperelman:The more the people working on the core stuff, the better the protocol will evolve faster and every bitcoin company will gain from that.
17:55:37orperelman:hah ;)
17:56:27Emcy:so youre being salaried to maintain bitcoin core like j garzik is?
17:56:58petertodd:Emcy: maintain isn't the right word; improving scalability and decentralization isn't "maintenance"
17:57:06sipa:only wumpus and gavin are actually paid to work on bitcoin core
17:57:08Emcy:id rather not get into the politics
17:57:08Emcy:politics is a bust wherever you encouter it
17:57:12justanotheruser:justanotheruser is now known as just[dead]
17:57:16Emcy:ok but flaoting fees perhaps shouldnt be higher on the priority lists than other stuff
17:57:21Emcy:fees dont really matter yet, other stuff does
17:57:44orperelman:Sipa - that is sad :(
17:57:48petertodd:Emcy: well, what's fascinating is that we *do* have floating fees already, and then we have clients delibrately making it impossible for their users to set fees
17:57:49orperelman:and needs to be changed
17:58:15petertodd:Emcy: which to me shows how amazingly political it is; the very idea that there should be a market there
17:58:46Emcy:maintain/work on
17:59:39Emcy:petertodd ive never (in my limited view) seen anyone arguing against a fees market
17:59:57petertodd:Emcy: I have - TD argues against that
18:00:11sipa:can we move this to #bitcoin-dev
18:00:14petertodd:Emcy: which leads to how android wallet can't set fees
18:00:28TD:or better, just stop it
18:00:52TD:this has long since passed trolling and is now downright lying. just go away peter
18:01:08TD:maybe try, you know, actually doing what you're being paid to do
18:01:17TD:write a big pile of good, quality code and get gavin to accept it
18:01:46Emcy:well i stumbled onto something wierd here
18:02:02petertodd:TD: the people I work for do not agree with gavin's views on bitcoin
18:02:35sipa:can we _please_ move this discussion elsewhere?
18:02:41petertodd:sipa: agreed
18:02:42sipa:this channel is not about bitcoin
18:02:48petertodd:/end thread
18:03:55tacotime_:uh oh
18:04:13super3:* super3 gets popcorn
18:05:32TD:he's putting on his robe and wizard hat!
18:05:47tacotime_:TD: lol
18:05:58petertodd:sure is taking him awhile in his old age
18:06:23petertodd:* petertodd turns 29 tomorrow, eek
18:06:43orperelman:happy bday peter!
18:06:51petertodd:lol, thanks
18:10:31amiller:lol, yeah happy birthday.
18:11:21sipa:* sipa casts level 3 primality age
18:19:27petertodd:* petertodd is embarassed at how long it took to get that joke
18:20:00just[dead]:just[dead] is now known as justanotheruser
18:25:44roidster:roidster is now known as Guest2244
18:37:38shesek:petertodd, happy birthday!
18:57:17maaku:happy birthday :)
19:22:07gavinandresen_:gavinandresen_ is now known as gavinandresen
19:22:48roidster:roidster is now known as Guest30128
19:54:25gavinandresen_:gavinandresen_ is now known as gavinandresen
20:19:11justanotheruser:justanotheruser is now known as just[dead]
21:05:19just[dead]:just[dead] is now known as justanotheruser
21:26:53justanotheruser:justanotheruser is now known as just[dead]
21:55:29rastapopuloto:rastapopuloto has left #bitcoin-wizards
22:09:43warren:http://www.reddit.com/r/dogecoin/comments/207hfb/ann_dogecoin16_its_ready_all_you_need_to_know/ Dogecoin proudly announces that it is now much cheaper to replace the entire chain.
22:28:40nsh:* nsh wonders how to remove the font
22:38:31antephialtic:must be nice to be able to hard fork the chain on a whim.
22:41:12gmaxwell:I like how they don't even highlight that they're changing the coin supply.
22:42:33nsh:just to remove the randomness, or to change the inflationaryness?
22:42:49nsh:inflation, i guess.
22:47:04gmaxwell:seems like they're making it finite.
22:47:44gmaxwell:the old scheme was accidentally infinite but they talk about a geometric decay there.
23:00:32nsh:i see
23:28:45mike4-:mike4- is now known as c--O-O