 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
|
I'm offering a small bounty - I'm not sure how much yet, perhaps 0.5 - 1 BTC - for an Android app widget that displays the following info:
* The current blockchain height
* Minute count since last block
* Total outstanding BTC mined (current formula is easy: 210,000*50 + (nHeight-210,000)*25)
It should look pretty and be open source / public domain. There are plenty of app widgets that show btc/usd price, but I'm more interested in seeing some real time stats about the network at a glance.
Is anyone interested in taking the offer?
|
|
|
|
|
I've added Litecoin support.
|
|
|
|
I am not sure if inventing special BIP32 versions for altcoins is a good idea.
There's no reason why you couldn't use the same BIP32 tree for all altcoins. Let's say path m/0/... for bitcoins, m/1/... for crapcoin and m/2/ for different shitcoin, etc.
I wondered this as well, however, I think it's worthwhile to make the effort to keep the keys separate. The same argument applies to standard addresses: there's no reason any of the altcoins changed their version byte. Also, why not use the same version bytes for bitcoin test and main networks? |
|
|
|
This didn't get a whole lot of traction over in the Bitcoin forums, so I wanted to add support for my favorite coin! If this can be of use to anyone, let me know! Below is a copy-paste of what's in the other post: --- I want to announce http://bip32.org, a JavaScript implementation of BIP32. This project is based on my Multisignature P2SH project. What is BIP32?BIP0032 is a Bitcoin Improvement Proposal that describes a method to determinsiticly generate Bitcoin (and now DOGECOIN!) addresses and private keys. It also describes some really cool features such as public key derivation which allows you to generate new addresses without needing a private key. Why should I care?If you're like me, then you just care because this stuff is cool. If you're not quite like me, then you're probably only interested in this if you like and/or use Brain Wallets. This implementation allows you to produce Extended Private Keys based only on a single passphrase, which is in turn used to produce multiple Bitcoin addresses. You have the advantage of deriving new addresses without ever needing to type in your passphrase. How do I use it?Simple. Change the Network type to "Dogecoin Mainnet" in the upper-righthand corner. Then type in a passphrase into the "Passphrase" box and tweak the value in "Keypair index". The generated keys are shown at the bottom of the page, along with a Dogecoin address you can send coins to. In order to spend, copy the "Derived private key", change the button at the top of the page to "BIP32 Key" and paste in the key you just copied. Now copy the "Key" in the Key Info section. This is the Dogecoin private key, and it can be used to spend by using the transaction generator at http://brainwallet.org/More advanced users can use the site to do the following things: - Inspect extended key information: Simply paste in the key, and the Key Info fields are shown
- Use any key derivation path you want: Switch the "Derivation Path" to "Custom" and enter your key path. The key must being with an "m". Variables "i" and "k" can show up in the path (i cannot be last), and you can only use private key derivation (using the apostrophe symbol) if the extended key you're deriving from is a private key.
- The public key/private key derivation method only describes whether the final Keypair Index is generated using Public Key or Private Key derivation. If this doesn't make sense to you, ignore it and leave it set to "Public Key"
Thanks. Feedback appreciated! Donations are welcome: DCcF9r3UqSzjQWAjDnsrw9WJvddhuuPXFM
To the devs out there: Dogecoin doesn't have any official "version bytes" for extended private keys, so I had to come up with some. If anyone cares to draft a BIP0032 proposal for Dogecoin, here are the constants I used: var DOGECOIN_MAINNET_PUBLIC = 0x02facafd;
var DOGECOIN_MAINNET_PRIVATE = 0x02fac398;
var DOGECOIN_TESTNET_PUBLIC = 0x0432a9a8;
var DOGECOIN_TESTNET_PRIVATE = 0x0432a243;
|
|
|
|
Can you explain this more? I don't think I fully grasp the security implications of public vs. private key derivation. As far as I can tell, even when deriving via public key, you still use the chain_code from the parent private extended key, which should make derivation by 3rd parties hard.
Nevermind - I've figured it out. Chain codes aren't private, so even if someone has M (the public key of m), they cannot derive m/i'. This is important: it means that even with knowledge of the master public key, you cannot see any privately derived keys, public or private. |
|
|
|
I don't know how to interpret M/i'.
I'd say its trying to mean the public key of m/i'. OK, this makes sense. The big/little M at the beginning describes whether the goal is to obtain/use/share the public or private extended keys in the result? One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.
It looks like its assuming that you are, by default, protecting the master private key by always making the first generation of children through private derivation. Can you explain this more? I don't think I fully grasp the security implications of public vs. private key derivation. As far as I can tell, even when deriving via public key, you still use the chain_code from the parent private extended key, which should make derivation by 3rd parties hard. |
|
|
|
I'm saddened that nobody has responded yet. I just put up http://bip32.org/ and I, too, had this exact concern while implementing it. I don't know how to interpret M/i'. In fact, it seems to me that you don't need private key derivation at all, just the ability to derive new private keys (from public key derivation) seems sufficient. |
|
|
|
I want to announce http://bip32.org, a JavaScript implementation of BIP32. This project is based on my Multisignature P2SH project. What is BIP32?BIP0032 is a Bitcoin Improvement Proposal that describes a method to determinsiticly generate Bitcoin addresses and private keys. It also describes some really cool features such as public key derivation which allows you to generate new addresses without needing a private key. Why should I care?If you're like me, then you just care because this Bitcoin stuff is cool. If you're not quite like me, then you're probably only interested in this if you like and/or use Brain Wallets. This implementation allows you to produce Extended Private Keys based only on a single passphrase, which is in turn used to produce multiple Bitcoin addresses. You have the advantage of deriving new addresses without ever needing to type in your passphrase. How do I use it?Simple. Type in a passphrase into the "Passphrase" box and tweak the value in "Account index". If you select another derivation path, "Keypair index" is available to change as well. The generated keys are shown at the bottom of the page, along with a Bitcoin address you can send coins to. In order to spend, copy the "Derived private key", change the button at the top of the page to "BIP32 Key" and paste in the key you just copied to the BIP32 extended key field. Now copy the "Key" in the Key Info section. This is the Bitcoin private key, and it can be used to spend by using the transaction generator at http://brainwallet.org/More advanced users can use the site to do the following things: - Inspect extended key information: Simply paste in the key, and the Key Info fields are shown
- Use any key derivation path you want: Switch the "Derivation Path" to "Custom" and enter your key path. The key must being with an "m". Variables "i" and "k" can show up in the path (k cannot be last), and you can only use private key derivation (using the apostrophe symbol) if the extended key you're deriving from is a private key.
- The public key/private key derivation method only describes whether the final Keypair Index is generated using Public Key or Private Key derivation. If this doesn't make sense to you, ignore it and leave it set to "Public Key"
Thanks. Feedback appreciated! Donations are welcome: 1NXvAo6tDoSxAqsrcNQ5PPJJM87gR4dHr7 |
|
|
|
Probably an Arduino based board, I don't think Pi's hardware is open (yet?) and trying to source that in bulk would only be a pain in the ass instead of actually saving money. Will check out some other microcontrollers, should be possible to find one that doesn't struggle with signing transactions and is "open". Something like this. Yes, please. I'd be one of your first customers. I am also happy to contribute code and testing, too. I've an arduino already so if you get a code repo setup I can help test. I've got an NFC board that I'd be happy to add support for too:) |
|
|
|
A public derivation of the masterkey for generating addresses is much better than P2SH enforced.
I respectfully disagree. If the server you use has the only copy necessary to spend your money then you are in an entirely different realm of banking. My solution proposes that you are in full control of your money and the "bank" is only there to provide some convenience.  !!! Public derivation D'oh. You're right! You're doing Bip32 public key derivation using a single key. For what it's worth, I'm the author of the javascript bip32 implementation at https://github.com/sarchar/brainwallet.github.com/blob/bip32gen/js/bip32.jsThe point of multisignature (whether it's p2sh or not) was to provide some backup in case of lost keys. |
|
|
|
A public derivation of the masterkey for generating addresses is much better than P2SH enforced.
I respectfully disagree. If the server you use has the only copy necessary to spend your money then you are in an entirely different realm of banking. My solution proposes that you are in full control of your money and the "bank" is only there to provide some convenience. |
|
|
|
this just defeats the entire purpose of bitcoin. u might as well walk down to your bank and deposit cash
You obviously don't understand the proposal. |
|
|
|
If a server is compromised the attacker can trick users into sending money to him.
In the case of a properly implemented nym->address system, a MITM attack couldn't spoof an address because he can't forge a signature. This would work especially well if a nym's pubkeys were registered in a system like Namecoin. |
|
|
|
Huh? TCP/IP is just a transport layer for data. The "second class" network is no different than Bitcoin's network except in the data it exchanges. The whole point of joining a network of peers is to facilitate CoinJoin, mixing, and other potential improvements in the future.
Well, you have to be much more precise in what you are talking about. Bitcoin works, because there is the proof of work and blockchain. This scheme removes those features, which makes little sense. One server compromise is enough for an attacker to compromise the network. Anyway. The BBP network doesn't need a blockchain and proof of work systems because there are no BBP-specific transactions. All transactions are legitimate Bitcoin transactions. A server compromise by itself is of generally no consequence because the server isn't authoritative over anything: it requires your permission to do anything. |
|
|
|
based entirely on XMPP
XMPP is a pretty cool idea. It definitely makes sense to not have to reimplement a messaging network, as these things already exist. I didn't really explicitly mention this, but building upon other open source software is the right thing to do. sx and the unSYSTEM project are making great strides doing similar things (though not really focused on the ease of use functionality). |
|
|
|
I doubt anyone's really interested, but I'll throw this out there. A while back I managed to get Bitcoin-Qt building using CMake and VS2010: https://github.com/sarchar/bitcoin/tree/cmake-buildOf course, there's no documenting how to set up all the environment vars and such, but it shouldn't be too difficult to figure out. |
|
|
|
If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).
I considered this, but there's the extra advantage that nobody knows for sure if a single entity in the loop is indeed a single entity. Consider a figure 8, where node C is at the apex, and when he receives the transaction, it's passed around a similar set of other nodes and returning back to C, he forwards it on in the other loop. You'd have to control a large number of nodes in such a network to be able to produce any real association. Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).
Do you have any more information on how a reencryption mix works w.r.t. CoinJoin? I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).
True - it's especially problematic as N goes larger. Worst case, you have to assume everyone in the group is against you. Limit yourself to a low number of rounds and try other peers if the # of rounds is exceeded. You could theoretically build a list of trusted peers where previous successful CJs have been executed, too. All this is just workaround for a fundamental problem, though. |
|
|
|
Very interesting concepts. However, this is really moving far away from Bitcoin protocol, which is based on P2P nodes. If you have nodes and servers like electrum, you introduce the problem of server trust. And to solve that you need something else than what is traditionally thought of as a server. The whole beauty of the system lies in the fact that trust is not needed, or rather is forced by the protocol. Security/trust are not just features, they are the fundamental primitive of the network. Bitcoin is based on the fact that one doesn't really have to trust any other node. Even if I own a server and control that server I have introduced several new problems. Perhaps there's some misunderstanding here. This idea for a bank is absolute trustless: if you are curious, inspect the code. It's an absolute requirement that all code be open so that you *can* trust your own server. You are talking about a BBP network. How are these different from cloud wallets? Why introduce a second class network? I think that makes no sense. Bitcoin protocol runs on TCP/IP which everyone has access to.
Huh? TCP/IP is just a transport layer for data. The "second class" network is no different than Bitcoin's network except in the data it exchanges. The whole point of joining a network of peers is to facilitate CoinJoin, mixing, and other potential improvements in the future. b) mining centralization/ASIC/botnets are a major problem.
Pretty sure this is off-topic.. |
|
|
|
|
Would this strategy work?
Take N>3 coin joiners wishing to mix their coins and give them an order: A to B to C to D to E and back to A, forming a circle.
A is responsible for creating the first transaction. We proceed in rounds, each person receives the transaction from the person before them and forwards it to the next guy, where E returns it to A to form a circle.
Each person, upon receiving the transaction does the following:
If the received transaction is completely signed, then either forward the transaction onto the next guy or broadcast it to the bitcoin network. Forward randomly so the next in line can't figure out who signed last.
Otherwise, randomly add unspent inputs (from the blockchain utxo set) to the transaction and then add some random outputs. The inputs and outputs don't need to be owned by the person adding them, but eventually you need to include your final inputs and outputs. Next, select a few inputs added in a previous round and remove them (in the first round there will be nothing to remove). Do the same for outputs. Don't remove inputs or outputs that others added because they will assume you're trying to cheat and leave. In a later round, say 2 or 3, optionally sign one of your real inputs. If a successive person changes the tx again, you'll have to resign in another, later round.
Continue rounds until all fake inputs and outputs have been removed and the remaining inputs have been signed.
The obvious downsides include having to resign multiple times, the potential for lots of rounds, and not scaling well to large values of N. Any other thoughts?
|
|
|
|
|
