1 2012-08-13 15:39:31 <luke-jr> gavininacar: to clarify: can "generated" be omitted, or do we need to specify false for every normal tx?
  2 2012-08-13 15:39:47 <sipa> i'd omit it for non-generation
  3 2012-08-13 15:39:51 <user_> hi, this transaction will be uncorfirmed forever?: www.blockchain.info/address/13AFvadrSnsAzSXTSguFRCJB6j5nzcAQ7i
  4 2012-08-13 15:40:03 <luke-jr> user_: unlikely
  5 2012-08-13 15:40:50 <gmaxwell> luke-jr: before answering look at its ancestors.
  6 2012-08-13 15:41:06 <luke-jr> ah
  7 2012-08-13 15:41:18 <luke-jr> odd, blockchain.info used to warn if there was even a chance of double spend
  8 2012-08-13 15:41:46 <luke-jr> wait, nm
  9 2012-08-13 15:41:50 <luke-jr> gmaxwell: what about its ancestors?
 10 2012-08-13 15:42:11 <gmaxwell> luke-jr: yea, I can't make sense of this. It looks like a double spend? but perhaps the UI is just confusing.
 11 2012-08-13 15:42:36 <luke-jr> gmaxwell: I think the unconfirmed txn is the spend
 12 2012-08-13 15:43:16 <gmaxwell> In any case, its a member of a really long unconfirmed chain.
 13 2012-08-13 15:43:25 <luke-jr> yeah
 14 2012-08-13 15:44:01 <gmaxwell> someone @!#!@ doesn't know how to use sendmany.
 15 2012-08-13 15:44:06 <luke-jr> user_: whoever sent this to you seems to be a spammer
 16 2012-08-13 15:44:31 <user_> was coinbase.com
 17 2012-08-13 15:44:41 <luke-jr> gmaxwell: way way back, there is a real double spend
 18 2012-08-13 15:44:47 <luke-jr> user_: no, it will never confirm
 19 2012-08-13 15:44:52 <luke-jr> the alternate chain has 101 confirms now
 20 2012-08-13 15:45:02 <luke-jr> so yours is basically -101
 21 2012-08-13 15:45:10 <user_> they sent me 0.1 to register and confirm account
 22 2012-08-13 15:45:21 <gmaxwell> There unconfirmed stub is 45 transactions long.
 23 2012-08-13 15:45:27 <gmaxwell> luke-jr: ah.
 24 2012-08-13 15:46:17 <user_> i tried withdraw the 0.1 and never confirm
 25 2012-08-13 15:46:24 <gmaxwell> man. really need negative confirmation support, this was a PITA to figure out. Would have been much easier if user_ said "my client says -101 confirmations!"
 26 2012-08-13 15:47:17 <user_> yes, but i'm not using any client
 27 2012-08-13 15:47:23 <luke-jr> sounds like maybe someone is exploiting coinbase.com, and coinbase.com is a spammer :P
 28 2012-08-13 15:47:35 <user_> the key was genersted from bitaddress
 29 2012-08-13 15:47:55 <user_> maybe
 30 2012-08-13 15:48:18 <gmaxwell> This is the losing doublespend: http://www.blockchain.info/tx-index/15496811/5340cb0f203d6ee57e96742e01af7991fc625f33429b5e17542a58004df5a567
 31 2012-08-13 15:48:25 <gmaxwell> it was a real pain to find on blockchain.info.
 32 2012-08-13 15:48:39 <freewil> luke-jr, does #1409 allow the client to receive sent coinbase txs for example from eligius?
 33 2012-08-13 15:48:42 <copumpkin> isn't coinbase that ycombinator-backed company that was on the news recently?
 34 2012-08-13 15:48:55 <sipa> copumpkin: it is
 35 2012-08-13 15:49:01 <copumpkin> okay
 36 2012-08-13 15:49:03 <luke-jr> gavininacar: sipa: listtx_generate_fold updated to use "generated":true
 37 2012-08-13 15:49:14 <luke-jr> freewil: pretty much, yes
 38 2012-08-13 15:50:07 <gribble> To see a nice sortable web view of all factoids, click here: http://gribble.dreamhosters.com/viewfactoids.php?db=%23bitcoin-dev || To see a list of the most popular factoids, run !rank || To search factoids, run !factoids search <yoursearchterm>
 39 2012-08-13 15:50:07 <grondilu> !facts
 40 2012-08-13 15:50:34 <freewil> luke-jr, nice +1
 41 2012-08-13 15:50:50 <sipa> gavininacar: i wonder if we should base the 75%/95% decision not just on nVersion==2, but on (nVersion==2 && has_height_in_coinbase), excluding people who think they are doing it right, but have a incorrect implementation (which seems to exist?)
 42 2012-08-13 15:51:11 <luke-jr> gmaxwell: btw, in case you missed it: https://bitcointalk.org/?topic=100390
 43 2012-08-13 15:52:41 <gmaxwell> sipa: oh that sounds prudent to me.
 44 2012-08-13 15:53:32 <sipa> maybe an incorrect nVersion==2 block can even count negatively, as it is evidence of people who will be hurt by the switchover
 45 2012-08-13 15:53:44 <gavininacar> sipa: that makes the counting code more complicated... is it worth it to make things easier for incorrect implementations?
 46 2012-08-13 15:54:37 <gavininacar> Right now the counting code doesn't have to fetch any transactions, which is a nice property.
 47 2012-08-13 15:55:01 <sipa> hmm, also true
 48 2012-08-13 15:55:16 <luke-jr> could always flag in the block index whether it was correct
 49 2012-08-13 15:55:43 <sipa> i'm only suggesting it because there seem to be people with incorrect implementations?
 50 2012-08-13 15:56:28 <luke-jr> would be nice to just find out who/what it is :/
 51 2012-08-13 16:02:27 <sipa> luke-jr: why "processing" after 2 confirmations (my intuition says 1)
 52 2012-08-13 16:03:36 <luke-jr> sipa: 1 could easily be an ordinary orphan race
 53 2012-08-13 16:03:48 <luke-jr> if orphans are 2 deep, chances are both chains contain your txn at least
 54 2012-08-13 16:04:05 <luke-jr> (real reason: I stole the rules from Spesmilo)
 55 2012-08-13 16:05:02 <sipa> right, but says "validating" at 1 is strange; if it has a confirmation (even with some chance of reversal), it is certainly valid
 56 2012-08-13 16:05:33 <sipa> (i'm nitpicking because the ">=2 confirmations" point was never special before)
 57 2012-08-13 16:09:40 <luke-jr> sipa: I don't have any strong feelings toward those tiers; if a change is wanted, just say how :p
 58 2012-08-13 16:11:10 <luke-jr> the only reason it's part of this pullreq is so there is a type-independent way to tell the status of a transaction regardless of whether it's a normal one or generated
 59 2012-08-13 16:12:54 <gmaxwell> luke-jr: could that also be a way to have depth independant safty intelligence?  E.g. not showing txn as fully confirmed at 6 deep if you've wittnessed a double spend?
 60 2012-08-13 16:13:40 <luke-jr> gmaxwell: possibly, though that is definitely outside the scope of that pullreq lol
 61 2012-08-13 16:13:44 <gmaxwell> sure.
 62 2012-08-13 16:15:59 <gmaxwell> oh! blockexplorer is on testnet3!
 63 2012-08-13 16:16:42 <gmaxwell> it thinks all the coinbases are strange?
 64 2012-08-13 16:16:48 <gmaxwell> I guess its confused by compressed public keys?
 65 2012-08-13 16:18:32 <gmaxwell> sipa: can you setup a version of your difficulty charts on testnet?
 66 2012-08-13 16:22:04 <gmaxwell> http://blockexplorer.com/testnet/block/000000007dacb5d4d071404703e73839b0f47fc82f912d75fab7933bf5306735 < look at the last transaction. Someone's using FLOAT.
 67 2012-08-13 16:22:49 <sipa> gmaxwell: a fee of 100k tnBTC?
 68 2012-08-13 16:22:56 <sipa> looks quite deliberate to me
 69 2012-08-13 16:23:12 <gmaxwell> Oh, actually it really was 100000.99999999. I don't remember that.
 70 2012-08-13 16:23:28 <gmaxwell> sipa: Yea, the transaction is mine, but I thought it was an even 100k.
 71 2012-08-13 16:24:08 <gmaxwell> (I did that so if someone wanted to do a TN3-IN-A-BOX they could fork the chain there and mine that block to have a supply of a lot of coins without a lot of mining)
 72 2012-08-13 16:25:05 <sipa> gmaxwell: yeah, i'll set up a testnet version (someday...)
 73 2012-08-13 16:25:38 <gmaxwell> No worries, I'll periodically nag. ;)
 74 2012-08-13 16:26:25 <sipa> gmaxwell: by the way, it seems that I2P actually has 256-bit addresses and not 80-bit ones
 75 2012-08-13 16:26:37 <sipa> the garlicat thing needs some resolver service still
 76 2012-08-13 16:39:05 <sipa> you'd probably want a separate host key per network you're connected to
 77 2012-08-13 16:39:46 <sipa> luke-jr: not a NAK, but i'd prefer processing from 1 confirmation on
 78 2012-08-13 16:40:33 <luke-jr> sipa: I don't really care. If you're saying "change it to 1 and I'll merge it now", I'll do it now :p
 79 2012-08-13 16:47:49 <jgarzik> gmaxwell: yeah, I poked theymos the other day, and he said he would update blockexplorer to testnet3 in the (then) next day or two
 80 2012-08-13 16:47:56 <jgarzik> so, kudos theymos
 81 2012-08-13 16:55:53 <sipa> hmm, maybe 0x06/0x07 pubkeys non-IsStandard is not that trivial, as you need to check the sigScript's pushes
 82 2012-08-13 17:02:37 <gavininacar> sipa: yes, non-trivial... also non-trivial is making transactions that put extra junk on the stack non-standard, and I want to do that, too.
 83 2012-08-13 17:03:24 <luke-jr> gavininacar: I thought you already did?
 84 2012-08-13 17:03:35 <gavininacar> ... and make non-DER-encoded signatures and scripts that use PUSHDATA4 when they don't need to...
 85 2012-08-13 17:03:56 <gavininacar> luke-jr: might have, I tend to have a bad memory for what I've already done did.
 86 2012-08-13 17:04:22 <sipa> the number of arguments is already checked
 87 2012-08-13 17:04:37 <sipa> sigScripts that push more than necessary are considered non-standard
 88 2012-08-13 17:06:48 <BlueMatt> gavininacar: PUSHDATA4 is easy - just make anything that uses PUSHDATA4 or PUSHDATA2 non-standard
 89 2012-08-13 17:07:14 <BlueMatt> eh...no PUSHDATA2 is ok
 90 2012-08-13 17:07:23 <sipa> for?
 91 2012-08-13 17:07:36 <BlueMatt> use in general, if you use PUSHDATA4 you did something wrong
 92 2012-08-13 17:07:43 <BlueMatt> (you cant push more than 520 bytes)
 93 2012-08-13 17:08:42 <sipa> but for the currently-valid standard scripts, no push can ever be more than 72 bytes, right?
 94 2012-08-13 17:08:54 <BlueMatt> well, that too
 95 2012-08-13 17:09:08 <BlueMatt> gavininacar: note that all those things only close some of the ways to make tx change hash but stay valid
 96 2012-08-13 17:09:31 <gavininacar> Closing some of them is better than changing none of them.
 97 2012-08-13 17:09:41 <gavininacar> The general principle is to remove degrees of freedom when possible
 98 2012-08-13 17:09:42 <BlueMatt> fair enough
 99 2012-08-13 17:09:52 <BlueMatt> also consider blocking putting extra bytes in a sig at pos n - 2
100 2012-08-13 17:10:10 <sipa> n-2 ?
101 2012-08-13 17:10:19 <BlueMatt> length - 2, sorry
102 2012-08-13 17:10:38 <gavininacar> You mean the extra OP_CHECKMULTISIG bug workaround push?
103 2012-08-13 17:10:50 <BlueMatt> no, I mean modifying the actual signature push
104 2012-08-13 17:11:06 <BlueMatt> you can throw any bytes you want at position length - 2 (or duplicate the last byte as many times as you want)
105 2012-08-13 17:11:06 <sipa> between the DER-encoded signature and the sigtype byte, right?
106 2012-08-13 17:11:10 <BlueMatt> yea
107 2012-08-13 17:11:28 <sipa> yeah that'd fall under checking the signature format
108 2012-08-13 17:11:30 <BlueMatt> oh, and you can change the sigtype byte to anything other than a valid value if its SIGHASH_ALL
109 2012-08-13 17:11:33 <gavininacar> Got it.  Yes, ack
110 2012-08-13 17:11:39 <BlueMatt> oh, was that mentioned? sorry
111 2012-08-13 17:11:59 <sipa> gavin mentioned checking the DER encoding; this is an extension of that
112 2012-08-13 17:14:07 <BlueMatt> that said, is it really worth it? its not a straightforward process - it adds the possibility of way more corner cases, and probably for nothing - the ability to change the hash of a tx will quite possibly persist
113 2012-08-13 17:15:38 <sipa> what other ways to change the tx without influencing the sighash do you know?
114 2012-08-13 17:15:55 <sipa> apart from using a weak sighash type