1 2012-11-18 00:06:39 <cjd> I think the main reason why bitcoin needs a somewhat complex bootstrap mechanism is because you can't just have 50000 bitcoin nodes connecting to a single "introduction node" to get addresses to connect to.
  2 2012-11-18 00:07:07 <cjd> This is how bittorrent dht does it but they use udp so it's only a single socket and it's a largely stateless protocol
  3 2012-11-18 00:07:35 <coyo> well, some more modern ideas about decentralization of initial seed nodes is that you COULD use well-known nodes such as xmpp servers or other otherwise-unrelated means to obtain an initial seed node, whereby peer exchange and/or node gossip would enable you to populate a larger table of active nodes.
  4 2012-11-18 00:08:14 <cjd> I've never seen that kind of thing work in the real world
  5 2012-11-18 00:08:36 <coyo> this method basically eliminates the need to rely on a hardcoded-and-high-value-target nodes for initial seeding.
  6 2012-11-18 00:09:03 <coyo> have you never seen any of the hardcoded seeds getting attacked as a general attack on the bitcoin network?
  7 2012-11-18 00:09:29 <cjd> no, I've never seen a network function using public servers for introduction
  8 2012-11-18 00:09:48 <coyo> i COULD provide a proof-of-concept for a public-chat-introduction, if you like
  9 2012-11-18 00:10:00 <coyo> it will take some time, as i am not a very good coder, but i COULD do it.
 10 2012-11-18 00:10:04 <cjd> the IRC introduction is arguably similar but that irc server is run by bitcoin people
 11 2012-11-18 00:10:19 <cjd> you're familiar with the IRC based introduction system right?
 12 2012-11-18 00:10:42 <coyo> the problem with the bitcoin server node introduction is that the bitcoin server nodes provide a small set of high-value targets of attack.
 13 2012-11-18 00:10:53 <coyo> i am familiar with it enough to know it exists.
 14 2012-11-18 00:11:13 <cjd> it does what you're talking about but it just shifts the attack target on to the irc network
 15 2012-11-18 00:11:22 <coyo> the difference
 16 2012-11-18 00:11:33 <coyo> is that the initial seeding does not use a hard-coded channel or network
 17 2012-11-18 00:11:38 <coyo> it would be directed by the user.
 18 2012-11-18 00:12:03 <coyo> you could /suggest/ chatrooms, but it would be, at least in theory, VERY decentralized
 19 2012-11-18 00:12:05 <cjd> ahh, you're talking about the gnutella "google for a directory server and paste it here" thing?
 20 2012-11-18 00:12:10 <coyo> so attackers have very little to gain.
 21 2012-11-18 00:12:21 <coyo> that is one way of looking at it.
 22 2012-11-18 00:13:12 <coyo> you could have a long list of directory servers (which only serve that purpose indirectly, since bitcoin nodes would use xmpp's client-side extensibility to gossip nodes)
 23 2012-11-18 00:14:14 <cjd> <xmpp is="stab" yourself="in the"><eye with="a:rusty"><spoon><ugly>
 24 2012-11-18 00:14:28 <coyo> it is.
 25 2012-11-18 00:14:40 <jgarzik> coyo: "this method" -- all methods so far described have high value targets
 26 2012-11-18 00:14:44 <coyo> but i can always design an alternative instant messaging protocol LATER
 27 2012-11-18 00:14:48 <jgarzik> bitcoin primarily uses peer exchange
 28 2012-11-18 00:14:54 <cjd> ^^
 29 2012-11-18 00:14:55 <jgarzik> the seeds are only if your address db is empty
 30 2012-11-18 00:15:18 <jgarzik> DNS seeds are the primary mechanism for seeding; IRC is disabled.
 31 2012-11-18 00:15:25 <cjd> \\o/
 32 2012-11-18 00:15:27 <jgarzik> hardcoded seeds are a fallback in case none of that works.
 33 2012-11-18 00:15:46 <coyo> jgarzik, i do not see how my suggestion would present extremely high value attack targets by nature of its design, but to answer your comment, many bitcoin nodes are very fresh newly-installed nodes.
 34 2012-11-18 00:15:47 <jgarzik> wiki also lists some fallback nodes
 35 2012-11-18 00:15:51 <coyo> there is a large rate of turnover.
 36 2012-11-18 00:16:03 <cjd> you end up shifting the attack onto your xmpp servers or on to whatever kind of chat network you use, it's a chicken-and-egg problem, there's no way out
 37 2012-11-18 00:16:10 <jgarzik> coyo: any initial greeting method becomes a high value target
 38 2012-11-18 00:16:14 <jgarzik> XMPP does not change that
 39 2012-11-18 00:16:53 <coyo> the method itself is more managable in terms of defensibility, because the underlying (vulnerable) IP network is no longer the attack surface.
 40 2012-11-18 00:16:56 <coyo> it is purely in your own code.
 41 2012-11-18 00:17:05 <coyo> thus, you can actually do something about it.
 42 2012-11-18 00:17:39 <Luke-Jr> coyo: you know we don't use a hardcoded node list normally?
 43 2012-11-18 00:17:43 <Luke-Jr> DNS ftw
 44 2012-11-18 00:17:50 <coyo> but the goal of my suggestion is merely that the potential attack targets of initial greeting be spread out as widely as possible.
 45 2012-11-18 00:18:07 <jgarzik> coyo: that's what DNS seeds already do
 46 2012-11-18 00:18:10 <coyo> uh, Luke-Jr it says so on the bitcoin wiki.
 47 2012-11-18 00:18:31 <coyo> is a DNS seed a specialized server?
 48 2012-11-18 00:18:50 <liori> note that DNS has the advantage of being cached on servers closer to user. xmpp and irc don't do that
 49 2012-11-18 00:18:59 <cjd> hmm
 50 2012-11-18 00:19:04 <jgarzik> XMPP is poorly defended shite.  Easy to bounce off the net with a DDoS -- and bitcoin sites have often been target of DDoS.
 51 2012-11-18 00:19:14 <coyo> when you say that, i imagine a fast-flux dynamic dns system to provide a huge dissipation of potential high-value attack targets.
 52 2012-11-18 00:19:28 <jgarzik> the best method would be somewhere sneaky, hidden on heavily defended Google servers or somesuch :)
 53 2012-11-18 00:19:42 <coyo> that would (probably) be ideal.
 54 2012-11-18 00:20:22 <coyo> by saying something like xmpp is a (possibly) better approach, i am not saying that xmpp isnt a huge stinking load of crap, and that their responses to attacks is NOT a bunch of pathetic whining.
 55 2012-11-18 00:20:27 <cjd> Also we must deprecate XMPP before it holds real time communication technology back for the the next 10 years
 56 2012-11-18 00:21:06 <coyo> i do not disagree, but designing an entirely new communications protocol is going to take awhile (that is to say, i'm working on it right now)
 57 2012-11-18 00:21:40 <coyo> i am somewhat surprised to see you here, cjd.
 58 2012-11-18 00:21:46 <cjd> actually dns is highly clever because if you're under pressure, you can use verisign's dns service and there is no botnet on the face of the earth which can take that down
 59 2012-11-18 00:21:50 <jgarzik> XMPP is a much poorer choice than IRC
 60 2012-11-18 00:22:00 <jgarzik> IRC has more, better-defended servers on DDoS-hardened networks
 61 2012-11-18 00:22:16 <jgarzik> cjd: or dnspark etc.
 62 2012-11-18 00:22:33 <coyo> i would like to say, publically, that i am very fascinated by your concept for an overlay internet protocol network using mpls-like switching labels for routing over an inherently-secure network.
 63 2012-11-18 00:22:58 <cjd> hmm.. it would be "nice" if the requestor had so send some small proof of work to the introduction server but that would break using dns
 64 2012-11-18 00:23:20 <cjd> coyo: thanks, I'm here to fill the bitcoin chain with crap :)
 65 2012-11-18 00:23:29 <coyo> cjd: proof-of-work is a very solid mechanism in nature. it's called signaling honestly.
 66 2012-11-18 00:23:51 <coyo> you could even call such a system "peacock"
 67 2012-11-18 00:23:59 <coyo> :3
 68 2012-11-18 00:24:33 <cjd> also this channel is hard to avoid, lots of developers who really really know what they're talking about.. it's like a breath of fresh air
 69 2012-11-18 00:24:45 <coyo> well, that's good.
 70 2012-11-18 00:24:58 <coyo> it's hard to find competent engineers who have ANY time for discussing protocols.
 71 2012-11-18 00:25:17 <coyo> but the internode protocol is an essential factor for the functioning of the bitcoin economy.
 72 2012-11-18 00:25:33 <coyo> i am a bit of a protocol geek.
 73 2012-11-18 00:25:49 <coyo> (in the sense of specialization, if not actual competence)
 74 2012-11-18 00:25:58 <jgarzik> for bitcoin initial peer seeding, it's more about defense than protocol quality. ;p  a crappy protocol that is DDoS- and government-hardened is worth more than a wonderful protocol lacking said qualities
 75 2012-11-18 00:26:10 <coyo> this is true.
 76 2012-11-18 00:26:18 <jgarzik> with bitcoin, all you need is _one_ valid peer, and you're golden
 77 2012-11-18 00:26:26 <jgarzik> you're on the network, peer-exchanging into the world
 78 2012-11-18 00:26:38 <cjd> this is good
 79 2012-11-18 00:26:58 <cjd> when I last dropped by, if you killed irc it would slowly lose connections until you were down to 8
 80 2012-11-18 00:27:08 <vazakl> virtual captain ahab, "you've got whale"
 81 2012-11-18 00:27:13 <coyo> i'll i wanted to point out was that using a very limited number of hardcoded peers seemed like a huge liability. since you guys have it covered, i'll let that go.
 82 2012-11-18 00:27:24 <jgarzik> bitcoin provides many methods for initial seeding, including manual specification.  You can hop onto IRC or post on the forum, asking for an IP address.  Once you get a good one, you're set.
 83 2012-11-18 00:27:39 <jgarzik> coyo: the hardcoded peer list is only used as a last resort
 84 2012-11-18 00:27:40 <coyo> *all i wanted
 85 2012-11-18 00:27:47 <coyo> hmm.
 86 2012-11-18 00:27:49 <jgarzik> if nothing else works
 87 2012-11-18 00:28:01 <coyo> you know what would be cool?
 88 2012-11-18 00:28:27 <jgarzik> George Lucas leaving the planet?
 89 2012-11-18 00:29:09 <coyo> if, some mechanism of either downloading a fresh binary, or compiling a copy of the bitcoin client hit a number of directory servers and "firmcoded" a fresh list of public seed peers?
 90 2012-11-18 00:29:34 <coyo> so, when distributing a binary in any fashion would have a constantly-mutating set of fairly fresh initial seed peers.
 91 2012-11-18 00:29:56 <jgarzik> coyo: cute but difficult to sign and keep un-trojaned
 92 2012-11-18 00:30:05 <coyo> true.
 93 2012-11-18 00:30:21 <jgarzik> coyo: don't waste too much time thinking about the hardcoded list.  it's updated once per release, quickly goes stale, and is only used as a last resort.
 94 2012-11-18 00:30:38 <jgarzik> Anybody BUT a new install will have a fresh peer list.
 95 2012-11-18 00:30:39 <coyo> i see.
 96 2012-11-18 00:30:59 <cjd> also initial seed peers should be nodes which aren't going to disappear one day and aren't run by phantomcircuit
 97 2012-11-18 00:31:17 <cjd> so there's a little bit of vetting I imagine
 98 2012-11-18 00:31:18 <jgarzik> cjd: DNS seeds strive to provide high quality seeds
 99 2012-11-18 00:31:25 <coyo> i have been learning about bitcoin in order to tightly integrate the existing bitcoin network into a unified overlay protocol of my own design
100 2012-11-18 00:31:27 <jgarzik> long uptime, different networks, etc.
101 2012-11-18 00:31:32 <cjd> /nod
102 2012-11-18 00:31:38 <coyo> inspired somewhat by cjd and other fine engineers' work.
103 2012-11-18 00:31:46 <cjd> what's it called?
104 2012-11-18 00:31:54 <coyo> i have not named it, yet.
105 2012-11-18 00:32:00 <phantomcircuit> cjd, lololol
106 2012-11-18 00:32:04 <cjd> what's it written in?
107 2012-11-18 00:32:33 <coyo> it's all on paper, i have not written it down as code, yet, but a proof of concept will be written fairly soon, in ruby as a prototype.
108 2012-11-18 00:32:52 <cjd> packet handling like with a TUN device?
109 2012-11-18 00:33:08 <coyo> after i've proven the concept, and have a working prototype, i'll pay some coders to re-write it from the ground up in C
110 2012-11-18 00:33:12 <coyo> sure.
111 2012-11-18 00:33:20 <coyo> it will require a tun device.
112 2012-11-18 00:33:35 <cjd> recommendation #1: don't use ruby if you want it to not take a week to send a packet
113 2012-11-18 00:34:09 <coyo> i am not a terribly competent programmer. would you recommend python's twisted library, instead?
114 2012-11-18 00:34:23 <phantomcircuit> cjd, what you dont trust me to be a seed node? :)
115 2012-11-18 00:34:24 <cjd> twisted would be better than ruby
116 2012-11-18 00:34:35 <coyo> i will be incapable of doing anything usable in c
117 2012-11-18 00:35:01 <cjd> C > C++ > Go > python > ruby
118 2012-11-18 00:35:03 <coyo> unless i just resign to hiring coders to translate my ideas into code even for the proof of concept.
119 2012-11-18 00:35:11 <coyo> i MAY be able to learn go.
120 2012-11-18 00:35:21 <cjd> some people will disagree that C > C++ and some will disagree that C++ > Go
121 2012-11-18 00:35:25 <Luke-Jr> jgarzik: XMPP is no worse than IRC. You're complaining about server implementation maturity issues
122 2012-11-18 00:35:34 <cjd> haha XMPP is shit
123 2012-11-18 00:35:53 <cjd> remember how unstable conference.jabber.org used to be?
124 2012-11-18 00:36:03 <coyo> it isnt much better, now
125 2012-11-18 00:36:06 <cjd> I had a buggy crap psi client and every time I connected it would crash
126 2012-11-18 00:36:11 <jgarzik> Luke-Jr: <jgarzik> IRC has more, better-defended servers on DDoS-hardened networks
127 2012-11-18 00:36:13 <coyo> even though it now has an entire company funding development
128 2012-11-18 00:36:18 <jgarzik> Luke-Jr: implementation is irrelevant
129 2012-11-18 00:36:19 <cjd> lol
130 2012-11-18 00:36:27 <Luke-Jr> jgarzik: that has nothing to do with IRC vs XMPP, it has to do with server implementations
131 2012-11-18 00:36:51 <cjd> if you mess up an irc implementation then you should be a plumber
132 2012-11-18 00:36:53 <Luke-Jr> you could do all the same stuff server-side with a server speaking XMPP
133 2012-11-18 00:37:11 <coyo> http://about.psyc.eu/XMPP#Technical_Issues_in_Jabber
134 2012-11-18 00:37:16 <jgarzik> Luke-Jr: No it has nothing to do with implementation.  IRC is hardened thanks to motivated admins and experience.
135 2012-11-18 00:37:17 <cjd> if you think XMPP is a good idea then you'll probably mess up the XMPP implementation --- then arguably... you should be a plumber
136 2012-11-18 00:37:38 <coyo> specialization is for insects :P
137 2012-11-18 00:37:38 <jgarzik> IRC is a crappy protocol, and the server implementations are crappy
138 2012-11-18 00:37:41 <Luke-Jr> jgarzik: IRC is a protocol. admins/experience/code are irrelevant
139 2012-11-18 00:37:53 <jgarzik> Luke-Jr: ok, when you rejoin the real world, let me know
140 2012-11-18 00:38:09 <cjd> you have to admit thought, IRC is hard to mess up too badly
141 2012-11-18 00:38:15 <Luke-Jr> freenode could deploy an XMPP port on their servers and it would work just as well
142 2012-11-18 00:38:24 <cjd> ough
143 2012-11-18 00:38:28 <coyo> IRC's primary strength lies in its simplicity of design
144 2012-11-18 00:38:31 <cjd> freenode isn't *that* bad is it?
145 2012-11-18 00:38:39 <cjd> I mean since the whole hyperion thing
146 2012-11-18 00:38:40 <coyo> it is much harder to screw up a simpler protocol.
147 2012-11-18 00:38:57 <coyo> freenode could be much worse, i guess.
148 2012-11-18 00:39:07 <Luke-Jr> it's just a protocol.
149 2012-11-18 00:39:17 <coyo> the culture and community leaves something to be desired..
150 2012-11-18 00:40:25 <cjd> it's way outdated but sadly it's the best thing we have
151 2012-11-18 00:40:32 <coyo> hey cjd, would you recommend msgpack or protobuf as a general data serialization protocol?
152 2012-11-18 00:40:49 <cjd> I am partial to bencode
153 2012-11-18 00:40:50 <coyo> at least in terms of effeciency and speed?
154 2012-11-18 00:40:54 <jgarzik> coyo: what is msgpack?
155 2012-11-18 00:41:11 <jgarzik> protobufs are nice and fast and widely deployed
156 2012-11-18 00:41:19 <cjd> protobuf probably has a bigger community and better support
157 2012-11-18 00:41:22 <coyo> http://wiki.msgpack.org/display/MSGPACK/Overview
158 2012-11-18 00:41:49 <cjd> ooop msgpack uses confluence, mos def protobuf
159 2012-11-18 00:41:54 <coyo> msgpack could use a little more love, in my opinion, but protobuf has a lot of real world deployment and a larger community to speak for it.
160 2012-11-18 00:41:56 <cjd> :)
161 2012-11-18 00:42:03 <coyo> what is confluence?
162 2012-11-18 00:42:14 <cjd> that wiki you linked to
163 2012-11-18 00:42:42 <coyo> what?
164 2012-11-18 00:43:01 <coyo> so you are judging the protocol based on the wiki software the project leaders chose to deploy?
165 2012-11-18 00:43:07 <cjd> yeap :)
166 2012-11-18 00:43:24 <cjd> XWiki or die
167 2012-11-18 00:43:59 <cjd> anyway... protobuf is probably a bit better
168 2012-11-18 00:44:13 <cjd> if you need it to go really fast then write structures to the wire
169 2012-11-18 00:44:28 <cjd> and you have to make sure they're all aligned
170 2012-11-18 00:45:42 <cjd> cjdns uses structures for the packet headers but when the routers are telling eachother about other nodes and sending pings and little crap like that, they use bencode
171 2012-11-18 00:45:57 <jgarzik> msgpack seems quite compact, and their slides claim to be faster than protobufs
172 2012-11-18 00:46:06 <jgarzik> still, protobufs are far more widely deployed and supported
173 2012-11-18 00:46:43 <cjd> if you need fast, I'd write structures directly to the wire.. if you don't need fast then I'd use a protocol like json or bencode
174 2012-11-18 00:47:17 <coyo> mmm.
175 2012-11-18 00:47:50 <coyo> json isnt much better than xml, though.
176 2012-11-18 00:47:59 <cjd> yeah, bencode is better
177 2012-11-18 00:48:19 <coyo> bencode has the benefit of being extremely simple and straightforward
178 2012-11-18 00:48:26 <coyo> and also being text-encoding neutral
179 2012-11-18 00:49:19 <cjd> cjdns uses a custom bencode parser which converts to an internal representation and it can convert between a json dialect and bencode
180 2012-11-18 00:49:36 <jgarzik> JSON is a lot better than XML... JSON is not infected with namespace crap, XPath, and all that other XML lard ;p
181 2012-11-18 00:49:46 <cjd> ^
182 2012-11-18 00:49:49 <jgarzik> much less duplication to achieve same goal
183 2012-11-18 00:50:08 <cjd> it just has forced UTF-8
184 2012-11-18 00:50:15 <cjd> so no sending bytes
185 2012-11-18 00:50:17 <jgarzik> JSON is widely popular, but needs a bit more type safety
186 2012-11-18 00:50:57 <coyo> ruby is very beautiful and fun to code, the only thing i can REALLY complain about is that most implementations have a horrible garbage collector.
187 2012-11-18 00:51:18 <cjd> ruby is
188 2012-11-18 00:51:18 <coyo> if ruby used a far more efficient garbage collector, it would not be so slow.
189 2012-11-18 00:51:23 <cjd> slow
190 2012-11-18 00:51:45 <cjd> garbage collection is the devil, it was slow in the 90s and it's slow now
191 2012-11-18 00:52:05 <coyo> the garbage collector theoretically can be very efficient.
192 2012-11-18 00:52:39 <phantomcircuit> only in theory
193 2012-11-18 00:52:42 <phantomcircuit> never in practice
194 2012-11-18 00:52:52 <cjd> heh
195 2012-11-18 00:54:35 <coyo> hmm.
196 2012-11-18 00:54:50 <coyo> it may be a possible sub-field to innovate in.
197 2012-11-18 00:55:12 <coyo> after reading http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29 it doesnt seem like there's any hard-and-fast constraint that says garbage collection should be crude and slow.
198 2012-11-18 00:56:35 <cjd> oddly enough the same is true for java
199 2012-11-18 00:56:41 <cjd> but in practice.... D:
200 2012-11-18 00:57:00 <coyo> but in practice java has fell pretty far from the mark.
201 2012-11-18 00:57:35 <coyo> though java's garbage collection is still superior to ruby's
202 2012-11-18 00:57:36 <cjd> yeahlol
203 2012-11-18 00:57:38 <cjd> jruby is the fastest implementation
204 2012-11-18 00:57:38 <coyo> which is actually the primary motivation behind jruby
205 2012-11-18 00:57:41 <coyo> ruby with jvm gc
206 2012-11-18 00:57:59 <coyo> yeah lol
207 2012-11-18 00:58:53 <cjd> compiled jruby to .class files?
208 2012-11-18 00:58:53 <jgarzik> using gcj
209 2012-11-18 00:58:54 <jgarzik> .o files
210 2012-11-18 00:59:40 <cjd> once I compiled helloworld.java with gcj and static linking
211 2012-11-18 00:59:43 <cjd> 120MB
212 2012-11-18 01:00:18 <coyo> holy hell.
213 2012-11-18 01:01:00 <coyo> 120mb is a lot of freaking binary code for a simple hello world program.
214 2012-11-18 01:01:08 <cjd> What I'd really like is a fast way to jump from java to native code (not sure if jni is fail or not) and then a nice way to optimistically compile .class files into .amd64.class files where they're loadable into a normal jvm but internally they're native code
215 2012-11-18 01:01:59 <coyo> though to be fair, a lot of that is theoretically common infrastructure, and, in theory, shouldnt be counted toward to final result in terms of size of actual problem-domain binary code.
216 2012-11-18 01:02:35 <coyo> that sounds pretty neat.
217 2012-11-18 01:03:25 <coyo> i wish ruby provided a method to dynamically compile down to assembly like common lisp can via sbcl
218 2012-11-18 01:08:03 <XertroV> ls
219 2012-11-18 01:08:16 <XertroV> sorry, my bad
220 2012-11-18 01:08:31 <cjd> user@debian:~/$ _
221 2012-11-18 01:08:56 <liori> on the topic of msgpack vs protobuf: they are solutions to different problems. msgpack is for free-form messages, protobuf is for fixed-format ones.
222 2012-11-18 01:09:06 <coyo> oh?
223 2012-11-18 01:09:15 <coyo> i didnt know that.
224 2012-11-18 01:09:22 <coyo> but that makes sense.
225 2012-11-18 01:09:31 <liori> in protobuf you statically define structures to send. msgpack can send anything json can
226 2012-11-18 01:09:33 <cjd> hmm msgpack is a free form encoding scheme?
227 2012-11-18 01:09:37 <coyo> i thought they were both serialization protocols.
228 2012-11-18 01:09:52 <coyo> and thus were alternatives to the same problem domain, serializing data structures.
229 2012-11-18 01:12:37 <cjd> protobuf = other end knows what the structure looks like but you can add a field and old nodes won't panic
230 2012-11-18 01:13:00 <liori> protobuf will result in smaller messages, because the messages don't have to be self-describing. but msgpack puts metadata into messages
231 2012-11-18 01:13:10 <cjd> msgpack = bencode
232 2012-11-18 01:13:42 <liori> also, protobuf does not encode the end of message in any way, you need to send message length separately
233 2012-11-18 01:14:59 <cjd> interesting
234 2012-11-18 01:14:59 <coyo> interesting. so if the protocol is very well-defined, you would use protobuf, because it is much more compact.
235 2012-11-18 01:15:10 <liori> in the extreme case if you just send two messages one after another without manually marking the end of first message, the decoder will firstly load into the structure values from the first message, then overwrite them with values from the second one. i experienced it once&
236 2012-11-18 01:15:22 <coyo> but if you have a rapidly-evolving and rapidly-extending protocol, bencoding/msgpack may be more feasible?
237 2012-11-18 01:15:33 <liori> something like that
238 2012-11-18 01:15:56 <cjd> IMO protobuf serves a very narrow field
239 2012-11-18 01:16:16 <liori> it's something like enforcing strict schema on xml vs. having tag soup of html
240 2012-11-18 01:16:45 <cjd> where it needs to be really fast and you can't stand the overhead of self describing but it doesn't need to be so fast that you really want to send aligned structures on the wire
241 2012-11-18 01:17:25 <coyo> delicious tag soup
242 2012-11-18 01:17:29 <coyo> om nom nom
243 2012-11-18 01:17:50 <cjd> benc has some high overhead but it doesn't really have to.. I was thinking about writing a serialized which packed numbers similar to satoshi varint
244 2012-11-18 01:18:01 <cjd> *serializer
245 2012-11-18 01:21:02 <coyo> rigatoni beef and black olives <3
246 2012-11-18 01:21:13 <cjd> heh
247 2012-11-18 01:21:43 <coyo> so cjd, how far did you progress on your new cjdns protocol version system?
248 2012-11-18 01:21:51 <cjd> done
249 2012-11-18 01:22:00 <cjd> there are 2 versions and they communicate ok
250 2012-11-18 01:22:06 <coyo> nice.
251 2012-11-18 01:22:26 <cjd> even though it would be a trainwreck for one to try to talk the wrong version to another
252 2012-11-18 01:22:40 <coyo> but now the protocol feature of version discrimination exists, and you can selectively gossip only compatible nodes, correct?
253 2012-11-18 01:22:53 <cjd> cjdns does not send version and verack packets like bitcoin so if you don't know the version in advance, you die
254 2012-11-18 01:23:00 <cjd> could
255 2012-11-18 01:23:42 <coyo> hmm.
256 2012-11-18 01:24:44 <coyo> how difficult would it be to design an 8192-bit version of IP?
257 2012-11-18 01:25:08 <coyo> assume i was going to use a label-switching strategy for routing effeciency.
258 2012-11-18 01:25:33 <cjd> I could design it in a day
259 2012-11-18 01:25:42 <coyo> really?
260 2012-11-18 01:26:05 <cjd> getting windows and linux and macos and firefox and irc and everything to communicate using it...
261 2012-11-18 01:26:14 <cjd> would take at least 20 years
262 2012-11-18 01:26:15 <coyo> so.. if i had 6000 dollars in the bank right now, you could return me an ip protocol stack prototype the next day? that's pretty impressive.
263 2012-11-18 01:26:32 <cjd> see above
264 2012-11-18 01:26:43 <coyo> i see it.
265 2012-11-18 01:26:57 <cjd> IPv6 was started in 1995 and it still hasn't taken off
266 2012-11-18 01:27:02 <coyo> but the great thing about an overlay network is that there's no need to rush.
267 2012-11-18 01:27:10 <coyo> things can gradually adopt the new protocol.
268 2012-11-18 01:27:16 <cjd> not if the application can't talk the protocol
269 2012-11-18 01:27:27 <cjd> firefox talks ipv6, that's why cjdns works
270 2012-11-18 01:27:32 <coyo> yeah.
271 2012-11-18 01:27:50 <cjd> if you want an absurdly large ip packet, you need to train your software to accept it
272 2012-11-18 01:27:51 <cjd> all of it
273 2012-11-18 01:28:06 <coyo> but that's your (good) strategy of using software that already has made internal codebase modifications and patches to use the existing ipv6 address bitlength.
274 2012-11-18 01:29:17 <coyo> but what you are saying is that it wouldnt be ridiculously difficult to get the protocol itself well defined and prototyped?
275 2012-11-18 01:29:51 <cjd> no but if you paid me to do it, you would feel ripped off because I would just respec the ipvy packet with larger source and dest fields
276 2012-11-18 01:29:58 <coyo> i hear you on the protocol stack per platform, though. i will probably use the strategy of virtualizing everything to the point of aggressive code portability.
277 2012-11-18 01:30:00 <cjd> *ipv6
278 2012-11-18 01:30:08 <coyo> oh.
279 2012-11-18 01:30:47 <coyo> yeah, but that wouldnt even require a day.
280 2012-11-18 01:30:50 <coyo> just a few minutes.
281 2012-11-18 01:31:37 <cjd> a day to work out the surprises
282 2012-11-18 01:31:39 <coyo> i wonder how difficult it would be to write userspace protocol stack libraries and a bridge tun adapter..
283 2012-11-18 01:31:59 <cjd> tcp in userspace already exists
284 2012-11-18 01:32:11 <cjd> note that you're basicly rewriting TOR or I2P
285 2012-11-18 01:32:14 <coyo> so it is well within the space of possibility.
286 2012-11-18 01:32:23 <cjd> and one of the main problems with those is they don't talk ipv4/6
287 2012-11-18 01:32:28 <coyo> well, i have different design goals to tor or i2p
288 2012-11-18 01:32:46 <cjd> also you don't need large packets
289 2012-11-18 01:32:51 <coyo> but you are correct in that i could learn from techniques used in those projects.
290 2012-11-18 01:33:15 <cjd> could use ipv4 packets if you're sure your users will not be using 10.0.0.0/8
291 2012-11-18 01:33:46 <cjd> just when someone does a dns lookup, you allocate an ipv4 address to that key and internally you map between your on-wire protocol and the ipv4 that their applications know and love
292 2012-11-18 01:34:12 <coyo> well, if i wanted to be blatant about being standards-uncompliance, i could use the 7.0.0.0/8 address space.
293 2012-11-18 01:34:35 <coyo> yeah, essentially, i'd be using an internal NAT
294 2012-11-18 01:34:38 <cjd> use 11.0.0.0, it's DoD so it will never be used in the real world :P
295 2012-11-18 01:34:43 <coyo> haha.
296 2012-11-18 01:34:45 <coyo> okay :D
297 2012-11-18 01:35:10 <cjd> cjdns can do the same thing with it's ipv6 packets
298 2012-11-18 01:35:30 <cjd> doesn't need to do any mapping, just to verify that someone hasn't collided a 128 bit ipv6 address
299 2012-11-18 01:35:35 <cjd> which btw is impossible right now
300 2012-11-18 01:35:47 <coyo> hmm. i just came up with a clever scheme for how to map addresses. writing this down.
301 2012-11-18 01:35:50 <cjd> in 10 years it might become possible but the protocol allows for preventing it
302 2012-11-18 01:36:45 <cjd> note that the application might not enjoy it's ipv4 address looking different to everyone
303 2012-11-18 01:36:47 <coyo> i'm not knocking your protocol, it's very clever, and i have learned a great deal from your approach.
304 2012-11-18 01:37:05 <cjd> if you were you wouldn't be the first or the last :)
305 2012-11-18 01:37:48 <coyo> this is true. having a unique nickspace will probably confuse a lot of p2p applications.
306 2012-11-18 01:38:41 <coyo> i wonder if simulating upnp or something would be possible to help adapt existing p2p applications..
307 2012-11-18 01:38:42 <cjd> yeah, for cjdns it's just for verification because there will never be an accidental collision, possibly in 10 years there would be intentional collisions though
308 2012-11-18 01:40:00 <coyo> 128 is pretty small in terms of collisions, though.
309 2012-11-18 01:40:07 <cjd> oh?
310 2012-11-18 01:40:16 <coyo> you are confident that it will take 10 years for collisions to be a problem?
311 2012-11-18 01:40:53 <cjd> define your attack equipment
312 2012-11-18 01:40:53 <coyo> well.
313 2012-11-18 01:41:51 <coyo> let's say i owned several diverse internetworks located in different regions of the world, owned enough physical and virtual machines to conduct sybil attacks, and owned entire network prefixes in terms of underlying IP address space.
314 2012-11-18 01:42:17 <cjd> sibyl attacks are not meaningful to colliding an ip addr
315 2012-11-18 01:43:00 <coyo> is brute forcing the hashes the only method of colliding a cjdns addr?
316 2012-11-18 01:43:14 <cjd> mhm
317 2012-11-18 01:43:41 <cjd> most powerful bruting system in the world is the bitcoin network
318 2012-11-18 01:43:55 <cjd> it regularly finds about a 64 bit collision
319 2012-11-18 01:44:03 <coyo> hehe.
320 2012-11-18 01:44:20 <cjd> if the whole bitcoin network finds a 64 bit collision for 500$
321 2012-11-18 01:44:36 <cjd> then a 65 bit collision costs 1000$ and takes the network 20 minutes
322 2012-11-18 01:44:38 <coyo> so the bitcoin network is a good gauge of what current computation capacity is?
323 2012-11-18 01:45:02 <cjd> /nod
324 2012-11-18 01:45:39 <cjd> ;;calc 500**54
325 2012-11-18 01:45:40 <gribble> 55511151231257823571160183624217802436680300162073375146205862269581979777786362589434315637728804045664120471286995972714091556960350167569006592
326 2012-11-18 01:45:43 <cjd> $
327 2012-11-18 01:45:49 <coyo> i wonder what the implications of TH/s such as the butterfly labs beast would mean for general information security?
328 2012-11-18 01:45:57 <coyo> that... is a large number.
329 2012-11-18 01:46:05 <cjd> would be the bitcoin network cost of finding a 128 bit collision
330 2012-11-18 01:46:22 <cjd> oops I typed 54 instead of 64
331 2012-11-18 01:46:29 <cjd> ;;calc 500**64
332 2012-11-18 01:46:30 <gribble> 54210108624275223917613798988921077516893656836376481800589749700708151459527474647904035368433110806403195264147109583005727447647617499010357186287782026036657630228774912
333 2012-11-18 01:46:33 <cjd> there ya go
334 2012-11-18 01:46:36 <coyo> yeah, that's an astronomically large number, and more than the capitalization of every market in the world.
335 2012-11-18 01:46:39 <coyo> that money does not exist.
336 2012-11-18 01:46:46 <cjd> mmm
337 2012-11-18 01:47:10 <cjd> but assuming miner's time was free, we could express it in terms of minutes
338 2012-11-18 01:47:15 <cjd> ;;calc 10**64
339 2012-11-18 01:47:15 <gribble> 10000000000000000213204190094543968723012578712679649467743338496
340 2012-11-18 01:47:17 <coyo> yeah.
341 2012-11-18 01:47:26 <coyo> still a pretty damned large number.
342 2012-11-18 01:47:32 <cjd> I think the heat death of the universe is a serious concern
343 2012-11-18 01:48:08 <coyo> though doesnt every miner discard every hash computed other than those with leading zeros?
344 2012-11-18 01:48:22 <coyo> those hashes would take up a LOT of space to retain.
345 2012-11-18 01:49:01 <coyo> i dont see how we could possibly avert the heat death of the universe.
346 2012-11-18 01:49:28 <cjd> don't try to collide 128 bits and it won't make that much heat ;)
347 2012-11-18 01:49:44 <coyo> heh.
348 2012-11-18 01:50:15 <xenland> the death of universe is just a theory based of what little we know about the universe, I wouldnt look too much into it until quantum science has some solid consist grounds
349 2012-11-18 01:50:29 <coyo> hello xenland
350 2012-11-18 01:50:41 <xenland> hey coyo i guess i just jumped in here huh?
351 2012-11-18 01:50:44 <cjd> yeah, I'm just making shit up to put those numbers into perspective
352 2012-11-18 01:50:59 <xenland> oh alright don't know what you bee talking about then
353 2012-11-18 01:51:15 <cjd> power necessary to collide 128 bits
354 2012-11-18 01:51:25 <cjd> of double sha256
355 2012-11-18 01:51:42 <cjd> (cjdns uses double sha512 but that just makes it a bit harder)
356 2012-11-18 01:51:45 <coyo> xenland, we were just talking about a project of cjd's as well as an experimental protocol stack i'm working on that attempts to integrate the bitcoin network into an overall incentive system.
357 2012-11-18 01:52:18 <cjd> I'm just here to spam the chain and make enemies
358 2012-11-18 01:52:29 <xenland> interesting indeed! /me sit backs and listens
359 2012-11-18 01:52:35 <xenland> lol
360 2012-11-18 01:52:54 <coyo> cjd and i were arguing over the relative mathematical difficulty between 128-bit hash collision attacks and 8129-bit hash collision attacks.
361 2012-11-18 01:54:00 <coyo> i was suggesting that an overlay protocol stack which included a heavily modified version of the Internet Protocol which incorporates some of cjd's ideas on switching labels for efficient packet forwarding without relying on network prefix aggregation.
362 2012-11-18 01:55:04 <xenland> Bitcoin Internet Protocal!
363 2012-11-18 01:55:19 <coyo> i suggested that transparent cryptographic security which uses the address bitlength of 8129 bits would be preferable due to projects such as gnu privacy guard now adopting widespread availability of 8129 bit public keypair generation.
364 2012-11-18 01:55:23 <cjd> my advice is to avoid trying to clone cjdns
365 2012-11-18 01:55:54 <cjd> someone who is an accomplished software developer 10 years older than I decided to port it to another language
366 2012-11-18 01:56:04 <cjd> he started reading and gave up pretty quickly
367 2012-11-18 01:56:10 <coyo> would you suggest an alternative method of switch labeling?
368 2012-11-18 01:56:26 <cjd> the one I have is the best except if you want to debug it
369 2012-11-18 01:56:47 <coyo> alright, so you are confident your approach is the best in terms of the switching labels?
370 2012-11-18 01:57:11 <cjd> me and a few other people spent a lot of time literally staring at 2 or 3 lines of code just trying to make sure they're right
371 2012-11-18 01:57:23 <cjd> best that exists
372 2012-11-18 01:57:23 <coyo> is there any hypothetical incremental improvement that COULD be made to the switching label forwarding system other than the address bit length?
373 2012-11-18 01:57:41 <coyo> alright.
374 2012-11-18 01:58:08 <coyo> the biggest thing i noticed about cjdns is that the existing community seems to believe that darknet-style privacy is actually feasible.
375 2012-11-18 01:59:39 <cjd> if you want to rewrite the switch, this file is a good place to start... try to see if you know why it uses the numbers and operations that it does https://github.com/cjdelisle/cjdns/blob/master/switch/LabelSplicer.h
376 2012-11-18 02:06:59 <coyo> i will attempt to read the file. i have extremely little experience with c
377 2012-11-18 02:45:32 <jgarzik> https://github.com/cjdelisle/cjdns  <<-- browsable tree
378 2012-11-18 02:45:41 <jgarzik> https://github.com/bitsofproof/supernode  <<-- incomprehensible tree
379 2012-11-18 02:45:51 <jgarzik> guess which one is Java?
380 2012-11-18 02:47:19 <coyo> hehe.
381 2012-11-18 02:47:24 <coyo> bitsofproof :3
382 2012-11-18 02:47:57 <coyo> jgarzik, dont you know that true art is incomprehensible?
383 2012-11-18 02:48:20 <coyo> therefore bitsofproof's supernode code is True Art
384 2012-11-18 02:49:56 <coyo> https://github.com/bitsofproof/supernode/blob/master/src/com/bitsofproof/supernode/main/Application.java it's actually not to bad in terms of browsability
385 2012-11-18 02:50:00 <coyo> it could be much worse
386 2012-11-18 02:51:33 <jgarzik> The code itself is readable, but the directory tree is not really browsable.  Typical Java project.  When your core code is split across >10 directories, you have a problem ;p
387 2012-11-18 03:02:28 <cjd> I appreciate your calling my project browsable, it's kind of as mess but at least it doesn't fall for the maven /path/path-to/path-to-the/path-to-the-end/path-to-the-end-of/path-to-the-end-of-the/path-to-the-end-of-the-universe antipattern
388 2012-11-18 03:07:04 <xenland> I never liked that about java it seemed like "less files ment more coding per page and vice versa"
389 2012-11-18 03:07:09 <cjd> nice ip addr graet
390 2012-11-18 03:08:21 <coyo> http://lesswrong.com/lw/p1/initiation_ceremony/ this is pretty cool.
391 2012-11-18 03:08:36 <coyo> i wish there was such a real thing as a baysian conspiracy.
392 2012-11-18 03:09:18 <coyo> 192.196.0.0/16? that's pretty cool.
393 2012-11-18 03:09:32 <coyo> *198
394 2012-11-18 04:40:49 <xenland> jgarzik: Are you aware of the reasons behind why pushpool only supports up to 300GH/s, I heard this was due to its single-threaded nature, is this true?
395 2012-11-18 04:43:47 <tyfaust> If I switch bitcoin clients can I keep my same wallet and also not have to re-download the transaction history?
396 2012-11-18 04:45:03 <coyo> ugh. i really hate those people.
397 2012-11-18 04:45:49 <coyo> fucking worthless dumbshits think they are the geniuses of the world, but are more useless pointless arrogant bastards than mensa members.
398 2012-11-18 04:45:54 <doublec> xenland: I would have thought pushpool would hit limitations in bitcoind before pushpool itself
399 2012-11-18 04:46:25 <cjd> coyo: wrong channel
400 2012-11-18 04:46:40 <coyo> cjd, this is one of the few channels i actually like.
401 2012-11-18 04:48:13 <coyo> meh.
402 2012-11-18 04:49:00 <xenland> doublec: Isn't all Bitcoind does is return the work needed how is that any load on Bitcoin?(or am i missing something)
403 2012-11-18 04:50:41 <doublec> xenland: bitcoind pre-0.7 had a single threaded rpc interface, where each call pretty much blocked until complete iirc
404 2012-11-18 04:51:17 <xenland> doublec: 0.7.1?
405 2012-11-18 04:51:26 <doublec> xenland: getwork submissions also have to verify the work
406 2012-11-18 04:52:03 <doublec> xenland: I don't know which version changed it
407 2012-11-18 04:52:14 <xenland> but is the latest version multi-threaded now?
408 2012-11-18 04:52:17 <xenland> or still single
409 2012-11-18 04:52:34 <doublec> I haven't followed the recent changes
410 2012-11-18 04:52:47 <xenland> okay thanks mate
411 2012-11-18 05:06:08 <jgarzik> xenland: correct
412 2012-11-18 05:06:18 <jgarzik> xenland: to be specific, single-threaded database and bitcoind connections
413 2012-11-18 05:06:36 <jgarzik> xenland: solution is obvious (multi-thread it), and it's back up to snuff
414 2012-11-18 05:06:51 <xenland> Thanks jgarzik
415 2012-11-18 05:07:04 <jgarzik> xenland: pull requests welcome :)
416 2012-11-18 05:07:58 <xenland> heh I'm still not that comfertable with the code yet, maybe one day I submit a pull request
417 2012-11-18 05:30:27 <tyfaust> If I switch Bitcoin clients can I keep my same wallet and also not have to re-download the transaction history?
418 2012-11-18 05:32:09 <jgarzik> tyfaust: Do you mean same-client/different-version, or wholly different software?
419 2012-11-18 05:32:48 <jgarzik> tyfaust: The "Satoshi" reference client from bitcoin.org keeps the same wallet.  If you are switching to, say, Armory or MultiBit, the wallet is totally different.
420 2012-11-18 05:40:35 <tyfaust> jgarzik, thanks. that is what I needed to know about the wallet. What about the re-downloading the transaction history with Armory or MultiBit?
421 2012-11-18 05:43:13 <jgarzik> tyfaust: sorry, don't know much about their internal operations
422 2012-11-18 05:43:32 <tyfaust> No worries. Thanks for your help.
423 2012-11-18 06:54:29 <phantomcircuit> !seen gav
424 2012-11-18 06:54:30 <gribble> I have not seen gav.
425 2012-11-18 06:54:44 <gribble> sipa was last seen in #bitcoin-dev 9 hours, 39 minutes, and 9 seconds ago: <sipa> "meh"
426 2012-11-18 06:54:44 <phantomcircuit> !seen sipa
427 2012-11-18 06:57:24 <dudecoin> hi
428 2012-11-18 06:57:56 <amiller> hi dudecoin
429 2012-11-18 06:59:01 <dudecoin> hi amiller... I would like to talk to talk to a bitcoin developer... I think this is the right channel
430 2012-11-18 06:59:12 <amiller> what's your question/concern/topic
431 2012-11-18 06:59:58 <dudecoin> I would like to talk about the "nLockTime"
432 2012-11-18 07:01:42 <dudecoin> anyone?
433 2012-11-18 07:01:46 <amiller> what about nlocktime
434 2012-11-18 07:02:57 <dudecoin> can I make a tx with nLockTime to be released in the future? Lets say... 300 blocks ahead.
435 2012-11-18 07:03:12 <amiller> yeah that's the way it works
436 2012-11-18 07:03:22 <amiller> afaik it is not currently enabled/enforced though
437 2012-11-18 07:03:23 <dudecoin> ok
438 2012-11-18 07:04:21 <dudecoin> also... in the same tx... I would like it to have an script with a condition
439 2012-11-18 07:08:57 <dudecoin> like: nLockTime=300. The script would have to validate this: IF (nLockTime>300) THEN <the payment have to be returned> ELSE <check if a proof of work is valid>
440 2012-11-18 07:10:46 <dudecoin> nLockTime=300 in my example means "active block number + 300 block ahead"
441 2012-11-18 07:12:12 <dudecoin> ?
442 2012-11-18 07:14:11 <dudecoin> amiller: can you help?
443 2012-11-18 07:16:05 <dudecoin> anyone?
444 2012-11-18 07:19:22 <dudecoin> no one?
445 2012-11-18 07:33:46 <dudecoin> ?
446 2012-11-18 07:39:59 <dudecoin> ??
447 2012-11-18 08:39:02 <dudecoin> anyone?
448 2012-11-18 08:40:57 <muhoo> what does the "id" parameter in the json rpc api do? what's that for?
449 2012-11-18 08:44:03 <Diablo-D3> nothing
450 2012-11-18 08:44:12 <Diablo-D3> jsonrpc 1.0 requires it, but nothing uses it
451 2012-11-18 08:44:32 <Diablo-D3> jsonrpc 2.0 apis like stratum do use it I think, though
452 2012-11-18 08:46:51 <dudecoin> hey... anyone alive?
453 2012-11-18 08:47:09 <dudecoin> I would like to talk to someone about "nLockTime"
454 2012-11-18 08:48:22 <Ferroh> dudecoin, it doesn't work currently because no client enforces it.
455 2012-11-18 08:51:42 <muhoo> Diablo-D3: thanks
456 2012-11-18 08:52:01 <dudecoin> Ferroh: ok... I have read it is disabled right now... but I would like to talk about this feature... can you talk to me about this?
457 2012-11-18 08:52:41 <Ferroh> I see that you are new to IRC :)
458 2012-11-18 08:52:44 <phantomcircuit> ;;bc,blocks
459 2012-11-18 08:52:45 <gribble> 208456
460 2012-11-18 08:52:52 <Diablo-D3> dem blocks
461 2012-11-18 08:52:54 <Ferroh> You'll get farther by asking your question, rather than asking if you can ask ;)
462 2012-11-18 08:53:13 <dudecoin> yes... I just started
463 2012-11-18 08:53:51 <dudecoin> well ok
464 2012-11-18 08:54:23 <dudecoin> I will pm you then
465 2012-11-18 08:55:28 <Ferroh> what?
466 2012-11-18 08:55:29 <Ferroh> no...
467 2012-11-18 08:55:40 <Ferroh> Just ask your question already.
468 2012-11-18 08:55:57 <Ferroh> If someone knows the answer, and they are not AFK, then they will answer.
469 2012-11-18 08:56:19 <dudecoin> like: I would like to setup a new version of the client with this feature enabled.
470 2012-11-18 08:56:32 <Ferroh> Most people will be AFK at the moment, since it is like 5AM EST
471 2012-11-18 08:57:31 <Ferroh> You'd like to patch bitcoind so that it supports nlocktime?
472 2012-11-18 08:57:37 <dudecoin> but my English is not good... well... lets go
473 2012-11-18 08:58:54 <dudecoin> then a tx could be done with nLockTime=300... The script would have to validate this: IF (nLockTime>300) THEN <the payment have to be returned to ALICE btc address> ELSE <check if a proof of work is valid - if valid send to BOB btc address>
474 2012-11-18 08:59:50 <Ferroh> Okay, but you realize that everyone would have to use a client that enforces nlocktime, right?
475 2012-11-18 09:00:07 <Ferroh> It is not enough to merely design your own personal client that supports nlocktime.
476 2012-11-18 09:00:21 <dudecoin> I would like if a tx could have a script with nLockTime and a condition like IF/ELSE inside
477 2012-11-18 09:00:36 <Ferroh> I know.
478 2012-11-18 09:00:40 <xenland> Maybe he is not talking about changing the protocal ferroh
479 2012-11-18 09:00:59 <dudecoin> yes... I could make it a new fork to make tests
480 2012-11-18 09:01:17 <Ferroh> xenland: nlocktime already exists but AFAIK no clients actually enforce the nlocktime rule
481 2012-11-18 09:01:26 <Ferroh> That is my understanding, anyway.
482 2012-11-18 09:01:56 <dudecoin> well... I dont know if it is changing the protocol... I think it is not a good idea... I just need to understand if my idea is right or not
483 2012-11-18 09:03:46 <dudecoin> the main idea is to make the nLockTime enabled... lets make an example... setup a tx with script inside... the script have nLockTime=300 and a IF/ELSE condition.
484 2012-11-18 09:03:59 <dudecoin> I need to know if it is possible or I'm talking bs
485 2012-11-18 09:05:59 <xenland> What is the purpose of doing all this?
486 2012-11-18 09:06:14 <xenland> like why are you needing to do anything with nLockTime
487 2012-11-18 09:07:01 <dudecoin> well... if it is possible? if it is possible I can continue...
488 2012-11-18 09:07:34 <dudecoin> xenland: is it possible? if it is possible I have a use for it...
489 2012-11-18 09:08:31 <dudecoin> a tx with script, nLockTime and  IF/ELSE inside the script...
490 2012-11-18 09:09:51 <xenland> I wouldn't know i don't know the purpose of nLockTime but perhabs there are some inactive OP_CODES that could assit you with your problem in the near future
491 2012-11-18 09:10:24 <dudecoin> ok...
492 2012-11-18 09:10:42 <dudecoin> see... I have read a little about nLockTime...
493 2012-11-18 09:11:25 <xenland> It sounds like you want something to happen after X amount of time but if it dosen't happen send the money to BOB
494 2012-11-18 09:12:12 <dudecoin> if I can do a tx that will be pending for sometime... lets say 2 days and also I can put a script  with IF/ELSE inside... I think a p2p trade could be done.
495 2012-11-18 09:13:29 <xenland> I'm not sure why you want a payment to pend so i can think of two ways to do this
496 2012-11-18 09:14:52 <dudecoin> the payment have to be pending... lets say... I want to send you 1 btc... but inside of this btc has a script with nLockTime=300 blocks ahead.
497 2012-11-18 09:15:49 <dudecoin> the payment is pending until 300 blocks.
498 2012-11-18 09:16:42 <dudecoin> The script inside have to validate this: IF (nLockTime>300) THEN <the original payment have to be returned to ALICE> ELSE <check if a proof of work is valid, if it is valid the payment goes to BOB>
499 2012-11-18 09:17:09 <xenland> I don't think I can really help any futher im not exactly sure what your trying to accomplish.
500 2012-11-18 09:18:15 <dudecoin> this is a draft idea to create a p2p exchange
501 2012-11-18 09:20:48 <xenland> AH
502 2012-11-18 09:21:12 <xenland> I think to keep messages in the Bitcoin pool memeory for a p2p exchange would be costly in terms of memory
503 2012-11-18 09:21:40 <xenland> So i dunno if its possible dosen't sound like it at the moment, perhaps you could use authization layers and have multiple ownerships control when it should be moved
504 2012-11-18 09:22:04 <dudecoin> alice sends 1 btc to bob but alice dont trust bob... so she makes a tx with nLockTime=300, and the script inside the tx have to validate this: IF (nLockTime>300) <pay ALICE> ELSE <a) validate a proof of work signed by bob... b) IF (VALID) then pay BOB>
505 2012-11-18 09:22:28 <xenland> There is an OP_CODE propoasl that shows how to do things like "Release Bitcoins when I DIe senarios" but they are not exact they have to be dealt with an out side controller as Bitcoin network can't confirm or deny you wer dead or not
506 2012-11-18 09:23:05 <xenland> dudecoin: dosen't multi-sig solve this kind of trust issue?
507 2012-11-18 09:24:28 <dudecoin> I think no
508 2012-11-18 09:25:34 <xenland> Maybe you don't understand the uses of multi-sig :P
509 2012-11-18 09:26:29 <dudecoin> in this scenery BOB has the payment alread sent to him but it is not released... to release the payment bob needs to provide a prof of work
510 2012-11-18 09:27:41 <dudecoin> if he do not provide a prof of work in the accorded time the payment will return to alice,
511 2012-11-18 09:28:03 <dudecoin> I cant see the multi-sign doing this
512 2012-11-18 09:29:08 <xenland> Oh i see you need it done in a maximum time frame
513 2012-11-18 09:29:16 <xenland> and trust is needed
514 2012-11-18 09:30:44 <dudecoin> I will try again... how to solve this: I send you 1 btc and you have to provide a proof of work... if you do not provide it until 300 blocks ahead you have to return the coins to me.
515 2012-11-18 09:31:54 <dudecoin> I think muti-sign cant solve this... but a tx with nLockTime and IF/ELSE inside could.
516 2012-11-18 09:32:48 <dudecoin> what do you think?
517 2012-11-18 09:33:09 <xenland> Sounds sound
518 2012-11-18 09:35:19 <dudecoin> so... my idea is ok?
519 2012-11-18 09:35:51 <dudecoin> are you a core developer?
520 2012-11-18 09:37:44 <xenland> No like i said earlyer I don't know what nLockTime does exactly as in I can't confirm or deny if it will work according to my research your idea "Is sound"
521 2012-11-18 09:39:27 <dudecoin> ;)
522 2012-11-18 09:39:39 <Diablo-D3> grumble
523 2012-11-18 09:39:57 <dudecoin> who do you think could help me?
524 2012-11-18 09:41:36 <xenland> jgarzik! What do you think about dudecoins p2p exchange idea to use OP_CODES if and the nLOCKTIME (assuming nLockTime was enforced)
525 2012-11-18 09:41:49 <xenland> (If/when jgarzik is available to take alook he will answer)
526 2012-11-18 09:43:01 <dudecoin> thanks xenlad!
527 2012-11-18 09:43:46 <phantomcircuit> dudecoin, a truly p2p exchange isn't possible unless you trust people to clear
528 2012-11-18 09:43:57 <phantomcircuit> and im not talking the bitcoin side of it
529 2012-11-18 09:46:39 <dudecoin> phantomcircuit:  I think my idea could solve this problem... cause ALICE already have sent to BOB the payment... BOB know it is there... but he have to release this payment providing a valid POW or the coins will return to ALICE
530 2012-11-18 09:47:45 <dudecoin> BOB is challenged to solve the problem. ALICE just have to wait
531 2012-11-18 09:51:21 <phantomcircuit> dudecoin, and in the meantime the price changes and BOB cancelled the trade
532 2012-11-18 09:52:44 <Eliel> would alice have the incentive in that situation to finish the proof of work?
533 2012-11-18 09:52:50 <dudecoin> if BOB do not agree to provide to POW he don't need to do anything... the coins will be returned to ALICE
534 2012-11-18 09:53:57 <phantomcircuit> that's kind of the point
535 2012-11-18 09:54:19 <phantomcircuit> dudecoin, you have two people who dont trust each other at all
536 2012-11-18 09:54:29 <phantomcircuit> come up with a way for them to exchange without escrow
537 2012-11-18 09:54:37 <phantomcircuit> that's the problem a p2p exchange is trying to solve
538 2012-11-18 09:54:39 <phantomcircuit> fundamentally
539 2012-11-18 09:54:43 <phantomcircuit> and it's not easy
540 2012-11-18 09:55:45 <dudecoin> you have to understand that this trade is a scrow itself...
541 2012-11-18 09:56:35 <dudecoin> lets say the proof of work is a signed message. only who holds a private key could sign it. so a valid proof of work is validated by the network
542 2012-11-18 09:57:03 <phantomcircuit> uh no it's not
543 2012-11-18 09:57:11 <phantomcircuit> it's proof that you have the bitcoins
544 2012-11-18 09:57:16 <dudecoin> no?
545 2012-11-18 09:57:44 <dudecoin> if you signs a message anyone in the network could check it, or I'm wrong?
546 2012-11-18 09:57:48 <phantomcircuit> what you've described is just a timed lock with a race
547 2012-11-18 09:58:35 <dudecoin> yes... it is a lock and yes it is a race to solve a problem.
548 2012-11-18 09:59:39 <Eliel> dudecoin: ok, so you've described the trick you want to do. I couldn't see an explanation of what it accomplishes though. What's the point?
549 2012-11-18 09:59:42 <dudecoin> the default winner is ALICE but only if BOB fails to provide a valid proof of work.
550 2012-11-18 10:00:00 <Eliel> what is accomplished by forcing bob to provide proof of work?
551 2012-11-18 10:00:55 <dudecoin> Eliel then all kind of P2P exchange could be done.
552 2012-11-18 10:01:11 <Eliel> too vague, explain what the proof of work helps in it
553 2012-11-18 10:02:04 <dudecoin> ok. lets say: BOB have to provide a proof of work that he have paid my LTC address Lxxxxxxx
554 2012-11-18 10:02:39 <dudecoin> hhe have do provide a signed message using a private key used in the payment
555 2012-11-18 10:04:08 <dudecoin> only the person who have made the payment can sign a valid message.. that is verified by the network... or I'm wrong?
556 2012-11-18 10:04:17 <Eliel> proof of work only proves you spent a lot of time calculating something. It proves nothing else.
557 2012-11-18 10:05:06 <muhoo> i'll ask tomorrow if needed, but if someone can send me some TEST NETWORK coins to mfYBFUnwbgmVusgdmFWC1VJxWVzq1TGFtU, i'd like to have some for testing an app
558 2012-11-18 10:05:38 <dudecoin> Eliel: no... he have to hold the address that have made the payment to the Lxxxx address
559 2012-11-18 10:06:10 <dudecoin> if he do not have the address he cant release the payment
560 2012-11-18 10:07:49 <dudecoin> understood?
561 2012-11-18 10:07:55 <Eliel> no, not really.
562 2012-11-18 10:08:08 <Eliel> I'm trying to figure out what the proof of work is for here.
563 2012-11-18 10:08:35 <dudecoin> the proof of work I'm talking about is a signed message
564 2012-11-18 10:08:46 <dudecoin> not the work
565 2012-11-18 10:09:05 <Eliel> that's a signature, not proof of work then
566 2012-11-18 10:10:12 <dudecoin> no
567 2012-11-18 10:11:30 <Eliel> proof of work == trying new, slightly different, messages until you find one with a hash that's less than difficulty.
568 2012-11-18 10:12:26 <Eliel> signature == a hash of a message signed with a private key using the ECDSA algorithm.
569 2012-11-18 10:13:37 <dudecoin> signature is ok...
570 2012-11-18 10:16:15 <dudecoin> proof of work I'm talking here is e.g.: you have to sign "this is the transaction id 12345" using the same address that have made the payment.
571 2012-11-18 10:17:46 <Eliel> proof of work is the wrong word for that.
572 2012-11-18 10:17:52 <Eliel> causes misunderstandings
573 2012-11-18 10:18:15 <dudecoin> I think it is ok
574 2012-11-18 10:19:31 <dudecoin> see lets say Alice and Bob want to trade 1 Bitcoin to 10 Litecoin. Alice addresses = 1Alice and LAlice. Bob adresses = 1Bob and L Bob
575 2012-11-18 10:23:36 <dudecoin> Alice send a tx to 1Bob and the proof of work that Bob have to provide = "ok" signed with LBob address.
576 2012-11-18 10:25:12 <dudecoin> if Bob cant provide this signed message he fails to release the coins...
577 2012-11-18 10:27:21 <XertroV> Hey, has anyone thought about using GPUs for block validation?
578 2012-11-18 10:48:27 <Eliel> I got myself an SSD for my laptop a few days ago. Might make sense to test the speed too :)
579 2012-11-18 10:48:44 <XertroV> i7-3615QM
580 2012-11-18 10:51:39 <Eliel> my laptop only has a core2duo P8400 @ 2.26Ghz :)
581 2012-11-18 11:09:17 <SomeoneWeird> <XertroV> Just seemed like a possibility, given that block generation works well on a GPU. But I imagine we're not at the stage of parallelising verification in any case, otherwise we'd have multicore. Anyway, just thought I'd mention in. < you can't
582 2012-11-18 11:10:20 <xenland> <xenland> Oh i see you need it done in a maximum time frame
583 2012-11-18 11:10:21 <xenland> <xenland> and trust is needed
584 2012-11-18 11:10:28 <xenland> ^ me earlyer :P
585 2012-11-18 11:10:55 <XertroV> Maximum timeframe? Are you talking about it just being computationally hard?
586 2012-11-18 11:27:12 <phantomcircuit> XertroV, there is an experimental pipelined verification of transactions
587 2012-11-18 11:27:18 <graingert> it's still IO bound so it hardly matters
588 2012-11-18 11:27:48 <phantomcircuit> graingert, with git HEAD ie 0.8.x it's cpu bound
589 2012-11-18 11:28:27 <phantomcircuit> graingert, no it's dropping berkeley db infavor of leveldb
590 2012-11-18 11:28:45 <phantomcircuit> it's funny the on disk stuff doesn't really need the guarantees of ACID
591 2012-11-18 11:28:55 <phantomcircuit> logically it's just a cache for the network status
592 2012-11-18 11:28:57 <graingert> https://github.com/bitcoin/bitcoin/blob/master/src/leveldb/util/bloom.cc
593 2012-11-18 11:29:30 <phantomcircuit> then i guess yes?
594 2012-11-18 11:30:19 <graingert> ololololol
595 2012-11-18 11:32:04 <graingert> phantomcircuit: why isn't it a submodule?
596 2012-11-18 11:37:40 <phantomcircuit> no idea
597 2012-11-18 11:37:49 <graingert> :(
598 2012-11-18 11:38:11 <phantomcircuit> lol asking me why design decisions were made
599 2012-11-18 11:38:18 <phantomcircuit> im not even on the security mailing list
600 2012-11-18 11:38:19 <phantomcircuit> lol
601 2012-11-18 11:38:35 <graingert> :(
602 2012-11-18 11:38:49 <graingert> it's not a design decision
603 2012-11-18 11:40:11 <graingert> is 20 seconds per block expected for 0.7
604 2012-11-18 11:46:46 <phantomcircuit> it varies by transaction count
605 2012-11-18 12:31:14 <graingert> ah
606 2012-11-18 17:26:57 <muhoo> hi all, i'd like some test network coins in order to test a library (simple clojure bitcoind json wrapper). can someone send some to me at mfYBFUnwbgmVusgdmFWC1VJxWVzq1TGFtU ?
607 2012-11-18 17:27:29 <muhoo> i'll send the link to the github of the wrapper if anyone wants it, it's very simple though.
608 2012-11-18 17:28:56 <D34TH> 156e6c00331f161db45141b2e75bf7ed9748aeb4d936635310b6ad6e72c353f8
609 2012-11-18 17:32:54 <D34TH> muhoo, enjoy
610 2012-11-18 17:35:15 <D34TH> i wish testnet diff was lower
611 2012-11-18 17:35:17 <D34TH> D:
612 2012-11-18 17:39:15 <muhoo> d3thanks
613 2012-11-18 17:39:28 <muhoo> D34TH: thanks
614 2012-11-18 17:41:36 <muhoo> still WIP, but this so far: https://www.refheap.com/paste/6820
615 2012-11-18 17:59:33 <sipa> anyone an idea what SER_SKIPSIG was ever used for?
616 2012-11-18 18:20:37 <Amit_btc> I have a question about how bitcoin protocol relays transactions. I read the wiki but still have some doubts
617 2012-11-18 18:21:02 <kjj_> what's your question?
618 2012-11-18 18:21:20 <Amit_btc> When someone sends BTC to someone else, does my client also receive the unconfirmed transaction?
619 2012-11-18 18:21:28 <Amit_btc> or I only get confirmed ones
620 2012-11-18 18:21:31 <Amit_btc> ?
621 2012-11-18 18:22:16 <Amit_btc> I am neither the sender nor receiver
622 2012-11-18 18:23:49 <kjj_> short answer is yes
623 2012-11-18 18:24:41 <kjj_> it is possible for some transactions to never show up at your node, and for others to only show up when they are included in a block
624 2012-11-18 18:24:58 <kjj_> but for the most part, your node sees transactions, even when your wallet isn't party to it
625 2012-11-18 18:25:07 <Amit_btc> What if I only want to receive (1) if I am the receiver or (2) it is in a block
626 2012-11-18 18:25:29 <sipa> Amit_btc: then you will not run a full node
627 2012-11-18 18:25:43 <kjj_> I can't imagine why you would want to do that, but if you really do, you'll have to hack the client pretty badly
628 2012-11-18 18:25:58 <Amit_btc> its the neighbors who will have to change
629 2012-11-18 18:26:00 <kjj_> basically, you don't know if you want the transaction or not until AFTER you already have it
630 2012-11-18 18:26:34 <Amit_btc> kjj_: yes that makes sense :)
631 2012-11-18 18:26:46 <sipa> Amit_btc: if you don't receive all transactions, you can't relay them yourself
632 2012-11-18 18:26:53 <sipa> Amit_btc: and that would be bad for the network
633 2012-11-18 18:26:55 <Amit_btc> so what does the client do? does it forget them?
634 2012-11-18 18:27:09 <sipa> it keeps them in memory until they're in a block
635 2012-11-18 18:27:16 <Amit_btc> ok
636 2012-11-18 18:27:27 <Amit_btc> thanks
637 2012-11-18 18:27:32 <Amit_btc> that clears up a lot
638 2012-11-18 18:27:32 <sipa> however, there is very recent work going on to extend the protocol
639 2012-11-18 18:27:44 <sipa> which would allow for server-side filtering
640 2012-11-18 18:27:54 <Amit_btc> sipa: what kind of filtering?
641 2012-11-18 18:28:02 <sipa> (both for non-confirmed transactions and transactions in blocks)
642 2012-11-18 18:28:29 <Amit_btc> does my default client also participate in mining
643 2012-11-18 18:28:34 <Amit_btc> ?
644 2012-11-18 18:28:45 <sipa> if you make it
645 2012-11-18 18:29:02 <sipa> it would allow nodes to create a filter description (using bloom filters on hashed properties of transactions), send that to their peer, and expect the peer to only relay transactions that match the filter
646 2012-11-18 18:29:08 <Amit_btc> In that case I would need those unconfirmed transactions
647 2012-11-18 18:29:41 <sipa> Amit_btc: mining is a very specialized business, and although there is still code in the reference client to do it, it is not optimized and only works on the CPU
648 2012-11-18 18:29:56 <sipa> it's not enabled by default, and not accessible from the GUI
649 2012-11-18 18:30:11 <sipa> most of the mining power these days comes from GPUs and FPGAs
650 2012-11-18 18:30:18 <sipa> soon, maybe also from ASICs
651 2012-11-18 18:30:49 <Amit_btc> ok
652 2012-11-18 18:31:14 <sipa> Amit_btc: you need the memory pool (the list of non-confirmed transactions) to assess the validity of other non-confirmed transactions (as they may depend on eachother)
653 2012-11-18 18:31:46 <sipa> without the memory pool, you wouldn't be able to verify whether even only transactions to yourself are valid
654 2012-11-18 18:31:53 <Amit_btc> yes (in case of satoshi dice)
655 2012-11-18 18:31:59 <sipa> in any case
656 2012-11-18 18:32:28 <sipa> though yes; they are a large source of unconfirmed transactions depending on other unconfirmed transactions
657 2012-11-18 18:33:34 <Amit_btc> Im just a bit concerned about the network traffic generated
658 2012-11-18 18:34:01 <sipa> if you're not willing to participate as a full node, don't run one
659 2012-11-18 18:37:17 <Amit_btc> so if I receive a new transaction referencing another previous transaction I dont have in the pool or the block chain, would I consider it valid or not?
660 2012-11-18 18:37:30 <sipa> no
661 2012-11-18 18:38:08 <Amit_btc> even though it could still be valid
662 2012-11-18 18:38:34 <kjj_> it is an orphan until you can verify all of the input transactions
663 2012-11-18 18:38:44 <Amit_btc> i see
664 2012-11-18 18:40:02 <kjj_> there is a limit to how many orphan Tx a node will keep in memory before it starts dumping them
665 2012-11-18 18:41:59 <sipa> yes, 10000
666 2012-11-18 19:17:06 <jgarzik> 10000?!?!?!?!?!
667 2012-11-18 19:17:09 <jgarzik> zomg
668 2012-11-18 19:18:16 <D34TH> i feel that number is large based on jgarzik's response
669 2012-11-18 19:19:24 <sipa> yes
670 2012-11-18 19:19:38 <jgarzik> hehehe
671 2012-11-18 19:19:43 <sipa> it's over NINE THOUSAND </Diablo-D3>
672 2012-11-18 19:23:31 <Diablo-D3> !
673 2012-11-18 19:23:42 <Diablo-D3> what, over nine thousand?!
674 2012-11-18 19:24:29 <Luke-Jr> that's ALMOST 7 BITCOINS
675 2012-11-18 19:26:23 <sipa> my arithmetic is failing me
676 2012-11-18 19:26:26 <sipa> the source code says
677 2012-11-18 19:26:37 <sipa> // 10,000 orphans, each of which is at most 5,000 bytes big is
678 2012-11-18 19:26:43 <sipa> // at most 500 megabytes of orphans:
679 2012-11-18 19:27:11 <sipa> have bytes shrunk by a factor of 10 lately?
680 2012-11-18 19:28:14 <cjd> ;;calc (10000*5000) / 1000000
681 2012-11-18 19:28:14 <gribble> 50
682 2012-11-18 19:28:24 <sipa> thanks!
683 2012-11-18 19:28:28 <jgarzik> sipa: heh
684 2012-11-18 19:28:35 <cjd> I can't do arithmatic either
685 2012-11-18 19:28:42 <jgarzik> sipa: there is of course the caveat that stored orphans are size-limited
686 2012-11-18 19:28:52 <jgarzik> If the orphan is too big, it just gets dropped.
687 2012-11-18 19:28:56 <sipa> yes
688 2012-11-18 19:30:35 <cjd> so I suppose there's a way to be unfriendly there by generating lots of transactions
689 2012-11-18 19:31:31 <sipa> well, orphans are not relayed
690 2012-11-18 19:31:41 <sipa> so you'd have a hard time propagating them
691 2012-11-18 19:32:01 <cjd> orphans? that means ones which didn't make it into the last block?
692 2012-11-18 19:32:57 <cjd> oh orphans are transactions which reference transactions which have not made it?
693 2012-11-18 19:32:57 <sipa> orphan transaction = a transaction that spends an output of an unknown transaction
694 2012-11-18 19:33:02 <cjd> gotit
695 2012-11-18 19:33:20 <sipa> unknown means neither in the block chain or in the memory pool in this case
696 2012-11-18 19:33:24 <cjd> /nod
697 2012-11-18 19:35:13 <cjd> you could probably generate a few MB/s of technically valid transactions but without nearly enough fees to get into the chain..
698 2012-11-18 19:37:14 <cjd> otoh nodes could have a limit of what they're willing to relay and when they limit out, they only relay the transactions with the highest fees
699 2012-11-18 19:38:29 <sturles> On the other hand miner nodes have an incentive to keep transactions with th highest fees to themselves, not relaying..
700 2012-11-18 19:39:04 <cjd> yeah but not everybody is a miner and that incentive is (for the moment) microscopic
701 2012-11-18 19:39:53 <cjd> the real concern (or perhaps it is acceptable) is a miners union which sets the price of transactions and will orphan any block which contains transactions with less fees than their number
702 2012-11-18 19:48:01 <Luke-Jr> cjd: that would be abuse :P
703 2012-11-18 19:49:14 <cjd> interestingly it would also be a way for governments to tax bitcoin
704 2012-11-18 19:49:32 <cjd> after all, tax is payment of tribute to the most powerful people in the land
705 2012-11-18 19:49:55 <cjd> and when power is measured in Gh/s, tax is payment to the mining unions
706 2012-11-18 20:04:07 <Luke-Jr> cjd: ??? governments already tax bitcoin
707 2012-11-18 21:02:49 <dudecoin> hi amiller
708 2012-11-18 21:34:08 <jgarzik> dudecoin: please ask bitcoin questions in-channel
709 2012-11-18 21:34:15 <jgarzik> dudecoin: PMs are annoying, and deny others knowledge
710 2012-11-18 21:35:02 <dudecoin> jgarzik: my English is not good
711 2012-11-18 21:35:42 <dudecoin> have you read the xenland question?
712 2012-11-18 21:36:23 <sipa> the xenland question?
713 2012-11-18 21:36:48 <dudecoin> about nLOCKTIME
714 2012-11-18 21:36:54 <sipa> where?
715 2012-11-18 21:37:15 <dudecoin> have to check in the logs
716 2012-11-18 21:38:35 <sipa> nLocktime is independent from the script code
717 2012-11-18 21:39:00 <sipa> it just enforces a minimum time/block at which the transactio can become valid
718 2012-11-18 21:39:56 <dudecoin> xenland\tjgarzik! What do you think about dudecoins p2p exchange idea to use OP_CODES if and the nLOCKTIME (assuming nLockTime was enforced)
719 2012-11-18 21:40:33 <sipa> nLocktime is enforced
720 2012-11-18 21:41:00 <sipa> but scripts cannot observe this
721 2012-11-18 21:41:12 <sipa> also, scripts do not control the outputs, only the validity
722 2012-11-18 21:41:51 <dudecoin> sipa: my draft idea is to create a tx with nLOCKTIME=300 and also have a script inside the tx to validate a signed message.
723 2012-11-18 21:42:38 <sipa> what is the point of that?
724 2012-11-18 21:42:42 <sipa> the message can't change
725 2012-11-18 21:43:40 <dudecoin> well, I dont know if my idea is right... this is why I need to talk to btc experienced developers...
726 2012-11-18 21:43:51 <Luke-Jr> sipa: "to accept this payment, you need to agree to this contract"?
727 2012-11-18 21:45:22 <sipa> dudecoin: what you can do (once transaction replacement is reenabled) is have two transactions, one with nLockTime=<sometime> with output to so,eone, and another replacing unbroadcasted one that sends the coins back to yourself
728 2012-11-18 21:45:50 <sipa> so by announcing the second transaction, you basically cancel the first one
729 2012-11-18 21:46:22 <sipa> wait, i'm missing something
730 2012-11-18 21:48:03 <dudecoin> My idea is like: Alice pay 1 btc to Bob. This tx has nLOCKTIME=300 and a script inside... Bob have to pay Alice 100 LTC and provide a signed message (a prof) that he owns the LTC address that have paid Alice.
731 2012-11-18 21:49:44 <cjd> is proving that Bob owns a given LTC address the final goal or is there more?
732 2012-11-18 21:49:57 <dudecoin> if he do not provide a proper signed message before 300 blocks ahead... the coins return to Alice...it he provide a proper signed message the operation is finished and BOB owns the coins
733 2012-11-18 21:51:24 <cjd> if you can explain the final goal, there's probably some dusty op code laying around in the bitcoin source which does exactly that..
734 2012-11-18 21:51:49 <sipa> dudecoin: scripts do not control the output, and cannot observe the time
735 2012-11-18 21:52:22 <dudecoin> BOB have to proof he have made a payment to Alice... the way to check if he have made a payment is to ask him to sign a message using the same public key that have made the payment to Alice...
736 2012-11-18 21:53:02 <sipa> that certainly doesn't prove he made a payment
737 2012-11-18 21:54:20 <cjd> if alice uses the same address all of the time.. then bob can pay that addr and sign a message saying he had done so using the same key and if it ever comes up, he can show the message proving that at that time, he had the key
738 2012-11-18 21:54:43 <cjd> if alice uses a different address all the time, then bob has no way to prove that he didn't just pay himself
739 2012-11-18 21:54:58 <cjd> unless he gets some kind of signed reciept
740 2012-11-18 21:55:52 <cjd> Alice could give Bob a signed message saying "when X bitcoin has been paid to address Y, you are now entitled to ..."
741 2012-11-18 21:56:05 <cjd> Bob puts bitcoin in address Y then holds the message to show to the judge
742 2012-11-18 21:56:29 <dudecoin> no? well, I think it proofs 1Alice, LAlice are Alices BTC and LTC public keys... 1Bob and LBob are Bob BTC and LTC public keys... Alice send a 1 btc to Bob using 1Alice... Bob send 1 LTC to LAlice using LBob... LSipa can't proof he made the transaction but LBob can.
743 2012-11-18 21:56:32 <sipa> even then, scripts can't look into the future
744 2012-11-18 21:57:06 <cjd> if you can make an address which starts with 1Alice then surely I can too :)
745 2012-11-18 21:57:25 <sipa> scripts are either valid or invalid, and independent from that final or non-final
746 2012-11-18 21:58:07 <sipa> but their validness or their outputs can never depend on any data outside of the transaction
747 2012-11-18 21:58:20 <cjd> dudecoin: are Alice and Bob doing an exchange of BTC for LTC without trust?
748 2012-11-18 21:59:20 <dudecoin> yes!
749 2012-11-18 21:59:32 <cjd> ahh
750 2012-11-18 21:59:36 <dudecoin> there are only Alice, Bob and the network
751 2012-11-18 22:01:06 <cjd> Bitcoin can't tell if an LTC transaction has gone through or not so this approach doesn't really work.. either Alice or Bob has the power to abuse it depending on the rules.
752 2012-11-18 22:01:10 <sipa> dudecoin: any real solution to that will need a transaction that can observe the state of the other chain
753 2012-11-18 22:01:11 <sipa> dudecoin: any real solution to that will need a transaction that can observe the state of the other chain
754 2012-11-18 22:01:38 <sipa> and that requires a proof the size of that other block chain
755 2012-11-18 22:01:46 <cjd> What does work, although it is awkward, is to use a multisig escrow transaction..
756 2012-11-18 22:01:47 <dudecoin> this is the step 2 of the history...
757 2012-11-18 22:02:56 <cjd> Alice pays Bob 100 BTC (because lets face it, nobody cares if it's 1) but the script is an escrow where both Alice and Bob have to sign off on it.  Bob pays the alt coins to alice, then they sign off and everyone's happy.
758 2012-11-18 22:03:14 <cjd> Or Bob doesn't pay and Alice doesn't sign, she loses the BTC but Bob doesn't get it.
759 2012-11-18 22:04:09 <cjd> If Alice is worried about Bob being a Dick and making her lose the BTC, she sends an escrowed ANYONECANPAY transaction which is underfunded and force Bob to put in some BTC of his own before it even becomes valid.
760 2012-11-18 22:04:25 <dudecoin> Alice dont need to sign again...
761 2012-11-18 22:04:38 <cjd> she has to sign again to release it from escrow
762 2012-11-18 22:04:50 <cjd> assuming the goods have been delivered
763 2012-11-18 22:05:09 <dudecoin> it is like a race... the default owner is Alice... unless Bob does his side work and proof he did.
764 2012-11-18 22:05:32 <cjd> that doesn't work either
765 2012-11-18 22:05:43 <dudecoin> * owner=winner
766 2012-11-18 22:05:50 <cjd> because if you do it that way, Bob delivers the goods and then Alice doesn't sign and she takes the loot.
767 2012-11-18 22:06:10 <cjd> it works because if Alice doesn't sign, noone gets the money.
768 2012-11-18 22:06:35 <dudecoin> that's not what I'm talking about...
769 2012-11-18 22:06:57 <cjd> nah, it's my method.. :)
770 2012-11-18 22:07:44 <sipa> i'm not sure how you want to accomplish doing an exchange between separatr chains, when transactions cannot observe the other chain
771 2012-11-18 22:08:31 <sipa> and even if it could, it would be vulnerable to a reversed spend
772 2012-11-18 22:08:40 <dudecoin> The way I'm thinking is Alice pay bob. And the payment is in Bob address... but he have to proof he did another work. If he do not proof the payment return to Alice after some time.
773 2012-11-18 22:09:41 <dudecoin> the observer is in the 2nd part of the history... I need to see if the 1st part is ok
774 2012-11-18 22:10:07 <dudecoin> Lets discuss the 1st part... the 2nd I will tell if the 1st part is sound.
775 2012-11-18 22:10:33 <dudecoin> if the 1st part is bs, well there are nothing to see on the 2nd part. ;)
776 2012-11-18 22:11:55 <dudecoin> the nLOCKTIME and the script can't work to do this?
777 2012-11-18 22:12:56 <dudecoin> or there are another way to do this?
778 2012-11-18 22:14:48 <dudecoin> or there are no way to do this?
779 2012-11-18 22:15:15 <sipa> not the way you describe
780 2012-11-18 22:15:35 <cjd> the problem is higher level, either Bob forges the proof or Alice refuses to give the validator up when Bob transfers the goods..
781 2012-11-18 22:15:42 <sipa> transactions cannot be conditional on some external propertry
782 2012-11-18 22:15:53 <sipa> they are valid or not valid
783 2012-11-18 22:16:10 <sipa> never "not yet valid"
784 2012-11-18 22:16:46 <dudecoin> cjd: Alice do not validate anything after she have paid bob...
785 2012-11-18 22:17:10 <cjd> you could create a transaction where to spend it they needed a password or something but there's no way for the LTC chain to yield that password upon a transfer
786 2012-11-18 22:17:21 <dudecoin> she have to do nothing... if bob do not do his side work the default action of the transaction is to return to her.
787 2012-11-18 22:17:55 <cjd> right and there's no way for Bob to prove that he paid her LTC
788 2012-11-18 22:19:32 <dudecoin> cjd: he is providing only a signed message that is valid or not... is not it like a password? there are only 2 result for a password: valid or invalid
789 2012-11-18 22:20:33 <dudecoin> cjd: no... only BOB has the public key that have made the payment to alice.
790 2012-11-18 22:21:11 <dudecoin> Lcjd != LBob. so Lcjd cant sign a message using LBob address
791 2012-11-18 22:21:54 <cjd> I can't really explain why I think it won't work so all I can say is start coding it and if it works then I'm a fool..
792 2012-11-18 22:23:15 <dudecoin> I'm not a coder so I cant do this work. But I have ideas and need to discuss with developers...
793 2012-11-18 22:24:16 <cjd> easy to change that http://learnpythonthehardway.org/
794 2012-11-18 22:24:44 <cjd> the benefit of learning to program is you get to actually see your ideas happen
795 2012-11-18 22:25:08 <dudecoin> if my idea is not ok, sign a message using any of your BTC  address for a transaction that I did.
796 2012-11-18 22:25:21 <cjd> https://github.com/floodyberry/scrypt-jane/blob/master/example.c <-- sexy
797 2012-11-18 22:25:44 <dudecoin> if you can I will believe my idea is wrong.
798 2012-11-18 22:27:40 <dudecoin> ;)
799 2012-11-18 22:29:02 <dudecoin> cjd: can you sign a message using any of my BTC address?
800 2012-11-18 22:29:22 <dudecoin> no?
801 2012-11-18 22:31:13 <dudecoin> understand now?
802 2012-11-18 22:33:31 <Luke-Jr> dudecoin: I'd be glad to demonstrate a double-spend attack???
803 2012-11-18 22:33:53 <dudecoin> ok
804 2012-11-18 22:35:24 <dudecoin> I think it is not possible to anyone to sign a message using someone else keys
805 2012-11-18 22:38:35 <dudecoin> 1Alice did a payment to 1Bob... LBob send 1 LTC to LAlice. Then LLukeJr, sign a message to proof he is LBob. How?
806 2012-11-18 22:39:29 <dudecoin> LLukeJr != LBob.
807 2012-11-18 22:41:09 <dudecoin> nodes in the network will reject it LLukeJr == LBob
808 2012-11-18 22:44:31 <dudecoin> Luke-Jr: what do you think?
809 2012-11-18 22:44:38 <Luke-Jr> dudecoin: there is no LLukeJr
810 2012-11-18 22:45:20 <dudecoin> well LAnyone then... how LAnyone can sign a message using LBob keys?
811 2012-11-18 22:45:35 <Luke-Jr> LBob signs a transaction pretending to send 1 LTC to LAlice, and gets his payment. Immediately, he also sends a double-spend of those LBob inputs to himself, invalidating the one he used to claim the Bitcoins
812 2012-11-18 22:45:52 <Luke-Jr> Bob ends up with both Bitcoins and scamcoins
813 2012-11-18 22:47:31 <cjd> for whatever that's worth ;)
814 2012-11-18 22:48:31 <dudecoin> no... he cant pretend
815 2012-11-18 22:49:19 <dudecoin> he have to do the payment then he have to proof the LAlice has the payment
816 2012-11-18 22:50:08 <cjd> well there's no actual difference between a transaction that he released and got into the LTC chain and a transaction what is still sitting on his computer.. it's the same data
817 2012-11-18 22:50:09 <cjd> well there's no actual difference between a transaction that he released and got into the LTC chain and a transaction what is still sitting on his computer.. it's the same data
818 2012-11-18 22:50:38 <cjd> so he creates the LTC tx to pay alice but instead of submitting it, he collects the BTC using it and then deletes it
819 2012-11-18 22:50:40 <dudecoin> a) he makes the payment...
820 2012-11-18 22:51:30 <dudecoin> at this point he will lose the 1 btc and 1 LTC if he do not proof he made the 1 LTC transaction to LAlice.
821 2012-11-18 22:51:50 <Luke-Jr> ???
822 2012-11-18 22:52:01 <Luke-Jr> dudecoin: I can prove I made the 1 LTC to Alice WITHOUT LOSING 1 LTC
823 2012-11-18 22:52:02 <cjd> ???
824 2012-11-18 22:52:03 <dudecoin> b) he sign a message using any of the input address used in the payment to LAlice... no other address is valid
825 2012-11-18 22:52:40 <Luke-Jr> dudecoin: do you know WHY the blockchain exists?
826 2012-11-18 22:53:43 <dudecoin> you have to make the payment and also have to provide a signed message using a address used in the payment to LAlice. How if LAlice has 0 coins... it is also invalid
827 2012-11-18 22:54:58 <dudecoin> yes and this is why the idea I have only work for trades using blockchains... it cant work for paypal coins
828 2012-11-18 22:55:12 <Luke-Jr> dudecoin: you can't know LAlice has 0 coins no matter what you do with signatures
829 2012-11-18 22:57:00 <cjd> If script was touring complete you could force them to push the tx to the stack along with the merkle branch leading back to the header and then prove that the header hash has the correct difficulty
830 2012-11-18 22:57:14 <cjd> but that would be the most outrageous abuse of script imaginable
831 2012-11-18 22:58:05 <dudecoin> Luke-Jr: no? the script inside a tx can't store small string information?
832 2012-11-18 22:58:38 <Luke-Jr> dudecoin: irrelevant
833 2012-11-18 22:59:01 <dudecoin> not irrelevant.
834 2012-11-18 22:59:11 <dudecoin> it is relevant.
835 2012-11-18 22:59:27 <dudecoin> it can store LAlice information that have to be paid by Bob
836 2012-11-18 22:59:40 <cjd> if you predicted the length of the merkle branch in advance you could use a bunch of OP_IF OP_SWAP OP_HASH to validate a merkle branch and finish it with an OP_LT
837 2012-11-18 23:00:06 <cjd> and you'd have a 100k transaction
838 2012-11-18 23:00:24 <cjd> and need to pay more than the LTC market cap in fees
839 2012-11-18 23:01:05 <weex> dudecoin: how do you deal with double-spends?
840 2012-11-18 23:01:22 <dudecoin> so... it could be stores in namecoin chain... I can write anything inside of the tx
841 2012-11-18 23:02:10 <cjd> OP_PUSH "please please please don't double spend this transaction" OP_DROP
842 2012-11-18 23:02:23 <weex> cjd: seems to be the best solution so far
843 2012-11-18 23:02:39 <cjd> the please please one or the merkle branch hell?
844 2012-11-18 23:02:49 <weex> please please...could add a pretty in there
845 2012-11-18 23:02:53 <cjd> :D
846 2012-11-18 23:03:16 <weex> this whole thing is about escrow right?
847 2012-11-18 23:03:42 <weex> or a cross-chain transaction
848 2012-11-18 23:03:43 <weex> or a cross-chain transaction
849 2012-11-18 23:03:47 <cjd> 
ACTION wonders if you could implement sha256 using the C preprocessor :)

850 2012-11-18 23:03:54 <dudecoin> weex: signedmessage and verifymessage validate the transaction
851 2012-11-18 23:04:27 <dudecoin> scrow and cross-chain
852 2012-11-18 23:04:28 <dudecoin> scrow and cross-chain
853 2012-11-18 23:04:47 <weex> dudecoin: but you have to wait for confirmations to trust anything
854 2012-11-18 23:04:50 <dudecoin> scrow... trades between chains
855 2012-11-18 23:05:09 <Luke-Jr> cjd: I guess you could abuse OP_IF to make it work XD
856 2012-11-18 23:05:44 <cjd> yeap, kind of like my 8 bit adding machine using #if
857 2012-11-18 23:06:04 <dudecoin> weex: this is in the 2nd part of the idea... but only 1 chain start the trade BTC...
858 2012-11-18 23:06:15 <cjd> cross platform __COUNTER__ ftw
859 2012-11-18 23:08:16 <dudecoin> weex: yes... after 6 confirmations are ok, no?
860 2012-11-18 23:08:55 <weex> depends on the value but ok...so your lock time is not going to be 5 minutes more like 2-3 hours to be safe
861 2012-11-18 23:10:12 <dudecoin> what is the nax nLOCKTIME can use? I was thinking about active block + x blocks ahead.