1 2014-07-27 01:20:59 <CryptoHustla> #nxt-dev
2 2014-07-27 03:20:33 <CryptoHustla> Can the testnet really be restarted?
3 2014-07-27 03:20:56 <SomeoneWeird> sure, it's been done before
4 2014-07-27 03:21:35 <CryptoHustla> whos in controll of that?
5 2014-07-27 03:31:33 <Luke-Jr> CryptoHustla: the dev team
6 2014-07-27 04:41:05 <ahmed_> Hi. Could someone here advise me on how to calculate hashrate?
7 2014-07-27 04:41:26 <ahmed_> my figures always end up way off (currently its 3x under what its supposed to be)
8 2014-07-27 09:49:02 <mn3monic> hi, what's the prefix for an hash160 to extract a base58 testnet p2sh addr? for mainnet, using pycoin's hash160_sec_to_bitcoin_address, I append b'\5' as prefix, any help is appreciated, thank you.
9 2014-07-27 10:24:11 <gmaxwell> Anyone care to check if their IPv4 reachable nodes are connected to 128.8.124.51 ?
10 2014-07-27 10:24:48 <wumpus> mine's not
11 2014-07-27 10:54:32 <Jouke_> gmaxwell: I just checked one node, but it is not connected to that IP
12 2014-07-27 10:56:09 <sipa> gmaxwell: mine's not
13 2014-07-27 10:56:17 <gmaxwell> Thanks.
14 2014-07-27 14:15:12 <jgarzik> cfields, if you have an extra time lying around, https://github.com/jgarzik/moxiebox configure.ac and C++ code could use some criticism
15 2014-07-27 14:15:31 <jgarzik> *some extra time
16 2014-07-27 14:17:07 <jgarzik> wallet42, can you fix your IRC software?
17 2014-07-27 14:53:56 <cfields> jgarzik: i suppose the moxie toolchain doesn't have a recognized triplet?
18 2014-07-27 14:54:20 <cfields> if not, you might consider adding one upstream
19 2014-07-27 14:54:40 <cfields> ah, it does :)
20 2014-07-27 14:54:54 <jgarzik> cfields, that's in flux
21 2014-07-27 14:55:18 <cfields> jgarzik: in a freshly cloned config.sub, i see an entry for moxie
22 2014-07-27 14:55:26 <jgarzik> cfields, I use --target=moxie-elf but the moxie author is in the process of adding a --target=moxiebox-$something entry
23 2014-07-27 14:55:47 <cfields> ah, ok
24 2014-07-27 14:56:15 <jgarzik> cfields, if you're building gcc, you want --enable-languages=c and --disable-libssp
25 2014-07-27 14:56:17 <cfields> jgarzik: fyi, target should only be used when building the toolchain itself
26 2014-07-27 14:56:25 <jgarzik> cfields, correct
27 2014-07-27 14:56:37 <cfields> it can lead to weird problems otherwise
28 2014-07-27 14:56:45 <cfields> jgarzik: ah, we may be talking about different things...
29 2014-07-27 14:56:57 <jgarzik> cfields, it leads directly to not working, if you are talking about moxiebox's configure ;0
30 2014-07-27 14:57:06 <jgarzik> cfields, moxiebox is effectively multi-target
31 2014-07-27 14:57:34 <jgarzik> cfields, most code is built for target=$host, but some code is built for target=moxie-elf
32 2014-07-27 14:57:36 <cfields> jgarzik: i was saying, with proper config.guess/sub support, you shouldn't need the MOX_GCC and friends in moxiebox
33 2014-07-27 14:57:38 <jgarzik> cfields, a bit strange
34 2014-07-27 14:58:05 <jgarzik> cfields, not so sure about that.......
35 2014-07-27 14:58:11 <jgarzik> cfields, multi-target is a strange beast
36 2014-07-27 14:58:41 <cfields> jgarzik: you mean it builds tools/libs for the builder and the host?
37 2014-07-27 14:59:09 <jgarzik> cfields, "sandbox" is target=$host. "libsandboxrt.a" is target=moxie-elf.
38 2014-07-27 14:59:24 <jgarzik> cfields, the runtime and the tests are always target=moxie-elf
39 2014-07-27 14:59:30 <cfields> jgarzik: ok
40 2014-07-27 14:59:49 <jgarzik> cfields, that's why runtime/Makefile.am specifies dependencies manually etc.
41 2014-07-27 14:59:55 <cfields> jgarzik: let me clarify a few things.. mostly stupid details, but they have specific meanings in this case
42 2014-07-27 15:00:28 <cfields> host is the triplet that runs the binaries. in 99% of cases, host=target. the exception is when creating the toolchain itself
43 2014-07-27 15:00:41 <cfields> so above, when you're saying host=target, i assume you mean build=host
44 2014-07-27 15:01:05 <cfields> build=box you're building on. host = where binaries run. target = what binaries produce machine code for
45 2014-07-27 15:01:28 <cfields> second, to solve that problem, CC_FOR_BUILD or so is usually used
46 2014-07-27 15:01:53 <cfields> so that you can use --host=moxie-whatever, and not confuse the build-system with the build binaries
47 2014-07-27 15:02:23 <jgarzik> cfields, OK, given that terminology, sandbox is multi-host
48 2014-07-27 15:02:29 <jgarzik> cfields, so that won't work ;p
49 2014-07-27 15:02:35 <cfields> heh, ok
50 2014-07-27 15:02:53 <cfields> (not trying to be pedantic, just making sure we're speaking the same language since there are specific meanings involved)
51 2014-07-27 15:02:59 <jgarzik> cfields, runtime and tests are always moxie-elf binaries
52 2014-07-27 15:03:14 <jgarzik> cfields, "sandbox" binary is whatever arch you want to run it on
53 2014-07-27 15:04:05 <j0b> so im trying to find the maximum size of OP_RETURN in the src.. and may i ask what is appropiate usage of it?
54 2014-07-27 15:04:18 <jgarzik> cfields, ...and let's move this discussion to #bitcoin-wizards please
55 2014-07-27 15:04:23 <cfields> sure
56 2014-07-27 15:04:52 <jgarzik> j0b, grep for OP_SMALLDATA (or OP_SMALL_DATA, I forget)
57 2014-07-27 15:05:03 <jgarzik> j0b, the limit is the size of a transaction, which is 1MB IIRC
58 2014-07-27 15:05:21 <j0b> https://en.bitcoin.it/wiki/Script
59 2014-07-27 15:05:23 <j0b> hm
60 2014-07-27 15:07:00 <j0b> jgarzik: ok, thx mate
61 2014-07-27 15:07:33 <sipa> j0b: for the consensus rule, or for standardness?
62 2014-07-27 15:08:44 <sipa> standardness allows a single OP_RETURN output, with at most a 40-byte push
63 2014-07-27 15:09:37 <sipa> consensus rules allow any OP_RETURN, with any size of script, though individual data pushes are limited to 520 byte
64 2014-07-27 15:10:27 <j0b> sipa: and if you want to store <= 100 byte? trying to see what it can be used for.
65 2014-07-27 15:10:48 <sipa> j0b: if it's less than 40 bytes, use OP_RETURN; otherwise, please just don't
66 2014-07-27 15:11:00 <j0b> allthough, im not that big fan of storing data on blockchain
67 2014-07-27 15:11:40 <j0b> has there been any talk about paralell blockchains?
68 2014-07-27 15:11:59 <j0b> that can be announced separately within the network
69 2014-07-27 15:12:17 <sipa> to serve which purpose?
70 2014-07-27 15:13:00 <j0b> additional currencys, like zerocoin blocks
71 2014-07-27 15:13:42 <sipa> why not on a separate network?
72 2014-07-27 15:14:23 <sipa> not everyone will care about such blocks, so restrict the propagation to those who do
73 2014-07-27 15:15:17 <j0b> sipa: since its quite heavy processing for zerocoin minting.. and you might not want to use zerocoin every time you want to do a transaction
74 2014-07-27 15:15:42 <sipa> i don't understand what that has to do with it
75 2014-07-27 15:15:57 <sipa> you can create wallet software which supports both networks
76 2014-07-27 15:16:04 <sipa> if there's a need for that
77 2014-07-27 15:16:26 <j0b> why build a paralellel network?
78 2014-07-27 15:16:27 <j0b> :)
79 2014-07-27 15:17:04 <sipa> because bitcoin nodes don't care about that data
80 2014-07-27 15:17:19 <sipa> it would add extra cost for them (badnwidth, storage, cpu), without benefit
81 2014-07-27 15:17:27 <j0b> indeed
82 2014-07-27 15:17:50 <j0b> but this is not for the bitcoin network
83 2014-07-27 15:18:11 <sipa> then don't do it on the bitcoin network
84 2014-07-27 15:39:13 <jgarzik> sipa, RE "Suggest other syntax: load=file:FILE. "file:X" is never valid JSON anyway." https://github.com/bitcoin/bitcoin/pull/4332/files#r15439861
85 2014-07-27 15:39:30 <jgarzik> sipa, not sure you understood the syntax (my fault for not giving better comments etc.)
86 2014-07-27 15:39:42 <jgarzik> sipa, you need both key ("NAME") and value ("FILE")
87 2014-07-27 15:40:15 <jgarzik> sipa, thus, on the command line, you may manually specify
88 2014-07-27 15:40:35 <sipa> uh, i mean NAME=file:FILE
89 2014-07-27 15:40:38 <jgarzik> "privatekeys={\"foo\":blahblah,\"var\":12313}"
90 2014-07-27 15:40:56 <jgarzik> or load.privatekeys=$filename
91 2014-07-27 15:41:08 <jgarzik> sipa, OK, that makes more sense
92 2014-07-27 15:42:06 <jgarzik> sipa, hrm, though on second thought, the logic of "if not a command, set a register" could be less ambiguous if there was
93 2014-07-27 15:42:09 <jgarzik> set.NAME=VALUE
94 2014-07-27 15:42:17 <jgarzik> load.NAME=$filename
95 2014-07-27 15:42:32 <sipa> that's very unintuitive, imho :)
96 2014-07-27 15:42:40 <sipa> but i'm nitpicking
97 2014-07-27 15:43:07 <jgarzik> could file.NAME=$filename
98 2014-07-27 15:43:14 <sipa> as other commands follow the COMMAND=PARAMS style
99 2014-07-27 15:43:31 <sipa> perhaps set=NAME:VALUE and load=NAME:FILE ?
100 2014-07-27 15:43:43 <jgarzik> sipa, I like that
101 2014-07-27 15:44:13 <sipa> so those become regular commands, that can be processing by the same interface as the others
102 2014-07-27 15:44:19 <jgarzik> +1
103 2014-07-27 15:44:38 <jgarzik> it's still processed by the same interface... just separated in --help output
104 2014-07-27 15:44:51 <jgarzik> the separation was largely for explanatory purposes
105 2014-07-27 15:45:14 <sipa> ah, good
106 2014-07-27 15:45:22 <sipa> no problem keeping that separated in help output
107 2014-07-27 16:09:52 <jgarzik> very odd
108 2014-07-27 16:09:57 <jgarzik> mapArgs suddenly stopped working
109 2014-07-27 16:11:19 <sipa> ?
110 2014-07-27 16:16:31 <jgarzik> sipa, no, my bug. was looking for mapArgs.count("--help")
111 2014-07-27 16:16:36 <jgarzik> one too many dashes
112 2014-07-27 16:28:09 <sipa> jgarzik: is it your birthday?
113 2014-07-27 16:30:24 <jgarzik> sipa, turned 40 "recently"
114 2014-07-27 16:30:47 <sipa> well, happy recent 0x28'th birthday then!
115 2014-07-27 16:31:00 <sipa> (0x28 looks so much better, doesn't it?)
116 2014-07-27 16:32:10 <jcorgan> i guess that makes me 0x2f
117 2014-07-27 16:33:00 <sipa> 0x1d here :)
118 2014-07-27 16:41:24 <iwilcox> Count it in drops of pitch from the pitch drop experiment, which are ~every 10y, then you're only 4 drops old. Or 1 leap drop old :)
119 2014-07-27 16:44:02 <Luke-Jr> really, the package manager should just be part of gitian..
120 2014-07-27 16:46:45 <jgarzik> sipa, BlueMatt, cfields: pull tester out of space again. what's the way to solve that permanently? We could copy+publish job results off-machine, if increasing disk space is onerous?
121 2014-07-27 16:47:00 <jgarzik> shove them to amazon s3, delete after 30 days
122 2014-07-27 16:47:35 <cfields> jgarzik: see #4592 for my suggested pull-tester replacement
123 2014-07-27 16:49:56 <Luke-Jr> (and turning Bitcoin Core into a package manager and OS in itself, sigh)
124 2014-07-27 16:51:58 <cfields> Luke-Jr: i'm not going to argue with you anymore. I don't agree with the points you're (not) making. If the others agree with your sentiments, then as always, I'll back down.
125 2014-07-27 16:52:51 <sipa> having that functionality inside gitian is equally fine to me
126 2014-07-27 16:52:58 <sipa> and admittedly more reusable
127 2014-07-27 16:53:20 <sipa> but gitian already needs some many wrapper scripts to make it work, meh
128 2014-07-27 16:54:42 <Luke-Jr> even actual package managers don't try to put all their packages in the same repository.
129 2014-07-27 16:55:17 <Luke-Jr> if gitian needs to be replaced, so be it. but there's no reason to tie it to BCCore like this
130 2014-07-27 17:08:57 <Luke-Jr> cfields: btw, you sound to be confusing releases with binaries.
131 2014-07-27 17:09:34 <Luke-Jr> releases are code/tags. binaries are just a convenience for those too lazy to build it themselves.
132 2014-07-27 17:19:33 <cfields> Luke-Jr: if that were the case, we'd let the distros handle our releases rather than actively trying to get them not to.
133 2014-07-27 17:20:09 <Luke-Jr> cfields: letting distros package Bitcoin Core is a goal; they just need to improve their process to do it safely first
134 2014-07-27 17:20:23 <Luke-Jr> we don't try to stop them from doing it correctly, just from doing it poorly
135 2014-07-27 17:21:15 <sipa> i don't see how we're either helping or making things harder for them
136 2014-07-27 17:21:27 <sipa> they'll keep just taking the source and building it in their own way
137 2014-07-27 17:21:52 <sipa> but the fact is that regardless of what distros are doing, _we_ are doing full binary releases
138 2014-07-27 17:22:06 <sipa> whether we should is a different discussion
139 2014-07-27 17:22:23 <sipa> but if we do, let's optimize the process for it
140 2014-07-27 17:22:56 <Luke-Jr> my point is only that producing those binaries is a job for something outside BCCore. we don't need to put the kitchen sink in the main repo just because we wash our plates we eat off of as we code
141 2014-07-27 17:23:59 <Luke-Jr> for the improvement of *Bitcoin*, we should also be doing things in a way that make it easier for (eg) btcd and DarkWallet to also use (perhaps they will contribute packages for dependencies they have, but we don't)
142 2014-07-27 17:24:43 <sipa> i understand that concern, and as i suggested, in the future that functionality can move to a different repository if we actually do have different repositories
143 2014-07-27 17:24:51 <sipa> the code is just not modularized enough for that
144 2014-07-27 17:25:17 <Luke-Jr> why wait?
145 2014-07-27 17:25:23 <Luke-Jr> the code is modularized enough for this part today
146 2014-07-27 17:25:26 <sipa> because it comes at a cost
147 2014-07-27 17:25:35 <sipa> needing to synchronize between different repositories
148 2014-07-27 17:25:39 <Luke-Jr> there is no inherent need to have binary-building tools inside the main repo
149 2014-07-27 17:25:55 <sipa> it makes automatic testing harder
150 2014-07-27 17:26:12 <Luke-Jr> the automatic tester can use a separate repo pretty easily..
151 2014-07-27 17:26:36 <sipa> well i'm fine with having it in a different repository
152 2014-07-27 17:26:47 <sipa> but the point is that we're currently already doing it in this one
153 2014-07-27 17:26:57 <jrick> multiple repos are a huge pain for us but we didn't have to modularize it that way (we could have made packages for each component, but in the same repo)
154 2014-07-27 17:27:06 <Luke-Jr> no, we're currently doing most of it in Ubuntu's packaging process
155 2014-07-27 17:27:30 <sipa> our gitian descriptors currently define which source version with which hash for dependencies to use
156 2014-07-27 17:27:40 <sipa> the main repository is fixing the dependencies
157 2014-07-27 17:28:48 <Luke-Jr> jrick: the current discussion is having scripts to build every dependency deterministically inside the main repo too
158 2014-07-27 17:29:35 <sipa> we already have those, inside gitian descriptors
159 2014-07-27 17:29:41 <sipa> where they can't be used for anything else
160 2014-07-27 17:30:02 <jrick> hmm, seems sane enough but we have to "vendor" some of our dependancies (goleveldb, gorilla websockets) since we don't want those changing without our control
161 2014-07-27 17:30:43 <sipa> we have some dependencies inside the source tree (leveldb in particular, soon probably libsecp256k1) as they're too consensus-critical
162 2014-07-27 17:31:11 <sipa> the rest is just regular dependency checking, using whatever is available
163 2014-07-27 17:31:31 <sipa> but optionally there is a system for doing deterministic builds (including some other dependencies) for binary releases
164 2014-07-27 17:32:05 <sipa> the proposal would move a large part of that out of gitian into a subdirectory of the main repo, where it can be make'd
165 2014-07-27 17:32:19 <sipa> so it can be reused by other parts (including automated testing)
166 2014-07-27 18:25:21 <mn3monic> hi, I still have problems with p2sh testnet hash base58 encoding, help is appreciated, if anyone is online
167 2014-07-27 18:25:47 <iwilcox> mn3monic: I'm sure the prefix is on the address types page on the wiki
168 2014-07-27 18:26:50 <mn3monic> iwilcox, yes, true, but doesn't work, maybe you can help me with some tests
169 2014-07-27 18:27:14 <mn3monic> >>> hash160_sec_to_bitcoin_address(hash160(binascii.unhexlify(hex_script)), address_prefix=b'\196')
170 2014-07-27 18:27:48 <mn3monic> doesn't return what I expect, but u'AbGvkcWnMLiBHH1DLaSPKdR7FDxz39CCSqom'
171 2014-07-27 18:28:16 <mn3monic> on the wiki: https://en.bitcoin.it/wiki/List_of_address_prefixes for p2sh testnet encodings, 196 is notified as the right prefix
172 2014-07-27 18:28:18 <iwilcox> Can we take this to #bitcoin?
173 2014-07-27 18:28:51 <mn3monic> ok
174 2014-07-27 21:07:14 <jcorgan> PR #4594 adds ZMQ-based publication of validated blocks and transactions; fire away :)
175 2014-07-27 21:20:09 <jcorgan> is pull-tester unhappy for everyone or just me?
176 2014-07-27 21:24:21 <petertodd> sipa: individual data pushes are only limited to 520 bytes if they are evaluated; op_return <slightly less than 1MB> is legal according to the consensus protocol
177 2014-07-27 21:26:34 <petertodd> j0b: in general, parallel blockchains aren't secure. if you need proof-of-publication I'd recommend you ignore op_return and use a generalized censorship resistant scheme: https://github.com/petertodd/blockpop
178 2014-07-27 21:35:23 <Luke-Jr> petertodd: please don't encourage spam
179 2014-07-27 21:48:09 <Eliel> Luke-Jr: There's demand for a generic proof of publication system. Unless a better solution is developed, Bitcoin is a natural fit in the eyes of those that want to do it.
180 2014-07-27 21:49:41 <gmaxwell> Eliel: I don't think you're correct about the demand. I think there is a kind of pretextual demand where people want something to exist, but not really. The things people create are rubbish, generally, and hyper inefficientâ and are never used.
181 2014-07-27 21:50:13 <gmaxwell> Most actually are not proof of publication, but proof of existance, which is very much less usefulâ for subtle reasons.
182 2014-07-27 21:51:41 <Luke-Jr> Eliel: no reason the data cannot be merge-mined
183 2014-07-27 21:51:52 <midnightmagic> Eliel: There are high-quality alternatives to spamming the bitcoin blockchain itself. There's IMO zero legitimate need to put the spam directly in the blockchain.
184 2014-07-27 21:52:24 <gmaxwell> Luke-Jr: the reason the data cannot be merged mined is simply that no one has made the tools.
185 2014-07-27 21:52:57 <Eliel> Also, merge mining will mean it'll be closer to proof of existence rather than proof of publication.
186 2014-07-27 21:53:02 <Luke-Jr> gmaxwell: exactly, laziness
187 2014-07-27 21:53:24 <gmaxwell> Eliel: hm? merge mining is one way to achieve scalable proof of publication.
188 2014-07-27 21:53:50 <gmaxwell> (otherwise there is no need for any kind of chain at all)
189 2014-07-27 21:54:07 <Eliel> yes, but it'll be weaker than including the data in bitcoin blockchain.
190 2014-07-27 21:54:13 <Luke-Jr> cfields: how do you avoid rebuilding in gitian? I thought you had said that, but saw no evidence of it in the code. :/
191 2014-07-27 21:54:35 <gmaxwell> Eliel: Weaker how?
192 2014-07-27 21:56:19 <Eliel> well, depends on the exact implementation, but if all copies of the blockchain have it, that's pretty good proof it was published.
193 2014-07-27 21:56:23 <gmaxwell> Eliel: using bitcoin makes you fundimentally weak because you're abusing a very narrow channel against its purposes, bitcoin already makes your life pretty hard for these applications.
194 2014-07-27 21:56:55 <gmaxwell> Eliel: it's not, encoding some data in the blockchain doesn't mean that anyone has seen it at all... it's not useful, and if the data is obvious, it'll end up getting blocked.
195 2014-07-27 21:57:22 <berndj-blackout> or pruned
196 2014-07-27 21:57:24 <gmaxwell> (and if you hide the data, it's no longer a proof of publication)
197 2014-07-27 21:58:05 <Eliel> well, true, if the data is actively fought against, that makes it less useful.
198 2014-07-27 21:58:45 <berndj-blackout> the more useful it is to you, the spammier it is to others, which gives them a greater incentive to fight it
199 2014-07-27 21:59:15 <gmaxwell> it's just a bad idea, but if there were actual demand there are plenty of ways of doing this that aren't disruptive to bitcoin.
200 2014-07-27 21:59:24 <Eliel> but true... bitcoin blockchain does have the drawback that it doesn't guarantee someone has actually looked at it.
201 2014-07-27 21:59:34 <Luke-Jr> "proof of publication in the blockchain" works "better" only because it is essentially "force others to store data they don't want to store"
202 2014-07-27 21:59:43 <wiretapped> proof of existence in the btc blockchain for software releases seems pretty useful, and relatively cheap/harmless to bitcoin
203 2014-07-27 21:59:49 <gmaxwell> and that people may actively censor it, and that the channel is so narrow it may be quite costly to use, and ...
204 2014-07-27 22:00:00 <Luke-Jr> wiretapped: there is zero value to putting it in the blockchain
205 2014-07-27 22:00:30 <wiretapped> the value is that when i install a piece of software i know i'm not the victim of a targetted attack
206 2014-07-27 22:00:33 <Eliel> Luke-Jr: you can achieve proof of existence with a single merkle root hash in one block for any number of pieces of data.
207 2014-07-27 22:00:36 <gmaxwell> wiretapped: proof of existence doesn't do much of value for software releases. I prove a honest version exists, I can concurrently prove a dishonest version exists. Not so helpful.
208 2014-07-27 22:00:48 <wiretapped> or at least not a targetted attack by someone incapable of subverting bitcoin
209 2014-07-27 22:00:53 <gmaxwell> wiretapped: what you want there is not a proof of existance at all.
210 2014-07-27 22:01:19 <wiretapped> gmaxwell: i'm thinking each software project has one bitcoin address they send release announcement transactions from
211 2014-07-27 22:01:25 <gmaxwell> you actually need double-spend protection for that, and bitcoin is not terribly scalable for that.
212 2014-07-27 22:01:30 <Luke-Jr> Eliel: that doesn't count as in the blcokchain
213 2014-07-27 22:01:48 <gmaxwell> wiretapped: then don't call that a proof of existance because it very much isn't one.
214 2014-07-27 22:02:13 <wiretapped> gmaxwell: yeah, you're right... it's related but different
215 2014-07-27 22:02:18 <wiretapped> what you you call that?
216 2014-07-27 22:02:29 <Luke-Jr> "signed by the author"? :p
217 2014-07-27 22:02:35 <gmaxwell> Luke-Jr: no.
218 2014-07-27 22:02:42 <wiretapped> Luke-Jr: signed by the author is quite different
219 2014-07-27 22:02:47 <wiretapped> signing keys can be compromised
220 2014-07-27 22:02:54 <berndj-blackout> wiretapped, why not just openpgp sign the release announcement?
221 2014-07-27 22:02:56 <Luke-Jr> so can bitcoin addresses
222 2014-07-27 22:02:58 <gmaxwell> It's the anti-double-spending problem. It's a uniqueness of history proof.
223 2014-07-27 22:02:59 <wiretapped> i want the decentralized append-only property
224 2014-07-27 22:03:12 <gmaxwell> y'all are not helping me by being clueless here. :)
225 2014-07-27 22:04:04 <gmaxwell> berndj-blackout: that threat he's trying to correct is where the author produces a good version and (at gun point) a bad version, both signed, and the bad version is just given to a few intended victims who hopefully won't noticeâ basically undermining the many-eyes-shallow-bugs property.
226 2014-07-27 22:04:17 <Luke-Jr> wiretapped: there's nothing inherently append-only about the blockchain.
227 2014-07-27 22:04:37 <wiretapped> Luke-Jr: lol i guess bitcoin isn't so useful then?
228 2014-07-27 22:04:52 <gmaxwell> And indeed, what bitcoin does is actually useful for thatâ unlike proof of existance / publication in general.
229 2014-07-27 22:04:54 <Luke-Jr> gmaxwell: then have every user sign the hash of what they've used (in a way that doesn't imply endorsement)
230 2014-07-27 22:05:12 <gmaxwell> though because bitcoin is not censorship resistant, it's a big liability if done in the obvious way here.
231 2014-07-27 22:05:19 <Luke-Jr> wiretapped: Bitcoin isn't strictly append-only.
232 2014-07-27 22:05:27 <gmaxwell> Since miners can simply block your software releases (e.g. vulnerable version must stay deployed)
233 2014-07-27 22:06:30 <gmaxwell> something like bytecoin/monero/etc. (or zerocash when it exists) would be much better, because they make censorship harder.
234 2014-07-27 22:06:53 <gmaxwell> or some bitcoin sidechain with the same cryptosystem, assuming we ever get one of those.
235 2014-07-27 22:07:28 <wiretapped> Luke-Jr: in the short term, no. i wouldn't trust it to certify that a software release has been permanantly recorded until many blocks have passed
236 2014-07-27 22:11:29 <wiretapped> gmaxwell: wow, i think that page covers all the things i've thought of plus several more :)
237 2014-07-27 22:11:52 <wiretapped> except maybe one thing (i just skimmed)
238 2014-07-27 22:12:11 <wiretapped> i think the thing i was describing above doesn't need to be append-only
239 2014-07-27 22:12:15 <wiretapped> it can be an add-only set
240 2014-07-27 22:12:25 <wiretapped> so it doesn't really need the proof of work of bitcoin
241 2014-07-27 22:13:03 <wiretapped> it could just be a majority of some large number of pre-selected notaries that acknowledge an item is in a set
242 2014-07-27 22:13:46 <gmaxwell> wiretapped: yes. I agree with that. (and the notaries produce digital signatures, so they can never 'remove' an item from their claims)
243 2014-07-27 22:14:03 <wiretapped> of course.
244 2014-07-27 22:14:42 <gmaxwell> and because you're not depending on a single global registry, you get some stronger censorship resistance (at least under some threat models)
245 2014-07-27 22:15:41 <gmaxwell> e.g. you'll accept the update as published if and only if half the notaries you trust have seen it. And there isn't a requirement that everyone use the same notaries if you need only add-only.
246 2014-07-27 22:16:29 <wiretapped> right. and notaries can also certify eachother's state
247 2014-07-27 22:17:13 <wiretapped> so i don't trust a notary's current state unless some other notaries know about its state
248 2014-07-27 22:18:04 <wiretapped> once you remove the need for a canonical ordering i think a lot of things become much easier :)
249 2014-07-27 22:18:37 <wiretapped> and the unordered add-only set could have a lot of useful applications
250 2014-07-27 22:19:30 <wiretapped> the thing i first thought of it for was shared write capabilities in tahoe-lafs
251 2014-07-27 22:19:50 <wiretapped> (currently sharing a write capabilty leads to sadness as there is no coordination of writes)
252 2014-07-27 22:27:19 <Eliel> I've written a rough high level design for a notary network that might work for something like this.
253 2014-07-27 22:29:49 <Eliel> it's by no means a finished idea but if you're curious, you might take a look https://docs.google.com/a/futuresolutions.fi/document/d/1xtG4im_yV0QI4YHsjgVsrH4pE2_hVXmAcG9ZMbjvsw4/edit#
254 2014-07-27 22:30:16 <gmaxwell> we might want to move this to #bitcoin-wizards
255 2014-07-27 22:31:40 <Eliel> yes, if someone wants to discuss what I've written in the document, please do so at #bitcoin-wizards
256 2014-07-27 22:48:03 <petertodd> wiretapped: fwiw I'm working on a proof-of-publication tool for software releases right now actually
257 2014-07-27 22:48:55 <petertodd> wiretapped: and this whole "miners may block your releases" thing is BS - them doing so destroys bitcoin as well, particularly if you use a timelock crypto scheme to force them to do so via whitelist rather than a blacklist
258 2014-07-27 22:50:42 <wiretapped> ACTION joins #bitcoin-wizards
259 2014-07-27 23:22:31 <go1111111> should the bitcoin PPA be updated to 0.9.2.1? Looks like 0.9.1 is the current version: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin .. BlueMatt?
260 2014-07-27 23:24:04 <iwilcox> go1111111: I think the debianisation in git works just fine in 0.9.2.1 and it's not hard to build as a package.
261 2014-07-27 23:24:59 <iwilcox> https://superuser.com/questions/699315/how-to-install-bitcoin-qt-wallet-on-debian-7/736508 worked fine for me with 0.9.2.1
262 2014-07-27 23:27:21 <go1111111> ok, I can try that. Seems like a bad experience that non-expert users who go to https://bitcoin.org/en/download will either get the old version or get stuck though
263 2014-07-27 23:27:47 <sipa> it should be updated, yes
264 2014-07-27 23:27:59 <gribble> The operation succeeded.
265 2014-07-27 23:27:59 <sipa> ;;later tell BlueMatt 0.9.2.1 ppa?