The JavaScript client is only a client, it does not act as a node in the peer-to-peer network. The peer-to-peer network is implemented in C++.

I really need to shut up now though.

For me there is no doubt both networks will be complementary. Ripple is obviously influenced by the fact that most of the team members come from a Bitcoin background. Bitcoin-related use cases are very much a priority. That's all I wanna say lest I get in trouble.

What I can tell you is that this project is the most fun I've had at any startup. The team is absolutely amazing and working on something like this and getting paid for it is a dream come true.

(Speaking of which - if you've got the skills, we're hiring.)

As far as the client is concerned, it's already open-sourced, so if you're bored waiting for more details to come out, feel free to check in on our progress: https://github.com/rippleFoundation/ripple-client/commits/master

Hey all,

This is an unofficial post announcing the next San Francisco Bitcoin meetup on the forums, so here goes:

Where: 2415 Mission St. (at 20th & Mission) - Downstairs office space
When: Tuesday, November 27, 2012, 7:00 PM to 10:00 PM
Who: Bring... EVERYONE.

More information and letting us know you're coming:

http://www.meetup.com/San-Francisco-Bitcoin-Social/events/85937822/

I'm in San Francisco at the moment, so I'm very excited to see at lot of you guys in person for the first time!

Cheers,

Stefan

Come to the next meetup Tuesday: http://www.meetup.com/San-Francisco-Bitcoin-Social/events/85937822/

Or feel free to stop by the Ripple office sometime at 181 Fremont - PM me beforehand to set up a time.

Very true, I hadn't thought of that, So yeah that underlines the point that you need to have the pubkey contained in the hash (and confirm it matches of course) to prevent this class of attack.

Yep.

--

One more point that is going to be obvious to those comfortable with elliptic curve math, but bears writing down: It's important that the base pubkey is captured in the hash, otherwise the scheme becomes ambiguous. I'll use the bond message case as an example.

Let's say you have a message pubkey M. It was calculated from issuer public key P₁ and Bond message hash b₁ as M = P₁ * b₁.

Now I'm an evil attacker and I want to create another pair P₂, b₂ that also results in M. What I can do I choose an arbitrary Bond message, calculate its hash b₂ and then calculate P₂ = M * b₂^-1. Obviously I don't have the corresponding private key but having a valid pair P₂, b₂ might be enough to cause problems depending on the use case. What prevents this attack is the fact that the Bond message contains the pubkey. If I try to enter P₂ into the bond message, its hash changes and P₂ is no longer correct. To make the message valid I would have to find a SHA256 collision, i.e. a Bond message where I've inserted P₂, but that results in the same hash b₂.

Well, at the very least it would be a size optimization.

Take for example the "BOND" message:


Can be reduced to:


Where <message pubkey> = <issuer pubkey> * <hash of bond message>.

The only necessary change to the bond network protocol is that the Issuer object must (rather than "may") contain the issuer pubkey.

You might say that now we cannot derive the hash of the bond message from the transaction if we haven't seen the corresponding Bond message yet. But if that's the case the hash of the Bond message wouldn't tell us anything anyway, so we don't lose anything. For the hashmaps we can use the message pubkey as the key, which can be derived from both the transaction and the Bond message, so indexing and lookups in either direction are still possible.

All the "BOND" string really does is alert us to the fact that we need to check this transaction against our index. In other words, it is there for performance reasons only, so whether it is necessary is really a practical/implementation concern, weighing blockchain bloat against bond node performance. Given that it's just six bytes though it seems certainly worth it.

If we want to really minimize the size of the output script, we can even use the hash of the message pubkey instead of the message pubkey itself.


I haven't looked at it in-depth, but it seems the same optimizations apply to the "POLICY" transaction, although I think a new broadcast and a new hashmap would have to be added to the bond network.

Maybe. Off the top of my head (sorry in advance if I'm missing something obvious):

Currently, the way we handle metadata in Bitcoin is that the metadata is transferred to the recipient, who then replies with a uniquely generated address. Once the sender makes the payment, the metadata can be determined by the address.

In theory, this already allows secure association of arbitrary metadata with a Bitcoin transaction. The problem is that we need to contact the recipient *before* we make the transaction, which doesn't work well for many use cases.

So how about this.

The recipient publishes their public ECDSA point P.

A sender generates a JSON metadata object M and calculates its hash e = SHA256(M). The sender then calculates a new public point P_M = P * e. Next, the sender creates a transaction sending the money to the address RIPE160(SHA256(P_M)). Finally, he transmits M to the recipient through a secure channel - this could be sent directly via HTTPS, encrypted email, etc. or perhaps left as an message in a DHT, encrypted with ECDH and the recipient's public point P as the key.


What properties does such a scheme have?

The recipient is committed to one set of metadata M for this transaction unless they can find a SHA256 collision. As long as the metadata object is kept private, no one else can determine the relationship between the public point P and the transaction-specific point P_M. The recipient does not need to be always-online.

Thanks for the warm welcome! As a user of the Bitcoin forums I've always had a lot of respect for the amazing job the staff has been doing, so I'm very much honored to become a part of this team and I'm looking forward to working with all of you!

For those who are wondering what I'll be doing exactly: My primary responsibility is to be available to take up admin duties when theymos is away. Other than that I may do the occasional standard moderating if I happen to be first on the scene. If there are any questions or concerns, don't hesitate to PM me. For those attending the London conference next week, I'm going to be there as well of course, so feel free to say hi!

I also went ahead and fixed the DER bug: https://github.com/bitcoinjs/bitcoinjs-lib/commit/07f9d55ccb6abd962efb6befdd37671f85ea4ff9

@piuk: Can you have a look at the patch please and let me know if it looks correct to you?


The BitcoinJS tip jar is: 13SjwsodtKsAhQwPx14s7aqKpnooeep4i5

Feel free to split the bounty between Joric and me. I did it mostly because I thought it'd be fun (and it was. )

Fixed: https://github.com/bitcoinjs/bitcoinjs-lib/compare/de6cfd37db...49114d6540

I also simplified the code somewhat: https://github.com/bitcoinjs/bitcoinjs-lib/commit/de6cfd37db72a8c29acacaf2aa33d46e88ca4b15

And by "somewhat" I mean a LOT. ^^'

Apparently all the fancy algorithm stuff I did was completely superfluous. - Thanks to Joric for the pointer.

No, these signatures aren't DER encoded at all. I'll take a look at your test cases and debug!

I implemented this as you asked:

https://github.com/bitcoinjs/bitcoinjs-lib/commit/9b2f94a028a7bc9bed94e0722563e9ff1d8e8db8

When ErebusBat asked for this on IRC it seemed like a fairly innocent feature request, I had no idea what I was getting myself into. A few hours later I was implementing the Tonelli-Shanks algorithm (another JavaScript first I think?) and calculating Legendre symbols.

The reason for all the complexity? Bitcoin's message signing facility uses compact signatures which use public key extraction to recover the pubkey from the signature. The Bitcoin core devs happily do their little calls out to the OpenSSL API, not realizing they just pulled in pages worth of algorithms.

Public key extraction is also very computationally expensive. Generating compact signatures is even worse, as the algorithm does 1-4 test verifications while signing. There are some more optimizations I can do, but this will almost certainly be too slow to run on smartphones. (Unless you find a way to hook up BitcoinJS' BigInt to a native big integer implementation of course.)

There is still one bug I have to figure out related to our implementation of Shamir's trick. Hopefully I'll be able to do that this weekend. We could really use a proper suite of unit tests for bitcoinjs-lib.

(The four test cases at the bottom of message.js will obviously be removed once I officially release this.)

Hey everybody, as promised we're following the recent "mini-meetup" up with a more regularly scheduled meetup:

When: Saturday, 7th of July 2012 at 16:30
Where: Oliver Twist Pub, Zurich
Who: All Bitcoin users, enthusiasts and skeptics welcome

No registration necessary. Special guests (time permitting) are two of the authors of "Two Bitcoins at the Price of One" from ETH Zurich, a paper looking at double spending attacks. You can have a read here

If you are interested in Swiss meetups, please subscribe to the bitcoin-switzerland mailing list.

Aww, we miss you too, mate.

Australia is at the top of my list of places I'd love to visit. Just a matter of saving up the necessary coin really. 

Hey everybody, I know it's very short notice, but here you go anyway:

When: Monday, 4th of June 2012 at 18:00
Where: Oliver Twist Pub
Who: All Bitcoin users and enthusiasts welcome

We've got Pieter Wuille aka sipa attending, so this is your chance to meet and have a beer with one of the most prolific core Bitcoin developers!

Depending on attendance and the feedback I get, we'll either hold an "official" Zurich meetup sometime in June/July as well or skip to Geneva after this one.

If you are interested in Swiss meetups, please subscribe to the bitcoin-switzerland mailing list.

Repayment received. Many thanks.

1DzKYgC3r3cgCujJPmnA8kQWYkHHKZFNVk

Good luck with whatever the hell it is you're doing. 

Would lend you the money at 8% p.a., so for a week that would be about 100 * .08 * 7/365 = 0.15 BTC interest.

Happy birthday us! 

Thanks everyone for making this possible! A lot of people have asked about a followup - right now I'm very busy and I can't promise anything, but WUC was certainly an awesome experience and I'd love to build on it in some form in the future.

One thing I can promise is that there is a (much needed) website relaunch incoming! If you have any comments or suggestions for that, please email them to info@weusecoins.com.