1 2014-09-08 01:04:54 <Delta706> I am interested in the idea of bitcoin pledges
2 2014-09-08 01:07:20 <justanotheruser> Delta706: what about it?
3 2014-09-08 01:07:29 <petertodd> michagogo: well, get wallet software that will never spend that dust - problem solved
4 2014-09-08 01:08:00 <petertodd> michagogo: remember that spending the dust does *not* make you more private, and at worst will reveal further information about you
5 2014-09-08 01:08:23 <Delta706> suppose I want to pledge some money to a project, on condition that enough people sign up
6 2014-09-08 01:09:43 <Delta706> so I could sign some pledge with my private key, indicating some trusted person can invoke the pledge
7 2014-09-08 01:10:17 <justanotheruser> Delta706: you could also do a large coinjoin between all pledgers
8 2014-09-08 01:10:45 <Delta706> ah, what is that?
9 2014-09-08 01:11:04 <Luke-Jr> Delta706: just sign a transaction paying N BTC to the recipient, but only having <N BTC as an input
10 2014-09-08 01:11:19 <Luke-Jr> Delta706: then have all contributors do the same, and anyone can combine them into a single transaction
11 2014-09-08 01:12:06 <Delta706> anyone? even someone not trusted?
12 2014-09-08 01:12:22 <poutine> Can't you do with an ANYONECANPAY transaction?
13 2014-09-08 01:12:54 <Luke-Jr> Delta706: there is no need for a trusted party.
14 2014-09-08 01:13:03 <Luke-Jr> poutine: this would have to be, yes
15 2014-09-08 01:13:28 <Delta706> ah, then that is different
16 2014-09-08 01:13:42 <Delta706> I want the pledge to indicate an address to trust
17 2014-09-08 01:13:47 <Luke-Jr> Delta706: the only difference I see is that yours requires a trusted party for no reason/benefit
18 2014-09-08 01:14:43 <Delta706> the reason for the trustee is because of additional conditions on the pledge
19 2014-09-08 01:15:02 <Luke-Jr> what additional conditions?
20 2014-09-08 01:15:43 <Delta706> suppose the pledge is to raise money for a computer for a hospital
21 2014-09-08 01:16:03 <Delta706> the trustee can then choose not to invoke it, if the hospital closes
22 2014-09-08 01:17:45 <justanotheruser> Delta706: that doesn't seem to add anything. The hospital will have the funds at the point when they want to buy the computer. You can sign the coinjoin at that point
23 2014-09-08 01:18:38 <Delta706> then you might as well pay at that point as well
24 2014-09-08 01:18:47 <Delta706> and forget about pledges
25 2014-09-08 01:19:30 <justanotheruser> well if you pledge with a group you know you won't end up giving them 0.1btc when they need 1btc leaving them 0.9 short
26 2014-09-08 01:20:39 <Delta706> but that works in my system too
27 2014-09-08 01:21:55 <justanotheruser> If you don't care if you reach the crowdfunding goal and the group needs to invest the money to get your/their product then there is no reason to do anything other than paying them directly and trusting them to pay you
28 2014-09-08 01:22:44 <Delta706> so you are saying trust them to repay you
29 2014-09-08 01:22:50 <Delta706> that is a payment, not a pledge
30 2014-09-08 01:23:03 <justanotheruser> s/pay you/follow their contract
31 2014-09-08 01:23:51 <Delta706> are there contracts in the block chain?
32 2014-09-08 01:24:07 <justanotheruser> of course
33 2014-09-08 01:24:25 <justanotheruser> you cant make invalid blocks and blocks containing invalid transactions are invalid
34 2014-09-08 01:24:39 <Delta706> those are transactions
35 2014-09-08 01:25:12 <justanotheruser> ?
36 2014-09-08 01:25:19 <Delta706> not contracts
37 2014-09-08 01:26:21 <justanotheruser> what exactly is your question? Please ask in #bitcoin
38 2014-09-08 01:36:08 <SwordsMiner> hello friends
39 2014-09-08 05:47:30 <nullbyte> ,
40 2014-09-08 13:31:10 <michagogo> Hm, seeing something weird...
41 2014-09-08 13:31:58 <michagogo> https://www.irccloud.com/pastebin/VBNIXKkE
42 2014-09-08 13:32:11 <michagogo> Both of them running, both the same binary
43 2014-09-08 13:32:23 <michagogo> ACTION wonders might be going on
44 2014-09-08 13:33:20 <bsm117532> netstat -anp | grep 8333
45 2014-09-08 13:33:50 <bsm117532> I bet one is not. Or, one is still starting up. (It checks the last 280 or so blocks on startup, and only opens the port after it's done, IIRC)
46 2014-09-08 13:33:59 <michagogo> bsm117532: nah, I checked debug.log
47 2014-09-08 13:34:17 <michagogo> I first noticed it when I noticed that the mainnet node only had outgoing connections
48 2014-09-08 13:34:43 <michagogo> Trying a different port now and seeing what happens
49 2014-09-08 13:35:21 <michagogo> nc: connect to 127.0.0.1 port 12321 (tcp) failed: Connection refused
50 2014-09-08 13:35:21 <michagogo> $ nc -zv 127.0.0.1 12321
51 2014-09-08 13:35:58 <michagogo> (started like this: screen -dmS mbitcoind gdb -ex "set debug timestamp on" -ex run --args bitcoind --datadir=/home/micha/.bitcoin_main --port=12321)
52 2014-09-08 13:38:39 <michagogo> Hmm.
53 2014-09-08 13:38:49 <michagogo> I may have found it
54 2014-09-08 13:38:55 <michagogo> 2014-09-08 13:24:28 Bound to 0.0.0.0:18333
55 2014-09-08 13:38:55 <michagogo> In testnet log: 2014-09-08 13:24:28 Bound to [::]:18333
56 2014-09-08 13:39:15 <michagogo> mainnet log has this: 2014-09-08 13:33:48 Bound to 127.0.0.1:xyz
57 2014-09-08 13:39:43 <michagogo> (the whitelist port)
58 2014-09-08 13:40:36 <michagogo> So initial diagnosis would be that -whitebind replaces the regular bind, rather than adding to it? o_O
59 2014-09-08 13:41:13 <sipa> ... that shouldn't be
60 2014-09-08 13:41:30 <michagogo> sipa: agreed
61 2014-09-08 13:41:43 <michagogo> I just commented out whitebind, let's see...
62 2014-09-08 13:41:47 <sipa> michagogo: ah
63 2014-09-08 13:41:49 <michagogo> yep
64 2014-09-08 13:41:50 <michagogo> 2014-09-08 13:41:22 Bound to 0.0.0.0:8333
65 2014-09-08 13:41:50 <michagogo> 2014-09-08 13:41:22 Bound to [::]:8333
66 2014-09-08 13:41:58 <sipa> if you *only* specify -whitebind, then that is the only binding
67 2014-09-08 13:42:07 <sipa> is that counterintuitive?
68 2014-09-08 13:42:08 <michagogo> That's...
69 2014-09-08 13:42:10 <michagogo> yes
70 2014-09-08 13:42:32 <michagogo> More importantly, not documented
71 2014-09-08 13:42:42 <sipa> idea was: if you specify how to bind (in any way), we shouldn't do anything by default
72 2014-09-08 13:42:45 <michagogo> (first thing I did when I saw that was read the --help text)
73 2014-09-08 13:43:09 <sipa> ok, needs documenting for sure
74 2014-09-08 13:43:21 <michagogo> It makes sense to not do anything by default if you specify a bind
75 2014-09-08 13:43:23 <sipa> but how would you otherwise configure that you *only* want a whitebind?
76 2014-09-08 13:43:33 <michagogo> listen=0?
77 2014-09-08 13:43:42 <michagogo> Hm
78 2014-09-08 13:43:45 <sipa> that will disable listening entirely
79 2014-09-08 13:44:16 <michagogo> I'd think, as a user, that whitebind would be independent of the regular listen/bind system
80 2014-09-08 13:44:37 <michagogo> If you use whitebind, anyone connecting to that port is a special case, not just another peer
81 2014-09-08 13:45:33 <sipa> hmm, interesting
82 2014-09-08 13:45:48 <sipa> -whitebind for me is "just some additional -bind, but with a special property"
83 2014-09-08 13:46:04 <sipa> it not listening in any special way, and not binding in any special way
84 2014-09-08 13:46:10 <sipa> -listen=0 means to me: don't listen
85 2014-09-08 13:46:12 <michagogo> Also, it's annoying that `bitcoind --help` creates an empty ~/.bitcoin
86 2014-09-08 13:46:46 <sipa> anyway, agree that it at least needs to be documented
87 2014-09-08 13:47:24 <michagogo> Maybe I'm misunderstanding what whitebind was designed for
88 2014-09-08 13:47:28 <wumpus> well in that case wouldn't it make sense to use the same option but add a flag, ie -bind a.b.c.d:e,white ?
89 2014-09-08 13:48:00 <wumpus> I agree it's somewhat confusing that -bind and -whitebind interfere with each other, but also agree it should be possible to have just whitebinds
90 2014-09-08 13:48:22 <michagogo> Personally, I'd think the intuitive way would be to separate -whitebind completely
91 2014-09-08 13:48:42 <wumpus> not sure about that, and what if later on we want to add yet another attribute to binds
92 2014-09-08 13:48:51 <sipa> wumpus: using some suffix on -bind is fine to me
93 2014-09-08 13:48:53 <wumpus> -blackbind -whitebind -yellowbind :p
94 2014-09-08 13:49:00 <sipa> -rainbowbind
95 2014-09-08 13:49:04 <michagogo> I think of it as "a way to give trusted software that speaks p2p access"
96 2014-09-08 13:49:15 <wumpus> sipa: +1 for that one
97 2014-09-08 13:49:29 <sipa> wumpus: ,white is maybe confusing, as a comma is a separator
98 2014-09-08 13:49:41 <sipa> but bikeshed :)
99 2014-09-08 13:49:56 <michagogo> Not as just another bind that has a special property
100 2014-09-08 13:50:09 <wumpus> in a sane configuration language you'd have something like bind ip:port { options whitelist; }
101 2014-09-08 13:50:17 <sipa> michagogo: you can do the same with -bind + -whitelist
102 2014-09-08 13:50:24 <michagogo> (more akin to rpc than p2p, in terms of how it's treated)
103 2014-09-08 13:50:53 <michagogo> sipa: not exactly
104 2014-09-08 13:51:04 <sipa> michagogo: if you only want -whitebind, i mean
105 2014-09-08 13:51:09 <michagogo> Specifically, not if you're expecting both trusted and untrusted software
106 2014-09-08 13:51:13 <michagogo> sipa: ah, right
107 2014-09-08 13:51:52 <michagogo> But it's the kind of thing that I'd say I probably never want to open to the internet, for example
108 2014-09-08 13:52:01 <sipa> michagogo: absolutely
109 2014-09-08 13:52:09 <sipa> i know it's not exactly identical to -bind + -whitelist; i suggested having -whitebind in the first place because otherwise you can't distinguish tor connections from localhost connections
110 2014-09-08 13:52:40 <sipa> but imho -whitebind clearly implies -listen, just like -bind...
111 2014-09-08 13:52:46 <sipa> anyway, semantics :)
112 2014-09-08 13:52:54 <michagogo> Which, to me, suggests it should be treated more like rpc in terms of the binding, etc
113 2014-09-08 13:53:05 <sipa> PRs welcome :)
114 2014-09-08 13:53:18 <michagogo> I wish I could :-/
115 2014-09-08 13:53:32 <michagogo> ACTION doesn't know C++...
116 2014-09-08 13:53:44 <sipa> then what are you waiting for? :p
117 2014-09-08 13:53:56 <michagogo> I know some Ruby, and I find I can often read code and get a sense of what's going on
118 2014-09-08 13:54:28 <michagogo> For now, though, will adding bind= lines for 0.0.0.0:18333 and [::]:18333 work?
119 2014-09-08 13:54:31 <michagogo> erm, 8333*
120 2014-09-08 13:54:50 <sipa> sure
121 2014-09-08 13:55:00 <michagogo> great
122 2014-09-08 13:56:49 <aschildbach> I wonder if OP_CHECKMULTISIG with 0 signatures and 0 pubkeys is supposed to return 1 or 0?
123 2014-09-08 13:58:33 <sipa> aschildbach: is valid
124 2014-09-08 13:58:39 <sipa> there's a unit test for that
125 2014-09-08 14:05:44 <aschildbach> sipa: Ok thanks. This causes the "0 0 0 CHECKMULTISIG 0 0 CHECKMULTISIG 0 0..." check in script_valid.json to violate the "null dummy" check. Are you aware of that?
126 2014-09-08 14:07:02 <aschildbach> sipa: I'm re-implementing this check for bitcoinj and want to evaluate if I need to disable this check for the script_*.json tests generally.
127 2014-09-08 14:07:16 <michagogo> Hm, interesting
128 2014-09-08 14:07:44 <michagogo> So the checkmultisig evals to true, and then the next checkmultisig pops off the 0 0, and then takes the extra...
129 2014-09-08 14:07:47 <michagogo> hmm
130 2014-09-08 14:08:46 <michagogo> Was that just written before the null dummy rule existed, before anyone thought the vallue of the dummy item could be important?
131 2014-09-08 14:09:27 <sipa> aschildbach: null dummy check?
132 2014-09-08 14:09:55 <michagogo> sipa: I assume he means the rule for the dummy being 0
133 2014-09-08 14:10:21 <sipa> oh, of course
134 2014-09-08 14:10:24 <sipa> aschildbach: interesting
135 2014-09-08 14:10:52 <sipa> aschildbach: that's a bug in the null dummy check, imho
136 2014-09-08 14:10:56 <michagogo> https://github.com/bitcoin/bitcoin/blob/0de61e7585e14cb552e985934fc5ddfeb6e8bd67/src/test/data/tx_invalid.json#L85
137 2014-09-08 14:11:08 <michagogo> sipa: why is it a bug?
138 2014-09-08 14:11:20 <michagogo> The input is the output of the previous checkmultisig
139 2014-09-08 14:11:32 <michagogo> It passes, so it's non-zerp
140 2014-09-08 14:11:34 <michagogo> zero*
141 2014-09-08 14:11:36 <aschildbach> I also don't understand why its a bug.
142 2014-09-08 14:11:54 <sipa> wait, maybe i'm misunderstanding
143 2014-09-08 14:12:23 <michagogo> The script is "0 0 0 CHECKMULTISIG 0 0 CHECKMULTISIG 0 0..."
144 2014-09-08 14:12:40 <michagogo> Then the first checkmultisig passes and you end up with "1 0 0 CHECKMULTISIG 0 0..."
145 2014-09-08 14:12:45 <aschildbach> The check is behaving correctly in my opinion. The question is more if we want the check to be active for the JSON tests