1 2014-05-06 00:36:41 <dgenr8> ACTION wonders how it is possible for 2 transactions to differ by "just fees"
2 2014-05-06 00:39:43 <petertodd> dgenr8: the outputs can be the same with additional inputs
3 2014-05-06 00:39:49 <dgenr8> child-pays-for-parent seems an excellent way to bump fees. it's not a respend, and it would still work if 1st xactn is confirmed
4 2014-05-06 00:41:00 <petertodd> it's also more expensive and to make it work well you need fairly complex network changes
5 2014-05-06 00:42:44 <dgenr8> more expensive how?
6 2014-05-06 00:43:17 <petertodd> dgenr8: work out the total fees needed to pay for a child-pays-for-parent vs. a replacement
7 2014-05-06 00:51:11 <olalonde> 23
8 2014-05-06 00:52:12 <petertodd> olalonde: with anyonecanpay, if you can change txouts significantly less
9 2014-05-06 01:00:39 <dgenr8> looking at your changes to AcceptToMemoryPool. all mempool txes that have at least one of the same inputs as tx are replaced. i don't see an attempt to figure out if the overall output set is the same.
10 2014-05-06 01:02:11 <petertodd> dgenr8: there is no attempt to do that at all
11 2014-05-06 01:03:33 <dgenr8> sounds like i could double-spend somebody pretty good then
12 2014-05-06 01:04:10 <petertodd> dgenr8: see https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
13 2014-05-06 01:07:26 <dgenr8> is that a demonstration of how to double-spend the changes to AcceptToMemoryPool? i don't follow
14 2014-05-06 01:08:07 <petertodd> dgenr8: try it out and see; you'll need a local node running https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
15 2014-05-06 01:08:52 <mr_burdell> is transaction signing and message signing done the same way?
16 2014-05-06 01:09:34 <mr_burdell> and why do transactions require the pubkey to be included, however signed messages can be used to calculate the pubkey?
17 2014-05-06 01:14:47 <sipa> mr_burdell: message signing uses different technology, that was presumably unknown when satoshi designed bitcoin's scripting language
18 2014-05-06 01:15:06 <mr_burdell> ah, ok... that makes sense
19 2014-05-06 01:15:51 <mr_burdell> are there any altcoins that have tried to implement that?
20 2014-05-06 01:15:59 <sipa> lol
21 2014-05-06 01:16:29 <mr_burdell> no actual crypto devs working on altcoins i guess
22 2014-05-06 01:16:40 <gmaxwell> Pretty much.
23 2014-05-06 01:16:41 <petertodd> mr_burdell: there's hardly any actual crypto devs on bitcoin...
24 2014-05-06 01:17:24 <gmaxwell> (though not entirely; there is an altcoin that uses a rather clever ring signature system for anonymity; ... amusingly, it's not one of the altcoins you've probably heard of)
25 2014-05-06 01:22:14 <dgenr8> petertodd: i'm flummoxed. you allow a tx to replace all others with 1+ matching utxo, as long as the fees are more, but it doesn't have to pay anyone who was being paid before? smells like free coffee
26 2014-05-06 01:22:49 <petertodd> dgenr8: unconfirmed transactions are unsafe, deal with it
27 2014-05-06 01:23:04 <petertodd> dgenr8: did you try the doublespend tool out? note how well it works even without miner support
28 2014-05-06 01:23:31 <dgenr8> the status quo is much safer than this change
29 2014-05-06 01:23:57 <petertodd> dgenr8: like I said, did you actually try it?
30 2014-05-06 01:26:08 <dgenr8> i think i can stipulate to the claim that your doublespend.py tool creates successful doublespends against the AcceptToMempool changes
31 2014-05-06 01:26:33 <petertodd> no, I mean, try it out and see if the double-spend gets mined, you may be surprised
32 2014-05-06 01:26:50 <petertodd> fwiw I'm running just four nodes with that patch applied - nothing special
33 2014-05-06 01:31:09 <dgenr8> petertodd: why are you running nodes with that patch applied?
34 2014-05-06 01:33:42 <petertodd> dgenr8: because I believe bitcoin would be better if we stop pretending that zeroconf is secure, and secondly on a technical level replace-by-fee behavior is extremely useful
35 2014-05-06 01:33:58 <petertodd> dgenr8: again, have you actually tried my script? like I keep saying, double-spending is already very easy
36 2014-05-06 01:35:28 <dgenr8> nobody is pretending 0-conf is secure. respends are happening and costing people money as we speak. and i don't see why you need to make it worse to prove it.
37 2014-05-06 01:36:12 <petertodd> well, if it's not secure, then we might as well bite the bullet and do something else to get the same effects...
38 2014-05-06 01:39:18 <petertodd> dgenr8: I notice you still haven't actually tried said tool...
39 2014-05-06 01:40:33 <dgenr8> petertodd: I'll try it. Also I would really appreciate your thoughts on whether we could reduce the insecure period in 0-conf by 10 - 100x with a consensus rule arount tx receipt time differences
40 2014-05-06 01:41:55 <petertodd> dgenr8: consensus doesn't work that way - you need a "detect and punish" system, which is what replace-by-fee scorched-earth intends to do, similarly fidelity bond schemes. also trusted third-parties possible, and they don't have to be very trusted. and finally, there's micropayment schemes and pre-signing schemes like the one I wrote up for mycelium wallet
41 2014-05-06 01:42:11 <petertodd> or you can stick your head in the sand and wish bitcoin was more like paypal...
42 2014-05-06 02:39:25 <efynn> Hi... Could you point me a full list of rpc json calls to interact with the blockchain? I want, for instance, list all transactions done in some address
43 2014-05-06 02:44:34 <pigeons> bitcoin-cli help
44 2014-05-06 02:57:04 <efynn> pigeons: I read those, do you know of any method to get a list of transactions that aren't mine?
45 2014-05-06 03:01:29 <pigeons> not a list. if you have the transactionid you get getrawtransaction to see one that isnt yours. you might need txindex enabled
46 2014-05-06 03:02:28 <pigeons> i guess i would look at a watch-only patch and add the address
47 2014-05-06 03:13:34 <efynn> What I need is like a listtransactions with an address parameter, so I can list all transactions involved with the address
48 2014-05-06 03:42:55 <efynn> https://bitcoin.stackexchange.com/questions/14170/is-there-a-json-rpc-method-for-retrieving-all-transactions-for-a-given-address
49 2014-05-06 03:43:11 <efynn> so there isn't any, I would have to implement my own =/
50 2014-05-06 03:45:05 <mr_burdell> efynn: depends what you're trying to do, but there are other tools that implement that feature
51 2014-05-06 03:45:19 <mr_burdell> electrum, bitcore, sx/obelisk
52 2014-05-06 03:46:28 <gmaxwell> efynn: generally that sort of thing should be avoided if at all possible, its inherently non-scalable, and requires gigabytes of additional indexes. (as well as being incompatible with pruning, meaning another 16gigabytes currently over the baseline requirements for block validation)
53 2014-05-06 03:51:48 <mr_burdell> gmaxwell: does txindex=1 turn off the pruning you're talking about or is that something else?
54 2014-05-06 03:54:07 <gmaxwell> mr_burdell: No, because we don't yet expose an option to turn it on. But depending on being able to do those kinds of lookups mean you could never have pruning.
55 2014-05-06 03:54:28 <gmaxwell> (so the marginal cost of using your node in that way is currently not obvious)
56 2014-05-06 03:55:49 <efynn> gmaxwell: The system I'm creating requires that to be secure, I can't blindly trust in blockchain.info, can I?!
57 2014-05-06 03:56:13 <mr_burdell> efynn: you can use other tools on top of bitcoind and still get that functionality
58 2014-05-06 03:56:23 <gmaxwell> efynn: I'm not sure where you extracted the idea that I'd ever suggest bc.i.
59 2014-05-06 03:56:26 <mr_burdell> without trusting anything but your own node
60 2014-05-06 03:56:39 <gmaxwell> efynn: rather you should think about what you're doing and consider if you really need that functionality.
61 2014-05-06 03:57:54 <dgenr8> petertodd: thank you for your thoughts, although I wish you were more specific.
62 2014-05-06 04:00:47 <efynn> thanks mr_burdell, I'll check other tools
63 2014-05-06 04:05:54 <efynn> gmaxwell: sorry about my misinterpretation, I'll rethink the system.
64 2014-05-06 06:56:47 <lalala> hello?
65 2014-05-06 06:57:44 <lalala> hello?
66 2014-05-06 06:58:20 <lalala> hi @smash?
67 2014-05-06 06:58:50 <smash> hi - am I in trouble?
68 2014-05-06 07:03:36 <lalala> @smash, no i'm just checking if people are active here
69 2014-05-06 07:04:17 <lalala> just wanna ask those having experience with bitcoin development
70 2014-05-06 07:05:13 <smash> oic, I'm no developer. just lurking
71 2014-05-06 07:06:18 <smash> I only come here to live vicariously :)
72 2014-05-06 07:08:37 <justanotheruser> lalala: don't ask to ask, just ask
73 2014-05-06 07:23:12 <lalala> is there an available api so i can implement a mobile app that uses bitcoin?
74 2014-05-06 07:23:47 <Luke-Jr> lalala: uh, you realise bitcoin is p2p, right?
75 2014-05-06 07:23:49 <sipa> if you want to rely on a centralized service, sure
76 2014-05-06 07:23:58 <sipa> but that's sort-of against bitcoin's spirit
77 2014-05-06 07:24:19 <sipa> (also, i doubt you'll get help for doing that here)
78 2014-05-06 07:24:26 <Luke-Jr> or maybe he wants BitcoinJ
79 2014-05-06 07:24:44 <Luke-Jr> guess he didn't say web api
80 2014-05-06 07:26:10 <lalala> i'm still researching about bitcoin. still a noob, actually.
81 2014-05-06 07:26:39 <lalala> i found third parties like coinbase.com who has available web api, but as much as possible we don't want to be dependent on third parties
82 2014-05-06 07:27:06 <sipa> if you don't want to depend on third parties, you'll need to speak the p2p protocol yourself
83 2014-05-06 07:27:19 <sipa> one way to do so on mobile is using BitcoinJ
84 2014-05-06 07:27:32 <lalala> oh i see
85 2014-05-06 07:28:26 <lalala> but looks like BitcoinJ is for java only. we're trying on obj-c/ios
86 2014-05-06 07:28:39 <Luke-Jr> lalala: Apple doesn't allow Bitcoin
87 2014-05-06 07:29:39 <lalala> yeah, i've read about the news. we're still experimenting though. maybe useful in the future
88 2014-05-06 10:23:01 <survic> will there be another Bitcoin release updating past openssl 1.0.1g?
89 2014-05-06 10:23:18 <wumpus> that's what 0.9.1 did
90 2014-05-06 10:23:40 <survic> I thought 0.9.1 updated *to* 1.0.1g?
91 2014-05-06 10:23:46 <wumpus> right
92 2014-05-06 10:23:56 <survic> CVE-2014-0198 affects 1.0.1g
93 2014-05-06 10:24:02 <wumpus> don't tell me that there was another critical issue with openssl?
94 2014-05-06 10:24:25 <t7> heh
95 2014-05-06 10:24:30 <survic> null pointer dereference > crash.
96 2014-05-06 10:24:36 <t7> lovely DOS attack
97 2014-05-06 10:25:02 <Apocalyptic> openssl is starting to look like sendmail back in the days
98 2014-05-06 10:25:03 <wumpus> looks pretty pointless in the case of bitcoin, only hosts already in rpcallow could do it *if* you have rpcssl enabled
99 2014-05-06 10:25:31 <survic> not unreasonable to think that there's nodes with * allowip
100 2014-05-06 10:25:37 <wumpus> if your host is not in the rpcallow list it slams the door on you before even calling OpenSSL
101 2014-05-06 10:25:44 <t7> survic: thats really bad practice
102 2014-05-06 10:25:52 <survic> not an emergency scramble thing like 0.9.1, but nice to update to that for 0.9.2
103 2014-05-06 10:26:10 <wumpus> it would make sense to upgrade openssl for next release, but it is not reason enough to do an urgent release
104 2014-05-06 10:26:27 <survic> t7: so are brain wallets, but they're in common use. people do stupid thing to "get stuff working". I bet there's solo miners that have done that.
105 2014-05-06 10:30:11 <survic> google: site:pastebin.com "rpcallowip=" "rpcssl=1"
106 2014-05-06 10:31:57 <survic> oh that's nice, there's bits of malware in those results for finding and emptying people's wallet.dat.