I personally won't be porting it to 2.x.  I really don't have an interest in maintaining that backwards compatability, tbh.  If someone wants to submit a patch (and possibly maintain a 2.x-focused branch), I'll likely merge it.

Right, the private key class takes an array of bytes (= the private key in big endian format).

Thanks for checking out pyspv, I haven't put much work into it since because its announcement went quite unnoticed

Thanks. I look forward to the feedback.

Small update - I've added a few new features.

• Allow any m-of-n (not just m-of-3) transactions
• Support for partially signing transactions
• Support for adding signatures to raw transactions

With the above, ms-brainwallet should work well for doing things like escrow and without to share private keys or have all the private keys in one place.

Hope people find it useful!

Yes, although I haven't written new code for the site in a while, I still consider myself responsible for its operation.

If you want to contribute, write some code

I wouldn't trust this service (yet!).  How can we be guaranteed that you aren't giving people bad addresses?

My suggestion: allow the owner of the account to sign using their GPG key a message that says "1xxx... is my Bitcoin address."  Anyone can verify the address belongs to the user by checking their public GPG key from a gpg key server.

Also, consider implementing Stealth addresses to improve privacy in the Blockchain.

Reserved

pyspv - An extensible Python 3 Bitcoin SPV library

WARNING: This is ALPHA software. USE AT YOUR OWN RISK.

I've been working on this project for the past month and I finally feel that it's time to tell the community about it and ask for some constructive feedback.  I'm also more than happy to accept code contributions

The goal of this project is to create a library that can be used with Bitcoin (and eventually altcoins) that makes it easy for you to develop applications, both client and server, without doing any of the tedious Blockchain/Network/Transaction programming.  Integrating Bitcoin into your application is now literally a two line change to your code.

Features:

• SPV implementation, so relatively lightweight
• Written in Python, so useful for both server and user applications
• Multisignature support, can create, send to and spend multisignature payments
• Stealth address support, can create, send to and spend stealth address payments
• Tor/SOCKS support
• Testnet support
• Extensible payment monitor and transaction building system
• Completely modular, so you can initiate multiple SPV instances in the same application (This would allow for multiple alt-coin wallets)

The source comes with a sample RPC wallet called simple-wallet.py, you can launch it simply:


The README describes the full set of RPC commands available, but here is a small demonstration:

(The stealth address implementation was based on sx, so they should be fully compatible)

(simple-wallet will generate new keys if not enough are provided on the command-line)

So, anyways.  If you have time, try it out and let me know.  Also, let me know if you end up using it in a project, I'd love to link to it from here.

TODO

* Namecoin support (I actually have this mostly working, but I need to implement AuxPOW for the new blocks)
* Once Namecoin works, I should be able to finish my P2P alt-chain trading code and help automate trades (see https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains)
* BIP32 (HDW) and BIP38 (Encryption) support
* BIP70 (Payment protocol) support
* More altcoins? More payment monitors?
* CPU mining support (To aid in the creation of new alt-coins)
* Bug fixes

NOTE: Looks like there's a crash that happens between OpenSSL and Python when using 64-Bit Python build, so refrain from using 64-bit python for now.  I'm looking into it.

I've had a few thoughts along this line, as well.. Perhaps instead of ANYUTXO, which is quite specific (don't hash the prevout field), why not build CHECKSIG2, which takes a flags word indicating each of the pieces of the transaction to sign (nLockTime, Outputs (Single, All, None), Inputs (With/Without prevouts, Anyonecanpay, sequence #s), etc.)?

I would actually consider writing the patch myself, if there was at all a decent chance of it being accepted into the reference client within the next several months.

Forgive me if this has been discussed to death and back, but lately I've been working on some Contracts transactions.  The realization that malleability prevents some of these contracts from working (trustlessly and securely) is starting to sink in.  

Dependent transactions just can't be built until they're included in the blockchain...

Does tx malleability basically mean that a number of advanced contracts are essentially broken?

1. Providing a deposit - Tx2 can't depend on Tx1 txid not changing. Step 2 sends the hash of Tx1 to the "website" to sign a refund tx.
2. P2P alt-chain trading - Tx2 can't refund Tx1 until it's in the blockchain, but you shouldn't fund Tx1 until Tx2 is signed.
3. Rapidly adjusted micropayments - (Does this hurt bitcoinj's security too?) Can't create refund T2 based on hash of T1.

I'm not interested in MtGox and their usage of transaction hashes, as that's just something they can fix.  These advanced contracts, on the other hand, heavily depend on a transaction hash not changing.

What happens if you hold 400$ worth of anti-credit and the price falls to 1$?  You would owe 400 bitcoins to close that anti-credit.

And on the flipside, I'm owed 400$ worth of bitcoins and I want to use my credit to purchase 400 bitcoins. Where do they come from?

And the problem exponentially increases as the price nears 0$.

BTW this feels like an options market, where obligations are paid with the equivalent USD amount in BTC.

It would be nice to keep 't' at the beginning of the string to be consistent with Bitcoin testnet.  tpXX and tuXX ?

Ah, you're right.  I'll update the text.  The keypair index is only available if you pick a derivation method that includes "i".


When you change the button at the top to BIP32 key, you can paste extended private keys into the "BIP32 Extended Key" field.


Perhaps there's layers of advanced-ness


You don't really need to understand these things if you're just a user of wallet software.  If you're going to be writing wallet software, it helps to know what these things are.  Some of them are critical pieces of knowledge.

There isn't a spec for the alt coins as far as I'm aware. It'd be nice if there was.

TBH, I was hoping that my version bytes would become the standard. Hypothetically, if my implementation were actually used by alt-coiners then when drafting the spec it'd be more of an issue that the spec has to deal with (that people have already adopted a standard to use).  Unfortunately, there's just no BIP-style development for any of the other coins, so I was forced to improvise if I wanted to support altcoins.

I was indeed going with XXpv/XXub for the public/private keypair prefixes.  For testnet, I was a little less concerned about consistency but it seems you have gotten the general gist of things.

The code isn't set in stone. If you guys want the version bytes changed, let me know:)

Maybe rbonestell can put up an apk?

Awesome! Bounty paid: https://blockchain.info/tx/8f0eb76c038e1744d136f6f74ae23d9577bd1add0b759c61dc8ef221976c9f36

Cool. I'm going to build it today and if it works I'll send you the bounty!

I'd like it to actually look nice   The functionality is easy, and if that were all I'd want then I would just make it myself...

Seems like blockchain.info would be fine for this. 

I don't understand what you are asking in the PM. All the details are here in the above post:)