Re: [Bitcoin-development] Introducing BitcoinKit.framework
As an FYI, I've sent Wendell and co some example code for how to use CPPJVM to use bitcoinj from native code. A rather rough Hello World app looks like this: https://github.com/mikehearn/cppjvm/blob/master/mytest/bcj-hello-world.cpp So, fairly C++ like. Further discussion of this should take place on the bitcoinj mailing list. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption
This isn't usable for SPV wallets unless it has a birthday in it. Otherwise you either need to scan the entire chain (slow) or find a fully indexed copy of the block chain (expensive, more centralised). Just add a UNIX time as an extra 4 bytes, or if you want to save a few characters then use a uint16 that represents days since birth of this specification. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption
Hi Mike, I had a similar request on the forums. I suggested adding either a 2 byte 'weeks since genesis' or 'months since genesis', but starting from spec birth works too. Would either of those work for you? jp On Jul 22, 2013, at 6:14 AM, Mike Hearn m...@plan99.net wrote: This isn't usable for SPV wallets unless it has a birthday in it. Otherwise you either need to scan the entire chain (slow) or find a fully indexed copy of the block chain (expensive, more centralised). Just add a UNIX time as an extra 4 bytes, or if you want to save a few characters then use a uint16 that represents days since birth of this specification. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [RFC] Standard for private keys with birth timestamp
Hello, I should have brought up this suggestion before, as there seems to be relevant other work. I'd like to propose encoding keys data (whatever type) with a birth timestamp as: * serialized key@unix timestamp in decimal The reason for not incorporating this inside the key serialization (for example BIP32), is because birth timestamps are more generally a property of an address, rather than the key it is derived from. For one, it is useful for non-extended standard serialized private keys, but for P2SH addresses, the private key is really the actual scriptPubKey, but birth data is equally useful for this. Reason for choosing the '@' character: it's not present in the base58, hex, or base64 encodings that are typically used for key/script data. One downside is that this means no checksum-protection for the timestamp, but the advantage is increased genericity. It's also longer than using a binary encoding, but this is an optional part anyway, and I think human typing is already fairly hard anyway. -- Pieter -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] HTTP REST API for bitcoind
URL: https://github.com/bitcoin/bitcoin/pull/2844 Adding an HTTP REST API for bitcoind has been occasionally tossed about as a useful thing. Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain. The first two implemented API calls are simple, returning a block or TX given a simple query string based on block hash, e.g. GET /rest/tx/TX-HASH or GET /rest/block/BLOCK-HASH This can be easily accessed via command line cURL/wget utilities. Output formats -- binary, hex or json -- may be selected via a bitcoin-format header. The general goal of the HTTP REST interface is to access unauthenticated, public blockchain information. There is no plan to add wallet interfacing/manipulation via this API. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption
I added a 2 byte 'weeks since 2013-01-01' field and updated the prefixes, ranges and test vectors.The updated proposal lives here:https://bitcointalk.org/index.php?topic=258678Cheers,jpOn Jul 22, 2013, at 06:14 AM, Mike Hearn m...@plan99.net wrote:This isn't usable for SPV wallets unless it has a birthday in it. Otherwise you either need to scan the entire chain (slow) or find a fully indexed copy of the block chain (expensive, more centralised). Just add a UNIX time as an extra 4 bytes, or if you want to save a few characters then use a uint16 that represents "days since birth of this specification". -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] HTTP REST API for bitcoind
+1 and thank you. I've prototyped a couple different Bitcoin projects that would benefit from this. I'm traveling with poor 'net so I haven't read the patches yet. I echo pull request comments about using Accept and Accept-Encoding headers. Same for an API version number in the URL. It'd be helpful, eventually, to have APIs corresponding to Bitcoin addr and version messages. Metadata about the network and the peer, respectively, are valuable in my use cases. Michael On Jul 22, 2013 1:43 PM, Jeff Garzik jgar...@bitpay.com wrote: URL: https://github.com/bitcoin/bitcoin/pull/2844 Adding an HTTP REST API for bitcoind has been occasionally tossed about as a useful thing. Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain. The first two implemented API calls are simple, returning a block or TX given a simple query string based on block hash, e.g. GET /rest/tx/TX-HASH or GET /rest/block/BLOCK-HASH This can be easily accessed via command line cURL/wget utilities. Output formats -- binary, hex or json -- may be selected via a bitcoin-format header. The general goal of the HTTP REST interface is to access unauthenticated, public blockchain information. There is no plan to add wallet interfacing/manipulation via this API. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
