jlrubin

13 ms·

121.
Krypt.co raises 1.2M to securely store your SSH private key on your phone(techcrunch.com)
77 points by jlrubin 9y ago|42 comments
122.
by jlrubin 9y ago
This is a truly excellent post, but Anish (humbly) buries the lede: Anish implemented a really fast checker called Porcupine which is available here https://github.com/anishathalye/porcupine . Would love to hear more on
123.
by jlrubin 9y ago
This was a fun write up. On the off chance the author is reading the comments here, there are a couple security features they need to add for it to be more complete (I'm probably missing some things). 1) They should add a call to acces
124.
by jlrubin 10y ago
It's not semantic, it is substantive. A maximally utilized SegWit block is larger than a maximally utilized current block. I.e., if you were planning out how much disk space you needed years in advance, you would have to increase that
125.
by jlrubin 10y ago
https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize... , which includes a reference implementation. It does optionally include an immediate reduction, followed by a gradual increase. This was dev
126.
by jlrubin 10y ago
That's one way to read it. Another way is: we are OK with a segwit soft-fork sooner so long as we can later clean it up with a hard-fork and re-enable our optimizations by June 2017. When a hard-fork happens, it can do almost anything,
127.
by jlrubin 10y ago
No, it is a space increase! Witness data is counted with a discount. Blocks can be larger than 1MB under SegWit.
128.
by jlrubin 10y ago
Thanks Ryan, these are good clarifications to the parent's post. For full transparency, I [OP, author of the PDF] am currently contracting with (but am not employed by) Chaincode and am currently #39 by commits (#26 by additions though
129.
by jlrubin 10y ago
Greg, I think the recursive algorithm should still be faster on the left hand side than just rolling the coinbase extra nonce, but after the first sqrt the numbers are pretty small so maybe the constants dominate.
130.
by jlrubin 10y ago
It's not that big of a computation even at 4 collisions, but yes, I'm familiar with the math (I wrote the PDF).
131.
by jlrubin 10y ago
SegWit + HF does not eliminate this class of optimization. Most SegWit+HF proposals would reorganize the bitcoin header structure so as to be compatible with ASICBOOST-like optimizations.
132.
by jlrubin 10y ago
Another problem with ASICBOOST is that it incentivizes a miner to try to partition the network such that the orphan rate increases, because mining on top of orphan blocks is more profitable. If we have two competing successors (S_1 and S_2)
133.
by jlrubin 10y ago
Notably, they don't include the optimal root generation algorithm, nor do they discuss segwit incompatibilities. Also, their 20% figure is unclear. The more collisions you can find, the more hash per second you should be able to gain.
134.
by jlrubin 10y ago
The problem with the proof of work is that the machinery became dependent on the selection of transactions in the block. A "standard" miner does not have this dependency. It's not a problem (depending on who you ask) that an
135.
Bitcoin's ASICBOOST Problem Explained [pdf](rubin.io)
152 points by jlrubin 10y ago|123 comments
136.
by jlrubin 10y ago
I guess that's what I'm trying to get across: I fundamentally agree with core's approach over any other. That's why I work on Core. Core not prevailing here would be upsetting to me because it would be opting for a subpa
137.
by jlrubin 10y ago
They gained the influence through being really really good at what they do. They don't command it though by illegitimate means. I regularly disagree with Greg, Luke, and Pieter; while I don't always come around to their 'side
138.
by jlrubin 10y ago
Thanks, my response was written with severe annoyance. I felt I did respond to the argument, as it was (to me) that A) dev is run by blockstream and B) there are no performance improvements. I was trying to evidence that by invoking my inde
139.
by jlrubin 10y ago
I'm not invoking authority, I'm invoking independence. Core isn't owned or run by Blockstream.
140.
by jlrubin 10y ago
My most recent effort was a new algorithm for caching which improve validation times up to 40% (measured) for new blocks, and also reduce the amount of memory required to speedily validate blocks. It also is more friendly to re-orged blocks
141.
by jlrubin 10y ago
I'm a Bitcoin Core Dev. I'm not employed by Blockstream. I work extensively on scalability, having personality designed and written patches to Bitcoin which have drastically improved block validation times in the Bitcoin Core clie
142.
by jlrubin 10y ago
That's not really the definition of numerical stability. You're thinking of linear system stability, which is a whole other topic. Numerical stability is how resilient a computation is to computational error. These computations ar
143.
by jlrubin 10y ago
I appreciate that the author wanted to implement their own eigen vector/value method, but really they should use: numpy.linalg.eig(x)[0] numpy.linalg.eigvals(x)[0] Numerical stability can be hard to get right...
144.
The Bug That Knocked Out Bitcoin Unlimited(bitcoinmagazine.com)
2 points by jlrubin 10y ago|0 comments
145.
by jlrubin 10y ago
This is somewhat false. It is true that Bitcoin can currently support about 7 txps. However, this isn't the whole picture. 1) A much better number to use is 4,500/10 minutes, because if the transactions aren't used in a prior
146.
by jlrubin 10y ago
What makes you say that cuckoo uses 2x memory?
147.
by jlrubin 10y ago
I'd be interested to see a comparison of cuckoo hashing v.s. robin hood on these benchmarks. I chose to use Cuckoo in my implementation of a high performance fixed-size cache for bitcoin signature validation (see https://git
148.
by jlrubin 10y ago
Author may be interested in http://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-m... as a way of avoiding modulo altogether.
149.
All your friends aren't dead: Facebook bug memorializes users
3 points by jlrubin 10y ago|0 comments
150.
by jlrubin 10y ago
Lots of really cool technology presented. Recommend watching TumbleBit and MimbleWimble talks, very promising developments.

More ›