1 2015-02-07 00:30:16 <cfields> gavinandresen: looks like we fixed/unfixed an equal amount of times. ok if i give it one last fix now and verify?
2 2015-02-07 02:32:50 <Genitrust> when broadcasting a transaction, i'm getting "Attempted OP_DUP on an empty stack"
3 2015-02-07 02:33:04 <Genitrust> any idea what this means? =|
4 2015-02-07 02:33:39 <sipa> you're doing an OP_DUP with an empty stack
5 2015-02-07 02:33:57 <sipa> for example, your scriptsig does not have a pubkey and sig pushed
6 2015-02-07 02:36:41 <dc17523be3> computer doesn't
7 2015-02-07 02:36:41 <dc17523be3> horsepower to do that. On the other hand Quantum
8 2015-02-07 02:36:55 <dc17523be3> er, pastebuffer, disregard
9 2015-02-07 02:47:16 <Genitrust> sipa ahh, ty
10 2015-02-07 02:47:34 <Genitrust> is "scriptsig" the signature on the spending scripts?
11 2015-02-07 02:47:50 <sipa> yes
12 2015-02-07 02:48:08 <Genitrust> i'm using pycoin, so i must be using something incorrectly before broadcasting
13 2015-02-07 02:54:34 <Genitrus_> sipa what do you mean by "have a pubkey and sig pushed"? i mean, where is the pubkey and sig "pushed" to?
14 2015-02-07 02:54:39 <Genitrus_> <--- just got disconnected >
15 2015-02-07 02:54:40 <Genitrus_> >\
16 2015-02-07 02:55:44 <sipa> Genitrus_: sorry, i don't have time to explain bitcoin scripting basics here
17 2015-02-07 02:56:03 <Genitrus_> do you know where i could find basics of bitcoin scripting? (besides the source code)
18 2015-02-07 02:56:13 <sipa> developer documentation
19 2015-02-07 02:56:18 <sipa> on bitcoin.org
20 2015-02-07 02:56:22 <sipa> and the bitcoin.it wiki
21 2015-02-07 02:56:42 <Genitrus_> wow....
22 2015-02-07 02:56:43 <Genitrus_> this is awesome
23 2015-02-07 02:56:52 <Genitrus_> i never knew bitcoin.org had this. maybe i should've looked around at their site more :P
24 2015-02-07 02:59:40 <SubCreative> <3
25 2015-02-07 03:12:08 <komara> http://www.ofnumbers.com/2015/02/06/what-is-the-blockchain-hard-fork-missile-crisis/
26 2015-02-07 03:12:22 <komara> ^^ When will gavin realize the damage he is about to do to bitcoin??
27 2015-02-07 03:14:34 <komara> I've done similar analysis and everything shows that we become more centralized with larger blocks. It's madness. We should focus on off-chain micropayment channel solutions rather then dump everything in the blockchain. Lower fees means more spam, and means people using PS2H tx's to publish shitloads of data. With a 1TB blockchain, I suspect we will see LESS THAN 1000 full nodes. at 10TB, maybe 250 or so, mostly controlled
28 2015-02-07 03:15:32 <komara> so much for a decentralized network... This sort of thing will just play into the hands of Ethereum
29 2015-02-07 03:22:47 <benjamindees> komara, what do you think the blocksize should be?
30 2015-02-07 04:31:50 <komara> benjamindees: 1MB until we see them all full. then maybe 2MB, then 3MB. jumping straight to 20MB, with no lower fees just is asking for spam and centralization
31 2015-02-07 04:36:28 <mappum> what sources of tx malleability will still exist after the changes in 0.10 that implement BIP 66?
32 2015-02-07 04:39:08 <phantomcircuit> mappum, iirc it doesn't plug 100% of the ecdsa based mutation issues
33 2015-02-07 04:39:17 <phantomcircuit> but those are substantially more difficult to use
34 2015-02-07 04:39:49 <mappum> phantomcircuit: difficult in what way?
35 2015-02-07 04:40:07 <phantomcircuit> you have to understand the math reasonably well or have someone explain it to you who does
36 2015-02-07 04:42:18 <cfields> y = 1 - x
37 2015-02-07 04:42:19 <cfields> :)
38 2015-02-07 04:43:55 <cfields> (assuming you were referring to signature malleability
39 2015-02-07 04:43:58 <cfields> )
40 2015-02-07 04:48:56 <mappum> will contract protocols that rely on presigned refund transactions will still be considered unsafe, even after bip66 v3 blocks are fully in effect?
41 2015-02-07 04:50:29 <mappum> (specifically in the case where the person mutating the transaction is one of the signers of the 2-of-2 multisig)
42 2015-02-07 04:56:00 <phantomcircuit> cfields, iirc bip66 restricts negative signatures
43 2015-02-07 04:57:01 <dooglus> hi. could someone explain how a node determines its external IP address now please?
44 2015-02-07 04:57:31 <dooglus> I'm not understanding the code - it looks like SeenLocal() in net.cpp is meant to count up other peers' ideas of our external address,
45 2015-02-07 04:57:49 <dooglus> but it doesn't increment the count if the address isn't already in the map - so how do the candidate addresses get into the map?
46 2015-02-07 04:58:39 <phantomcircuit> dooglus, grep -rF External
47 2015-02-07 04:58:48 <phantomcircuit> oh actually
48 2015-02-07 04:58:55 <phantomcircuit> peers will tell you what they think your ip is
49 2015-02-07 04:58:58 <sipa> dooglus: we don't
50 2015-02-07 04:59:27 <dooglus> https://github.com/bitcoin/bitcoin/commit/845c86d1 stopped it using a 3rd party service
51 2015-02-07 04:59:28 <sipa> dooglus: but if we don't have a good idea of our own IP, we just report back the IP they think they're using to connect to us
52 2015-02-07 04:59:51 <sipa> upnp or local interface ip are still used for actual discovery
53 2015-02-07 05:00:10 <dooglus> I have upnp disabled, and my local interface IP is a LAN IP
54 2015-02-07 05:00:16 <dooglus> so am I out of luck?
55 2015-02-07 05:00:36 <sipa> use -externalip then
56 2015-02-07 05:00:41 <kanzure> "I also ran a node behind nat (with a port forward) which hasn't had bitcoin running on it recently without UPNP or other ways of discovering an IP and confirmed that it eventually gained inbound connections."
57 2015-02-07 05:00:51 <kanzure> https://github.com/bitcoin/bitcoin/pull/5161#issuecomment-60840573
58 2015-02-07 05:01:25 <dooglus> right - and using -externalip works
59 2015-02-07 05:01:40 <dooglus> but without it, I'm never seeing that my external IP address is discovered
60 2015-02-07 05:02:03 <sipa> indeed
61 2015-02-07 05:02:07 <kanzure> btw what is the problem you are actually experiencing?
62 2015-02-07 05:02:14 <kanzure> network discovery problems, or just literally the ip address?
63 2015-02-07 05:02:26 <kanzure> s/network/node
64 2015-02-07 05:02:59 <dooglus> the initial problem was with an altcoin - I'm never seeing any incoming connections unless I explicitly tell other peers to -connect=me
65 2015-02-07 05:03:27 <cfields> phantomcircuit: it doesn't enforce low S values
66 2015-02-07 05:03:45 <dooglus> I traced the problem to Seenlocal() never adding my external IP to the mapLocalHost map - it's able to increment the vote count if it ever gets into the map, but it doesn't
67 2015-02-07 05:04:12 <kanzure> hmm, this seems hard to diagnose because it ma be using old fork of bitcoind
68 2015-02-07 05:04:15 <kanzure> *may
69 2015-02-07 05:07:32 <kanzure> or, someone may have done a strange merge from upstream that knicked this behavior
70 2015-02-07 05:08:15 <kanzure> are you seeing this same problem with recent bitcoind?
71 2015-02-07 05:10:20 <dooglus> I'm building recent bitcoind now
72 2015-02-07 05:10:23 <dooglus> will report back
73 2015-02-07 05:11:10 <dooglus> yes, I am
74 2015-02-07 05:11:17 <dooglus> "2015-02-07 05:11:22 send version message: version 70002, blocks=3563, us=0.0.0.0:8333, peer=9"
75 2015-02-07 05:11:32 <dooglus> I'm sending a bunch of version messages with "us=0.0.0.0"
76 2015-02-07 05:11:54 <dooglus> 2015-02-07 05:11:22 receive version message: /Satoshi:0.9.3/: version 70002, blocks=342356, us=<my IP>, peer=9
77 2015-02-07 05:12:05 <dooglus> despite many peers all telling me the same IP address for me
78 2015-02-07 05:12:26 <dooglus> this is with bitcoin's master branch
79 2015-02-07 05:12:50 <dooglus> consequently: $ ./bitcoin-cli getpeerinfo | grep inbound | sort | uniq -c
80 2015-02-07 05:12:51 <dooglus> 8 "inbound" : false,
81 2015-02-07 05:12:59 <dooglus> all my connections are outbound
82 2015-02-07 05:13:50 <sipa> well if your node does not know its own ip, it can't report it
83 2015-02-07 05:14:47 <dooglus> right - but 10 different peers have all told it the same IP address
84 2015-02-07 05:14:56 <dooglus> it just didn't count them
85 2015-02-07 05:15:11 <dooglus> look at the definition of bool SeenLocal(const CService& addr) in net.cpp
86 2015-02-07 05:15:14 <sipa> there's no reason why you would be reachable on that ip
87 2015-02-07 05:15:31 <dooglus> except that 10 different peers are telling me that I am?
88 2015-02-07 05:15:40 <kanzure> you don't know that they are different peers
89 2015-02-07 05:15:45 <sipa> that's where they see a connection from
90 2015-02-07 05:15:57 <sipa> we could perhaps use that as a weaker guess
91 2015-02-07 05:16:11 <dooglus> oh, so it's a chicken and egg issue?
92 2015-02-07 05:16:22 <dooglus> nobody can connect to me because nobody has connected to me?
93 2015-02-07 05:16:39 <sipa> but especially in firewalled or natted setups, it's very unlikely that a connection from an ip can be reverse to it
94 2015-02-07 05:16:43 <kanzure> this seems like the sort of thing that a sysadmin should set explicitly, rather than trusting nodes on the network to report accurately
95 2015-02-07 05:17:20 <sipa> if you want to be reachable behind a nat, set your external ip using -externalip
96 2015-02-07 05:17:21 <dooglus> so mapLocalHost is for deciding which of my several network interface IPs to advertise?
97 2015-02-07 05:17:28 <sipa> yes
98 2015-02-07 05:17:54 <dooglus> ok. that's the problem. I thought this was an attempt to do what the 3rd party check was doing, without using a 3rd party
99 2015-02-07 05:18:15 <dooglus> we used to connect to checkip.dyndns.org and ask them what our external IP address was
100 2015-02-07 05:18:26 <dooglus> and then I could run a node without having to know my external IP address
101 2015-02-07 05:18:42 <dooglus> simply forwarding a port on the router was enough to have it just work
102 2015-02-07 05:18:44 <dooglus> not it isn't
103 2015-02-07 05:18:46 <harding> dooglus: I think your node will send a P2P addr message to the remote node with the IP it told you that you have.
104 2015-02-07 05:18:48 <dooglus> now*
105 2015-02-07 05:19:03 <sipa> no, what it does is that *if* you get an incoming connection, and we don't know our own address, we report to that node back what it told us
106 2015-02-07 05:19:13 <sipa> but that's only for incoming connections
107 2015-02-07 05:43:15 <dooglus> sipa: that doesn't appear to happen either
108 2015-02-07 05:43:55 <dooglus> sipa: I made a connection to the node that doesn't know its IP address. it replied with us=0.0.0.0:8333
109 2015-02-07 05:44:53 <gmaxwell> gah
110 2015-02-07 05:44:56 <gmaxwell> you're going in circles.
111 2015-02-07 05:45:09 <gmaxwell> dooglus: thats fine, that response is not used for anything.
112 2015-02-07 05:45:23 <gmaxwell> Advertisment of a node is via address messages.
113 2015-02-07 05:45:46 <gmaxwell> Which bitcoin core will correctly do now by turning around a peers claim of what it sees us as.
114 2015-02-07 05:46:28 <gmaxwell> Announcements are fairly infrequent and only really happen if you're synced up, so it can take a while to have an effect.
115 2015-02-07 05:49:47 <dooglus> do I need to have received an incoming connection before my address will be advertised?
116 2015-02-07 05:54:38 <gmaxwell> No.
117 2015-02-07 05:55:27 <gmaxwell> Assuming your outbound peers are reporting the correct IP for you, it'll work with no further configuration.
118 2015-02-07 06:01:23 <dooglus> ok. I'll let it sync the blockchain and check in a few days whether it has any inbound peers or not
119 2015-02-07 06:02:32 <mappum> dooglus: if you use the 0.10 release candidate your block sync will be much faster
120 2015-02-07 06:03:05 <kanzure> also... -maxconnections
121 2015-02-07 06:03:06 <dooglus> I'm using the master HEAD
122 2015-02-07 06:04:26 <dooglus> " -maxconnections=<n> Maintain at most <n> connections to peers (default: 125)" -- 125 isn't enough?
123 2015-02-07 06:05:38 <sipa> dooglus: we only fetch from outgoing connections for IBD
124 2015-02-07 06:06:36 <dooglus> I only have outgoing connections - that's my whole problem :)
125 2015-02-07 06:07:24 <sipa> i mean that for IBD it won't matter that you have incoming connections or not
126 2015-02-07 06:07:31 <dooglus> right
127 2015-02-07 06:08:48 <dooglus> oh, MAX_OUTBOUND_CONNECTIONS is hardcoded - I see
128 2015-02-07 06:10:26 <gmaxwell> Having more is not helpful in any case in general and would just waste network resources)
129 2015-02-07 06:54:19 <jgarzik> dooglus, once you use -externalip for a while, other peers will remember that address and advertise it to yet other peers, and you'll start to get incoming connections -- assuming your firewall and everything is set up correctly to permit incoming TCP traffic
130 2015-02-07 06:54:44 <jgarzik> The address has to propagate, in order for peers to discover your node
131 2015-02-07 06:55:51 <jgarzik> dooglus, Also, consistently long uptimes helps
132 2015-02-07 06:57:21 <gmaxwell> no need to ever use externalip if your outbound is via the same IP you can accept inbound on; though it can be somewhat faster.
133 2015-02-07 07:08:18 <dooglus> gmaxwell: I am seeing incoming connections now, even if I chang the port I'm listening on
134 2015-02-07 07:08:40 <dooglus> I don't understand the mechanism still
135 2015-02-07 07:08:45 <dooglus> but it's working...
136 2015-02-07 07:11:21 <phantomcircuit> dooglus, the remote peers that you connect to have your external ip address
137 2015-02-07 07:11:29 <phantomcircuit> they tell other peers about it eventually
138 2015-02-07 07:11:33 <phantomcircuit> and they try to connect to you
139 2015-02-07 07:11:37 <gmaxwell> phantomcircuit: not quite
140 2015-02-07 07:11:49 <gmaxwell> remote peers tell you. You, knowing nothing better, tell the network.
141 2015-02-07 07:11:58 <phantomcircuit> gmaxwell, some of the "server" peers actually do exactly that
142 2015-02-07 07:12:12 <phantomcircuit> there's 1 of them which spits out a nearly endless stream of nonsensical addresses
143 2015-02-07 07:12:16 <gmaxwell> well they shouldn't; thats busted and screws with the network somewhat. And isn't needed.
144 2015-02-07 07:12:43 <gmaxwell> phantomcircuit: some of that is people trying to map the network topology. You should probably ban those IPs. :)
145 2015-02-07 07:14:44 <phantomcircuit> gmaxwell, i guess my loverly scanning code that just asks for "addr" on a a timer probably messes with them pretttty godo
146 2015-02-07 07:15:15 <dooglus> so is AdvertizeLocal() an essential part of the process (assuming the whole network was running unmodified bitcoin core, and not advertising my IP out of turn)
147 2015-02-07 07:16:57 <gmaxwell> It is the process.
148 2015-02-07 07:17:29 <gmaxwell> (pretty much)
149 2015-02-07 07:17:45 <dooglus> ok
150 2015-02-07 07:25:52 <dooglus> thanks for your help and patience!
151 2015-02-07 07:41:14 <unicodesnowman> dooglus, seeking help for patching your altcoin?
152 2015-02-07 07:45:53 <dooglus> unicodesnowman: kindof - except it's not mine, and I'm trying to figure out why the patch someone else made isn't working
153 2015-02-07 08:00:06 <Luke-Jr> dooglus: someone in ##altcoin-dev may know - although I suspect most are here too (but you can ask direct altcoin questions there too)
154 2015-02-07 10:06:48 <Mr_Freeze> the joys of getting back into c++, not to mention learing git an github
155 2015-02-07 10:06:58 <Mr_Freeze> *learning
156 2015-02-07 11:15:44 <swagtoshi> hi anyone using toshi here? I'm stuck with docker toshi is killing and exiting as soon as I start it :\