What is Reddit's opinion of 0bin.net?

From 3.5 billion Reddit comments

> holding up the CLTV patch

Last I checked Wladimir J. van der Laan and Pieter Wuille both agreed there's no way CLTV was going to get into v0.10.0, simple as that. Remember that when CLTV was proposed we were expecting v0.10.0 to be released "any time soon"

I personally aren't going to risk my reputation on a insufficiently tested patch, so I'm quite happy to let it take the time it needs to for us to be sure CLTV is the right solution. If you think waiting for more peer review beyond "cool feature!" is "holding things up", well, your loss.

As for hating on Viacoin... I don't see the Bitcoin community ponying up the cash to get CLTV implemented - I've billed Viacoin something like $3k for CLTV already. Before you be an asshole about something you're getting for free, you could start by paying for it. Donations accepted.

> Also, anyone wondering if they should invest in Viacoin should know that it's so centralized CHECKLOCKTIMEVERIFY is being enabled via a hardfork purely on the whim of BTCDrak telling people to upgrade all at once.

And the flip side of that small community, is it means if CLTV turns out to have a bug, fixing it is easy and won't cost all that much money. Screw up Bitcoin and miners alone lose tens of thousands of dollars an hour.

Great FUD! Yay! FUD!

>I have been thinking about publishing them but I fear retribution.

Retribution? Like what, exactly?

You could, for example, use Tor browser bundle and post the emails to http://0bin.net/ (encrypted pastebin, see the FAQ topic on plausible deniability), set a one hour expiration timer and link the pastes to any thread in the Bitcointalk speculation subforum or #bitcoin on freenode IRC.

Count on helpful members of the Bitcoin community to mirror it for you,
if there's even a grain of truth to allegations of corruption.

Or you could send a PGP encrypted email to any Bitcoin journalist, someone with a proven ability to do a proper writeup. It would be the story of the year! (I couldn't find a public PGP key for [email protected], which they should fix, for future cases like this.)

I expect OP not to deliver. But we'll see.

>they will send the legal counsel out to the provider

This is silly. The Bitcoin foundation has no power to do that.

Unless leaking the emails constitutes a probable crime on your part, then they would have to contact a law enforcement agency and convince them to issue a subpoena to obtain your IP from whatever service you used to host the emails. Yeah.

It's not like the Bitcoin Foundation have extra-legal superpowers.

There isn't a whitepaper yet, this stuff is too immature for that.

The coinwitness post is describing the mad-scientist cousin of this idea: it's stuff that has a better security model but requires really immature bleeding edge cryptography stuff which isn't ready for prime time at all. The two way peg is what you get when you subtract out the rocket science (and start solving a bunch of the fine engineering details that arise when you start actually trying to build something :))

You might want to see this update post by Adam Back to bitcoin-development: http://sourceforge.net/p/bitcoin/mailman/message/32108143/

Or where I described some of the basis ideas on IRC: http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt

Or this high level abstract I wrote for a small crypto conference. http://0bin.net/paste/0Up4ooAtTMXETizb#kbPCmCHvFF6jcRW1zqUWiqfh4NU2Es5pPtZ1xbd2py0=

>They soon employ almost all of the most active Bitcoin Core developers.

"Active" is kind of nebulous so I'm assuming this is an intuition of yours but it'd be interesting to more precisely understand the level of influence a single company may or may not have on protocol development in a real objective and quantifiable way.

For instance, if I scrape #bitcoin-core-dev IRC logs since January 1st, I see of those who have spoken at least 500 lines (~2 lines per day on average), 50% of the lines come from either a Blockstream employee or contractor. If I drop the 500 lines restriction completely it's more like 40%-- also I'm ignoring the GitHub bot. It would be interesting to do more analysis on this and other public communication channels and GitHub activity as well as include data for other organizations like the MIT DCI. Some people can't be linked to a single organization but it would also be good to bucket unknown contributors to get a sense for upper bounds.

Please take these numbers with a grain of salt-- I threw the script together in a couple of minutes. Please double-check it for accuracy before forming any strong conclusions: http://0bin.net/paste/wuZl4RtbximTo+fl#9cit6ZHtaK-K4Gl5sgyPxleqjSga9pqz/ztRQtKZG71. Edit: Edited the script for clarity but it had no impact on the data.

Also this shouldn't be "damning" and is not indicative of any wrong-doing or otherwise ill behavior. It's simply an attempt at trying to better understand the spheres of influence surrounding Bitcoin protocol development.

Further edit: On my lunch break I converted words.json to CSV and created a chart with Google Sheets: http://imgur.com/a/itIu6. I make 0 claims about what it says wrt influence or anything else. I just thought it might be interesting to those who don't pay much attention to Core's primary development IRC channel.

unfortunately, BUIP's are published on a site which has started blocking all archive sites. I'm aware of no durable storage for "BUIP" documents.

I'll paste a copy to a pastebin, I guess. http://0bin.net/paste/bHeJs5MdilfyAJki#IOjDd0vSL-unkyNKs4EebIIXFhSuG+PQwjtzRpwbR5o

I dont think it's even about scale. Some companies want control because they failed to communication with the developers, and built up unfounded siloed suspicions. I think /u/gavinandresen certainly contributed to it by interposing his negative views - imagine if as a company your trusted interface to developers is telling you they need to be fired, and you trust him so you believe him.

(If you want to hear Gavin say it see http://0bin.net/paste/8YeL12K5CwP26YUP#kSSLpZ2+PC9RqgcbiP0-bYbDhIHAMRCB3t2CpHkxokQ excerpt at bottom from the podcast http://www.bitcoin.kn/2015/09/adam-back-gavin-andresen-block-size-increase/ )

Gavin has a lot to answer for in the current disaster IMO. If this happened in my company it is Gavin that would be fired.

I had no idea these things were in demand. I work in hosting and see all types of shell (including c99, etc) uploaded on a regular basis.

They just get nuked normally. No guarantees they are not backdoored of course. I literally just did a grep across my quarantine folders for c99shell and pasted it as-is. I take no responsibility if you get yourself pwn'd, etc.

http://0bin.net/paste/-BXOykoFkwAyz37q#dY9ktg5bK5v7W5fyf3hB0rSuedAG8qdwT2FzAs55wBt

That being said, stick it on a VM in a private network and you should be grand. After all, someone else was using this one to compromise sites.

I'm not certain. The Core is very similar for each version, with the main difference apparently being where the recursion is introduced. Anyone who can read Core better than I can have some insight? The Occ=LoopBreaker stands out to me, but I don't remember if that's significant, really.

V1 Core

V2 Core

the first hit on google when i put in CEG TEK International was

this site which is an article about them trying to scam people into sending them money

EDIT: here's a copy of one of the letters another teksavvy user got. Seems these guys own rights to a lot of funky porn. Probably why they're banking on people paying without putting up a fuss

DOUBLE EDIT: I misread, and CEG is copyright enforcement group. they sue on behalf of copyright holders

From IRC:

http://0bin.net/paste/BU7XMcvaIYZS4E3C#oy2LOSvm0bLWJTG+z2wduD2jUGSJinlVFrogYjct8do

Don't got time to search for the commit right now, so you would've to look that up yourself.

Hope this helps.

Properly redacted Mar 31: http://0bin.net/paste/T8raaUmHU7+-pAJm#W3jU310efyv0KTEgpJF2+jHvftfy7yRprZcFZqCpkZ8

Properly redacted Mar 17: http://0bin.net/paste/4-NIZ05TI7VF0xUF#gR8q9WUB4hmD3zydNfQm2AVdAjIm4wKP+DyftYQITv+

>Of course there was public discussion 0_o.

>In addition to (an in advance of) the public discussion I directly contacted these 42 orgs http://0bin.net/paste/wmuzO-KTc3RQc39I#KUBSZohk6LXNzFYotPMHkG-2KnZTRoMxQIoii/sHbci -- ones I didn't contact were because I couldn't find contact information or because they simply didn't come to mind for anyone working on the lists, or because we simply didn't know they existed.

Why is Kraken not on that list? Quite a big exchange to forget about asking.

Optimized (-O2)

Looks like some extra bookkeeping (which I absolutely can't read) at the top of each function, and an extraneous case is optimized out of both V1 and V2.

Nope, still no luck. :(

I have a public donations address you can send to: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv or ask me privately for a fresh address if you're worried about anonymity.

Similar services:

• http://0bin.net/

• https://cryptobin.org

• https://defuse.ca/pastebin.htm

With the last one, you can (optionally) do the encryption entirely outside the browser with GPG. Instructions are provided about how to do this. This means that you don't have to trust that the javascript encryption code was not compromised on the server.

The same thing is also possible (in theory) with any of these services, but you don't get any instructions on how to construct the request in a form that will be accepted by the server.

http://0bin.net/paste/RwuGo5Rr8cJL3eUF#cLz76mNbpcmKjRZdlEluBVu7W5AEIzUcfXdaE5V+C0I=

here's a script I wrote up with an explanation in English for a client a while back about the problem. It's technical, but if you just read the English parts I think you'll get it.

tl;dr Yes. If your random numbers are bad... which brainwallet has been known to have bad random numbers.

Ok we added a FAQ t address the security concerns:

http://0bin.net/faq/

I think this is very good so many people raise these issues, it proves that more and more uses are becomming self aware of the all security thing.

Of course there was public discussion 0_o.

In addition to (an in advance of) the public discussion I directly contacted these 42 orgs http://0bin.net/paste/wmuzO-KTc3RQc39I#KUBSZohk6LXNzFYotPMHkG-2KnZTRoMxQIoii/sHbci -- ones I didn't contact were because I couldn't find contact information or because they simply didn't come to mind for anyone working on the lists, or because we simply didn't know they existed.

Very odd! And sure thing :) Posted on 0bin for easier copy/paste.

http://0bin.net/paste/po1d1ijIhNyJqgCk#Lw5vKkhbxvr-7WNeOEjza05Zg6+8lYMAMqtPK3yvQf0

That will "burn after reading", so no worries about your code hanging around the web.

If you want some different test data, this is my input: http://0bin.net/paste/qT1AkxlUgGcu9fSd#MlplEe6eHrwpRAVwYNT-S3Xbl2+GBnY5Z3ENn82Zouo

For that input, you should weed out 871 strings for the first rule (pairs) and 60 strings for the second rule (repeated characters with one in the middle), leaving you with 69 nice strings.

You can restructure your file::readFile() function to something like this, then you know when you've got each section right.

Awesome man! we have a 2 week turnaround time. Please upload pics to infobox.com or dropfile.to

Put sensitive details into a one time readable message using http://0bin.net/, https://onetimesecret.com/ or http://sms4tor3vcr2geip.onion/ and send to us.

1. Install npm (google for your OS)
2. npm install -g bitcoinjs-lib
3. save the following text into a file and name it anything you want with .js extension. (I'll call it btc.js) http://0bin.net/paste/o69N4P-oubF9+bKr#ZsRYD+Ierdu252U11StexLIp8bnS3WXtn+iCAaRKHZt
4. cd /dir/to/btc.js/folder
5. node btc.js 1 1000000 xpub6Qm11a4pbvfQkheU9FEdm1WiX48Bvm4JRSCQyj1zeCu2rzwfD8cJXhjGHbBrtfFKKjs1ito3wjRS6YLraqCDWLy218sRf5j2WRmSEcZsQ9U
6. A file called addresses_xxxx.csv will be saved in that directory with btc.js.

it's for signatures.

generating the same random number twice for any signature from the same private key will allow an attacker that knows both signatures to calculate your private key.

See this for more info: http://0bin.net/paste/RwuGo5Rr8cJL3eUF#cLz76mNbpcmKjRZdlEluBVu7W5AEIzUcfXdaE5V+C0I=

Having to move your mouse for five minutes before every signature (you have to generate 1 new random number for every input signed) would be cumbersome.

I know this is a month old post... but I found something similar to what you are talking about on a tech forum. Address reuse opens you up to weak random number generators.

As long as the random number generator used by the program signing transactions is good, you should be fine. However, sometimes programs rely on RNGs that are tied to the OS. If there is a bug in the OS's Random Number Generator, there could be catastrophic failure, and loss of bitcoins.

If you hold bitcoin on an address that has never signed anything. (aka you received any number of bitcoin transactions but have not spent any bitcoins from it) Random Number Generators only affect you once (during private key generation) but if you reuse addresses, you're pulling a lottery of two signatures using the same random number, which means you're pulling a lottery of getting your bitcoins stolen.

QT's RNG is pretty good. But still, that doesn't mean EVERY bitcoin wallet's RNG is good, so this was created to set an example of "good habits"

Scary stuff. Here's real life example using an old forum post to prove the concept.

http://0bin.net/paste/RwuGo5Rr8cJL3eUF#cLz76mNbpcmKjRZdlEluBVu7W5AEIzUcfXdaE5V+C0I=