1 2015-11-28 00:16:01 <Diablo-D3> gmaxwell: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c3fc7ac9a0b978ee8538058743d21feef25f7b33
2 2015-11-28 04:30:01 <jtoomim> darthandroid are you on?
3 2015-11-28 04:30:18 <jtoomim> oh grumble, did it again. wrong channel, sorry.
4 2015-11-28 06:35:40 <alex__> hi
5 2015-11-28 09:55:14 <aschildbach> Hi guys, did the dust level recently change?
6 2015-11-28 09:57:33 <aschildbach> I see reject messages like this one: Received Reject: tx xxx for reason 'dust' (64)
7 2015-11-28 09:58:18 <sipa> 0.11.2 temporarily has a higher relay fee, to combat the mempool bloating
8 2015-11-28 09:58:29 <sipa> 0.12 will have dynamic relay fee
9 2015-11-28 09:58:31 <aj> (0.11.1 has the higher relay fee too)
10 2015-11-28 09:58:41 <aschildbach> Dust, not fee
11 2015-11-28 09:58:50 <aj> dust is calculated based on relay fee
12 2015-11-28 09:59:04 <aschildbach> The smallest output of that transaction is 0.00000655 BTC -- not enough?
13 2015-11-28 09:59:10 <sipa> dust is defined as having outputs that cost at least 1/3 of their value to spend
14 2015-11-28 09:59:27 <aschildbach> It used to be 546 sat.
15 2015-11-28 09:59:45 <sipa> 546 sat at 1000 sat/kByte relay fee
16 2015-11-28 10:00:35 <aj> yeah, it's now 5000 sat/kB so 0.00002730 dust limit aiui
17 2015-11-28 10:01:05 <aschildbach> So how many satoshis is it now exactly?
18 2015-11-28 10:01:21 <aschildbach> (You should probably tell wallets as they need to adapt their code)
19 2015-11-28 10:01:29 <aschildbach> wallet authors
20 2015-11-28 10:01:33 <sipa> aschildbach: you shouldn't assume it's a constant
21 2015-11-28 10:02:15 <aschildbach> Well it's currently defined as a constant in bitcoinj
22 2015-11-28 10:02:17 <sipa> how do you estimate what fee to pay?
23 2015-11-28 10:02:30 <aschildbach> Fee is a constant too
24 2015-11-28 10:02:42 <sipa> ouch
25 2015-11-28 10:02:55 <aschildbach> constant per KB of course
26 2015-11-28 10:03:08 <sipa> i guess that's possible as long as you can easily push out updates
27 2015-11-28 10:03:31 <aschildbach> Fee shouldn't go up anyway, so that's no problem.
28 2015-11-28 10:04:00 <sipa> well it certainly can gonup if there is more transaction demamd
29 2015-11-28 10:04:05 <sipa> *go up
30 2015-11-28 10:04:23 <aschildbach> If that "go up" is persistent, users will go away.
31 2015-11-28 10:04:42 <aschildbach> So it can't go up higher than "perceived free".
32 2015-11-28 10:05:26 <aschildbach> But back to my question: What's the exact dust amount in sat.?
33 2015-11-28 10:06:00 <sipa> 1/3 of the minimum relay fee per byte, times the size to spend it
34 2015-11-28 10:06:24 <sipa> the minimum relay fee per byte is configurable, and will as of 0.12 by dynamic
35 2015-11-28 10:06:52 <sipa> in 0.11.1 it is by default 5 satoshi per byte
36 2015-11-28 10:07:10 <sipa> corresponding to a dust limit of around 2730
37 2015-11-28 10:07:15 <aschildbach> So there is no "per KB" rule any more?
38 2015-11-28 10:07:35 <sipa> 5000 per KB = 5 per byte...
39 2015-11-28 10:08:40 <aschildbach> It used to be per "started KB", no? So there is a difference between these two
40 2015-11-28 10:09:02 <sipa> not for a very long time
41 2015-11-28 10:09:13 <aschildbach> How much is "very long"?
42 2015-11-28 10:09:19 <sipa> years at least
43 2015-11-28 10:09:58 <aschildbach> That's weird, didn't we lower the fee from 0.1 mBTC to 0.01 mBTC per "started KB" just 1.5 years ago?
44 2015-11-28 10:10:17 <sipa> per kilobyte, not per started kilobyte
45 2015-11-28 10:10:26 <aschildbach> ok didn't know that
46 2015-11-28 10:11:02 <aschildbach> But good to know kilobytes don't play a role any more. We should adapt the bitcoinj code for that.
47 2015-11-28 10:11:03 <sipa> aschildbach: i wasn't aware that anyone still used that rule, sorry
48 2015-11-28 10:11:26 <sipa> it also doesn't make sense economically, as miners optimize per byte of storage
49 2015-11-28 10:11:28 <aschildbach> Bitcoinj is more or less built on the bitcoind 0.7 rules or so...
50 2015-11-28 10:11:50 <aschildbach> Sure, that's what I always thought. Per KB just doesn't make any sense
51 2015-11-28 10:13:27 <sipa> in 0.12, the mempool will be limited by increasing the relay fee when it grows too big
52 2015-11-28 10:14:01 <sipa> in practice, it seems that will result in lower relay fees than 0.11.1
53 2015-11-28 10:14:09 <aschildbach> I would make more sense to increase the block size instead.
54 2015-11-28 10:14:18 <aschildbach> Because otherwise the users run away.
55 2015-11-28 10:14:54 <sipa> or some types of transactions become uneconomical, and others take over
56 2015-11-28 10:16:07 <aschildbach> Well it's not going to happen in a clean way. The market is not transparent enough for users to decide what kind of transactions they can do and which they can't.
57 2015-11-28 10:16:32 <aschildbach> Unless Bitcoin degrades into an Inter-Banking thing only.
58 2015-11-28 10:16:38 <sipa> please
59 2015-11-28 10:16:55 <sipa> i understand your view, but there are a lot of concerns here
60 2015-11-28 10:18:26 <aschildbach> Sure
61 2015-11-28 15:41:39 <SomeT> hi, is there a tutorial on how to modify bitcoin from the source code?
62 2015-11-28 15:41:48 <SomeT> so many files that I have no idea where to start
63 2015-11-28 15:55:44 <gijensen> SomeT: This sounds like a #Bitcoin question
64 2015-11-28 17:02:26 <CBP_xneutron> yo!
65 2015-11-28 17:35:19 <Genitrus_> ?
66 2015-11-28 17:35:19 <Genitrus_> can all JSON-PRC commands be done with the JSON HTTP bitcoin server
67 2015-11-28 17:37:59 <sipa> Genitrus_: your question is a bit confused, but I think the answer is yes
68 2015-11-28 17:38:12 <sipa> JSON-RPC is by definition done over HTTP, because that's how the protocol is defined
69 2015-11-28 17:38:24 <Genitrus_> sipa thanks. sorry for the confusion, it's likely my diction...learning more of these terms
70 2015-11-28 17:38:28 <Genitrus_> ooooh
71 2015-11-28 17:38:32 <Genitrus_> sweet. thanks sipa :)
72 2015-11-28 17:38:43 <Genitrus_> i'm deploying a full bitcoin node
73 2015-11-28 17:40:54 <Genitrus_> https://bitnodes.21.co/ sveeeeet
74 2015-11-28 19:26:08 <btcdrak> sipa: gmaxwell: petertodd: rusty: could you please check the versionbits BIP9 PR which adds the start time to softfork deployment https://github.com/bitcoin/bips/pull/219/files
75 2015-11-28 19:26:42 <sipa> i'm in favor, but it seems rusty is against it
76 2015-11-28 19:31:56 <btcdrak> sipa: ok will check with him, but I thought this was brought up recently in the context of BIP65 where f2pool began deployment before an official release meaning no-nodes would have upgraded. I thought that was the case we're trying to deal with.
77 2015-11-28 19:32:59 <btcdrak> sipa: I'll drop rusty a note, thanks.
78 2015-11-28 19:33:12 <sipa> btcdrak: rusty commented on the PR, and suggests an alternative (a suggestion to not advertize until a flag data, but not make the consensus logic depend on it)
79 2015-11-28 19:33:47 <btcdrak> s/data/date?
80 2015-11-28 19:34:16 <sipa> yes
81 2015-11-28 19:34:40 <btcdrak> sipa: I believe this is what CodeShark means in the text that we dont start counting the bit until a flag date.
82 2015-11-28 19:34:59 <btcdrak> "The '''deploytime''' specifies a time at which the bit starts counting towards lock-in."
83 2015-11-28 19:35:10 <sipa> no
84 2015-11-28 19:35:33 <btcdrak> oh I see, it's still consensus.
85 2015-11-28 20:03:51 <btcdrak> so it looks like just Antpool, 21 and Eligius are left to upgrade for v4 blocks :)
86 2015-11-28 20:04:10 <sipa> wow, 55% :s
87 2015-11-28 20:07:25 <Luke-Jr> btcdrak: Eligius is pretty much on v4, just not making them with the header version number changed yet
88 2015-11-28 20:07:56 <Luke-Jr> that'll probably be switched today
89 2015-11-28 20:08:01 <btcdrak> Luke-Jr: ah, thanks for clarifying.
90 2015-11-28 20:09:59 <btcdrak> I saw bitcoinj got updated as well, so things might go more smoothly for their downstream this time...
91 2015-11-28 22:16:07 <Luke-Jr> btcdrak: want to act on maaku's comments before I merge bips#245 ?
92 2015-11-28 22:16:27 <btcdrak> Luke-Jr: yes I was just going to do that now thanks!
93 2015-11-28 22:16:32 <btcdrak> 1 sec
94 2015-11-28 22:32:59 <btcdrak> Luke-Jr: should be good to go now thanks!
95 2015-11-28 22:34:43 <Luke-Jr> k
96 2015-11-28 22:42:17 <god[> hello, someone knows how to sign transaction with different inputs addresses using nodejs bitcoinjs-lib ? i get this => Error: No, this would invalidate signatures
97 2015-11-28 22:43:25 <Luke-Jr> god[: inputs are not addresses
98 2015-11-28 22:43:53 <god[> i know, i mean inputs from differents addresses
99 2015-11-28 22:44:00 <Luke-Jr> inputs are also not from addresses
100 2015-11-28 22:44:11 <god[> omaigar
101 2015-11-28 22:45:10 <god[> i have to sign transaction that have multiple inputs from different addresses with all those private keys
102 2015-11-28 22:45:20 <god[> but i get error
103 2015-11-28 22:51:06 <god[> http://paste.ofcode.org/Dw94z8CLVjyvd95N6aGQDY
104 2015-11-28 22:51:36 <god[> is something wrong with the order i add inputs and sign ?
105 2015-11-28 23:53:34 <god[> can someone please tell me why this transaction is rejected by network? http://paste.ofcode.org/34nKjT4AnFW2D7jm8HELYbW
106 2015-11-28 23:57:30 <gmaxwell> god[: what does your node log when you try to sendrawtransaction it?
107 2015-11-28 23:58:00 <god[> sorry i signed it with wrong private key
108 2015-11-28 23:58:02 <god[> thanks