1 2016-02-03 00:00:24 <jtimon> Luke-Jr: how is the controversial softfork case different from the controversial hardfork one for any placeholder of <controversial> besides easier and faster deployment?
  2 2016-02-03 00:01:18 <jtimon> and that's a question that should be answered if bip99 is ever going to get to final state
  3 2016-02-03 00:04:04 <Luke-Jr> jtimon: the "default" state
  4 2016-02-03 00:04:16 <Luke-Jr> jtimon: softforks require consensus to veto; hardforks require consensus to pass
  5 2016-02-03 00:04:26 <Luke-Jr> jtimon: emailed the list re "consensus" terminology
  6 2016-02-03 00:05:27 <jtimon> and the same applies to <uncontroversial> in bip99, the two concepts are complementery in that sense, orthogonally to soft/hard fork terminology, and that's on purpose, and the proposed code is "whatever is in the uncontroversial/only-hardfork quarter on time and it's trivial to backport to 0.2 and forward-port to 0.14"
  7 2016-02-03 00:06:29 <jtimon> re the "default" state; no idea what you maymean by this
  8 2016-02-03 00:07:41 <jtimon> re: "softforks require consensus to veto; hardforks require consensus to pass" I assume you mean adiption consensus here, how is nearly-100% different from nearly-100%?
  9 2016-02-03 00:08:19 <jtimon> sorry, I guess I should check the mailing list
 10 2016-02-03 00:19:55 <Chris_Stewart_5> Luke-Jr: don't softforks require consensus to enforce? I.e. super majority of the hash rate?
 11 2016-02-03 00:42:36 <Luke-Jr> Chris_Stewart_5: supermajority is not consensus ;)
 12 2016-02-03 03:40:30 <rusty> kanzure, btcdrak: I don't understand Dave Scotese's latest bitcoin-dev mail.  Did someone moderate him and he's replying to the reject message?
 13 2016-02-03 03:41:37 <phantomcircuit> rusty, he seems to have hit the automated grey listing
 14 2016-02-03 03:42:40 <btcdrak> rusty: I was just finding the uptodate message regarding policy http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012258.html
 15 2016-02-03 03:44:10 <kanzure> rusty: no idea
 16 2016-02-03 03:44:25 <rusty> btcdrak: yes, given how much that thread fizzled, I guess we continue moderation as before.
 17 2016-02-03 03:44:32 <kanzure> rusty: his emails seem sort of off-topic
 18 2016-02-03 03:44:39 <kanzure> "please include the name of the moderator that approves the email" lol no
 19 2016-02-03 03:44:56 <rusty> kanzure: I'm rejecting that first one now.
 20 2016-02-03 03:45:03 <rusty> kanzure: yeah, the second one is just chat for the sake of chat AFAICT.
 21 2016-02-03 03:45:06 <btcdrak> oh absolutely, the moderation policy is absolutely fine as it. Clearly it's working.
 22 2016-02-03 03:45:08 <kanzure> yeah so reject both
 23 2016-02-03 03:50:07 <rusty> kanzure: hmm, his second is actually on-topic, replying to the question LukeJr raised.  It's a hairball question, though, and I think using "defining" instead of "consensus" is not going to work, but it's a direct reply.
 24 2016-02-03 03:50:45 <kanzure> this is dumb.
 25 2016-02-03 03:52:10 <rusty> kanzure: Luke-Jr opened a classic bikeshed opportunity, we should simply blame him :)
 26 2016-02-03 03:53:05 <Luke-Jr> rusty: ⁈
 27 2016-02-03 03:53:27 <rusty> Luke-Jr: you asked for people's opinion on terminology...
 28 2016-02-03 03:53:44 <Luke-Jr> rusty: that was someone else who broached that subject..
 29 2016-02-03 03:57:49 <kanzure> yeah i'm in favor of blaming luke-jr
 30 2016-02-03 03:57:51 <kanzure> works for me
 31 2016-02-03 03:59:33 <rusty> Luke-Jr: hmm, I'm just reading a quote, don't have context.  You might be right.
 32 2016-02-03 12:01:06 <jtimon> Luke-Jr: re: "softforks require consensus to veto; hardforks require consensus to pass" I don't undesrtand, don't just both of adoption consensus in the same way ("everybody" must agree that they will adopt it)? what do you mean "consensus to veto"? you mean everyone must agree to veto them or they should be adopted?
 33 2016-02-03 12:04:40 <phantomcircuit> jtimon, a soft fork can be enforced by nothing more than a majority of hashing power
 34 2016-02-03 12:06:05 <jtimon> phantomcircuit: I know, but we're talking about Luke-Jr's BIP, which explicitly say miners should have no power over the consensus rules (as in, if they deploy a controversial softfork, we should ASIC-reset hardfork them out)
 35 2016-02-03 12:07:11 <phantomcircuit> jtimon, im not sure that would actually be necessary, a soft fork by design is essentially censorship of transactions which violate a specific rule
 36 2016-02-03 12:07:24 <phantomcircuit> all we need to prevent that is fees to exceed subsidy
 37 2016-02-03 12:09:13 <jtimon> mhmm, say an evil miner cabal softforks to only allow...I don't know, p2pk, or only transfers from addresses that contain a "22" in them...I know these 2 examples are stupid, but still...
 38 2016-02-03 12:10:21 <jtimon> in those (unlikely) cases we could ASIC-reset miners
 39 2016-02-03 12:11:36 <jtimon> in any case, luke's BIP very clearly says that adoption consensus != miners, so when he said here that " softforks require consensus to veto" he cannot possibly mean "miners" by "consensus" there
 40 2016-02-03 12:19:23 <phantomcircuit> jtimon, i think it's a better long term bet that fees provide an incentive not to censor transactions based on things which are not widely accepted
 41 2016-02-03 12:21:12 <jtimon> phantomcircuit: I just want to undesrtand what Luke-Jr means, I'm not talking about bets
 42 2016-02-03 12:21:59 <phantomcircuit> jtimon, yes if a mining cabal began censoring transactions for reasons users disagreed with the pow could be changed (although probably with a massive amount of effort and nuisance...)
 43 2016-02-03 12:23:36 <jtimon> phantomcircuit: of course it would be painful, but philosophycally, it helps explain why miners are NOT in control of the consensus rules
 44 2016-02-03 12:24:12 <phantomcircuit> jtimon, yes, miners provide ordering and nothing more
 45 2016-02-03 12:25:02 <jtimon> phantomcircuit: agreed, that's why "a soft fork can be enforced by nothing more than a majority of hashing power" can be confusing to many people
 46 2016-02-03 12:27:56 <phantomcircuit> jtimon, a soft fork enforced by a majority of hashing power is only temporary without the client side lock in
 47 2016-02-03 12:42:25 <jtimon> yep
 48 2016-02-03 14:51:04 <Chris_Stewart_5> what does this comment mean wrt to this scriptsig and scriptPubKey
 49 2016-02-03 14:51:06 <Chris_Stewart_5> ["1 0x05 0x01 0x00 0x00 0x00 0x00", "VERIFY", "P2SH,STRICTENC", "values >4 bytes can be cast to boolean"]
 50 2016-02-03 15:04:53 <gavinandresen> Chris_Stewart_5: if I recall Script details correctly, that scriptPubKey pushes 1 (0x1) onto the stack and then pushes the 5-byte version of 1 (0x00000001) onto the stack. The VERIFY pops the 5-byte version and casts it to a boolean TRUE and succeeds. Then the other 1 is left on the stack and the script succeeds.
 51 2016-02-03 15:05:37 <gavinandresen> Chris_Stewart_5: it is a good test because Script has wacky rules about booleans and numbers....
 52 2016-02-03 15:05:58 <Chris_Stewart_5> Ok that makes sense with the 0x05 push op. Thanks for the clarification gavinandresen
 53 2016-02-03 15:09:32 <gavinandresen> Luke-Jr : RE: defining consensus:  can we just steal from the IETF process or some other standardization process people seem to be mostly happy with?  I'm sorry not to give you more specific feedback, but I don't consider myself an expert at governance/standardization processes.
 54 2016-02-03 15:09:51 <gavinandresen> (and I don't really want to become an expert on that)
 55 2016-02-03 15:18:45 <phantomcircuit> gavinandresen, you want to steal the governance process from organizations which standardized the likes of tls? no thanks
 56 2016-02-03 15:19:48 <gavinandresen> phantomcircuit: this famous quote by Winston Churchill comes to mind:  “Democracy is the worst form of government, except for all the others.”
 57 2016-02-03 15:20:31 <gavinandresen> phantomcircuit: ... happy to steal a better process if you know of something that works better.
 58 2016-02-03 15:21:11 <phantomcircuit> bitcoin isn't a democracy, if it was we'd all be wasting our time
 59 2016-02-03 15:21:43 <gavinandresen> phantomcircuit: you're too literal.  Re-cast the quote as "The IETF process is the worst form of standardization, except for all the others"
 60 2016-02-03 15:21:46 <phantomcircuit> the rules were laid bare and clear for all to see before deciding to participate in the system
 61 2016-02-03 15:22:01 <phantomcircuit> to try and change those rules after the fact cannot be done by a simple majority
 62 2016-02-03 15:22:13 <phantomcircuit> if it can then the system is a failure and mike was right
 63 2016-02-03 15:22:59 <gavinandresen> (I'm going to be quiet about philosophizing about governance processes, as I said I don't want to become an expert but I think we should listen to experts....)
 64 2016-02-03 15:23:01 <phantomcircuit> gavinandresen, im thinking you're not entirely aware of the ietf process
 65 2016-02-03 15:23:16 <gavinandresen> I'm not entirely aware of the IETF process, that's true.
 66 2016-02-03 16:10:04 <kaalia> How can i query blockchain to find transaction fee per block?
 67 2016-02-03 16:10:23 <kaalia> using json rpc or similar?
 68 2016-02-03 16:10:46 <Spartn> Hi
 69 2016-02-03 16:10:52 <Spartn> Someone?
 70 2016-02-03 16:11:24 <Spartn> Français?
 71 2016-02-03 16:13:07 <Spartn> Pls?
 72 2016-02-03 16:14:37 <Spartn> Allo
 73 2016-02-03 16:15:20 <gijensen> Spartn, try #bitcoin its more general
 74 2016-02-03 16:16:53 <kaalia> How can i query blockchain to find transaction fee per block?
 75 2016-02-03 16:17:01 <gevs> Spartn come in private
 76 2016-02-03 16:17:14 <kaalia> Anyone?
 77 2016-02-03 16:17:22 <gijensen> kaalia, I'm not sure if you can. You can get all the transactions in a block with "getblock" then if you have txindex=1, you can use getrawtransaction on each transaction and add the fees together. If you set verbose on "getblock" to "False" you can get the raw block and parse it yourself.
 78 2016-02-03 16:18:46 <Spartn> thanks gijensen
 79 2016-02-03 16:27:15 <cluelessperson> hm
 80 2016-02-03 16:40:35 <Chris_Stewart_5> What exactly is the use case for having an alternative stack?
 81 2016-02-03 17:37:13 <gijensen> kaalia, I'm almost ready to release a tool that'll make scripting RPC commands really easy. I'll add a function to get fee by txid (provided you have txindex=1)
 82 2016-02-03 18:05:56 <Luke-Jr> jtimon: economic consensus *can* veto a soft-fork, is the point
 83 2016-02-03 18:07:01 <Tasoshi> how?
 84 2016-02-03 18:07:46 <Luke-Jr> gavinandresen: Unlike the IETF, Bitcoin has no governance; BIPs can only hope to accurately model what the reality is. I'll look into if the IETF's governance might be close enough match for this though
 85 2016-02-03 18:08:00 <Tasoshi> Luke-Jr, how does the economic majority veto a soft fork?
 86 2016-02-03 18:08:20 <Luke-Jr> Tasoshi: hardforking away from the group of miners enforcing the softfork
 87 2016-02-03 18:08:40 <Tasoshi> how is that a veto? that's suicide, not veto
 88 2016-02-03 18:08:49 <Luke-Jr> no, it isn't suicide.
 89 2016-02-03 18:08:50 <jtimon> Luke-Jr: just like it can veto hardforks, no? what is the difference? I still don't undesrtand your  "softforks require consensus to veto; hardforks require consensus to pass"
 90 2016-02-03 18:09:07 <Luke-Jr> jtimon: the economic consensus is requires for a hardfork in the first place
 91 2016-02-03 18:09:10 <Luke-Jr> required*
 92 2016-02-03 18:09:24 <Tasoshi> of course it is suicide, hardforking away from the miners brings security down to 0
 93 2016-02-03 18:09:35 <Luke-Jr> Tasoshi: nonsense
 94 2016-02-03 18:09:35 <Tasoshi> last time we had 0 security price was pretty close to 0 too
 95 2016-02-03 18:09:52 <Luke-Jr> price was highest in 2012 when GPU mining flourished
 96 2016-02-03 18:10:03 <jtimon> oh, I think I get it, you require economic consensus to deploy the hardfork that would invalidate (veto) the unwanted softfork, is that what you mean?
 97 2016-02-03 18:10:06 <Tasoshi> in 2012 price was 2 dollars
 98 2016-02-03 18:10:28 <Luke-Jr> jtimon: yes
 99 2016-02-03 18:11:52 <Luke-Jr> Tasoshi: more like $6, but I guess you're right, it was 2013-2014 the price went to $1k
100 2016-02-03 18:12:00 <Luke-Jr> Tasoshi: in any case, price doesn't follow security
101 2016-02-03 18:12:08 <Tasoshi> and that is when asics came on too
102 2016-02-03 18:12:17 <Tasoshi> higher security = higher price...
103 2016-02-03 18:12:27 <Luke-Jr> evil miners would be the least secure possibility anyway
104 2016-02-03 18:12:34 <Luke-Jr> Tasoshi: no, that isn't true
105 2016-02-03 18:12:40 <Luke-Jr> higher price = higher security
106 2016-02-03 18:12:46 <jtimon> Tasoshi: that's because the security is paid with the subsidy (which varies in price) not because the price depends on the security (although it may actually happen if many investors/speculators are using the labor theory of value in their predictions, just like bitcoin could rise on rainy days if enough people believe rainy days cause bitcoin to rise in price)
107 2016-02-03 18:12:52 <Tasoshi> 51% of miners can't be evil, that is the assumption and the whole point of bitcoin
108 2016-02-03 18:12:54 <Luke-Jr> higher price provides more funding for mining development
109 2016-02-03 18:13:07 <Luke-Jr> Tasoshi: we're talking about a situation where >51% are evil
110 2016-02-03 18:13:35 <Tasoshi> the only way that situation can apply is if a world government corrupted all the miners...
111 2016-02-03 18:14:01 <Tasoshi> and in that case, if it is at all possible for such congregation, our problems would be far greater
112 2016-02-03 18:14:13 <jtimon> I'm confused, what situation are we talking about?
113 2016-02-03 18:14:25 <Luke-Jr> Tasoshi: no, that isn't.
114 2016-02-03 18:14:47 <Luke-Jr> jtimon: miners decide to softfork in something the economic consensus decides is evil
115 2016-02-03 18:15:11 <Luke-Jr> for example, voiding bitcoins mined before 2014
116 2016-02-03 18:15:13 <Tasoshi> miners can soft fork an increase of the 21m limit...
117 2016-02-03 18:15:41 <Tasoshi> everything can be soft forked - I think that is a direct quote from gmaxwell
118 2016-02-03 18:16:18 <jtimon> oh, I see, Tasoshi thinks an ASIC-reset hardfork would be suicidal and it would be better to swallow whetever softfork they want to enforce no matter how evil/absurd it is, like, say, 1% minimum fees
119 2016-02-03 18:16:18 <Tasoshi> but of course no one would have a say in the case of a hard fork, because all the old nodes would be tricked to serve the "evil miners"
120 2016-02-03 18:16:38 <Luke-Jr> "Miners before 2014 had a much lower difficulty. Therefore, the value of any such unspent bitcoins will be reduced to merely 5 BTC instead of 50/25."
121 2016-02-03 18:16:56 <Tasoshi> sorry, no one would have a say in the case of that sort of soft fork* because everyone would be tricked to serve the "evil miners"
122 2016-02-03 18:17:36 <Luke-Jr> Tasoshi: a hardfork can block it by firing that set of miners
123 2016-02-03 18:17:56 <Tasoshi> jtimon, let us assume everyone cpu or gpu mines, what stops me from creating a cpu or gpu mining farm? Well nothing of course
124 2016-02-03 18:19:00 <Tasoshi> It is speculated satoshi had one... it is not a high logical jump from more cpu to get more cpu...
125 2016-02-03 18:19:02 <jtimon> I'm not sure how you can softfork an increase in inflation, but let's say it's possible and use that as our example. In that case would not be better to hardfork than continue depending on those evil miners?
126 2016-02-03 18:19:43 <jtimon> I don't see the problem with you creating a GPGPU farm or even a new ASIC for the new hashing algorithm
127 2016-02-03 18:20:19 <Tasoshi> well, if you have to hardfork the miners, except for in super extreme situations, you are simply declaring and admitting that the whole thing does not work
128 2016-02-03 18:20:47 <Tasoshi> for what makes you think the next miners would behave, etc.
129 2016-02-03 18:20:54 <jtimon> in fact, it would probably be nice to have GPGPU mining free software for the new algorithm ready before doing such a hardfork
130 2016-02-03 18:21:46 <Tasoshi> jtimon, as I mentioned earlier, I think there is no difference whatever between cpu and asics mining. In the former, you can just buy tons of laptops...
131 2016-02-03 18:22:09 <jtimon> no, I'm just declaring the evil miner's hardware obsolete, hopefully the new miners won't be stupid enough to do an evil softfork again to lost a lot of invested money like their predecessors
132 2016-02-03 18:22:13 <Tasoshi> except of course that asics provide far higher security and thus higher value
133 2016-02-03 18:23:13 <Tasoshi> but it isn't the miners who did the evil soft fork to begin with, presumably it was the developers...
134 2016-02-03 18:23:29 <jtimon> I really don't get your point aboug cpu vs GPU vs ASIC mining, I'm not saying ASIC are bad, but if the owners of those ASICs are stupid and evil we can just deprecate their hardware and wait for new ASICs to appear
135 2016-02-03 18:23:59 <Tasoshi> only if you wish to admit the concept does not work
136 2016-02-03 18:24:55 <jtimon> I believe the concepts works and is very simple: miners don't decide the rules, if they attempt to control the rules in evil ways, users can get together and "fire them"
137 2016-02-03 18:24:55 <Luke-Jr> CodeShark: is it intentional that you are using two different emails in various BIPs?
138 2016-02-03 18:25:39 <Tasoshi> that applies only in super extreme circumstances which really should not be possible
139 2016-02-03 18:26:45 <Tasoshi> if it is possible then what you ought to learn is that the thing does not work, in my view
140 2016-02-03 18:27:48 <Luke-Jr> Tasoshi: miners were never intended to have any power over the rules
141 2016-02-03 18:27:58 <Tasoshi> a government can not coerce all the miners, and 51% of miners must behave honestly as far as any logics applies, if either fails then the whole thing has to go back to the blackboard
142 2016-02-03 18:28:40 <Tasoshi> the miners are the keepers of the rules, they protect from potentially evil developers
143 2016-02-03 18:29:00 <Tasoshi> and ractify or otherwise what is proposed
144 2016-02-03 18:29:15 <Luke-Jr> Bitcoin is not government-resistent.
145 2016-02-03 18:29:53 <Luke-Jr> miners have slightly more influence than developers over the rules, but neither group is intended to control them
146 2016-02-03 18:30:22 <Tasoshi> miners have ultimate say over the rules with the developers having none
147 2016-02-03 18:30:24 <jtimon> Tasoshi: in my view, that case is possible, and it's users who need to protect themselves from evil developers or miners
148 2016-02-03 18:31:12 <Tasoshi> all the developers can do is propose and everyone is freely and fully entitle to ignore them completely
149 2016-02-03 18:31:17 <Tasoshi> especially the miners
150 2016-02-03 18:31:41 <jtimon> Tasoshi: I disagree, users have to accept the rules, neither miners nor developers have any "governance power" over the consensus rules
151 2016-02-03 18:31:41 <Tasoshi> but you can not easily ignore what 51% of the miners do or do not decide
152 2016-02-03 18:31:57 <Luke-Jr> Tasoshi: you are wrong
153 2016-02-03 18:31:59 <Luke-Jr> well
154 2016-02-03 18:32:01 <Tasoshi> they hold the keys, giving you the only option of joining or leaving
155 2016-02-03 18:32:09 <Luke-Jr> not easily, in the case of softforks
156 2016-02-03 18:32:15 <Luke-Jr> but for hardforks, miners have zero say
157 2016-02-03 18:32:27 <jtimon> as explained, "the keys" can be taken away from them with a hardfork
158 2016-02-03 18:32:36 <Tasoshi> jtimon the users have the suicide say - again they can choose to leave or join
159 2016-02-03 18:33:18 <Luke-Jr> it's not suicide.
160 2016-02-03 18:33:26 <Luke-Jr> it's just a replacing of miners.
161 2016-02-03 18:33:46 <Tasoshi> no, it is a degrading of security to 0
162 2016-02-03 18:33:53 <Luke-Jr> no, it isn't.
163 2016-02-03 18:33:57 <Luke-Jr> there are lots of GPU miners
164 2016-02-03 18:33:59 <Tasoshi> bitcoin retains no value at 0 security
165 2016-02-03 18:34:04 <jtimon> I'm sure many GPUs would be ready to mine from day 1
166 2016-02-03 18:34:07 <Tasoshi> when 1 guy can attack it in his own basement
167 2016-02-03 18:34:16 <Luke-Jr> bitcoin retains more value at GPU security, than at evil-ASIC-miner security
168 2016-02-03 18:34:35 <Tasoshi> currently it takes 2 billions to externally attack bitcoin - fire all the miners and prob just 10k or 100k is enough
169 2016-02-03 18:35:07 <Tasoshi> asics are not evil, I went through this. Nothing stops you from creating a gpu mining farm
170 2016-02-03 18:35:21 <Luke-Jr> ASICs are not evil, but we're talking about a scenario where the ASIC miners have become evil
171 2016-02-03 18:35:28 <Tasoshi> then
172 2016-02-03 18:35:36 <Tasoshi> describe the scenario
173 2016-02-03 18:35:43 <jtimon> Tasoshi: people should probably start waiting more than 6 confirmation for some time as an additional safety meassure, as the bitcoin withepaper explains, more confirmations means more security, not only more hashrate
174 2016-02-03 18:51:49 <Tasoshi> jtimon the ideal scenario is where we don't have to wait for even one confirmation. Remember there is a person on the other side of the screen waiting... and I am sure they would much rather not
175 2016-02-03 18:58:14 <Luke-Jr> gavinandresen: reading RFC 7282, so far I get the impression that "obstructive" should be changed to "addressed or obstructive" - does that improve it in your view?
176 2016-02-03 19:18:49 <jtimon> Tasoshi: I never read anything about that "don't wait for any confirmation" in the withepaper, but payment channels ala lightning could deliver that
177 2016-02-03 21:10:57 <Luke-Jr> or maybe I should make a separate repo for it and just add a link..
178 2016-02-03 21:28:04 <Lightsword> hmm, looks like armory is being shut down https://bitcointalk.org/index.php?topic=1351792.0
179 2016-02-03 21:30:05 <zooko> Hm.
180 2016-02-03 21:30:57 <kefkius> That'd be a cool thing to have Travis CI run on PRs Luke-Jr
181 2016-02-03 21:31:48 <zooko> kefkius, Luke-Jr: we're working on a similar thing in the Zcash project, here's the first test of it: https://github.com/zcash/notzcash/pull/7
182 2016-02-03 21:32:06 <zooko> We'd be willing to give bitcoin devs access or configure it as they need to let it serve bitcoin core dev as well.
183 2016-02-03 21:32:22 <zooko> Since the Zcash project is based on bitcoin core and we need to do lots of tests and CI and stuff on Bitcoin core anyway.
184 2016-02-03 21:32:29 <zooko> Plus which we'd like to contribute, if useful.
185 2016-02-03 21:33:13 <Luke-Jr> kefkius: oh, good point
186 2016-02-03 21:33:27 <Luke-Jr> zooko: topic is bips, not Core :p
187 2016-02-03 21:33:30 <Lightsword> looks like there’s at least someone interested in maintaining it going forward https://bitcointalk.org/index.php?topic=1351924.0
188 2016-02-03 21:33:56 <zooko> Luke-Jr: oh, I'm confused what kefkius was suggesting then
189 2016-02-03 21:34:37 <Luke-Jr> kefkius: running the BIP sanity checker on the bips repo in Traivs
190 2016-02-03 21:34:50 <kefkius> ^
191 2016-02-03 21:35:26 <zooko> Ooh, I see.
192 2016-02-03 21:36:04 <Lightsword> curious if it would be remotely feasible to support armory’s HD wallet format within core https://bitcoinarmory.com/wallet-format/
193 2016-02-03 21:49:24 <instagibbs> kanzure, waxwing, where was that waxwing CT breakdown? Can't find it via google
194 2016-02-03 21:49:36 <Luke-Jr> Lightsword: not a goal IMO
195 2016-02-03 21:49:47 <waxwing> instagibbs: github.com/AdamISZ/ConfidentialTransactions (or similar)
196 2016-02-03 21:49:57 <Luke-Jr> Lightsword: note the HD wallet algorithm is non-standard
197 2016-02-03 21:50:06 <instagibbs> grazie ill try to figure it out
198 2016-02-03 21:50:14 <waxwing> https://github.com/AdamISZ/ConfidentialTransactionsDoc
199 2016-02-03 21:50:18 <instagibbs> https://github.com/AdamISZ/ConfidentialTransactionsDoc
200 2016-02-03 21:50:22 <instagibbs> thx
201 2016-02-03 21:50:44 <Lightsword> Luke-Jr, is the HD wallet algorithm appear to be secure?
202 2016-02-03 21:51:33 <Luke-Jr> Lightsword: I am not aware of any public audits.
203 2016-02-03 21:52:47 <Lightsword> Luke-Jr, hmm, core is planning HD wallet support at some point right?
204 2016-02-03 21:53:06 <Luke-Jr> Lightsword: based on the BIPs, yes
205 2016-02-03 21:54:12 <Lightsword> Luke-Jr, is core planning to leave the wallet database format as is(bdb seems like a weird choice) or redo it with a conversion utility?
206 2016-02-03 22:09:27 <helo> Lightsword: i think it's a goal, but not yet planned
207 2016-02-03 22:10:42 <Lightsword> helo, any idea why the wallet didn’t just use something like sqlite? sqlite is extremely well tested and has a stable file format unlike bdb
208 2016-02-03 22:11:08 <helo> bdb was chosen by satoshi afaik. it was used for the block index as well as the wallet.
209 2016-02-03 22:17:40 <Luke-Jr> Lightsword: SQL is overkill, and doesn't actually improve anything
210 2016-02-03 22:17:55 <Luke-Jr> Lightsword: the idea is an append-only format
211 2016-02-03 22:19:06 <Luke-Jr> but really, the whole thing needs a rewrite
212 2016-02-03 22:19:11 <Luke-Jr> it's too malleable-vulnerable now
213 2016-02-03 22:22:13 <Lightsword> Luke-Jr, sqlite isn’t that heavy though and natively handles other issues such as shutdowns mid write etc, it’s also has aviation level certifications with full branch test coverage, I realize SQL isn’t really neccesary but it could still come in useful in theory, IMO it’s probably better than trying to make our own custom format
214 2016-02-03 22:22:50 <Lightsword> https://www.sqlite.org/testing.html
215 2016-02-03 22:28:45 <helo> append only is highly desired
216 2016-02-03 22:29:07 <kanzure> i have been missing sqlite://:memory: lately....
217 2016-02-03 22:29:30 <kanzure> so as an alternative i have been thinking about wrapping postgresql in a docker container and making a c library that speaks to dockerland
218 2016-02-03 22:29:48 <kanzure> and then destroy the container at the end, rather than maintaining a local postgresql on /dev/shm or something
219 2016-02-03 22:32:46 <Lightsword> helo, is there any reason we can’t get the same result by just restricting the allowed sqlite queries to write only operations?
220 2016-02-03 22:33:10 <Luke-Jr> Lightsword: sqlite never does append-only, even if you only write
221 2016-02-03 22:33:49 <Lightsword> Luke-Jr, what’s the reason for append only? to guard against corruption?
222 2016-02-03 22:33:52 <helo> i think part of the goal is to not re-write data that is already recorded
223 2016-02-03 22:33:54 <Luke-Jr> yes
224 2016-02-03 22:34:20 <Luke-Jr> also allows incremental backups
225 2016-02-03 22:34:54 <Lightsword> Luke-Jr, corruption should not be an issue with sqlite, it can handle poweroff mid write without issues
226 2016-02-03 22:36:02 <Luke-Jr> Lightsword: …
227 2016-02-03 22:36:10 <Luke-Jr> you underestimate bad hardware
228 2016-02-03 22:36:28 <Luke-Jr> wumpus: I apparently don't have admin to bitcoin/bips necessary for enabling Travis. Could you fix that?
229 2016-02-03 22:36:58 <Lightsword> Luke-Jr, maybe…but even in append only we would have to handle corruption to some degree if it’s that bad
230 2016-02-03 22:37:31 <Luke-Jr> Lightsword: it would be immediately noticed updating the incremental backup, which would itself be unaffected
231 2016-02-03 22:47:00 <Lightsword> Luke-Jr, the main issue I think is that a custom append only format is just going to be extra maintainence overhead that could be easially avoided
232 2016-02-03 22:49:52 <Lightsword> and might present portability issues while sqlite is widely tested across many platforms
233 2016-02-03 22:51:28 <helo> i think just switching to "some other light db" has been deemed not worth it
234 2016-02-03 22:58:20 <Luke-Jr> in theory, I suppose a simple append-only format would be a SQL log :P