Latest posts of: endian7000

Show Posts
Pages: [1]

Bitcoin / Bitcoin Discussion / Re: [Guide] Saving your wallet.dat to PAPER

on: June 22, 2011, 04:54:36 PM

See also: https://github.com/bitcoin-labs/paper-keys

Bitcoin / Bitcoin Technical Support / Re: Lost Savings Wallet Addresses?!

on: June 08, 2011, 12:28:21 AM

Holy crap, that's horrible! My condolences! Perhaps next-gen clients should be much more explicit about key management... Meanwhile, perhaps you'd prefer something tangible and easily modeled like https://github.com/bitcoin-labs/paper-keys

Bitcoin / Project Development / Re: Go to Wall St in Front of N.Y. Stock Exchange With Sandwich Billboard - 100BTC

on: February 23, 2011, 03:56:10 PM

Someone in my office (near the NYSE) said they saw it this morning! Of all the mornings for me to come in late...

Bitcoin / Bitcoin Discussion / Re: Major Retail Point of Sale Initiative in USA

on: January 11, 2011, 05:49:44 PM

About "/vX.Y/"... How about using semver, dropping the Z? http://semver.org/

Bitcoin / Bitcoin Discussion / Re: Major Retail Point of Sale Initiative in USA

on: January 11, 2011, 05:48:35 PM

Quote from: davout on January 11, 2011, 04:20:26 PM It becomes pretty easy to clear payments between two of these entities based on : - trust, or - Instance A maintaining a security deposit at instance B Absolutely. Quote - trust Exactly what /api/vX.Y/attach-identity-to-transfer.js is trying to help with: bringing the trust requirement from "A will settle this debt" to "A won't attempt to multi-spend in conflict with this transfer" (Well, that plus getting a copy of the ordinary bitcoin transfer data to B ASAP.) Quote - Instance A maintaining a security deposit at instance B This wouldn't need any changes to B. A could open and use an ordinary account on B.

Bitcoin / Bitcoin Discussion / Re: Major Retail Point of Sale Initiative in USA

on: January 11, 2011, 05:41:40 PM

This should have been my first post... hub: a generic term for bitcoin-central, account-hub, ... A, B: specific hub instances (the account-hub repo should probably be given a less generic name) standard account service aspects ordinary bitcoin transfers to external bitcoin addresses rapid transfer between bitcoin addresses controlled by the hub (1) API call: attach-identity-to-transfer A makes an ordinary bitcoin transfer to B A also makes an API call: B.com/api/vX.Y/attach-identity-to-transfer.js This tells B that A has access to the private key which created that transfer and that A is claiming both that (i) A is the only person with that access and (ii) A will not attempt to multi-spend. POST /api/vX.Y/attach-identity-to-transfer.js Code: Content-Type: application/json X-Coinholder-Signature: ...TODO standardize... X-Hub-Signature: ...TODO standardize... { bitcoin_transfer: "...base64-encoded copy of the standard bitcoin transfer data..." hub_url: "..." hub_public_key: {...TODO standardize...} } ...where Coinholder is the private key used in the standard bitcoin transfer. (2) invoices We could call them "requests", but "invoices" doesn't conflict with "HTTP requests" in our discussion. An invoice is a JSON object: Code: { hub_url: "..." # Each invoice gets its own bitcoin address: bitcoin_address: "..." # Care is needed when parsing or generating these strings: amount: "10.7582 BTC" optional_info: { title: "..." t: ms since 1970 lat: "..." lng: "..." } } Hubs will offer a create-invoice API call of some sort to their customers. (3) invoice broadcasting Suppose there's an invoice payable to an account on B, but the merchant has no way of getting the invoice directly to the customer. (e.g. for POS-machine/smartphone transfers without using near-field wireless or barcode-scanning) Later: a well-designed P2P network Now: B makes an HTTP request to EACH of the other hubs it knows about. POST /api/vX.Y/post-invoice.js Code: Content-Type: application/json X-Hub-Signature: ...TODO standardize... { invoice: {...invoice...} } POST /api/vX.Y/withdraw-invoice.js Code: Content-Type: application/json X-Hub-Signature: ...TODO standardize... { bitcoin_address: "..." } So... how do (1), (2), and (3) each sound as additions to what a standard account services offer? bitcoin-central can probably easily implement (these simple additions) before I implement (them + everything else an account service needs to do)

Bitcoin / Bitcoin Discussion / Re: Major Retail Point of Sale Initiative in USA

on: January 11, 2011, 04:39:05 PM

Absolutely. Centralization is unnecessary and insane for an online "Pay with BitCoin" button. All the merchant site needs to provide the client with is e.g. {hub_url:, bitcoin_address:} and e.g. a BitCoin browser plugin can take it from there. Though there could be some site(s) with an intro-to-bitcoin-payments page that the button would lead to if you didn't have the plugin.

Bitcoin / Bitcoin Discussion / Re: Major Retail Point of Sale Initiative in USA

on: January 10, 2011, 05:47:50 PM

Quote from: endian7000 on January 10, 2011, 04:41:34 PM (1) I hate the AGPL. AH will be under a permissive license. (2) Competition is a good thing (3) I wanted to focus specifically on the APIs and protocols at first (4) (NodeJS + CoffeeScript) is awesome Quote from: davout on January 10, 2011, 05:06:10 PM 1. is not set in stone Quote from: davout on January 10, 2011, 05:06:10 PM 2. so is cooperation Absolutely! ...and with compatible licenses, there can be competing projects which borrow code extensively from each other are in open discussion with each other have their sets of supported APIs overlap Speaking of which, what are your plans for bitcoin-central's API? Quote from: davout on January 10, 2011, 05:06:10 PM 3. this is not specific to any implementation Right. I meant that I wanted to build an API-server before dealing with a frontend codebase. Quote 4. can't argue with this one i guess... Come on in -- the coffee's hot! ...and tools will improve drastically during 2011.

Bitcoin / Bitcoin Discussion / Re: Major Retail Point of Sale Initiative in USA

on: January 10, 2011, 04:41:34 PM

Wow, I didn't realize Bruce had started talking about AH here already. I was planning to wait until there was a full spec proposal and a cool demo, then become an active forum member. Sorry you had to first hear of my account-hub ideas through Bruce's enthusiastic but semi-technical and semi-correct wording. So howdy, everyone. This is my first of many forum posts. I was planning to lone-wolf it until a prototype later this week, but I'm looking forward to future collaboration! Basically, AH provides an ordinary (mybitcoin.com)-like account server with a full API and a mobile client using that API, plus (1) There's a high-speed side network for broadcasting invoices among the AHs (2) If you're an AH ("X") making an ordinary bitcoin transfer to another AH ("Y"), you can immediately increase Y's estimate of the probability that the transaction won't fail due to a multi-spend attempt by making an API call to Y and signing (that transfer data + your public key) with your private key and the private key used for the transfer. That's about it so far. I'm pretty busy today, but I'll write more this week. Meanwhile, I pushed more documentaion this morning: https://github.com/tafa/account-hub Quote Why not re-use the bitcoin-central source code (1) I hate the AGPL. AH will be under a permissive license. (2) Competition is a good thing (3) I wanted to focus specifically on the APIs and protocols at first (4) (NodeJS + CoffeeScript) is awesome Quote I ask because I'm also working on an Android app. A app that communicates with the Bitcoin network, or an app that just acts as a client for account servers? I'm only doing the latter. Quote Everything he does, he has committed Not true. In the public repos, I've only committed documentation so far. There's implementation work that hasn't been added to those repos. Within a few days, that won't be the case. Quote ...Ripple... That could be really cool. The current AH services do not involve debt, but AHs could provide debt-related services as well... I'll read up on all the details of Ripple soon.

Pages: [1]