1 2014-03-28 00:00:38 <sipa> yes
2 2014-03-28 00:04:03 <maaku> ok thanks
3 2014-03-28 00:52:07 <pootietang> hey guys, we noticed that there are lots of fake transactions on the blockchain, is there an ongoing attack on the network?
4 2014-03-28 00:52:38 <lianj> pootietang: fake?
5 2014-03-28 00:52:39 <pootietang> I mean n the mempool, not the blockchain
6 2014-03-28 00:53:09 <pootietang> yes, large transactions
7 2014-03-28 00:53:40 <lianj> if they are in the mempool, they are checked. how can they be fake then?
8 2014-03-28 00:59:01 <pootietang> here's an example: http://pastebin.com/wpDHw98p
9 2014-03-28 01:03:51 <sipa> doesn't load
10 2014-03-28 01:04:01 <Luke-Jr> loads, but I see nothing odd
11 2014-03-28 01:04:20 <sipa> what do you mean by 'fake' anyway?
12 2014-03-28 01:06:25 <pootietang> sipa: I'm not sure if they are fake, did you see the one I juste put up?
13 2014-03-28 01:06:29 <sipa> no
14 2014-03-28 01:06:38 <midnightmagic> Who's 'we'?
15 2014-03-28 01:07:12 <sipa> but i don't even understamd what concept you may be referring to by 'fake'
16 2014-03-28 01:07:21 <sipa> bitcoin validates everything, so either it is invalid and ignored, or valid and accepted
17 2014-03-28 01:07:48 <lechuga_> shesek, olalonde: belated thx re: bip70
18 2014-03-28 01:07:48 <pootietang> looking through the inputs, they have the same txid, they seem forged
19 2014-03-28 01:07:57 <lechuga_> luke-jr: :)
20 2014-03-28 01:08:57 <sipa> pootietang: thry just consume many outouts created by the same transaction
21 2014-03-28 01:09:03 <sipa> pootietang: perfectly valid
22 2014-03-28 01:09:50 <sipa> *they, outputs
23 2014-03-28 01:10:20 <sipa> (it's unusual though; perhaps some dos attack)
24 2014-03-28 01:10:51 <sipa> but not invalid; just larger than necessary at most
25 2014-03-28 01:12:29 <LarsLarsen> There is really nothing preventing a ridonkulous number of outputs except the chance miners will drop it for sheer size right?
26 2014-03-28 01:12:29 <pootietang> sipa: ok thanks a lot
27 2014-03-28 01:13:17 <sipa> LarsLarsen: miners will demand a large fee
28 2014-03-28 01:13:48 <LarsLarsen> sipa: commensurate with its size, yeah, which is why sharing transaction fees in joined transactions wont really save you much at all.
29 2014-03-28 01:14:04 <LarsLarsen> sipa: just some overhead
30 2014-03-28 01:18:32 <pootietang> sipa: if that transaction is valid, why doesn't appear on blockchain.info?
31 2014-03-28 01:18:47 <pootietang> here's the hash: b6c57ca5418c2b0fc0e89fcaf8a8729f30f2fba608748048e0f44626d89ca38f
32 2014-03-28 01:19:20 <dgenr8> Is there an effort to make the standards for relaying the same as those for inclusion in a block?
33 2014-03-28 01:20:21 <LarsLarsen> There is no standard for inclusion in a block, other than being valid
34 2014-03-28 01:21:44 <dgenr8> Why not relay all valid?
35 2014-03-28 01:23:37 <dgenr8> txmall
36 2014-03-28 01:24:31 <dgenr8> but other than that ...
37 2014-03-28 01:26:08 <dgenr8> sorry if this is a faq. the two code sections are structured differently so its not obvious to me
38 2014-03-28 01:29:02 <kazcw> To limit the impact of any kind of maliciously-crafted or unusually costly non-standard script. Some potential types of bad transactions would do less damage if they're hard to get into blocks.
39 2014-03-28 01:30:16 <kazcw> s/blocks/blocks and mempools/
40 2014-03-28 01:35:30 <topynate> i've been wondering about that. the expensive operations are the cryptographic ones - wouldn't static analysis be enough to put an upper bound on how many of them a script could execute?
41 2014-03-28 01:38:50 <kazcw> there's an upper bound on sigops, but how sure are we that that's the only way the scripting language can be abused -- or will be able to be abused after seemingly innocuous future changes?
42 2014-03-28 01:40:02 <dgenr8> thanks for your time kazcw
43 2014-03-28 01:41:00 <topynate> well, we can't. not without formal verification, anyway. but how is making it harder to get something that devious into a block protective? once it was in a block every full node would end up executing it anyway.
44 2014-03-28 01:42:44 <topynate> incidentally, has anyone ever proposed formally verifying all or part of bitcoin core? it's comparable in LOC to another large formally verified program.
45 2014-03-28 01:43:39 <kazcw> It covers stuff that's problematic in the mempool. For stuff that's expensive in blocks, it helps because there are fewer miners who would need to update or to change their policies in order to prevent future such transactions being mined.
46 2014-03-28 01:59:25 <copumpkin> anyone know of bitcoin-qt compiled for ARM floating around? or do I have to build it myself
47 2014-03-28 02:05:12 <beethoven8201> ;;google "bitcoin-qt raspberry pi"
48 2014-03-28 02:05:12 <gribble> Tutorial how to run Bitcoin-qt on the Raspberry Pi » CoinCafe.net: <http://coincafe.net/2013/07/06/how-to-run-bitcoin-qt-on-the-raspberry-pi/>; Raspberry Pi ⢠View topic - Devcoin-qt and Bitcoin-qt @ rpi: <http://www.raspberrypi.org/phpBB3/viewtopic.php?t=21681&p=207323>; Bitcoin with Raspberry Pi - Bitcoin Forum: <https://bitcointalk.org/index.php?topic=191729.0>
49 2014-03-28 02:05:20 <beethoven8201> copumpkin: sorry that's the best I can do
50 2014-03-28 02:05:32 <copumpkin> yeah, I saw a few of those that just said to compile it
51 2014-03-28 02:05:34 <copumpkin> was hoping to avoid that, but am compiling now :)
52 2014-03-28 02:05:43 <copumpkin> not on a raspberry pi, at least
53 2014-03-28 02:06:00 <beethoven8201> copumpkin: I almost want to run an ARM emulator for the sole purpose of avoiding compilation on slow hardware
54 2014-03-28 02:06:19 <beethoven8201> but I guess that's what cross compiling is for
55 2014-03-28 02:06:20 <kazcw> that's what cross-compilation is for...
56 2014-03-28 02:06:23 <kazcw> heh
57 2014-03-28 02:06:24 <beethoven8201> yes
58 2014-03-28 02:06:29 <beethoven8201> jinx
59 2014-03-28 02:06:29 <beethoven8201> junx
60 2014-03-28 02:07:22 <beethoven8201> kazcw: in my dreams I do all the work in the vm and just copy it into an embedded device.. all libraries included
61 2014-03-28 02:07:33 <beethoven8201> cross compiling and deploying was hard last time I had to do it
62 2014-03-28 02:08:29 <copumpkin> let's see how fast this is
63 2014-03-28 02:08:49 <beethoven8201> copumpkin: if I may ask -- what are you deploying on... an android or something?
64 2014-03-28 02:10:36 <copumpkin> I bought myself one of these and figured I'd put bitcoin on it: http://utilite-computer.com/web/utilite-models
65 2014-03-28 02:12:11 <emowataji> nifty
66 2014-03-28 02:12:58 <maaku> adam3us gmaxwell sipa : here is a branch with soft-fork rules to add commitments outside of the coinbase, by means of a miner-can-spend output
67 2014-03-28 02:12:58 <maaku> https://github.com/maaku/bitcoin/tree/coinbase-commitments
68 2014-03-28 02:13:14 <maaku> I need to write a draft BIP for the mailing list before I'll turn it into a pull request
69 2014-03-28 02:13:17 <maaku> but comments are welcome
70 2014-03-28 02:14:08 <maaku> (this would be the mechanism for putting block header commitments for spv proofs, or utxo commitments into a block, in a way that you don't have to include the coinbase transaction or an ugly midstate)
71 2014-03-28 02:15:40 <emowataji> copumpkin: which one did you get?
72 2014-03-28 02:17:55 <copumpkin> rightmost
73 2014-03-28 02:18:04 <copumpkin> just plugged it in an hour or so ago
74 2014-03-28 02:20:19 <emowataji> nice. tempting to get one haha!
75 2014-03-28 02:25:24 <copumpkin> yup :)
76 2014-03-28 02:25:30 <copumpkin> it's not without hiccups, but it's a neat little piece of hardware
77 2014-03-28 03:27:33 <topynate> are the conditions for the serialized script of a BIP16 spend to be standard, exactly the same as those for other kinds of scripts?
78 2014-03-28 03:27:36 <topynate> so for instance if i made a 3-of-4 P2SH transaction, how easy would it be to spend it?
79 2014-03-28 03:33:38 <sipa> topynate: trivial
80 2014-03-28 03:34:03 <sipa> topynate: all the same standardness rules apply, except for the max 3 keys limitation on muktisig
81 2014-03-28 03:35:54 <topynate> interesting. could BIP16 be updated with that exception?
82 2014-03-28 03:45:38 <charlefoo> anyone here familiar with BIP 32?
83 2014-03-28 03:48:21 <charlefoo> I have question about BIP 32
84 2014-03-28 03:52:17 <kazcw> don't ask to ask, just ask
85 2014-03-28 03:59:31 <charliefr> can someone explain the idea/importance of hardened keys in BIP 32?
86 2014-03-28 04:45:14 <brettbrett>
87 2014-03-28 05:15:44 <brettbrett> arise
88 2014-03-28 05:58:10 <maaku> topynate: the 3 key limitation is a default relay rule, not a protocol rule
89 2014-03-28 05:59:35 <topynate> maaku: is standardness not a suitable topic for inclusion in a BIP?
90 2014-03-28 06:00:41 <topynate> maaku: i mean, it should be documented somewhere, it seems like the most logical place is with the associated feature
91 2014-03-28 06:03:02 <Burrito> charliefr, I think for hardened keys, parent public keys cannot be used to calculate child public keys. Also, "Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is easy to find kpar."
92 2014-03-28 06:03:02 <Burrito> So in the event of an exposed parent extended public key and one of its hardened child parent keys, it is hard to find the parent of that extended private key.
93 2014-03-28 06:03:03 <Burrito> The "Security" section of the proposal is more bullet-pointed outline about what is and isn't possible with hardened/non-hardened keys: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security
94 2014-03-28 06:03:54 <topynate> maaku: in fact it _is_ documented in BIP16, just not accurately - which is why i submitted a pull req
95 2014-03-28 06:04:38 <charliefr> "Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is easy to find kpar." How exactly?
96 2014-03-28 06:04:49 <charliefr> slash where can i find the details on that?
97 2014-03-28 06:06:18 <Burrito> charliefr, Like this, I gather. https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/deterministic.py#L35 -- I don't think that code module yet accounts for hardened keys at all, it appears new in the proposal.
98 2014-03-28 06:06:28 <Burrito> Line 35 of that file
99 2014-03-28 06:07:52 <Burrito> The function it refers to at the end is here https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/main.py#L261
100 2014-03-28 06:08:40 <Burrito> charliefr, rather than line 35 in that first file, look at line 118 (as well)
101 2014-03-28 06:09:40 <neotap> hi can some one help me compile bitcoin 0.9.0 on linux, every time i try to makefile i get " *** No rule to make target `makefile.unix'"
102 2014-03-28 06:10:15 <Luke-Jr> neotap: #bitcoin (or just follow any standard Linux build instructions)
103 2014-03-28 06:11:48 <neotap> i followed the standard linux build instruction. over at the doc section.
104 2014-03-28 06:13:11 <Luke-Jr> neotap: this is #bitcoin-dev, for development discussion. if you want support, you need to ask somewhere else
105 2014-03-28 06:14:37 <maaku> topynate: no, the IsStandard() test is a quirky feature of Bitcoin Core . by its very nature it is NOT something which other implementations should be striving for compatability with
106 2014-03-28 06:15:59 <maaku> relay policy is just that - a policy decision. just like transaction fees it is not something which should be considered "standard", which is what the BIP process is about
107 2014-03-28 06:17:21 <maaku> although given the importance of Bitcoin Core it is fine to mention off-handedly "oh by the way, at the time this is written Bitcoin Core doesn't relay or mine scripts with more than 3 public keys in a CHECKMULTISIG"
108 2014-03-28 06:17:30 <maaku> but it must be very clear that this is a default policy choice, not a validation or protocol rule
109 2014-03-28 06:19:53 <maaku> ACTION thinks that IsStandard should be renamed MeetsLocalPolicy or something like that
110 2014-03-28 06:20:09 <topynate> anything to draw attention away from it? (kidding!)
111 2014-03-28 06:29:24 <topynate> Luke-Jr, maaku: BIP 11 is explicitly focused on adding a new standard transaction type. you could argue that creating a policy on what should be a standard type is valuable, but the distinction between a standard for relay policies and the actual relay policies is splitting hairs, i feel
112 2014-03-28 06:29:40 <dcousens> for compressed public keys, is it expected that the resultant address should verify against a message signed by its uncompressed equivalent?
113 2014-03-28 06:30:10 <Luke-Jr> topynate: standard transactions != relayed transactions (IsStandard)
114 2014-03-28 06:31:16 <topynate> given that the code path for BIP16 redeeming scripts never goes through IsStandard, I don't disagree with you
115 2014-03-28 06:31:42 <Luke-Jr> pretty sure they do, actually
116 2014-03-28 06:32:07 <Luke-Jr> yep
117 2014-03-28 06:32:42 <Luke-Jr> CTransaction::AreInputsStandard
118 2014-03-28 06:32:49 <Luke-Jr> under if (whichType == TX_SCRIPTHASH)
119 2014-03-28 06:33:25 <topynate> it calls Solver and checks that it doesn't return false
120 2014-03-28 06:33:50 <topynate> but that doesn't cover the M >=3 or N >= 3 case, which is handled specially in IsStandard
121 2014-03-28 06:40:18 <dcousens> Luke-Jr: any ideas on whether bitcoind checks (both) the uncompressed/compressed version of an address when verifying a signed message?
122 2014-03-28 06:40:18 <Luke-Jr> dcousens: not sure.
123 2014-03-28 06:40:19 <Luke-Jr> topynate: it appears you are right, but again unrelated to the BIP
124 2014-03-28 06:40:20 <Luke-Jr> topynate: bare multisig will probably be !IsStandard soon
125 2014-03-28 06:41:16 <topynate> um. shouldn't there be a BIP for that? seeing as it would otherwise put Bitcoin Core out of compliance with an accepted BIP
126 2014-03-28 06:43:11 <Luke-Jr> topynate: no, and it wouldn't.
127 2014-03-28 06:43:20 <Luke-Jr> IsStandard is not BIP material
128 2014-03-28 06:44:04 <topynate> i'm not talking about IsStandard, i'm talking about standard transactions :)
129 2014-03-28 06:44:25 <Luke-Jr> I was talking about IsStandard, obviously. That's why I said it.
130 2014-03-28 06:46:20 <topynate> if there's an accepted BIP that proposes a multisig as a standard transaction type - which there is - and if Bitcoin Core doesn't relay those transactions, then how is Bitcoin core not failing to comply with an accepted BIP?
131 2014-03-28 06:47:08 <Luke-Jr> topynate: relay policy is not something decided by BIPs
132 2014-03-28 06:47:25 <Luke-Jr> the BIP just says what the standard way to make such transactions is
133 2014-03-28 06:47:43 <Luke-Jr> it doesn't say people are obliged to forward them
134 2014-03-28 06:49:25 <Luke-Jr> on that note, I wonder if we should just rewrite IsStandard to use boost::regex or something
135 2014-03-28 06:50:04 <Luke-Jr> otoh, not sure regex is user-friendly
136 2014-03-28 06:50:19 <Luke-Jr> the current matching engine might be better, parsed from a string
137 2014-03-28 06:52:20 <topynate> luke-jr: i think saying that BIP 11 just proposed a standard way of doing a multisig transaction is stretching it. but i don't want to get into hermeneutics
138 2014-03-28 07:30:18 <dcousens> Luke-Jr: sorry, do you think a signed message should verify against the compressed and uncompressed address against which it is being checked?
139 2014-03-28 07:30:44 <dcousens> (assume they provide the compressed address, but the message is verified against the uncompressed equivalent)
140 2014-03-28 07:30:44 <dcousens> message is signed*
141 2014-03-28 07:31:43 <Luke-Jr> dcousens: I suppose it's unavoidable
142 2014-03-28 07:32:53 <dcousens> I mean, in the end, the pubkey is carried in the signature itself, you're just checking that that pubkey matches the hashed address, if that hashed address was the hash of the compressed pubkey, then it'll fail, even though its correct
143 2014-03-28 07:33:02 <dcousens> (I know you know this, just saying for others)
144 2014-03-28 07:33:30 <Luke-Jr> oh? I didn't know it failed
145 2014-03-28 07:33:56 <dcousens> I've only read the code, but I'll need to test it before I assert that
146 2014-03-28 07:34:43 <dcousens> But my impression is (the code is simple) it will fail
147 2014-03-28 08:12:28 <ferdiando> The limit that only 520 bytes may be pushed to the stack...Is that an inherent limit? Or part of the reference implementation that can be bypassed?
148 2014-03-28 08:28:42 <ferdiando> thanks
149 2014-03-28 08:28:42 <Luke-Jr> no
150 2014-03-28 09:13:07 <serphacker> hi guys, I send btc to an address which is not in my wallet via txY. I want to know if txY has been spent. Can I achieve that via RPC and bitcoind ? If i do gettransaction txY I only know conf number but I don't know if txY was spent in another transaction.
151 2014-03-28 09:18:36 <Luke-Jr> serphacker: what you're describing there doesn't sound like something useful outside of forensics..
152 2014-03-28 09:19:55 <Luke-Jr> serphacker: what is your goal?
153 2014-03-28 09:20:27 <serphacker> Luke-Jr: my goal is to know if the bitcoin sent to one address has been spent
154 2014-03-28 09:21:05 <serphacker> that's why I want to know if tx was used in another tx
155 2014-03-28 09:21:14 <wumpus> the address index patch could help you there (or another way of building output-based indexes...)
156 2014-03-28 09:21:24 <Luke-Jr> serphacker: bitcoins are fungible. that UTXO could have been spent by someone entirely unrelated to the person who receives with the address you sent to.
157 2014-03-28 09:22:37 <serphacker> Luke-Jr: I know that
158 2014-03-28 09:23:37 <Luke-Jr> serphacker: forensics require indexes bitcoind doesn't maintain; as wumpus said, one of those has a patch, but not sure if that will be of use to you
159 2014-03-28 09:24:04 <Luke-Jr> I still have no idea what you're trying to accomplish either :p
160 2014-03-28 09:25:02 <serphacker> wumpus: do you have a link to this patch
161 2014-03-28 09:28:21 <wumpus> https://github.com/bitcoin/bitcoin/pull/3652
162 2014-03-28 09:29:24 <serphacker> wumpus: thanks
163 2014-03-28 09:30:48 <arubi> whoa that's useful..
164 2014-03-28 09:31:37 <serphacker> indeed wumpus transaction index by address may help me
165 2014-03-28 10:25:10 <wumpus> I may pick up the watchonly patch if wangbus doesn't get around to it
166 2014-03-28 10:46:39 <serphacker> I can't create two instance of bitcoind using the same "regtest" right ?
167 2014-03-28 10:48:24 <wumpus> sure you can, that's what the qa tests do
168 2014-03-28 10:48:37 <wumpus> and datadir
169 2014-03-28 10:48:37 <wumpus> just make sure that they have their own RPC and P2P ports
170 2014-03-28 10:49:34 <serphacker> wumpus: I connect them together using addnode ?
171 2014-03-28 10:49:40 <wumpus> yes
172 2014-03-28 10:49:43 <sipa> using -connect
173 2014-03-28 10:51:07 <serphacker> ha right, I misconfigured my second node connecting to wrong listening port