01:07:41home_jg:home_jg is now known as jgarzik
01:15:08maaku_:what bug?
01:15:31petertodd:maaku_: how SignatureHash() can return 1 without an error
01:15:43maaku_:i see
01:15:50maaku_:i wasn't aware of that
01:16:31maaku_:petertodd: I thought it came up on either bitcoin-x or the ripple users mailing list
01:16:33petertodd: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:47petertodd:ripple users mailing list?!
01:17:14petertodd:I hear if 0 had been returned instead it'd be a backdoor to spend anyones funds apparently
01:17:42maaku_:jtimon and I epxlored the idea in depth on the #freicoin channel and email prior to developing freimarkets
01:17:45maaku_: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:16petertodd:ah, too bad
01:18:38maaku_:i thought the idea was even older ... i was a little disappointed I couldn't find public discussion
01:18:48maaku_:only because it would have been interesting to see what we thought then
01:18:55petertodd:we've been kinda bad at that far too often
01:19:11maaku_:having this channel helps though
01:19:19maaku_:most ideas get filtered through here at some point
01:19:23petertodd:yes, especially with logbot
01:19:54jtimon:I think all my proposals in the forum directly involve hardfork changes rather than using regular colored coins
01:20:02maaku_:petertodd: https://groups.google.com/forum/#!forum/rippleusers
01:20:12maaku_:it's the pre-ripple mailing list
01:20:22petertodd:sighash -> no results
01:20:25maaku_:er, pre-opencoin
01:20:47petertodd:it's pre-'the abomination that shall not be named'
01:20:56jtimon:yeah, kind of death now, but we discussed p2p trading on "ripplecoin" much earlier than anybody even talked about colroed coins
01:24:41jtimon: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:11jtimon:very mixed with monetery philoshophical discussions and the like I fear
01:27:02petertodd: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:13jtimon: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:07petertodd:yeah, oh well, interesting to see the idea develop anyway
01:30:41petertodd: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:27sipa:petertodd: i'm commenting
01:31:33maaku_:petertodd: That's my chief concern
01:31:49maaku_:haven't had time today to write a note...
01:32:15petertodd: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:22jtimon:petertodd yeah, although in-chain validated colors are I think superior I like colored coins
01:32:29maaku_:They seem to think it is sufficient to check the UTXO set and see if there is a balance
01:32:34maaku_:But that doesn't cover all use cases
01:32:49petertodd:maaku_: yup, chief among them the most basic of "I just created a new wallet"
01:33:40petertodd:jtimon: funny thing is colored coins has kinda lead me down the path of "do we need miners to validate anything?"
01:33:48petertodd:jtimon: (that and MSC)
01:34:43jtimon: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:03maaku_:"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:04petertodd:jtimon: there's a real solution, at least if you are a shareholder in seagate...
01:35:07jtimon:miners need to at least validate fees it seems ;)
01:35:23petertodd:jtimon: not if miners == users :)
01:35:30petertodd:maaku_: yup
01:35:55petertodd:maaku_: hell, armory wallet's checksums caught a typo on my part doing exactly that kind of thing
01:35:57jtimon:petertodd yeah, but we didn't found a way to merge the tx pow chains
01:36:33petertodd:jtimon: oh, you mean merge the per-tx pow proofs?
01:37:34maaku_: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:42jtimon: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:24jtimon:actually I don't quite rembember the main problems right now
01:39:00petertodd: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:21jtimon:maaku_ maybe I can find some of those #freicoin discussions on quassel's logs
01:40:23jtimon:but I think we preferred sub-transactions very fast
01:40:57petertodd:jtimon: what block interval did you do?
01:41:39jtimon:there was no block interval, transaction were just hashed on top of another as users created them
01:41:47petertodd:well that's insane :P
01:42:38jtimon:well, that's implied in "there's no blocks" I think and Ryan's main motivation was fastest transactions
01:43:24petertodd:you still need to come to consensus, and that still takes speed-of-light limited time at best
01:44:49jtimon:This was the initial proposal https://bitcointalk.org/index.php?topic=4382
01:45:19jtimon:not sure if we did there or in rippleusers mailing list but we found fatal flaws
01:46:09petertodd: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:31jtimon:so I conluded that you need periodic blocks, thus miners, thus miners to validate at least the fees they receive
01:48:53petertodd: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:02jtimon:but even with the ripple protocol v.06 you could use a blockchain for atomic commits
01:49:32petertodd: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:39petertodd:oh, interesting!
01:49:46jtimon:in freimarkets you can pay fees in any asset, not only the hostcoin
01:53:29jtimon: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:12petertodd: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:41jtimon:yeah, they could hash most of the stuff without validating and only validate the minimum to receive fees
01:57:48jtimon:note how 2PC ripple (or FM private chains) don't need full proof of inclusion but just timestamping
01:58:11petertodd: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:01jtimon:I'm having troubles imagining a chain wehre the hostcoin is implemented as scripts
02:00:26petertodd: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:11jtimon:no inputs and outputs?
02:01:31petertodd: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:55petertodd:jtimon: you'd provide proof of output existance by proving some other previous script left a stack with certain data on it
02:02:08petertodd:like I said, deeply meta and overcompelx :P
02:04:02jtimon: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:43petertodd:yeah, but remember that validation is probably the cheapest part of the whole system
02:04:54maaku_:petertodd: SHOULD and MUST have identical meaning in RFC usage
02:05:14petertodd:maaku_: they do? that's wonderfully confusing :)
02:05:23maaku_:yeah :\
02:05:25petertodd:maaku_: anyway, I hope my intent there was clear
02:05:34jtimon:no, I mean, you could hash 2 GB and just put the root of the tree in the actual blockchain
02:05:49maaku_:petertodd: it was. just an fyi.
02:05:56jtimon:only that is transmitted to the whole network, until it is needed by miners
02:06:03petertodd:jtimon: right, but in that case, remember that proof-of-publication is essential to crypto-currencies
02:06:23petertodd:jtimon: it's only until the data is published and proven to be published that you can say anything about double-spends
02:06:32maaku_: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:37maaku_:taxpayer dollars at work...
02:07:07jtimon:petertodd unless you have external accountants
02:08:03jtimon:for example, each issuer acts as his own accountant and just timestamps his chain in bitcoin to make fraud more unlikely
02:08:22maaku_:petertodd: ignore me i'm wrong!! i got SHALL and SHOULD mixed up
02:08:35petertodd:maaku_: ah, that makes more sense
02:08:46petertodd:jtimon: how specifically does that make fraud unlikely?
02:09:12maaku_:but for the NASA humor : http://nasawatch.com/archives/2011/06/at-nasa-shall-n.html
02:09:36jtimon:you have a centralized chain without proof of work and with the blocks signed by the accountant (maybe multisig or something)
02:10:02jtimon:but everything it's published and signed just like in bitcoin
02:10:22petertodd:jtimon: right, so fraud is discouraged because the accountant can only get away with publishing a single version of the chain?
02:10:55petertodd:makes sense, but make it clear that you're not just doing timestamping
02:11:04jtimon:he cannot give a differnt chain to each person
02:11:39jtimon:take into account that he may not give the full chain to everyone, that's a configurable privacy/trust tradeoff
02:11:50petertodd:sure, and again, timestamping *alone* can't do that
02:12:25maaku_:well the private chain may not be public, but users are given receipts with their transactions & merkle paths
02:12:26jtimon:well, by timestamping I meant another use case
02:12:52maaku_:and they can reconstruct the ledger state and/or prove fraud with those receipts
02:12:59petertodd: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:05jtimon:for example, use timestamping for atomic trades between assets in several private chains
02:13:36jtimon:or the blockchain commit method in 2PC ripple, that's just using timestamping
02:13:53petertodd:timestamping == time is proven, but there is no way for a third-party to know if anything is being timestamped at all
02:14:13petertodd:proof-of-publication == guaranteed for some well-defined third-party to know something was published
02:14:20jtimon:yeah, the parties communicate the messages between them before timestamping
02:14:33petertodd:well, see that's not proof-of-publication then
02:14:45jtimon:the timestamp is only the commit that the validity of their signed "promises" depnds on
02:15:06petertodd:e.g. could your ledger keeper create two different ledgers and give them to different clients, each with conflicting information?
02:15:19jtimon:but yeah, for the root of the private chain thing is proof of publication
02:15:40petertodd:right, and that root is *guaranteed* to be in the blockchain in some well defined way that a third party can find?
02:15:43jtimon:petertodd, that's configurable
02:16:05petertodd:right, so you can turn that form of fraud detection off basically
02:16:37jtimon:the accountant can just public all the blocks, that's the more trustless I think
02:17:19petertodd: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:19jtimon:but he could only publish the headers and give eaach person only the information he needs
02:17:33jtimon:in this way he could allow double-spends
02:18:02petertodd: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:45jtimon:and the accountant can give the full chain independently or not
02:19:04jtimon:that's what's configurable
02:25:57petertodd:maaku_: thanks for the comment
02:27:34sipa:gmaxwell: who do you think should have 'merge' rights on the bips repo?
02:30:18maaku_:gmaxwell: who should have 'status update' rights on the bips repo?
02:30:26maaku_:(draft -> accepted)
02:30:40gmaxwell:I think we might need to redefine the status update stuff.
02:31:34gmaxwell:I think document is or isn't done vs "widely regarded as the right thing" are coplanar characteristics.
02:31:48gmaxwell:and they're both important piece of info.
02:31:59maaku_:gmaxwell: agreed
02:32:12gmaxwell: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:50gmaxwell: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:59maaku_:gmaxwell: i think having some review over draft -> stable is a good thing. a sort of "last call for comments!"
02:38:23maaku_:it's the word 'Accepted' which gives us trouble. it specifies The Standard
02:39:48gmaxwell: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:29petertodd:* petertodd goes off to write BIP-666 Stolen Coin Blacklists via embedded data in the
02:46:32petertodd:UTXO set
02:47:01gmaxwell:I was thinking more like ROT-13 locked transactions.
02:48:15petertodd:or a one-line patch setting MAX_BLOCK_SIZE to infinity...
02:49:15sipa:how about disabling the subsidy limit check? miners would only do things that make long-term economic, sense right?
02:49:30sipa:oh wait, been there done that
02:49:50petertodd:nah, miners just needed more time to come to grips with the overflow bug
02:49:57petertodd:I'm sure they would have used it responsibly
02:50:39petertodd:or s/OP_NOP2/OP_PING/
02:50:40maaku:maaku is now known as Guest24092
02:50:59petertodd:don't forget OP_WGET
02:51:15petertodd:(after ping has been tested thoroughly in the lab!)
02:51:39Guest24092:Guest24092 has left #bitcoin-wizards
02:52:04Guest24092:Guest24092 is now known as maaku
03:04:02gmaxwell:come on guyes, bad ration of spec length and code to stupidity.
03:04:09gmaxwell:I suggest instead, OP_RAND.
03:04:38petertodd:I can do better than that: OP_UNDEFINED
03:04:41gmaxwell: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:52maaku:petertodd: nah too obvious
03:05:00gmaxwell:OP_UNDEFINED doesn't seem to have a purpose, while OP_RAND might actually seem sensible to someone.
03:05:13andytoshi:OP_BLOCKHEIGHT is another
03:05:32petertodd:andytoshi: that ones not so obvious to screw up...
03:05:32andytoshi:"because nLockTime is nonstandar"
03:05:45andytoshi:petertodd: hmm, yeah
03:05:53gmaxwell:well OP_BLOCKHEIGHT could potentially be done safely enough.
03:05:56petertodd:andytoshi: you *can* implement that in a reasonable way
03:05:59maaku:andytoshi: there are actual uses for OP_BLOCKHEIGHT...
03:06:12petertodd:andytoshi: heck, I'm unconvinced about satoshi's argument there, given double-spends
03:07:18petertodd: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:10petertodd:in memory of satoshi: OP_GET_ENDIANNESS
03:08:23maaku:petertodd: seed based on the prev block hash, transaction id, and network time
03:08:43gmaxwell:nah, implementation bugs aren't fun, for an example bad spec you want things which are unsafe in any implementation.
03:08:56petertodd:maaku: ooh, GetAdjustedTime() & ~0xff so most of the time it works
03:08:57gmaxwell:well network time rounded to the minute or something.
03:09:26gmaxwell:but that just draws attention to the importance of consistency.
03:09:39maaku:that's a bad thing? :P
03:09:43gmaxwell:remember a lot of people (most?) around bitcoin think only the miner mining the block evaluates the script.
03:09:51petertodd:sipa: we already had that...
03:09:56sipa:oh? :(
03:10:09petertodd:sipa: txid duplicate issue
03:10:16petertodd:sipa: OP_ETHEREUM
03:10:49petertodd:gmaxwell: remind me to call it a scriptWitness in my alt coin...
03:11:04andytoshi:we could have something which looks at the coinbase transaction outputs
03:11:05gmaxwell: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:28sipa:OP_BLOCKHEIGHT may be an example of that
03:12:11andytoshi: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:31petertodd:andytoshi: that's why I did up OP_CHECKLOCKTIME...
03:12:32maaku:andytoshi: ?
03:13:06petertodd:andytoshi: specifically OP_CHECKLOCKTIMEVERIFY
03:13:17sipa:andytoshi: you can make it safe by having it either behave as NOP, or fail the script
03:13:25andytoshi:maaku: specifically, i thought OP_HEIGHT_IS_MORE_THAN would be reorg-safe since the tx would always be eventually valid
03:13:48sipa:andytoshi: well, we have locktime for that
03:13:49andytoshi: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:52petertodd:andytoshi: exactly my point with the CHECKLOCKTIMEVERIFY version - it used the IsFinal stuff for that
03:14:01maaku:ok it was your definition of 'safe' i was curious about
03:14:06petertodd:sipa: can't use that to prevent a txout from being spent
03:14:15gmaxwell:sipa: yea but making locktime a output property and conditional on other things in the script could be useful.
03:14:23andytoshi:petertodd: ah, good catch, i wasn't thinking about the *VERIFY behaviour
03:14:27maaku:the interesting applications of OP_BLOCK_HEIGHT is exactly when those which are not reorg safe
03:14:27sipa:gmaxwell: right
03:14:42petertodd:maaku: such as?
03:15:10maaku:petertodd: e.g. cross-chain extrospection or in-script pegging
03:15:30petertodd:maaku: what specifically makes them not reorg safe?
03:16:36maaku:petertodd: the script becoming invalid if it doesn't make it on the chain by the cutoff
03:16:59petertodd:maaku: I mean, why do you need that?
03:18:40andytoshi: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:05petertodd:andytoshi: OP_PREVBLOCKHASH too
03:20:12andytoshi:maybe i should scroll through all the threads on bct written by users i've ignore'd...
03:20:23maaku: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:33sipa:andytoshi: you must be suicidal
03:20:54petertodd:maaku: right, I guess I'm just not seeing why exactly, got a writeup?
03:20:55maaku:we have some examples at the end of the freimarkets paper
03:21:16andytoshi:there was also a discussion about double-spend bonds where we came up with some nonobviously broken solutions
03:21:58andytoshi:oh, we gotta propose OP_FROMADDRESS :)
03:22:18petertodd:andytoshi: and OP_TOADDRESS so it can be viral
03:22:29maaku:except that actually makes sense in the context of a script...
03:22:57maaku:(from address being its own address)
03:23:08sipa:except that addresses are a layer on top of scripts...
03:24:24petertodd:why not OP_CODESEPARATOR?
03:24:37petertodd:it could mess with signatures in really bizzare ways
03:25:30ageis:ageis is now known as Guest25108
03:25:39OneFixt_:OneFixt_ is now known as OneFixt
03:25:42petertodd:sipa: btw, re: malleability, you don't have any working code do you? because litecoin will be doing a soft-fork...
05:48:07Guest25108:Guest25108 is now known as ageis
06:27:12ryan-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:15ryan-c:I see a couple python impls, it looks pretty straightforward
06:35:50gmaxwell:I would bet some of those have an incorrect varint implementation. :P
06:37:02ryan-c:gmaxwell: ISTR some issues with javascript libs screwing that up too, though I don't think it was for signatures.
06:37:14ryan-c:gmaxwell: do you know if pybitcointools is any good?
06:37:20gmaxwell:no idea.
06:39:03ryan-c:gmaxwell: Lots of failing to encode numbers larger than 252 correctly?
06:39:15gmaxwell:yep, so it works on simple tests.
06:39:26ryan-c:* ryan-c looks at the source
06:42:13ryan-c:I see a num_to_var_int function there that looks correct.
06:42:42ryan-c:https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L285 < that however is... um...
06:42:50ryan-c:probably still safe?
06:45:19shinybro_:shinybro_ is now known as shinybro
07:01:49phantomcircuit:gmaxwell, iirc varint is normally correctly implemented by python implementations
07:27:28Guest2211:Guest2211 is now known as firepacket
09:34:28sipa:petertodd: i have some code
09:34:52sipa: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:28maaku:would it be correct for the foundation to make a statement regarding this snafu?
12:11:43Emcy:what snafu
12:11:53c0rw1n:the gox fuckup i spose
12:13:26c0rw1n:it's a thing completely private to gox, i don't see what the foundation has to do with it
12:13:39maaku:sorry i took the question here because #bitcoin-dev is a mess
12:14:02Xarikins: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:13maaku:c0rw1n: public relations? i think it falls in their charter
12:16:28maaku:the "protect and promote" part
12:17:37Emcy: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:18:22Emcy:so its that mallebility flaw, but everyone has known about it for a long time
12:19:47maaku: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:30Emcy:am yet to read gox statement
12:22:00Emcy: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:07Emcy:this isnt politics
12:22:24maaku:TL;DR bitcoin withdraws suspended until malleability is fixed, and blames bitcoin developers for their problems
12:23:28Emcy:are they seriously saying theyre not gonnar esume withdrawls until the devs rip out openssl and put something bespoke in?
12:23:44Emcy:they cant possibly be serous
12:24:00maaku:and transaction malleability is not limited to openssl either
12:24:22maaku:* maaku inserts extra NOPs in his scriptSigs, for giggles
12:24:30Emcy:mt.gox statement synopsis "Look! Over there!"
12:24:33Xarikins: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:41Xarikins:it's a red herring
12:25:30Emcy:if thats true then its working
12:25:45c0rw1n:some people suspect that gox is on fractional reserve
12:26:44maaku:that's somewhat silly, charged words considering that they don't lend
12:28:26Emcy:are they calling for the network to process and include a new seperate sha hash?
12:29:11Xarikins: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:37c0rw1n:they're going to wait for a while...
12:29:46Emcy: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:19Emcy: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:59Emcy:yeah from what i understand of the details that whole statement is an evenly worded punt. Good show gox
12:33:24gmaxwell:see also my post at http://sourceforge.net/mailarchive/forum.php?thread_name=CAAS2fgTx8UzQiocyNMfMNkt2uUZRTmhagb2BY9TPuAupVjVa2g%40mail.gmail.com&forum_name=bitcoin-development
12:35:18Emcy: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:30Emcy:it is what it is and its up to them to make what they can of it
12:35:58Emcy:ending up with bussiness people calling technical shots will end in tears
12:37:36Xarikins: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:01maaku:Xarikins: I don't think it is reasonable to make unsubstantiated claims which result in $1 billion material loss
12:41:27Xarikins:yeah, i'm not defending gox
12:41:30Xarikins:defending maxwell
12:42:14Xarikins:sorry, should have been more clear
13:06:01Emcy:i think gox might find people might haver more faith in gregories analysis than thier own
13:13:06Emcy:gox uses bc core consensus code but not its wallet right
13:13:27Xarikins:that's my understanding as well
13:16:04petertodd: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:08Emcy: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:29Emcy:which is like punishing unrelated cusomters for the fuckups that happened to some other ones
13:16:44Emcy:could they just eat the double payouts and get everything moving again
13:25:22Emcy: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:32Emcy:thats pretty irresponsible.........
13:28:48Xarikins:that's why everyone is so upset, yeah
13:29:02Xarikins:basically gox trashed the market to save a little time/face for themselves
13:29:30Emcy:looks that way
13:29:40Emcy:oh, -dev is chock full of this right now...
13:43:06jtimon: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:44jtimon:well, maybe this is -dev discussion?
13:43:55petertodd:jtimon: saw first; accept with higher fee is referred to ad replace-by-fee
13:45:23jtimon:thank you, is there a pull request implementing replace-by-fee?
13:46:18petertodd:not a pull-req, but I've done patches implementing it
13:46:28petertodd:there's a 5BTC bounty right now to do it
13:47:37sipa:it's not uncontroversial, though
13:48:38jtimon:sipa yeah, that would make some seq-replacement proposals more unlikely to ever happen
13:48:45petertodd:sipa: otoh, only a small % of the network needs to adopt the rule for it to succeed
13:49:00sipa:petertodd: yeah, and i expect it to happen eventually
13:49:18sipa:but there is some residual assumption of 0-conf security that would be undermined by it
13:49:58jtimon:anyway, you can't stop miners from doing it, first-saw-first-served is not enforceable by the protocol rules
13:49:58petertodd: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:26petertodd: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:03jtimon:well, that's enforced by collusion, not enforced by the rules
13:51:31petertodd:jtimon: sure, but from a social/political perspective it's easy to see how that kind of collusion would happen
13:51:46jtimon:kind of a fake softfork but I get your point
13:52:01petertodd:"BTCGuild and GHash.IO team up to make Bitcoin safe!"
13:52:15jtimon:Luke-Jr does eligious implement replace-by-fee?
13:52:47petertodd:jtimon: Luke-Jr considered it, but decided not to until the zero-conf safe scorched earth version of it was implemented
13:53:36jgarzik:jgarzik is now known as home_jg
13:54:49petertodd:jtimon: good summary of what that is: https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
13:55:20petertodd:(the jargon in this industry is kinda impenetrable...)
13:58:31Luke-Jr:petertodd: no, the problem was it didn't allow replace-by-child-fee
13:58:58petertodd:Luke-Jr: ? that's what you need for the scorched earth thing to work
13:59:08Luke-Jr:yes, that's half of it
13:59:19petertodd:Luke-Jr: yeah, and better network relay rules
13:59:59petertodd: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:15Luke-Jr:petertodd: sure (assuming it's mergable and/or can still provide the current functionality we need)
14:01:29petertodd:Luke-Jr: ah, ok, well that's a good deal easier...
14:01:59Luke-Jr:petertodd: .. and stable ;)
14:02:19Luke-Jr:I had to back out your partial CPFP implementation because it was assert-failing, remember.
14:02:30petertodd:Luke-Jr: right, that one
14:04:13petertodd: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:32petertodd:Luke-Jr: skips all the complex network protocol changes that'd be made, but can still be used via the pushtxn interface
14:07:12Luke-Jr:petertodd: I don't think pushtxn interface should be necessary :/
14:08:27petertodd: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:55petertodd: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:28Luke-Jr:sure, but you can keep tx1b in a second inactive mempool just in case tx2 shows up
14:10:11petertodd: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:19petertodd:so I agree that's a decent way to do it
14:10:40petertodd:in fact, I could write a patch doing that with a lot less changes than my full CPFP mempool rewrite...
14:12:04phantomcircuit:that press release is painful
14:12:19tacotime_:tacotime_ is now known as tt_away
14:12:28phantomcircuit:blaming the bitcoin protocol was not a good plan
14:14:23Luke-Jr:MtGox seems to be operating on a "what is best for our legal liability" policy, more than what is most correct :|
15:49:28andytoshi:<.< look at the abstract of this paper http://arxiv.org/abs/1402.1718
15:51:03Emcy:new witholding attack?
15:51:20nsh:for some value of new no doubt
15:55:54andytoshi:Emcy: who knows, the abstract has no many misunderstandings that i'm not gonna open it
15:58:42jgarzik_:jgarzik_ is now known as jgarzik
16:41:54andytosh1:andytosh1 is now known as andytoshi
19:00:18nsh_:nsh_ is now known as nsh
21:20:39home_jg:home_jg is now known as jgarzik
22:41:34tt_away:tt_away is now known as tacotime_