| 01:07:41 | home_jg: | home_jg is now known as jgarzik |
| 01:15:08 | maaku_: | what bug? |
| 01:15:31 | petertodd: | maaku_: how SignatureHash() can return 1 without an error |
| 01:15:43 | maaku_: | i see |
| 01:15:50 | maaku_: | i wasn't aware of that |
| 01:16:31 | maaku_: | petertodd: I thought it came up on either bitcoin-x or the ripple users mailing list |
| 01:16:33 | petertodd: | if SIGHASH_SINGLE is used and txin idx > max txout idx you get an error, SignatureHash() returns 1... but that error is never caught anywhere so it's treated as though the hash was 1 |
| 01:16:47 | petertodd: | ripple users mailing list?! |
| 01:17:14 | petertodd: | I hear if 0 had been returned instead it'd be a backdoor to spend anyones funds apparently |
| 01:17:42 | maaku_: | jtimon and I epxlored the idea in depth on the #freicoin channel and email prior to developing freimarkets |
| 01:17:45 | maaku_: | but the only public comment my google-fu can find is an offhanded remark here : https://bitcointalk.org/index.php?topic=278671.msg3022051#msg3022051 |
| 01:18:16 | petertodd: | ah, too bad |
| 01:18:38 | maaku_: | i thought the idea was even older ... i was a little disappointed I couldn't find public discussion |
| 01:18:48 | maaku_: | only because it would have been interesting to see what we thought then |
| 01:18:55 | petertodd: | we've been kinda bad at that far too often |
| 01:19:04 | maaku_: | yeah |
| 01:19:11 | maaku_: | having this channel helps though |
| 01:19:19 | maaku_: | most ideas get filtered through here at some point |
| 01:19:23 | petertodd: | yes, especially with logbot |
| 01:19:54 | jtimon: | I think all my proposals in the forum directly involve hardfork changes rather than using regular colored coins |
| 01:20:02 | maaku_: | petertodd: https://groups.google.com/forum/#!forum/rippleusers |
| 01:20:12 | maaku_: | it's the pre-ripple mailing list |
| 01:20:22 | petertodd: | sighash -> no results |
| 01:20:25 | maaku_: | er, pre-opencoin |
| 01:20:47 | petertodd: | it's pre-'the abomination that shall not be named' |
| 01:20:56 | jtimon: | yeah, kind of death now, but we discussed p2p trading on "ripplecoin" much earlier than anybody even talked about colroed coins |
| 01:24:41 | jtimon: | well, my knowledge of bitcoin was very limited back then so I just made new message types for everything ala namecoin I think, but here's the thread about "ripplecoin" if you're interested (I doubt there's any mention of sighash_single though) https://bitcointalk.org/index.php?topic=3557.0 |
| 01:26:11 | jtimon: | very mixed with monetery philoshophical discussions and the like I fear |
| 01:27:02 | petertodd: | I think without referencing sighash_single you don't have a attribution; the idea really delves into the nitty gritty of what bitcoin can do |
| 01:28:13 | jtimon: | no, I don't think I can claim attribution I think we mark and I briefly discussed it on #freicoin when designing freimarkets but I don't remember for sure |
| 01:29:07 | petertodd: | yeah, oh well, interesting to see the idea develop anyway |
| 01:30:41 | petertodd: | maaku_, sipa, gmaxwell: you guys do realize that bip39 is setup so that mistyping the (optional) password can't be detected right? I realized that my discussion about that on the pull-req probably glossed over that misfeature too much |
| 01:31:27 | sipa: | petertodd: i'm commenting |
| 01:31:33 | maaku_: | petertodd: That's my chief concern |
| 01:31:49 | maaku_: | haven't had time today to write a note... |
| 01:32:15 | petertodd: | maaku_: yeah, I was more focusing on how the utf8 made even the general case lead to undetectable typos, but I was thinking I was probably not being clear enough |
| 01:32:22 | jtimon: | petertodd yeah, although in-chain validated colors are I think superior I like colored coins |
| 01:32:29 | maaku_: | They seem to think it is sufficient to check the UTXO set and see if there is a balance |
| 01:32:34 | maaku_: | But that doesn't cover all use cases |
| 01:32:49 | petertodd: | maaku_: yup, chief among them the most basic of "I just created a new wallet" |
| 01:33:40 | petertodd: | jtimon: funny thing is colored coins has kinda lead me down the path of "do we need miners to validate anything?" |
| 01:33:48 | petertodd: | jtimon: (that and MSC) |
| 01:34:43 | jtimon: | well, yeah as said ryan and I went through that validation-less path a little bit but didn't found a real solution |
| 01:35:03 | maaku_: | "Make paper wallet. Type in key incorrectly but start using. Delete wallet.dat (you've got a paper backup, right?). Later try to recreate wallet... and nothing." |
| 01:35:04 | petertodd: | jtimon: there's a real solution, at least if you are a shareholder in seagate... |
| 01:35:07 | jtimon: | miners need to at least validate fees it seems ;) |
| 01:35:23 | petertodd: | jtimon: not if miners == users :) |
| 01:35:30 | petertodd: | maaku_: yup |
| 01:35:55 | petertodd: | maaku_: hell, armory wallet's checksums caught a typo on my part doing exactly that kind of thing |
| 01:35:57 | jtimon: | petertodd yeah, but we didn't found a way to merge the tx pow chains |
| 01:36:33 | petertodd: | jtimon: oh, you mean merge the per-tx pow proofs? |
| 01:37:34 | maaku_: | petertodd: i don't care for attribution, I was just trying to find older discussion that might be relevant, but it looks like it was just between Jorge and me |
| 01:37:42 | jtimon: | yes, instead of block chains, there's just transaction chains, and you can merge them with a transaction hashing on top of two chains |
| 01:38:24 | jtimon: | actually I don't quite rembember the main problems right now |
| 01:39:00 | petertodd: | I think you can use non-interactive proofs and merkle sum trees there to sum total work, but I haven't rigorously gone through the details |
| 01:39:21 | jtimon: | maaku_ maybe I can find some of those #freicoin discussions on quassel's logs |
| 01:40:23 | jtimon: | but I think we preferred sub-transactions very fast |
| 01:40:57 | petertodd: | jtimon: what block interval did you do? |
| 01:41:39 | jtimon: | there was no block interval, transaction were just hashed on top of another as users created them |
| 01:41:47 | petertodd: | well that's insane :P |
| 01:42:38 | jtimon: | well, that's implied in "there's no blocks" I think and Ryan's main motivation was fastest transactions |
| 01:43:24 | petertodd: | you still need to come to consensus, and that still takes speed-of-light limited time at best |
| 01:44:49 | jtimon: | This was the initial proposal https://bitcointalk.org/index.php?topic=4382 |
| 01:45:19 | jtimon: | not sure if we did there or in rippleusers mailing list but we found fatal flaws |
| 01:46:09 | petertodd: | I'm not surprised. In situations with "honest" parties I suspect stuff like that can work, kinda, but it's too easy to imagine ways to game the system. |
| 01:47:31 | jtimon: | so I conluded that you need periodic blocks, thus miners, thus miners to validate at least the fees they receive |
| 01:48:53 | petertodd: | see, miners don't have to necessarily all get fees via the same system; you can imagine miners getting paid fees via, for instance, different colors of colored coins given to them |
| 01:49:02 | jtimon: | but even with the ripple protocol v.06 you could use a blockchain for atomic commits |
| 01:49:32 | petertodd: | or at the extreme, even a totally generic advanced scripting consensus system where the system itself has no concept of coins, and scripts running on it implement those things |
| 01:49:39 | petertodd: | oh, interesting! |
| 01:49:46 | jtimon: | in freimarkets you can pay fees in any asset, not only the hostcoin |
| 01:51:03 | jtimon: | http://archive.ripple-project.org/Protocol/BlockChainCommitMethod |
| 01:53:29 | jtimon: | but still miners need to validate what they receive, no? unless they're somehow paid off-chain to include your transaction (howdo you know which miner will solve the block a priori?) |
| 01:54:12 | petertodd: | well that's one possibility, equally they could validate what *they* receive, but nothign else, e.g. "Mine this weird-ass shit, oh, and this valid colored coin tx that I'm giving you" |
| 01:56:41 | jtimon: | yeah, they could hash most of the stuff without validating and only validate the minimum to receive fees |
| 01:57:48 | jtimon: | note how 2PC ripple (or FM private chains) don't need full proof of inclusion but just timestamping |
| 01:58:11 | petertodd: | in the abstract blockchain scenario where coins themselves are implemented as scripts, you could wind up with a bizzaro world where there's evolutionary competition over what embedded consensus systems offer the most $/hash for miners, all things considered |
| 01:59:01 | jtimon: | I'm having troubles imagining a chain wehre the hostcoin is implemented as scripts |
| 02:00:26 | petertodd: | it would be damn complex, don't get me wrong; my thinking along those lines is basically you have a key-value consensus system, where the keys are scripts, and the values are what is on the stack after the script is executed |
| 02:01:11 | jtimon: | no inputs and outputs? |
| 02:01:31 | petertodd: | now it's a one-shot system, so only the first key executed leaves a value, and to make that useful, the scriptPubKey's need to be curried functions |
| 02:01:55 | petertodd: | jtimon: you'd provide proof of output existance by proving some other previous script left a stack with certain data on it |
| 02:02:08 | petertodd: | like I said, deeply meta and overcompelx :P |
| 02:04:02 | jtimon: | anyway, back to scalability, it's interesting to think about things that are hashed but not validated until they have to become fees |
| 02:04:43 | petertodd: | yeah, but remember that validation is probably the cheapest part of the whole system |
| 02:04:54 | maaku_: | petertodd: SHOULD and MUST have identical meaning in RFC usage |
| 02:05:14 | petertodd: | maaku_: they do? that's wonderfully confusing :) |
| 02:05:23 | maaku_: | yeah :\ |
| 02:05:25 | petertodd: | maaku_: anyway, I hope my intent there was clear |
| 02:05:34 | jtimon: | no, I mean, you could hash 2 GB and just put the root of the tree in the actual blockchain |
| 02:05:49 | maaku_: | petertodd: it was. just an fyi. |
| 02:05:56 | jtimon: | only that is transmitted to the whole network, until it is needed by miners |
| 02:06:03 | petertodd: | jtimon: right, but in that case, remember that proof-of-publication is essential to crypto-currencies |
| 02:06:23 | petertodd: | jtimon: it's only until the data is published and proven to be published that you can say anything about double-spends |
| 02:06:32 | maaku_: | there's a funny NASA memo I've got somewhere mandating future communications to use SHOULD instead of MUST for clarity and standards compliance |
| 02:06:37 | maaku_: | taxpayer dollars at work... |
| 02:06:42 | petertodd: | ugh... |
| 02:07:07 | jtimon: | petertodd unless you have external accountants |
| 02:08:03 | jtimon: | for example, each issuer acts as his own accountant and just timestamps his chain in bitcoin to make fraud more unlikely |
| 02:08:22 | maaku_: | petertodd: ignore me i'm wrong!! i got SHALL and SHOULD mixed up |
| 02:08:35 | petertodd: | maaku_: ah, that makes more sense |
| 02:08:46 | petertodd: | jtimon: how specifically does that make fraud unlikely? |
| 02:09:12 | maaku_: | but for the NASA humor : http://nasawatch.com/archives/2011/06/at-nasa-shall-n.html |
| 02:09:36 | jtimon: | you have a centralized chain without proof of work and with the blocks signed by the accountant (maybe multisig or something) |
| 02:10:02 | jtimon: | but everything it's published and signed just like in bitcoin |
| 02:10:22 | petertodd: | jtimon: right, so fraud is discouraged because the accountant can only get away with publishing a single version of the chain? |
| 02:10:35 | jtimon: | yes |
| 02:10:55 | petertodd: | makes sense, but make it clear that you're not just doing timestamping |
| 02:11:04 | jtimon: | he cannot give a differnt chain to each person |
| 02:11:39 | jtimon: | take into account that he may not give the full chain to everyone, that's a configurable privacy/trust tradeoff |
| 02:11:50 | petertodd: | sure, and again, timestamping *alone* can't do that |
| 02:12:25 | maaku_: | well the private chain may not be public, but users are given receipts with their transactions & merkle paths |
| 02:12:26 | jtimon: | well, by timestamping I meant another use case |
| 02:12:52 | maaku_: | and they can reconstruct the ledger state and/or prove fraud with those receipts |
| 02:12:59 | petertodd: | I'll admit, I may have a bit of bias here, but I strongly suggest using the term proof-of-publication for that use case :) |
| 02:13:05 | jtimon: | for example, use timestamping for atomic trades between assets in several private chains |
| 02:13:36 | jtimon: | or the blockchain commit method in 2PC ripple, that's just using timestamping |
| 02:13:53 | petertodd: | timestamping == time is proven, but there is no way for a third-party to know if anything is being timestamped at all |
| 02:14:13 | petertodd: | proof-of-publication == guaranteed for some well-defined third-party to know something was published |
| 02:14:20 | jtimon: | yeah, the parties communicate the messages between them before timestamping |
| 02:14:33 | petertodd: | well, see that's not proof-of-publication then |
| 02:14:45 | jtimon: | the timestamp is only the commit that the validity of their signed "promises" depnds on |
| 02:15:06 | petertodd: | e.g. could your ledger keeper create two different ledgers and give them to different clients, each with conflicting information? |
| 02:15:19 | jtimon: | but yeah, for the root of the private chain thing is proof of publication |
| 02:15:40 | petertodd: | right, and that root is *guaranteed* to be in the blockchain in some well defined way that a third party can find? |
| 02:15:43 | jtimon: | petertodd, that's configurable |
| 02:16:05 | petertodd: | right, so you can turn that form of fraud detection off basically |
| 02:16:37 | jtimon: | the accountant can just public all the blocks, that's the more trustless I think |
| 02:17:19 | petertodd: | well there's three options: force the whole blocks to be made public, force the fact that a block exists to be made public, (but not the block itself) force all blocks to be timestamped |
| 02:17:19 | jtimon: | but he could only publish the headers and give eaach person only the information he needs |
| 02:17:33 | jtimon: | in this way he could allow double-spends |
| 02:18:02 | petertodd: | important thing is that the proof-of-publication cases ensure that you know what you're being given is *the* history, although the history may be bogus |
| 02:18:17 | jtimon: | yes |
| 02:18:45 | jtimon: | and the accountant can give the full chain independently or not |
| 02:19:04 | jtimon: | that's what's configurable |
| 02:25:57 | petertodd: | maaku_: thanks for the comment |
| 02:27:34 | sipa: | gmaxwell: who do you think should have 'merge' rights on the bips repo? |
| 02:30:18 | maaku_: | gmaxwell: who should have 'status update' rights on the bips repo? |
| 02:30:26 | maaku_: | (draft -> accepted) |
| 02:30:40 | gmaxwell: | I think we might need to redefine the status update stuff. |
| 02:31:34 | gmaxwell: | I think document is or isn't done vs "widely regarded as the right thing" are coplanar characteristics. |
| 02:31:48 | gmaxwell: | and they're both important piece of info. |
| 02:31:59 | maaku_: | gmaxwell: agreed |
| 02:32:12 | gmaxwell: | Ideally I'd like to see the process work in a way that basically every point of decision is one that any moron could correctly decide. |
| 02:34:50 | gmaxwell: | e.g. A document is non-longer draft when the people working on it say it isn't (± some copyedting around that point). E.g. indicating if only one or no one of any interest is complaining that its bad bad bad. vs it being more widely contested (and linking to some directory of the arguments) vs basically everyont thinks it stinks. |
| 02:37:59 | maaku_: | gmaxwell: i think having some review over draft -> stable is a good thing. a sort of "last call for comments!" |
| 02:38:23 | maaku_: | it's the word 'Accepted' which gives us trouble. it specifies The Standard |
| 02:39:48 | gmaxwell: | some might be helped by some kind of boilerplate and some intentionally bad BIPs. Bips about how to implement something don't actually tell you if thats a good practice. |
| 02:46:29 | petertodd: | * petertodd goes off to write BIP-666 Stolen Coin Blacklists via embedded data in the |
| 02:46:32 | petertodd: | UTXO set |
| 02:47:01 | gmaxwell: | I was thinking more like ROT-13 locked transactions. |
| 02:48:15 | petertodd: | or a one-line patch setting MAX_BLOCK_SIZE to infinity... |
| 02:49:15 | sipa: | how about disabling the subsidy limit check? miners would only do things that make long-term economic, sense right? |
| 02:49:30 | sipa: | oh wait, been there done that |
| 02:49:50 | petertodd: | nah, miners just needed more time to come to grips with the overflow bug |
| 02:49:57 | petertodd: | I'm sure they would have used it responsibly |
| 02:50:39 | petertodd: | or s/OP_NOP2/OP_PING/ |
| 02:50:40 | maaku: | maaku is now known as Guest24092 |
| 02:50:49 | sipa: | OP_X86 |
| 02:50:59 | petertodd: | don't forget OP_WGET |
| 02:51:15 | petertodd: | (after ping has been tested thoroughly in the lab!) |
| 02:51:39 | Guest24092: | Guest24092 has left #bitcoin-wizards |
| 02:52:04 | Guest24092: | Guest24092 is now known as maaku |
| 03:04:02 | gmaxwell: | come on guyes, bad ration of spec length and code to stupidity. |
| 03:04:09 | gmaxwell: | I suggest instead, OP_RAND. |
| 03:04:38 | petertodd: | I can do better than that: OP_UNDEFINED |
| 03:04:41 | gmaxwell: | because it's a nice chainforking bug that would take three lines of code to implement, and probably have a shorter spec than just about anything. |
| 03:04:52 | maaku: | petertodd: nah too obvious |
| 03:05:00 | gmaxwell: | OP_UNDEFINED doesn't seem to have a purpose, while OP_RAND might actually seem sensible to someone. |
| 03:05:13 | andytoshi: | OP_BLOCKHEIGHT is another |
| 03:05:32 | petertodd: | andytoshi: that ones not so obvious to screw up... |
| 03:05:32 | andytoshi: | "because nLockTime is nonstandar" |
| 03:05:45 | andytoshi: | petertodd: hmm, yeah |
| 03:05:53 | gmaxwell: | well OP_BLOCKHEIGHT could potentially be done safely enough. |
| 03:05:56 | petertodd: | andytoshi: you *can* implement that in a reasonable way |
| 03:05:59 | maaku: | andytoshi: there are actual uses for OP_BLOCKHEIGHT... |
| 03:06:12 | petertodd: | andytoshi: heck, I'm unconvinced about satoshi's argument there, given double-spends |
| 03:07:18 | petertodd: | a good one would be to implement OP_RAND such that it looks safe, e.g. appears to be based on the prevblockhash, but also includes a byte or two of unallocated memory |
| 03:08:10 | petertodd: | in memory of satoshi: OP_GET_ENDIANNESS |
| 03:08:23 | maaku: | petertodd: seed based on the prev block hash, transaction id, and network time |
| 03:08:43 | gmaxwell: | nah, implementation bugs aren't fun, for an example bad spec you want things which are unsafe in any implementation. |
| 03:08:56 | petertodd: | maaku: ooh, GetAdjustedTime() & ~0xff so most of the time it works |
| 03:08:57 | gmaxwell: | well network time rounded to the minute or something. |
| 03:09:07 | gmaxwell: | jinx. |
| 03:09:26 | gmaxwell: | but that just draws attention to the importance of consistency. |
| 03:09:39 | maaku: | that's a bad thing? :P |
| 03:09:40 | sipa: | OP_OVERWRITE_UTXO_SET |
| 03:09:43 | gmaxwell: | remember a lot of people (most?) around bitcoin think only the miner mining the block evaluates the script. |
| 03:09:45 | andytoshi: | OP_CHECK_SIG_IS_DER_ENCODED |
| 03:09:51 | petertodd: | sipa: we already had that... |
| 03:09:56 | sipa: | oh? :( |
| 03:10:03 | sipa: | OP_INFINITY_LOOP |
| 03:10:09 | petertodd: | sipa: txid duplicate issue |
| 03:10:16 | petertodd: | sipa: OP_ETHEREUM |
| 03:10:27 | sipa: | OP_TURING |
| 03:10:49 | petertodd: | gmaxwell: remind me to call it a scriptWitness in my alt coin... |
| 03:11:04 | andytoshi: | we could have something which looks at the coinbase transaction outputs |
| 03:11:05 | gmaxwell: | but I think a good example bad bip is where joe-technical guy can go read it and think "hey this sounds great" ... and then you have a link on it: "This BIP is contested: [link to arguments against it]" and you read them and go "oh crap, this is harder than I thought." |
| 03:11:28 | sipa: | OP_BLOCKHEIGHT may be an example of that |
| 03:11:38 | petertodd: | indeed... |
| 03:12:11 | andytoshi: | i actually thought i had a working op_blockheight a few weeks ago, and it turned out later that composing it with OP_NOT would wreck the 'safety' i thought i had |
| 03:12:31 | petertodd: | andytoshi: that's why I did up OP_CHECKLOCKTIME... |
| 03:12:32 | maaku: | andytoshi: ? |
| 03:13:06 | petertodd: | andytoshi: specifically OP_CHECKLOCKTIMEVERIFY |
| 03:13:17 | sipa: | andytoshi: you can make it safe by having it either behave as NOP, or fail the script |
| 03:13:25 | andytoshi: | maaku: specifically, i thought OP_HEIGHT_IS_MORE_THAN would be reorg-safe since the tx would always be eventually valid |
| 03:13:48 | sipa: | andytoshi: well, we have locktime for that |
| 03:13:49 | andytoshi: | whereas if a tx can be eventually invalid, then you have the potential for a reorg to destroy it and all its children |
| 03:13:52 | petertodd: | andytoshi: exactly my point with the CHECKLOCKTIMEVERIFY version - it used the IsFinal stuff for that |
| 03:14:01 | maaku: | ok it was your definition of 'safe' i was curious about |
| 03:14:06 | petertodd: | sipa: can't use that to prevent a txout from being spent |
| 03:14:15 | gmaxwell: | sipa: yea but making locktime a output property and conditional on other things in the script could be useful. |
| 03:14:23 | andytoshi: | petertodd: ah, good catch, i wasn't thinking about the *VERIFY behaviour |
| 03:14:27 | maaku: | the interesting applications of OP_BLOCK_HEIGHT is exactly when those which are not reorg safe |
| 03:14:27 | sipa: | gmaxwell: right |
| 03:14:42 | petertodd: | maaku: such as? |
| 03:15:10 | maaku: | petertodd: e.g. cross-chain extrospection or in-script pegging |
| 03:15:30 | petertodd: | maaku: what specifically makes them not reorg safe? |
| 03:16:36 | maaku: | petertodd: the script becoming invalid if it doesn't make it on the chain by the cutoff |
| 03:16:59 | petertodd: | maaku: I mean, why do you need that? |
| 03:18:40 | andytoshi: | so, i think the fact that we got into an argument here suggests that BLOCKHEIGHT has some good nonobvious problems. OP_RAND is also nice because it has great applications and is an instant fork |
| 03:19:05 | petertodd: | andytoshi: OP_PREVBLOCKHASH too |
| 03:20:12 | andytoshi: | maybe i should scroll through all the threads on bct written by users i've ignore'd... |
| 03:20:23 | maaku: | petertodd: well, that's the point: to do things like multi-chain/server ripple trades you have some scripts which are only valid up to a certain block height |
| 03:20:33 | sipa: | andytoshi: you must be suicidal |
| 03:20:54 | petertodd: | maaku: right, I guess I'm just not seeing why exactly, got a writeup? |
| 03:20:55 | maaku: | we have some examples at the end of the freimarkets paper |
| 03:21:16 | andytoshi: | there was also a discussion about double-spend bonds where we came up with some nonobviously broken solutions |
| 03:21:58 | andytoshi: | oh, we gotta propose OP_FROMADDRESS :) |
| 03:22:13 | sipa: | lol |
| 03:22:18 | petertodd: | andytoshi: and OP_TOADDRESS so it can be viral |
| 03:22:29 | maaku: | except that actually makes sense in the context of a script... |
| 03:22:57 | maaku: | (from address being its own address) |
| 03:23:08 | sipa: | except that addresses are a layer on top of scripts... |
| 03:24:24 | petertodd: | why not OP_CODESEPARATOR? |
| 03:24:37 | petertodd: | it could mess with signatures in really bizzare ways |
| 03:25:30 | ageis: | ageis is now known as Guest25108 |
| 03:25:39 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 03:25:42 | petertodd: | sipa: btw, re: malleability, you don't have any working code do you? because litecoin will be doing a soft-fork... |
| 05:48:07 | Guest25108: | Guest25108 is now known as ageis |
| 06:27:12 | ryan-c: | sipa: (or anyone else if they know) is there reference other than the source of how bitcoin's sign/verifymessage work? My google-fu is failing. |
| 06:35:15 | ryan-c: | I see a couple python impls, it looks pretty straightforward |
| 06:35:50 | gmaxwell: | I would bet some of those have an incorrect varint implementation. :P |
| 06:37:02 | ryan-c: | gmaxwell: ISTR some issues with javascript libs screwing that up too, though I don't think it was for signatures. |
| 06:37:14 | ryan-c: | gmaxwell: do you know if pybitcointools is any good? |
| 06:37:20 | gmaxwell: | no idea. |
| 06:39:03 | ryan-c: | gmaxwell: Lots of failing to encode numbers larger than 252 correctly? |
| 06:39:15 | gmaxwell: | yep, so it works on simple tests. |
| 06:39:26 | ryan-c: | * ryan-c looks at the source |
| 06:42:13 | ryan-c: | I see a num_to_var_int function there that looks correct. |
| 06:42:42 | ryan-c: | https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L285 < that however is... um... |
| 06:42:50 | ryan-c: | probably still safe? |
| 06:45:19 | shinybro_: | shinybro_ is now known as shinybro |
| 07:01:49 | phantomcircuit: | gmaxwell, iirc varint is normally correctly implemented by python implementations |
| 07:27:28 | Guest2211: | Guest2211 is now known as firepacket |
| 09:34:28 | sipa: | petertodd: i have some code |
| 09:34:52 | sipa: | but not a full implememtation of all rules i propose |
| 09:40:14 | _ingsoc: | _ingsoc is now known as Guest62956 |
| 10:28:53 | _ingsoc: | _ingsoc is now known as Guest70232 |
| 12:10:28 | maaku: | would it be correct for the foundation to make a statement regarding this snafu? |
| 12:11:43 | Emcy: | what snafu |
| 12:11:53 | c0rw1n: | the gox fuckup i spose |
| 12:13:26 | c0rw1n: | it's a thing completely private to gox, i don't see what the foundation has to do with it |
| 12:13:39 | maaku: | sorry i took the question here because #bitcoin-dev is a mess |
| 12:14:02 | Xarikins: | I think gmaxwell already did respond to it. http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ |
| 12:14:13 | maaku: | c0rw1n: public relations? i think it falls in their charter |
| 12:16:28 | maaku: | the "protect and promote" part |
| 12:17:37 | Emcy: | The difference here is that the MtGox wallet software appears to have not handled this case gracefully at all, and apparently simply wouldn't notice transactions that it "didn't make" spending its own coins. |
| 12:17:39 | Emcy: | welp |
| 12:18:22 | Emcy: | so its that mallebility flaw, but everyone has known about it for a long time |
| 12:19:47 | maaku: | yes, but spreading FUD about alleged fundamental flaws in the bitcoin protocol and reference client, and alleged lack of developer response is detrimental to the entire effort |
| 12:20:30 | Emcy: | am yet to read gox statement |
| 12:22:00 | Emcy: | why not just be straight with people about the technical side of things, instead of mumbling your way through a statement that you hope shuts people up and diverts them long enough for you to fix the problem |
| 12:22:07 | Emcy: | this isnt politics |
| 12:22:24 | maaku: | TL;DR bitcoin withdraws suspended until malleability is fixed, and blames bitcoin developers for their problems |
| 12:23:28 | Emcy: | are they seriously saying theyre not gonnar esume withdrawls until the devs rip out openssl and put something bespoke in? |
| 12:23:44 | Emcy: | they cant possibly be serous |
| 12:24:00 | maaku: | and transaction malleability is not limited to openssl either |
| 12:24:22 | maaku: | * maaku inserts extra NOPs in his scriptSigs, for giggles |
| 12:24:30 | Emcy: | mt.gox statement synopsis "Look! Over there!" |
| 12:24:33 | Xarikins: | the cynic in me thinks that they're intentionally trying to drive price down to handle their insolvency issues, and that this has nothing to do with the protocol itself |
| 12:24:41 | Xarikins: | it's a red herring |
| 12:25:09 | Emcy: | perhaps |
| 12:25:30 | Emcy: | if thats true then its working |
| 12:25:45 | c0rw1n: | some people suspect that gox is on fractional reserve |
| 12:26:44 | maaku: | that's somewhat silly, charged words considering that they don't lend |
| 12:28:26 | Emcy: | are they calling for the network to process and include a new seperate sha hash? |
| 12:29:11 | Xarikins: | they didn't call for anything specific in the press release, they just acted like heroes for letting people know about this crippling protocol bug, and they're standing by, waiting for bitcoin devs to fix it |
| 12:29:37 | c0rw1n: | they're going to wait for a while... |
| 12:29:46 | Emcy: | the new hash's purpose will be to track a given transaction and can be computed and indexed by hashing the exact signed string via SHA256......We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized. |
| 12:30:19 | Emcy: | why dont they compute such hashes on thier own system, seeing as they dont feel able to handle the well known mallebility issue like everyone else |
| 12:31:59 | Emcy: | yeah from what i understand of the details that whole statement is an evenly worded punt. Good show gox |
| 12:33:24 | gmaxwell: | see also my post at http://sourceforge.net/mailarchive/forum.php?thread_name=CAAS2fgTx8UzQiocyNMfMNkt2uUZRTmhagb2BY9TPuAupVjVa2g%40mail.gmail.com&forum_name=bitcoin-development |
| 12:35:18 | Emcy: | you also get an undercurrent that gox thinks bitcoin core owes them anything........this is why i think coredevs should nevert respond directly to the business side of anything in bitcoin |
| 12:35:30 | Emcy: | it is what it is and its up to them to make what they can of it |
| 12:35:58 | Emcy: | ending up with bussiness people calling technical shots will end in tears |
| 12:37:36 | Xarikins: | I think the response is reasonable. Mt. Gox is a business, but they're making technical claims that should get some response, even if their claims are dubious |
| 12:41:01 | maaku: | Xarikins: I don't think it is reasonable to make unsubstantiated claims which result in $1 billion material loss |
| 12:41:27 | Xarikins: | yeah, i'm not defending gox |
| 12:41:30 | Xarikins: | defending maxwell |
| 12:41:37 | maaku: | oh |
| 12:42:14 | Xarikins: | sorry, should have been more clear |
| 13:06:01 | Emcy: | i think gox might find people might haver more faith in gregories analysis than thier own |
| 13:13:06 | Emcy: | gox uses bc core consensus code but not its wallet right |
| 13:13:16 | sipa: | yes |
| 13:13:20 | sipa: | (afaik) |
| 13:13:27 | Xarikins: | that's my understanding as well |
| 13:16:04 | petertodd: | sipa: well, send me the code and I'll add it to litecoin's v3 patch so it can be tested there first |
| 13:16:08 | Emcy: | i think gm might be correct in that theyve got an accounting mess to sort out, and punted for time on it with this statement |
| 13:16:29 | Emcy: | which is like punishing unrelated cusomters for the fuckups that happened to some other ones |
| 13:16:44 | Emcy: | could they just eat the double payouts and get everything moving again |
| 13:25:22 | Emcy: | this market impact has been incredible though.........anyone else think that its because what people initially took away from gox statement is that bitcoin itself is fundamentally broken in a way that leaves them *unable* to proceed |
| 13:25:32 | Emcy: | thats pretty irresponsible......... |
| 13:28:48 | Xarikins: | that's why everyone is so upset, yeah |
| 13:29:02 | Xarikins: | basically gox trashed the market to save a little time/face for themselves |
| 13:29:30 | Emcy: | looks that way |
| 13:29:40 | Emcy: | oh, -dev is chock full of this right now... |
| 13:43:06 | jtimon: | related question...if a double-spent arrives, what does the reference miner currently do? accept the one saw first or accept the one with the higher fee? |
| 13:43:44 | jtimon: | well, maybe this is -dev discussion? |
| 13:43:55 | petertodd: | jtimon: saw first; accept with higher fee is referred to ad replace-by-fee |
| 13:45:23 | jtimon: | thank you, is there a pull request implementing replace-by-fee? |
| 13:46:18 | petertodd: | not a pull-req, but I've done patches implementing it |
| 13:46:28 | petertodd: | there's a 5BTC bounty right now to do it |
| 13:47:37 | sipa: | it's not uncontroversial, though |
| 13:48:38 | jtimon: | sipa yeah, that would make some seq-replacement proposals more unlikely to ever happen |
| 13:48:45 | petertodd: | sipa: otoh, only a small % of the network needs to adopt the rule for it to succeed |
| 13:49:00 | sipa: | petertodd: yeah, and i expect it to happen eventually |
| 13:49:18 | sipa: | but there is some residual assumption of 0-conf security that would be undermined by it |
| 13:49:58 | jtimon: | anyway, you can't stop miners from doing it, first-saw-first-served is not enforceable by the protocol rules |
| 13:49:58 | petertodd: | sipa: only reason I haven't claimed that bounty was because it was for wallet code, and I can probably earn the same amount of money with a lot less stress doing something else :P |
| 13:50:26 | petertodd: | jtimon: well... the scary thing is it *is* enforcable if major pools collude, and if they do that it'll become a way to screw over small miners |
| 13:51:03 | jtimon: | well, that's enforced by collusion, not enforced by the rules |
| 13:51:31 | petertodd: | jtimon: sure, but from a social/political perspective it's easy to see how that kind of collusion would happen |
| 13:51:46 | jtimon: | kind of a fake softfork but I get your point |
| 13:52:01 | petertodd: | "BTCGuild and GHash.IO team up to make Bitcoin safe!" |
| 13:52:15 | jtimon: | Luke-Jr does eligious implement replace-by-fee? |
| 13:52:47 | petertodd: | jtimon: Luke-Jr considered it, but decided not to until the zero-conf safe scorched earth version of it was implemented |
| 13:53:36 | jgarzik: | jgarzik is now known as home_jg |
| 13:54:49 | petertodd: | jtimon: good summary of what that is: https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189 |
| 13:55:20 | petertodd: | (the jargon in this industry is kinda impenetrable...) |
| 13:58:31 | Luke-Jr: | petertodd: no, the problem was it didn't allow replace-by-child-fee |
| 13:58:58 | petertodd: | Luke-Jr: ? that's what you need for the scorched earth thing to work |
| 13:59:08 | Luke-Jr: | yes, that's half of it |
| 13:59:19 | petertodd: | Luke-Jr: yeah, and better network relay rules |
| 13:59:59 | petertodd: | Luke-Jr: I mean, so you'd be ok if it only did replacement w/ child fees, and you don't care if the relay rules were fixed? |
| 14:01:15 | Luke-Jr: | petertodd: sure (assuming it's mergable and/or can still provide the current functionality we need) |
| 14:01:29 | petertodd: | Luke-Jr: ah, ok, well that's a good deal easier... |
| 14:01:59 | Luke-Jr: | petertodd: .. and stable ;) |
| 14:02:19 | Luke-Jr: | I had to back out your partial CPFP implementation because it was assert-failing, remember. |
| 14:02:30 | petertodd: | Luke-Jr: right, that one |
| 14:04:13 | petertodd: | Luke-Jr: see, one thing that could be done is to get things in a state where you have a special RPC call that can add >=2 transactions to the mempool at once, have them be evaluated in one shot, and if they're more profitable, add them |
| 14:04:32 | petertodd: | Luke-Jr: skips all the complex network protocol changes that'd be made, but can still be used via the pushtxn interface |
| 14:07:12 | Luke-Jr: | petertodd: I don't think pushtxn interface should be necessary :/ |
| 14:08:27 | petertodd: | Luke-Jr: well the issue is you have tx1a in the mempool right now, paying fee 0.1, you want to get tx1b mined instead, which conflicts, but pays no fee, and you do that by giving the node tx2, respending tx1b with a fee of 0.2 |
| 14:08:55 | petertodd: | Luke-Jr: but you can't add tx1b to the mempool, because it would be unprofitable, unless you evaluate tx2 at the same time |
| 14:09:28 | Luke-Jr: | sure, but you can keep tx1b in a second inactive mempool just in case tx2 shows up |
| 14:10:11 | petertodd: | Luke-Jr: right, so one model there could be we don't discard tx's that don't get added to the mempool, and limit that second inactive mempool by size |
| 14:10:19 | petertodd: | so I agree that's a decent way to do it |
| 14:10:40 | petertodd: | in fact, I could write a patch doing that with a lot less changes than my full CPFP mempool rewrite... |
| 14:12:04 | phantomcircuit: | that press release is painful |
| 14:12:19 | tacotime_: | tacotime_ is now known as tt_away |
| 14:12:28 | phantomcircuit: | blaming the bitcoin protocol was not a good plan |
| 14:12:46 | home_jg: | indeed |
| 14:14:23 | Luke-Jr: | MtGox seems to be operating on a "what is best for our legal liability" policy, more than what is most correct :| |
| 15:49:28 | andytoshi: | <.< look at the abstract of this paper http://arxiv.org/abs/1402.1718 |
| 15:51:03 | Emcy: | new witholding attack? |
| 15:51:20 | nsh: | for some value of new no doubt |
| 15:55:54 | andytoshi: | Emcy: who knows, the abstract has no many misunderstandings that i'm not gonna open it |
| 15:58:42 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 16:41:54 | andytosh1: | andytosh1 is now known as andytoshi |
| 19:00:18 | nsh_: | nsh_ is now known as nsh |
| 21:20:39 | home_jg: | home_jg is now known as jgarzik |
| 22:41:34 | tt_away: | tt_away is now known as tacotime_ |