| 00:05:16 | coryfields: | coryfields is now known as cfields |
| 00:56:07 | Ademan: | 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:36 | Ademan: | I'm not sure how interesting/useful it would be though |
| 00:57:40 | nsh_: | well, if it's neither interesting, nor useful, it might well be art |
| 01:07:28 | kanzure: | nsh_: harsh definition of art :) |
| 01:37:08 | super3: | tacotime_, you there? |
| 01:37:16 | tacotime_: | yeah, what's up? |
| 01:39:45 | tacotime_: | * tacotime_ spent all day working on code to hash genesis blocks and feels like a noob. also kind of brain dead. |
| 01:40:01 | tacotime_: | first day really coding in about four years though, guess i should have expected it. |
| 02:04:19 | sipa: | tacotime_: #bitcoin-dev please |
| 02:04:47 | tacotime_: | sipa: mea culpa |
| 03:48:45 | artifexd: | artifexd is now known as artifexd_afk |
| 03:59:34 | justusranvier: | What's the story of transaction 4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2? |
| 04:00:43 | justusranvier: | Is it an example of the 1-conf attack mentioned in the rationale of BIP16? |
| 04:01:29 | jcorgan: | wtf |
| 04:05:54 | [BNC]dansmith: | [BNC]dansmith is now known as dansmith_btc |
| 04:10:44 | phrackage_: | phrackage_ is now known as phrackage |
| 04:33:20 | petertodd: | lol, forked webbtc.com yet again with codeseparator |
| 04:37:24 | petertodd: | pity, coinbase is lucky eligus's pushtxn is down and I'm too lazy to fire up a !IsStandard() node |
| 04:39:50 | petertodd: | ah, there you go: drop_signatures() in bitcoin-ruby doesn't drop OP_CODESEPARATOR's |
| 04:40:28 | petertodd: | 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:36 | just[dead]: | just[dead] is now known as justanotheruser |
| 05:13:54 | tacotime: | tacotime is now known as tt_zzz |
| 05:26:58 | gmaxwell: | https://www.usenix.org/system/files/1403_02-08_mickens.pdf |
| 05:27:15 | gmaxwell: | [OT but fun; but dear god if this man finds bitcoin he will burst into flames] |
| 05:28:47 | jcorgan: | lold |
| 05:30:04 | gmaxwell: | (his other articles are also fantastic, including the one on byzantine consensus) |
| 05:45:11 | midnightmagic: | gmaxwell: THANK YOU for the awesome paper. Excellent. |
| 05:46:25 | midnightmagic: | "bicoastal liberal elites" ha ha |
| 05:49:33 | justanotheruser: | Does anyone have a link regarding the Bitmessage flood using GPU? |
| 05:59:08 | Ademan: | haha selectors, then geolocation, then |
| 06:18:09 | gmaxwell: | 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:50 | jcorgan: | oh, that guy |
| 06:27:27 | gmaxwell: | 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:16 | lagarde: | 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:24 | maaku: | lagarde: CJ is more generally useful - e.g. hiding regular payment transactions |
| 07:34:45 | maaku: | or colored coin exchanges, or matched donations, etc. |
| 07:35:09 | maaku: | CS is pretty much only good for mixing or cross-chain atomic swaps, as far as I can tell |
| 07:35:41 | gmaxwell: | they do different things too, CJ screwes up analysis (if used widely) while CS hides from it. |
| 07:36:23 | gmaxwell: | 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:40 | gmaxwell: | I think both are useful techniques. |
| 07:37:15 | gmaxwell: | CJ also has the possiblity of no one but you actually knowing for sure which output is yours, which is neat. |
| 07:37:27 | gmaxwell: | and cannot be achieved in any two party protocol. |
| 07:39:02 | maaku: | 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:21 | gmaxwell: | 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:06 | lagarde: | 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:37 | gmaxwell: | right. CS does something else thats of note, which is that it lets you hide your contract terms. |
| 07:42:33 | gmaxwell: | 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:54 | lagarde: | It seems to me that CS is a superset of CJ. More complex implementation. But achieves more anonymity AND privacy than CJ. |
| 07:43:17 | gmaxwell: | lagarde: I still don't agree there. They do different things to the transaction graph. |
| 07:43:45 | gmaxwell: | 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:04 | gmaxwell: | meaning it might be much easier to get CJ participants esp for casual use. |
| 07:44:39 | gmaxwell: | there is also the detail that at the moment you can't implement CS fully securely, due to malleability. |
| 07:45:03 | lagarde: | 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:04 | gmaxwell: | (your refunds can get nuked and leave you vunerable to extortion) |
| 07:45:22 | jtimon: | mhmm, I wasn't aware of the malleability problem with CS |
| 07:45:25 | gmaxwell: | (also in general CS is much more DOS attack abuse vulnerable) |
| 07:45:39 | gmaxwell: | jtimon: anything that depends on a precomputed refund has potential issues. |
| 07:46:34 | lagarde: | 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:41 | gmaxwell: | (e.g. dos attack: I go to swap with you, we establish the escrow. oops you vanish) |
| 07:47:07 | gmaxwell: | (now your coins are stuck until the escrow times out... vs CJ where you could retry ten times per second) |
| 07:47:33 | gmaxwell: | lagarde: hah, well you can't just wave away details like that. They matter. |
| 07:48:12 | jtimon: | gmaxwell, so regular cross-chain is vulnerable too... |
| 07:49:06 | jtimon: | interesting |
| 07:50:05 | gmaxwell: | 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:52 | jtimon: | * jtimon realises that he needs to learn more malleability |
| 07:51:12 | jtimon: | I was convinced that it wasn't really a big deal at all |
| 07:51:25 | jtimon: | just had much noise around it |
| 07:51:51 | jtimon: | s/more about |
| 07:52:40 | gmaxwell: | IMO really the only big deal about it is that it breaks refunds. |
| 07:53:23 | gmaxwell: | 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:41 | lagarde: | Need to do more study on malleability as well. Don't understand how it can break refunds. |
| 07:58:00 | gmaxwell: | lagarde: someone changes your payment into the escrow, the precomputed refund transaction which was spending the original txid is no longer valid. |
| 07:59:49 | jtimon: | thanks, gmaxwell, going to sleep now, but I'll read your latest comments on coinswap and probably come back with more answers |
| 08:00:24 | Ademan: | heh, apparently I'm not the only one looking into coinswap, I don't recall what motivated me originally |
| 08:00:36 | Ademan: | recently* |
| 08:03:33 | maaku: | when doing a pow "skip list", why not commit links to *every* previous block? |
| 08:03:55 | gmaxwell: | makes the commitments big. |
| 08:04:31 | maaku: | well, presumably you'd use an incremental hash tree |
| 08:04:39 | gmaxwell: | isn't needed to get log() asymptotic complexity in any cas.e |
| 08:05:17 | gmaxwell: | 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:01 | maaku: | ok but it doesn't break the security of the model, right? |
| 08:06:45 | maaku: | to let the miner choose whatever back-link commitments they want, so long as they are revealed for validation |
| 08:07:33 | gmaxwell: | yea no just maybe efficiency. |
| 08:07:39 | maaku: | ok |
| 08:08:33 | maaku: | i was trying to figure out if restrictions on that (e.g. deterministic selection of back links) should be enforced or not |
| 08:09:00 | maaku: | it's obviously cleaner if you can just leave that to the miner |
| 08:16:06 | petertodd: | gmaxwell, maaku: MMR's can trade-off commitment size vs. age fairly easily if you do a linear top-level linking chain |
| 08:17:09 | petertodd: | 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:48 | warren: | Does anyone know if the TradeFortress fiasco was resolved with most people paid back? |
| 09:35:04 | justanotheruser: | justanotheruser is now known as just[dead] |
| 09:55:35 | TD: | warren: afaik he just disappeared |
| 10:02:22 | warren: | TD: thanks |
| 10:02:30 | warren: | it's hard to follow all the drama |
| 10:19:39 | TD: | too many bitbanks and too many people using them |
| 12:55:50 | lagarde: | 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:32 | lagarde: | sorry meant to post this in #bitcoin-dev |
| 13:49:00 | tt_zzz: | tt_zzz is now known as tacotime_ |
| 13:49:14 | tacotime_: | tacotime_ is now known as msg |
| 13:49:31 | msg: | msg is now known as tacotime_ |
| 15:22:52 | jgarzik: | gmaxwell, (off-topic) https://plus.google.com/106514939597919545192/posts/BWYPBaouPMj |
| 15:57:26 | artifexd_afk: | artifexd_afk is now known as aritfexd |
| 16:06:50 | petertodd: | warren. TD: inputs.io? a slim majority of the funds were paid back from cold storage |
| 16:09:34 | TD: | ok |
| 16:15:14 | comboy: | jgarzik: awesome video |
| 16:18:37 | maaku: | 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:40 | maaku: | i need to whiteboard an MMR structure and see if it'll work |
| 16:21:59 | petertodd: | 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:16 | maaku: | 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:54 | maaku: | 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:56 | petertodd: | maaku: yeah, if you're actually going to use the proofs recently then they probably make sense |
| 16:24:06 | petertodd: | ah, yeah, gmaxwell was telling me about that |
| 16:24:28 | maaku: | 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:23 | petertodd: | when you say "skip", do you intend to enforce this in the way the proofs are structured? |
| 16:25:40 | maaku: | enforce which property? |
| 16:25:56 | petertodd: | enforce the property that work changes how far back you can skip |
| 16:26:53 | maaku: | 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:52 | petertodd: | 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:20 | petertodd: | worth thinking about exactly where and how that could break down, and if it breaking down doesn't matter in some applications |
| 16:28:36 | maaku: | although when using the structure, you can only trust links up to the lucky factor of the block |
| 16:28:39 | maaku: | ugh, lag |
| 16:29:18 | petertodd: | 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:40 | petertodd: | OTOH... you don't know how lucky you are until you find the pow! so that's probably unavoidable |
| 16:30:37 | maaku: | yeah the point is that you commit to information which points back further than the work required |
| 16:31:15 | maaku: | 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:01 | maaku: | 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:14 | petertodd: | which makes the proofs bigger so... meh, don't bother :) |
| 16:32:42 | sipa: | petertodd: are you talking about SPV level validation or full validation? |
| 16:33:06 | sipa: | for SPV proofs you only reveal one link back from each block, and it itself proves the necessary POW |
| 16:33:19 | maaku: | petertodd: well, every now and then you get blocks like 282405, which would let you link back to every other prior block |
| 16:33:20 | petertodd: | 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:58 | sipa: | maaku: for multiple links back, you can already bias them towards encoding shorter links shorter |
| 16:34:10 | sipa: | by using a non-balances merkle tree for the links |
| 16:34:32 | petertodd: | 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:59 | maaku: | sipa: yes, but i'd like to explore the option of an incrementally updated non-balanced merkle tree that includes *all* blocks |
| 16:35:18 | sipa: | oh, you're not talking about the skip list anymore? |
| 16:35:27 | maaku: | sipa: skip list to the extreme |
| 16:35:40 | sipa: | got it |
| 16:36:35 | maaku: | 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:53 | sipa: | it can probably be made deterministic |
| 16:36:55 | petertodd: | 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:07 | sipa: | and there's probably a provably optimal strategy |
| 16:37:08 | petertodd: | maaku: see, MMR improves on that situation, but not that much |
| 16:37:22 | maaku: | sipa: yes, it certainly can be made deterministic |
| 16:37:32 | petertodd: | maaku: one issue with arbitrarily chosen links is finding paths through that crazy forrest isn't necessarily trivial |
| 16:37:38 | maaku: | although i wonder too if there is some other application which benefits from block header commitments |
| 16:38:49 | maaku: | petertodd: yes, but what we want is the most recent couple of blocks to have a short path |
| 16:39:08 | maaku: | and i'm not sure how to do that while keeping the good properties of a sparse merkle tree / mmr |
| 16:41:02 | maaku: | maybe a heap over aggregate work, or something like that |
| 16:41:23 | petertodd: | 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:53 | petertodd: | 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:21 | maaku: | petertodd: ?? don't you need 64 hashses to show the path through a sparse merkle tree? |
| 16:43:16 | petertodd: | 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:34 | petertodd: | 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:29 | just[dead]: | just[dead] is now known as justanotheruser |
| 16:48:14 | maaku: | hrm... i think a merkle heap would be the ideal structure here |
| 16:48:19 | petertodd: | merkle heap? |
| 16:50:28 | maaku: | well, a merklized heap structure |
| 16:50:36 | maaku: | http://en.wikipedia.org/wiki/Heap_%28data_structure%29 |
| 16:51:16 | petertodd: | yeah, could work |
| 16:53:48 | justanotheruser: | maaku: how could you have a heap merkle tree? The above value is just determined by hashing the children, right? |
| 16:54:10 | maaku: | justanotheruser: yes |
| 16:54:19 | maaku: | the above hash |
| 16:54:21 | maaku: | not value |
| 16:54:34 | maaku: | just replace pointers by hashes |
| 16:54:49 | justanotheruser: | I see |
| 17:00:44 | maaku: | you can make any structure a merkle structure just by replacing pointers by hashes |
| 17:01:03 | maaku: | well, any acyclic structure |
| 17:02:16 | sipa: | 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:28 | sipa: | "mining difficulty is expected to go up significantly" |
| 17:02:57 | c0rw1n: | could that conceivably be a good idea? |
| 17:03:25 | petertodd: | c0rw1n: depends on whether or not you work for JPMorgan |
| 17:03:41 | c0rw1n: | i mean, hard limit the number of blocks, and roll them around |
| 17:03:43 | petertodd: | c0rw1n: it *is* a legit PoW... but with truncated hashes! |
| 17:03:53 | sipa: | c0rw1n: no |
| 17:03:59 | wumpus: | lol sipa |
| 17:04:02 | petertodd: | c0rw1n: not at all - a hard limit makes it possible to get into |
| 17:04:21 | petertodd: | *get into end the world scenarios where someone rewrites the chain, permanently, with less than the total amount of work done |
| 17:04:52 | justanotheruser: | The april 1st update should include pizza blocks |
| 17:05:32 | tacotime_: | 10,000 bitcoin blocks every may 18th |
| 17:05:50 | justanotheruser: | ugh... reindexing takes forever |
| 17:05:53 | c0rw1n: | 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:11 | sipa: | justanotheruser: #bitcoin-dev |
| 17:06:38 | c0rw1n: | (if that makes no sense, that's because i'm being an idiot. it happens. often.) |
| 17:06:47 | justanotheruser: | sipa: will that help me, or is that commend just off topic? |
| 17:06:48 | justanotheruser: | *comment |
| 17:07:00 | petertodd: | justanotheruser: unless you have a new moon math datastructure to fix that for us it's not ontopic here |
| 17:07:05 | sipa: | justanotheruser: this channel is not about bitcoin, but post-bitcoin-ideas |
| 17:07:46 | justanotheruser: | Bitcoin should save where it left off reindexing so I don't have to restart if my computer shuts down! |
| 17:07:55 | sipa: | #bitcoin-dev, please |
| 17:08:10 | justanotheruser: | Sorry, I meant that as an idea |
| 17:08:12 | tacotime_: | 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:30 | sipa: | justanotheruser: if it's an idea for bitcoin, #bitcoin-dev |
| 17:08:37 | tacotime_: | Just to keep track of everything, as there's a lot of different stuff floating around. |
| 17:08:42 | petertodd: | tacotime_: please do, so I can stop threatening to write a book :P |
| 17:08:46 | justanotheruser: | sipa: oh, my mistake |
| 17:08:46 | c0rw1n: | tacotime_: that could possibly same me infinity time |
| 17:09:06 | tacotime_: | Haha, sure thing. I think it will save everyone a lot of time. |
| 17:09:21 | petertodd: | tacotime_: quite seriously I'd be happy to review it |
| 17:09:37 | maaku: | ok I *think* the merklized priority search tree is exactly what we're looking for |
| 17:09:50 | maaku: | it's a combination of binary search tree and heap |
| 17:10:08 | petertodd: | 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:21 | tacotime_: | petertodd: thanks, good to know as I'll inevitably misunderstand some of the more complex things. |
| 17:10:31 | maaku: | the root node is the maximal node, and left and right branches evenly split the remaining nodes |
| 17:10:34 | tacotime_: | petertodd: Sure. |
| 17:11:06 | tacotime_: | And maybe get a softfork wishlist up too for things like minor bugs in scripts |
| 17:11:25 | petertodd: | tacotime_: true! we have the hardfork wishlist, but not the softfork one |
| 17:11:50 | petertodd: | tacotime_: have you seen the new bitcoin/bips repo? |
| 17:12:03 | tacotime_: | yeah, it's really nice looking, that's you right? |
| 17:12:36 | petertodd: | 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:58 | petertodd: | tacotime_: note that github now has in-browser editing of repos |
| 17:13:18 | tacotime_: | 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:20 | tacotime_: | ah cool |
| 17:13:39 | petertodd: | tacotime_: for sure, and when we tell them to piss off, that can also include "hey! hit the fork button" |
| 17:14:00 | tacotime_: | petertodd: haha true :) |
| 17:16:24 | rastapopuloto: | rastapopuloto has left #bitcoin-wizards |
| 17:27:07 | Emcy: | hmm anyone heard of twister? |
| 17:27:54 | petertodd: | Emcy: yes, it's madness |
| 17:27:56 | Emcy: | it seems like it takes that approach of take all the individual technologies and throw then in a big pot and simmer |
| 17:28:23 | Emcy: | petertodd does it not work then? |
| 17:28:46 | petertodd: | 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:09 | petertodd: | Emcy: thrown in some bananas and other fruits for good measure |
| 17:29:31 | Emcy: | but hwats if its actually tasty |
| 17:29:49 | petertodd: | well, I can assure you it's not :P |
| 17:30:14 | petertodd: | 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:33 | Emcy: | well thats no good |
| 17:30:47 | petertodd: | indeed, dumb project |
| 17:31:01 | Emcy: | bitcoin still uses checkpoints tho |
| 17:31:09 | petertodd: | only as a anti-dos measure |
| 17:31:23 | petertodd: | that we've been updating checkpoints about once per release sends a *very* bad message |
| 17:31:55 | Emcy: | perhaps |
| 17:32:04 | TD: | * TD shrugs |
| 17:32:05 | petertodd: | do you understand why checkpoints are an anti-dos measure? |
| 17:32:15 | TD: | i don't think it sends a bad message. it says "defence in depth" |
| 17:32:26 | TD: | sure, it shouldn't actually be necessary, but it can't really hurt either |
| 17:32:29 | Emcy: | stops huge hilarious reorgs |
| 17:32:59 | petertodd: | Emcy: *no*, checkpoints are needing for initial sync, because otherwise an attacker can flood you with low PoW blocks |
| 17:33:22 | petertodd: | 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:24 | TD: | that could be resolved in other ways |
| 17:33:56 | petertodd: | Emcy: of course, better sync algorithms don't need checkpoints... but having looked into writing one, the checkpoint way is much easier :) |
| 17:35:03 | TD: | i continue to be amazed by how many people pick up a block chain and suddenly everything looks like a nail |
| 17:35:12 | justanotheruser: | justanotheruser is now known as just[dead] |
| 17:36:13 | Emcy: | TD block chains are exciting |
| 17:36:29 | Emcy: | petertodd how long has fixing p2p been on the todo list |
| 17:36:41 | petertodd: | Emcy: forever? |
| 17:36:55 | Emcy: | i dont know why other things have taken precedence |
| 17:37:11 | Emcy: | things mostly related to 'growing bitcoin' it seems |
| 17:37:32 | Emcy: | why build your dream home on sandy foundations |
| 17:37:41 | petertodd: | Emcy: what fixes to apply is a political decision is part of the problem |
| 17:38:19 | TD: | i think "lack of people writing code" is a far bigger constraint than politics |
| 17:38:21 | petertodd: | Emcy: well, to their credit a big part of why mastercoin hired me is to fix bitcoin |
| 17:38:44 | TD: | there is only one person doing serious work on the p2p/consensus/etc parts of bitcoin core (gavin) |
| 17:38:55 | Emcy: | about as political as architectural concerns re: foundations in building projects, as in my anology |
| 17:39:12 | just[dead]: | just[dead] is now known as justanotheruser |
| 17:39:28 | Emcy: | what is mastercoin and why did they hire you |
| 17:41:52 | petertodd: | 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:52 | petertodd: | Emcy: they hired me because they're dependent on the existence of a blockchain, currently bitcoin, although they could switch |
| 17:41:52 | petertodd: | Emcy: http://mastercointalk.org/index.php?topic=155.msg466#msg466 |
| 17:42:43 | petertodd: | 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:18 | petertodd: | Emcy: which in turn would have made the current fee drop less dangerous |
| 17:50:54 | zooko`: | zooko` is now known as zooko |
| 17:52:05 | TD: | fee estimation isn't even merged yet |
| 17:52:27 | TD: | 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:36 | orperelman: | 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:46 | TD: | jeff is mostly working on bitcore, from what i understand |
| 17:52:53 | TD: | note bitcore != bitcoin core, confusingly enough :) |
| 17:53:06 | petertodd: | 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:08 | orperelman: | yea - I meant bitcoin core notbitcore my bad |
| 17:53:18 | orperelman: | gave wrong example :) |
| 17:53:22 | TD: | 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:48 | TD: | 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:15 | Emcy: | TD that i take as true, the core team doesnt have enough people or resources |
| 17:54:15 | Emcy: | though i though gavin was finishing up the payment protocol, and then doing the fees market? Not scalability and foundation stuff |
| 17:54:15 | Emcy: | er by foundation stuff i mean low level p2p engineering |
| 17:54:26 | TD: | fees *is* low level p2p engineering :) |
| 17:54:32 | orperelman: | yes I agree with you on that one mike. |
| 17:54:35 | petertodd: | 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:44 | TD: | and the payment protocol was needed to enable lots of other things, so it's good that this is finally getting done |
| 17:55:02 | petertodd: | Emcy: fess is highly political because people aren't willing to accept it's actually a market |
| 17:55:06 | petertodd: | *fees |
| 17:55:15 | TD: | * TD goes back to doing actual work instead of wasting time on trolls |
| 17:55:18 | orperelman: | 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:37 | orperelman: | hah ;) |
| 17:56:27 | Emcy: | so youre being salaried to maintain bitcoin core like j garzik is? |
| 17:56:58 | petertodd: | Emcy: maintain isn't the right word; improving scalability and decentralization isn't "maintenance" |
| 17:57:06 | sipa: | only wumpus and gavin are actually paid to work on bitcoin core |
| 17:57:08 | Emcy: | id rather not get into the politics |
| 17:57:08 | Emcy: | politics is a bust wherever you encouter it |
| 17:57:12 | justanotheruser: | justanotheruser is now known as just[dead] |
| 17:57:16 | Emcy: | ok but flaoting fees perhaps shouldnt be higher on the priority lists than other stuff |
| 17:57:21 | Emcy: | fees dont really matter yet, other stuff does |
| 17:57:44 | orperelman: | Sipa - that is sad :( |
| 17:57:48 | petertodd: | 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:49 | orperelman: | and needs to be changed |
| 17:58:15 | petertodd: | Emcy: which to me shows how amazingly political it is; the very idea that there should be a market there |
| 17:58:46 | Emcy: | maintain/work on |
| 17:59:39 | Emcy: | petertodd ive never (in my limited view) seen anyone arguing against a fees market |
| 17:59:57 | petertodd: | Emcy: I have - TD argues against that |
| 18:00:11 | sipa: | can we move this to #bitcoin-dev |
| 18:00:14 | petertodd: | Emcy: which leads to how android wallet can't set fees |
| 18:00:28 | TD: | or better, just stop it |
| 18:00:52 | TD: | this has long since passed trolling and is now downright lying. just go away peter |
| 18:01:08 | TD: | maybe try, you know, actually doing what you're being paid to do |
| 18:01:17 | TD: | write a big pile of good, quality code and get gavin to accept it |
| 18:01:46 | Emcy: | well i stumbled onto something wierd here |
| 18:01:46 | Emcy: | later |
| 18:02:02 | petertodd: | TD: the people I work for do not agree with gavin's views on bitcoin |
| 18:02:30 | gavinandresen: | BLASPHEMERS! THEY SHALL FEEL MY WRATH! |
| 18:02:35 | sipa: | can we _please_ move this discussion elsewhere? |
| 18:02:41 | petertodd: | sipa: agreed |
| 18:02:42 | sipa: | this channel is not about bitcoin |
| 18:02:48 | petertodd: | /end thread |
| 18:03:55 | tacotime_: | uh oh |
| 18:04:13 | super3: | * super3 gets popcorn |
| 18:05:32 | TD: | he's putting on his robe and wizard hat! |
| 18:05:47 | tacotime_: | TD: lol |
| 18:05:58 | petertodd: | sure is taking him awhile in his old age |
| 18:06:23 | petertodd: | * petertodd turns 29 tomorrow, eek |
| 18:06:43 | orperelman: | happy bday peter! |
| 18:06:51 | petertodd: | lol, thanks |
| 18:10:31 | amiller: | lol, yeah happy birthday. |
| 18:11:21 | sipa: | * sipa casts level 3 primality age |
| 18:19:27 | petertodd: | * petertodd is embarassed at how long it took to get that joke |
| 18:20:00 | just[dead]: | just[dead] is now known as justanotheruser |
| 18:25:44 | roidster: | roidster is now known as Guest2244 |
| 18:37:38 | shesek: | petertodd, happy birthday! |
| 18:37:50 | nsh: | +1 |
| 18:57:17 | maaku: | happy birthday :) |
| 19:22:07 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 19:22:48 | roidster: | roidster is now known as Guest30128 |
| 19:54:25 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 20:19:11 | justanotheruser: | justanotheruser is now known as just[dead] |
| 21:05:19 | just[dead]: | just[dead] is now known as justanotheruser |
| 21:26:53 | justanotheruser: | justanotheruser is now known as just[dead] |
| 21:55:29 | rastapopuloto: | rastapopuloto has left #bitcoin-wizards |
| 22:09:43 | warren: | 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:40 | nsh: | * nsh wonders how to remove the font |
| 22:38:31 | antephialtic: | must be nice to be able to hard fork the chain on a whim. |
| 22:41:12 | gmaxwell: | I like how they don't even highlight that they're changing the coin supply. |
| 22:42:33 | nsh: | just to remove the randomness, or to change the inflationaryness? |
| 22:42:42 | nsh: | inflationarity? |
| 22:42:49 | nsh: | inflation, i guess. |
| 22:47:04 | gmaxwell: | seems like they're making it finite. |
| 22:47:44 | gmaxwell: | the old scheme was accidentally infinite but they talk about a geometric decay there. |
| 23:00:32 | nsh: | i see |
| 23:28:45 | mike4-: | mike4- is now known as c--O-O |