1 2015-09-20 02:14:31 <morcos> maaku: I'm not sure why the n^2 argument is irrelevant?  as gmaxwell said, it speaks to the inherent scalability issues where every node not only has to receive every message but do processing work on it to.  for instance how would contrast that and the scalability of something like lightning
  2 2015-09-20 02:15:11 <morcos> where only some narrow subset of the participants even needs to see the messages involved.
  3 2015-09-20 02:29:26 <CodeShark_> morcos: flood networks have inherent scalability issues that have been discused at length in networking literature - only a few bitcoiners seem oblivious to this  :p
  4 2015-09-20 02:31:44 <morcos> yeah i felt a bit stupid trying to explain why i didn't think it was irrelevant, but then i don't understand why maaku called the O(n^2) observation "irrelevant academic wankery"
  5 2015-09-20 02:32:40 <CodeShark_> http://bit.ly/1JicZzO
  6 2015-09-20 02:37:27 <Belxjander> morcos: academia and published application projects have separate goals for the target during design and implimentation
  7 2015-09-20 02:37:57 <CodeShark_> Theoretical constaints still apply to applications
  8 2015-09-20 02:40:22 <CodeShark_> Perhaps there are better approaches to pointing things out to different audiences - I'm not sure of the context of maaku's comment...have to scroll up
  9 2015-09-20 02:40:25 <instagibbs> I think it's important when relating it to fundamntally different systems, like Paypal, vs using as talking point in blocksize "debate" where it doesn't inform much. Probably why it keeps popping up.
 10 2015-09-20 02:45:30 <CodeShark_> The O(n^2) observation is extremely relevant to network engineers...probably nonsense to most laypeople
 11 2015-09-20 02:48:08 <CodeShark_> furthermore, this observation is a general feature of flood networks...it applies to far more than just the blocksize issue
 12 2015-09-20 02:49:01 <CodeShark_> Which is why in practice flood networks are small
 13 2015-09-20 02:50:10 <CodeShark_> If you want large networks you need routing
 14 2015-09-20 03:32:37 <phantomcircuit> morcos, the n in the O(n^2) of the flood network is the inventory messages
 15 2015-09-20 03:32:51 <phantomcircuit> it certainly is O(n^2) but for relatively small values of n
 16 2015-09-20 03:33:09 <phantomcircuit> the bigger issue is certainly the scaling complexity for initial block synchronization
 17 2015-09-20 03:33:30 <phantomcircuit> relying on UTXO commitments to node validation is a security reduction from the current full node model
 18 2015-09-20 03:35:06 <phantomcircuit> it alters the incentives in exactly the same way as #5842
 19 2015-09-20 03:36:57 <phantomcircuit> if nobody is able to check the utxo commitments except for nodes which are already online, then the security assumptions are the same more or less as many PoS coins and we should all just go home
 20 2015-09-20 03:51:08 <CodeShark_> In the limit of myopic industry pressure, O(n^2) approaches O($$$)
 21 2015-09-20 03:53:22 <CodeShark_> I'd supply the proof but I'm afraid it won't fit in the margin
 22 2015-09-20 04:00:08 <maaku> phantomcircuit: eh it's not _that_ bad. if we were to checkpoint the utxo set every quarter, and download from the most recent checkpoint >= 1yr ago and validate from there, it is not clear to me that we would be taking on any risk in practice
 23 2015-09-20 04:00:54 <maaku> to quote a redditer, it'd be like killing the last living unicorn for sport. the world would be a less magical and more sad place, but it's not clear we'd actually lose anything of value
 24 2015-09-20 04:01:56 <maaku> since a 1-year 51% attack has the power to kill bitcoin anyway
 25 2015-09-20 04:02:38 <CodeShark_> checkpoints break strict cryptographic verifiability...but then again, so do soft forks :p
 26 2015-09-20 04:03:51 <maaku> CodeShark_: ? I'm imagining UTXO commitments in each block, and a convention that full nodes serialize out and keep around the utxo set every 13,104 blocks (3mo)
 27 2015-09-20 04:04:23 <CodeShark_> You're not talking about hardcoding it into the software?
 28 2015-09-20 04:04:28 <maaku> no
 29 2015-09-20 04:04:42 <maaku> sorry overload of 'checkpoint'
 30 2015-09-20 04:04:54 <maaku> and during IBD you go to the highest multiple of 13,104 that is at least 52,416 blocks old (1yr), and get the utxo commitment from that block
 31 2015-09-20 04:05:09 <maaku> then fetch that from a peer
 32 2015-09-20 04:06:02 <maaku> so you cap IBD to process between 12mo and 15mo of blocks
 33 2015-09-20 04:07:21 <maaku> I don't see any way around this unfortunately, since making IBD constant requires an insane restriction on growth
 34 2015-09-20 04:08:11 <CodeShark_> Right...the security model still requires a sufficiently large number of noncolluding full validator nodes and at least one whistleblower...but we could formalize this and make it acceptable
 35 2015-09-20 04:09:20 <maaku> and its security model isn't much worse than #5842, which was already almost merged
 36 2015-09-20 04:09:58 <maaku> (#5842 would have disabled signature checks for transactions > 8064 blocks old)
 37 2015-09-20 04:11:43 <maaku> morcos: my comment above was before I had read Gavin's most recent blog post. He does a good summary of various O(n^2) arguments, if you haven't read it
 38 2015-09-20 04:12:00 <CodeShark_> eventually snarks might help improve the security...but I think the weakest link is something else anyhow
 39 2015-09-20 04:12:24 <Luke-Jr> Linux 4.2 includes a new RNG entropy source: https://lwn.net/Articles/642166/
 40 2015-09-20 04:12:35 <Luke-Jr> anyone know if it's sane? seems to be semi-controversial
 41 2015-09-20 04:15:55 <maaku> morcos: the wankery I was referring to is that I don't know any measurement that is O(n^2) -- other than the content of my own talk -- which affects practical concerns such as validation time
 42 2015-09-20 04:17:13 <maaku> yes total system work to validate a block is O(n^2) -- O(n) machines validating O(n) work each -- but what matters for scalability is how long it takes one block to validate [O(n)] and how many hops there are in the network [O(log n)]
 43 2015-09-20 04:17:29 <maaku> so validation scales with O(n log n), not O(n^2) in terms of propogation time
 44 2015-09-20 04:18:14 <maaku> system resources of a node scale with O(n). bandwidth scales with O(n)
 45 2015-09-20 04:19:16 <CodeShark_> O(n) is still pretty bad if we want billions of users :p
 46 2015-09-20 04:19:19 <maaku> to answer your question, lightning makes system resources and bandwidth scale O(log n) for transactions, O(n) for settlement
 47 2015-09-20 04:19:57 <maaku> CodeShark_: sure, but linear we can deal with, especially if only infrequent settlement is required
 48 2015-09-20 04:20:06 <CodeShark_> I think the main concern is IBD
 49 2015-09-20 04:20:15 <maaku> see above :)
 50 2015-09-20 04:20:16 <kadoban> Luke-Jr: Sounds like at worst the entropy estimation is optimistic.
 51 2015-09-20 04:20:37 <maaku> I think the main concern is getting everyday transactions off-chain...
 52 2015-09-20 04:20:48 <maaku> so that scaling is logarithmic, not linear
 53 2015-09-20 04:21:23 <maaku> or completing the snarks-summoning spell so scaling is constant for validators
 54 2015-09-20 04:22:32 <dgenr8> maaku: what would you change first?
 55 2015-09-20 04:23:46 <maaku> dgenr8: regarding?
 56 2015-09-20 04:25:00 <dgenr8> scalability in general
 57 2015-09-20 04:26:35 <CodeShark_> fix malleabilty? :)
 58 2015-09-20 04:28:20 <CodeShark_> Add absolute and relative locktime, use masts, etc...
 59 2015-09-20 04:30:07 <maaku> dgenr8: bips 65,68,112,113
 60 2015-09-20 04:31:01 <maaku> that gives us trustless hub and spoke
 61 2015-09-20 04:31:54 <maaku> then malleability fixes for full lightning
 62 2015-09-20 04:33:06 <maaku> meaning bip62, then a checksig2 with ntxid among other things
 63 2015-09-20 04:38:34 <dgenr8> the "replacement" in bip62 refers to offline replacements in eg LN channels?
 64 2015-09-20 04:38:41 <CodeShark_> are we sticking with the sequence semantics for 112?
 65 2015-09-20 04:39:04 <dcousens> thoughts on https://github.com/bitcoin/bitcoin/issues/6697?
 66 2015-09-20 04:39:17 <dgenr8> sorry bip68
 67 2015-09-20 04:39:33 <maaku> dgenr8: loosely, yes
 68 2015-09-20 04:40:30 <maaku> the example given is not a lightning channel
 69 2015-09-20 04:41:44 <maaku> in lightning CSV is used for branch selection in reconciliation, not transaction replacement as explained
 70 2015-09-20 04:43:02 <dgenr8> fyi the word "replace" doesn't appear after the motivation section
 71 2015-09-20 04:44:15 <maaku> CodeShark_: the bit inversion is going away for 112
 72 2015-09-20 04:45:01 <CodeShark_> maaku: does that mean we'll be using CHECKMATURITYVERIFY?
 73 2015-09-20 04:46:10 <maaku> CodeShark_: it's looking like both BIP 68 and BIP 112 will drop the bit inversion
 74 2015-09-20 04:47:03 <maaku> so the CSV name still fits
 75 2015-09-20 04:47:21 <maaku> but sequence numbers will count up for larger lock-times.
 76 2015-09-20 04:51:51 <CodeShark_> Hmm...I still think the "sequence" concept is baggage...will require more documentation and will be harder to explain to newcomers...but there are so many other issues that are so much more severe that by comparison this is a smal nit
 77 2015-09-20 04:52:59 <maaku> CodeShark_: eh, it's a name. that's not a complaint about the consensus rules proposed, right?
 78 2015-09-20 04:53:17 <CodeShark_> Yeah, as I said small nit
 79 2015-09-20 04:54:14 <Luke-Jr> "sequence" has always meant "increment for newer versions of the transaction to give hints to miner policies", while "wait N blocks before being spendable" has always been "maturity". <.<
 80 2015-09-20 04:54:20 <maaku> When it was first proposed I think it was important that it preserved the semantics of nSequence. Otherwise I don't think we would have built the unanimous acceptance of BIP 68 that we have today
 81 2015-09-20 04:54:59 <Luke-Jr> maaku: wasn't it originally called RCLTV, not sequence?
 82 2015-09-20 04:56:42 <maaku> Other people used that term, yes. I always found it too awkward
 83 2015-09-20 04:57:13 <maaku> I actually like the term sequence :)
 84 2015-09-20 04:57:36 <CodeShark_> too generic :p
 85 2015-09-20 04:59:15 <CodeShark_> try explaining what "sequence" means to someone new to bitcoin...vs. "maturity"
 86 2015-09-20 04:59:51 <CodeShark_> My nit is mostly pedagogical, I think
 87 2015-09-20 05:00:25 <Luke-Jr> maaku: sequence might be okay if it didn't already mean something else
 88 2015-09-20 05:00:44 <Luke-Jr> and not only that, but that old meaning is also the previous use of the field >_<
 89 2015-09-20 05:01:44 <CodeShark_> Then try using the term "sequence" consistently without being ambiguous when discussing the system design
 90 2015-09-20 05:02:40 <CodeShark_> My hunch is that the term "maturity" is much more likely to be quickly grasped...and will create much less confusion
 91 2015-09-20 05:08:13 <CodeShark_> Having said that, I'd rather expend political capital elsewhere if there's a lot of pushback
 92 2015-09-20 05:11:24 <Luke-Jr> CodeShark_: version bits!
 93 2015-09-20 05:11:37 <CodeShark_> Yes, working on it :)
 94 2015-09-20 05:11:43 <Luke-Jr> [22:40:04] * Luke-Jr ponders if the version bits BIPs cover how GBT should behave
 95 2015-09-20 05:11:52 <Luke-Jr> ^ I suspect this is being overlooked thus far
 96 2015-09-20 05:14:34 <CodeShark_> Interesting point...hmm
 97 2015-09-20 05:17:54 <CodeShark_> would mining pool operators set their preferences in the config?
 98 2015-09-20 05:23:28 <CodeShark_> Also, perhaps once a bit is cleared we should require that the line be taken out of the config when restarting
 99 2015-09-20 05:26:18 <phantomcircuit> <maaku> phantomcircuit: eh it's not _that_ bad. if we were to checkpoint the utxo set every quarter, and download from the most recent checkpoint >= 1yr ago and validate from there, it is not clear to me that we would be taking on any risk in practice
100 2015-09-20 05:26:28 <phantomcircuit> if we are relying on checkpoints for security
101 2015-09-20 05:26:38 <phantomcircuit> then we have exactly the same security model as most PoS coins
102 2015-09-20 05:28:01 <CodeShark_> Luke-Jr: another possibility is adding a preferences flag to gbt...but that seems uglier
103 2015-09-20 05:28:50 <phantomcircuit> <maaku> since a 1-year 51% attack has the power to kill bitcoin anyway
104 2015-09-20 05:28:52 <phantomcircuit> no no no
105 2015-09-20 05:29:18 <Luke-Jr> CodeShark_: probably GBT needs a way for clients to indicate which softforks they support by token/identifier, and for the server to indicate which version bits they are triggered by
106 2015-09-20 05:29:27 <phantomcircuit> a 51% reorg going back a full year will very likely at best gain the attacker nothing more than the coinbase rewards for those blocks
107 2015-09-20 05:29:38 <phantomcircuit> (and destroying bitcoin in the process)
108 2015-09-20 05:30:16 <phantomcircuit> but if there are utxo commitments then it gains them potentially infinity bitcoins for as long as it takes for exchanges to realize they're now worthless
109 2015-09-20 05:31:27 <phantomcircuit> the risk/reward ratio for the attacker is potentially hugely different
110 2015-09-20 05:31:53 <CodeShark_> Luke-Jr: I'd rather specify this behavior in a separate BIP since strictly speaking it's at the API layer and not the consensus layer
111 2015-09-20 05:31:57 <phantomcircuit> ie the risk is the same but the reward is potentially hugely outsized in a world with utxo commitments
112 2015-09-20 05:32:32 <Luke-Jr> CodeShark_: well, GBT is the only part of the API that is specified, but ok :p
113 2015-09-20 05:37:34 <CodeShark_> phantomcircuit: what if utxo commitments are combined with conservation proofs?
114 2015-09-20 05:39:36 <CodeShark_> a simple sum tree as part of the utxo commitment should fix that, no?
115 2015-09-20 05:39:38 <phantomcircuit> CodeShark_, conservation proofs?
116 2015-09-20 05:45:41 <CodeShark_> It would make such attacks far more likely to be detected
117 2015-09-20 05:48:25 <phantomcircuit> CodeShark_, no i mean im not sure what you're talking about, can you define that
118 2015-09-20 05:48:27 <maaku> phantomcircuit: does it matter how bitcoin dies, so long as it dies?
119 2015-09-20 05:48:53 <phantomcircuit> maaku, it matters that an attacker has different incentives to do the attack!
120 2015-09-20 05:49:07 <CodeShark_> i'm not 100% clear on your attack scenario
121 2015-09-20 05:49:19 <maaku> phantomcircuit: they won't cheat an exchange though as they can only fool a new node spinning up
122 2015-09-20 05:50:03 <CodeShark_> A malicious miner with 51% hashpower mines a block with invalid utxos they can redeem, yes?
123 2015-09-20 05:50:59 <CodeShark_> With a sum tree, we enforce that all outputs cannot total beyond X
124 2015-09-20 05:51:10 <phantomcircuit> CodeShark_, ah i see
125 2015-09-20 05:53:22 <phantomcircuit> CodeShark_, that helps things, the fraud proof is reduced to a sufficient number of branches which show the sum going up more than it should
126 2015-09-20 05:56:06 <CodeShark_> they'd have to remove someone else's outputs
127 2015-09-20 05:56:22 <CodeShark_> Which is detectable
128 2015-09-20 05:57:18 <phantomcircuit> CodeShark_, i'd certainly have to think about it more, but that potentially closes the gap between the rewards significantly
129 2015-09-20 05:57:35 <phantomcircuit> <maaku> phantomcircuit: they won't cheat an exchange though as they can only fool a new node spinning up
130 2015-09-20 05:57:50 <phantomcircuit> unfortunately nothing i have seen from exchanges would tell me that's true
131 2015-09-20 05:57:58 <phantomcircuit> maybe that can be fixed though
132 2015-09-20 05:58:24 <phantomcircuit> (note: that is the same external risk as a government/bank that simply wants to break bitcoin)
133 2015-09-20 06:07:38 <deego> https://www.reddit.com/r/Bitcoin/comments/3k3kli/theymos_mike_hearns_view_is_similar_to_satoshis/cuuxmuq?context=3 - too bad people go to reddit to get informed on bitcoin and on blocksize debate.  reddit: The place  where *core* developer's comments get downvoted below 0.
134 2015-09-20 06:07:53 <CodeShark_> phantomcircuit: there are a few subtleties here, though - for instance, outputs that involve multiparty contracts...or maturity requirement changes
135 2015-09-20 06:08:04 <deego> err, i had meant to post this in #bitcoin
136 2015-09-20 06:09:29 <phantomcircuit> CodeShark_, i thought so, thus my "i have to think about it more" comment :)
137 2015-09-20 06:10:52 <phantomcircuit> potentially there is a solution which equalizes the risk/reward between the current security model and a model in which virtually all nodes trust the utxo commitments
138 2015-09-20 06:11:06 <phantomcircuit> but i've certainly not seen such a scheme as of yet
139 2015-09-20 06:15:05 <CodeShark_> phantomcircuit: presumably a scheme that does not require SNARKs or SNARGs :)
140 2015-09-20 06:21:10 <phantomcircuit> CodeShark_, depends on whether you want quantum position money
141 2015-09-20 06:21:12 <phantomcircuit> :P
142 2015-09-20 06:22:05 <CodeShark_> You mean quantum superposition money? :)
143 2015-09-20 06:22:15 <CodeShark_> SchroedingerCoin
144 2015-09-20 06:22:55 <phantomcircuit> CodeShark_, well technically bitcoin is already that
145 2015-09-20 06:23:28 <phantomcircuit> (note for the casual observer... that was a joke)
146 2015-09-20 06:24:14 <CodeShark_> Well, there is some truth to that...
147 2015-09-20 06:24:59 <CodeShark_> If only we could get parallel chains to interfere with one another...
148 2015-09-20 06:26:05 <CodeShark_> Perhaps the miner "basis" could be rotated
149 2015-09-20 06:26:48 <CodeShark_> We apply a hadamard transform to the block headers before hashing :p
150 2015-09-20 06:29:28 <CodeShark_> Perhaps we'll finally have a retroactive invalidation scheme...
151 2015-09-20 06:29:41 <CodeShark_> A passive retroactive invalidation scheme
152 2015-09-20 06:30:17 <phantomcircuit> CodeShark_, lol
153 2015-09-20 07:56:44 <CodeShark_> Hmmm...not happy about adding soft fork thresholds to chain params directly...but perhaps we can use an abstract base class for soft fork thresholds so anyone creating a new alt/sidechain or testnet can inherit from it
154 2015-09-20 07:56:57 <CodeShark_> or perhaps we can just instantiate a map at runtime
155 2015-09-20 07:58:05 <CodeShark_> Using a dynamic structure like a map, the soft forks unit can check to see if an entry exists at runtime
156 2015-09-20 07:58:19 <Luke-Jr> CodeShark_: isn't the expiry inherently chain-dependent? seems like the same class of parameters..
157 2015-09-20 07:59:13 <CodeShark_> it is...but I don't want to pollute the Consensus::Params class with chain-specific forks
158 2015-09-20 08:00:53 <CodeShark_> I'm thinking how to best parametrize soft forks...we could even have callable soft fork objects that can handle the logic
159 2015-09-20 08:01:16 <Luke-Jr> oh, sure. but I wouldn't try to share softfork params between chains
160 2015-09-20 08:02:28 <CodeShark_> right - the idea is that we can see whether the chain supports some particular rule and if so, see whether it has been activated
161 2015-09-20 08:03:47 <CodeShark_> so the consensus code can basically be chain-agnostic
162 2015-09-20 08:04:53 <CodeShark_> If we define abstract structures for the chain state, we could even stick the rule definitions into the soft fork classes themselves
163 2015-09-20 08:05:25 <CodeShark_> So softforks become plugins, so to speak
164 2015-09-20 08:06:10 <Luke-Jr> that's probably a bit too far :p
165 2015-09-20 08:06:43 <CodeShark_> Well, it will certainly make source code maintenance a heck of a lot easier :)
166 2015-09-20 08:07:49 <CodeShark_> And it will allow all soft fork proposals to be specified as code modules that can be trivially merged
167 2015-09-20 08:07:57 <Luke-Jr> not so sure - what happens when a later soft fork modifies an earlier one? :P\
168 2015-09-20 08:09:02 <CodeShark_> we replace the older module with a new one
169 2015-09-20 08:09:05 <Luke-Jr> anyhow, I am way late to bed.. night
170 2015-09-20 08:09:15 <CodeShark_> night
171 2015-09-20 08:11:51 <CodeShark_> the trickiest part could be dealing with additions to the script
172 2015-09-20 08:13:20 <CodeShark_> New op codes will require the script interpreter to call the module as well
173 2015-09-20 08:14:48 <CodeShark_> We should separate the activation logic from the rules, though...so that different chains can reuse implementations even if they use different activation thresholds
174 2015-09-20 08:17:28 <CodeShark_> For instance, instead of doing https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4 we could call the softfork module for any no_op
175 2015-09-20 08:18:19 <CodeShark_> And pass it the current stack
176 2015-09-20 08:20:17 <CodeShark_> Then we never have to touch interpretter.cpp to merge a softfork
177 2015-09-20 08:20:35 <CodeShark_> *interpreter.cpp
178 2015-09-20 08:22:36 <CodeShark_> We can also have a pre- and a post-processing hook so we can support things like bip62
179 2015-09-20 08:24:23 <CodeShark_> we allow for preprocessing (or overriding) of specific existing op code behavior
180 2015-09-20 08:26:30 <CodeShark_> It would be beautiful if we could specify softforks as modules that can be trivially merged - and it's totally doable
181 2015-09-20 08:27:21 <CodeShark_> Trivially unit-tested, too
182 2015-09-20 08:29:21 <CodeShark_> The more we can reduce the need for code review effort the faster we can move
183 2015-09-20 08:29:33 <CodeShark_> Because that's the bottleneck
184 2015-09-20 08:31:07 <CodeShark_> It's well-worth the upfront effort...and can probably be accomplished in stages that don't cause too much downstream rebase pain
185 2015-09-20 08:35:05 <CodeShark_> it's actually probably easier to start with this than try to refactor the consensus stuff first...and it puts in place design patterns we can later apply to a real libconsensus
186 2015-09-20 12:50:21 <jgarzik> tnx
187 2015-09-20 12:50:30 <jonasschnelli> np
188 2015-09-20 12:54:43 <jgarzik> jonasschnelli, FYI something like https://github.com/jgarzik/picocoin/pull/45 is a more-complete solution for the UniValue -fPIC issue.
189 2015-09-20 12:56:15 <jonasschnelli> jgarzik: hmm.. isn't https://github.com/jgarzik/univalue/pull/6/files very similar?
190 2015-09-20 12:57:33 <jonasschnelli> https://github.com/jgarzik/univalue/pull/6 and https://github.com/jgarzik/univalue/pull/7 are different solutions... i prefere #6
191 2015-09-20 12:58:12 <jgarzik> jonasschnelli, yes, but #6 is incomplete.  univalue tests need to reference .la.  configure.ac needs library versioning macros.
192 2015-09-20 12:58:48 <jgarzik> jonasschnelli, header needs to be installed
193 2015-09-20 12:59:19 <jgarzik> jonasschnelli, #6 fixes the issue but results in a halfway conversion to libtool :)
194 2015-09-20 12:59:58 <jonasschnelli> jgarzik: Oh.. yes. Right. It's unfinished. I'll complete it soon if you think its going into the right direction...
195 2015-09-20 13:00:09 <jonasschnelli> Then i'll also close #7
196 2015-09-20 13:00:28 <jgarzik> jonasschnelli, ACK on merging #6 if it completes the libtool conversion
197 2015-09-20 13:00:37 <jonasschnelli> okay. will complete.
198 2015-09-20 13:00:40 <jgarzik> tnx
199 2015-09-20 14:42:05 <maaku> CodeShark_: yes, that was my argument last friday. much cleaner.
200 2015-09-20 15:11:25 <mjerr> does anyone have further details/full paper of http://cs.ucsb.edu/~koc/cren/project/2015Abstracts/OsuntokunAbstract.pdf ('OP_SCHNORRCHECKSIG: Exploring Schnorr Signatures as an Alternative to ECDSA for Bitcoin')
201 2015-09-20 15:16:01 <maaku> mjerr: schnorr checksig is implemented in elements alpha, for what it's worth
202 2015-09-20 15:16:54 <mjerr> maaku, oh, interesting, should take a deeper look into it.. I'm more interested in 'basic' information about ecdsa vs schnorr for now
203 2015-09-20 15:18:07 <maaku> #bitcoin-wizards would be a place to ask about that
204 2015-09-20 15:39:15 <andytoshi> mjerr: i said 5 minutes about this at 40:30 of https://www.youtube.com/watch?v=G6PnLSH40lQ
205 2015-09-20 15:39:19 <andytoshi> but yeah, -wizards
206 2015-09-20 15:39:45 <mjerr> oh right
207 2015-09-20 15:39:46 <mjerr> thanks
208 2015-09-20 15:50:22 <roasbeef> mjerr: i never wrote a paper, i wrote some (partially finished) code implementing bos-coster style batch sig verification, wrote a slidedeck and gave a preso
209 2015-09-20 15:52:11 <roasbeef> page 9 of: http://ed25519.cr.yp.to/ed25519-20110926.pdf gives a good overview of ec schnorr vs ecdsa
210 2015-09-20 15:54:24 <mjerr> thanks! :)
211 2015-09-20 16:31:42 <Luke-Jr> wtf is wrong with Travis? https://github.com/bitcoin/bitcoin/pull/6703
212 2015-09-20 18:14:36 <jonasschnelli> Luke-Jr: seems to be related to you PR... last PR built fine: https://travis-ci.org/bitcoin/bitcoin/builds/81261890
213 2015-09-20 18:14:42 <jonasschnelli> Maybe the configure.ac changes?
214 2015-09-20 18:14:47 <jonasschnelli> (very unlinkely)
215 2015-09-20 18:15:03 <jonasschnelli> Maybe a random error: try force push to re-kick travis?
216 2015-09-20 18:15:45 <Luke-Jr> tried that last night
217 2015-09-20 18:21:17 <moa> jonasschnelli: which configure.ac changes?
218 2015-09-20 18:21:30 <jonasschnelli> moa: https://github.com/bitcoin/bitcoin/pull/6703/files#diff-67e997bcfdac55191033d57a16d1408aR685
219 2015-09-20 18:21:47 <Luke-Jr> jonasschnelli: it never got that far
220 2015-09-20 18:22:17 <jonasschnelli> Or maybe this could be the source of the travis issue: https://github.com/bitcoin/bitcoin/pull/6703/files#diff-c949f93d03f44a4217d7a138f9e2e54aR200
221 2015-09-20 18:23:23 <Luke-Jr> it's affecting bfgminer as well
222 2015-09-20 18:23:44 <Luke-Jr> I think Travis is just broken
223 2015-09-20 18:23:52 <jonasschnelli> Luke-Jr: can be.
224 2015-09-20 18:24:41 <jonasschnelli> Luke-Jr: yeah. Travis has some issues: https://www.traviscistatus.com
225 2015-09-20 18:26:01 <Luke-Jr> ah