Could you then present this address as a QR code so a live phone or other device could send coins to it?
Already on the to-do list, I'm currently poking around with the zxing QR code lib and should have something cobbled together soonish! How can you copy the generated priv key or address ? At the moment, with your eyes and your fingers, anything else would break the "no communications with the outside world" rule of paper wallets, but I am working on making a QR code as we speak, might not get to finish it today but soon. Damnit. And if you make it a textbox ? We could easily copy the contents by long pressing it. EDIT: 1 bitcoin going your way right now if you do it  This seems like a decent compromise until I can get QR codes working, give me a few and I'll see what I can do for ya. |
|
|
|
Could you then present this address as a QR code so a live phone or other device could send coins to it?
Already on the to-do list, I'm currently poking around with the zxing QR code lib and should have something cobbled together soonish! How can you copy the generated priv key or address ? At the moment, with your eyes and your fingers, anything else would break the "no communications with the outside world" rule of paper wallets, but I am working on making a QR code as we speak, might not get to finish it today but soon. |
|
|
|
Could you then present this address as a QR code so a live phone or other device could send coins to it?
Already on the to-do list, I'm currently poking around with the zxing QR code lib and should have something cobbled together soonish! |
|
|
|
The first party sends that public key to the second party. The second party also creates a private key, but instead of multiplying it by G, he multiplies it by the public key received from the first party. The result is a new composite public key for which neither side knows the private key.
...
I believe (someone correct me if I'm wrong), the way to get the private key that corresponds to the composite public key, is to take the two private keys (which are integers), multiply them together, and mod them by some very large constant. The result (another integer) is the composite private key. This actually doesn't work very well. But a very slight change makes it work perfectly: 1) The first party generates a private key (S1) and a corresponding public key (GxS1). It passes (GxS1) to the second party. It stores S1. 2) The second party generates a private key (S2) and a corresponding public key (GxS2). It stores S2. 3) The public key you use is the sum of the two public keys (GxS1 + GxS2). For OpenSSL, EC_POINT_add does this. 4) When you need the private key, you use (S1+S2) modulo the order. This works because Gx(S1+S2) = GxS1 + GxS2. Neither party alone can get the needed private key. Update: Actually, now that I think about it, it might work. But the way I mentioned above is simpler. Even easier then, SpongyCastle (BouncyCastle for Android, because Android lacks a native ECC implementation) has ECPoint.add so all I'd need to do is add S1+S2 % order (is the order typically notated N for ECC or am I thinking of something else?)... I think... God, ECC math makes me feel like I missed an important day in high school algebra... |
|
|
|
I think I see what you're getting at, and your assumption that I have a fair grasp on ECC is definitely correct, I'm just not entirely sure how to actually implement that functionality in real code. Practically everything ECC-related I've dealt with thus far has been happily encapsulated in simple little libraries - I've never actually had to do the scalar multiplication myself. Perhaps some day when I have the time to do serious digging, I can implement this, but I'll be honest enough to say that I don't have the skillset to start on it just yet. You don't actually do the ECC multiplication yourself - but you'll notice you call on the library to do it. Look at whatever line of code takes a private key and turns it to a public key. Chances are you're calling a "multiply" function out of a library, and you're passing it a constant called G (which came from the same library). All you do is replace G with something else. That "something else" is a public key. G is the same "type" of data as a public key... in fact, the constant G is nothing more than the public key you would get if you used the number "1" (0x00000000000000000000000000000001) as a private key. I am not sure what you mean by never having done "scalar multiplication" - this is normal multiplication - see, 5*10=50...that's scalar multiplication. To combine two private keys you just do normal multiplication and division (using a bignum of course, to account for the fact that these numbers will be too big to fit in an int or float or whatever). Makes sense! Conveniently, I see this in BitcoinJ's implementation of ECKey.java static {
// All clients must agree on the curve to use by agreement. Bitcoin uses secp256k1.
X9ECParameters params = SECNamedCurves.getByName("secp256k1");
ecParams = new ECDomainParameters(params.getCurve(), params.getG(), params.getN(), params.getH());
secureRandom = new SecureRandom();
}
So now all I have to do is copypasta this over to my codebase, import all the things, then play trial and error for an hour to get it to accept pubkey #1 in place of params.getG() if I'm understanding you correctly. Oh and implement the multiplication and modulo you described for the privkeys, unless you got that math wrong, which should be pretty trivially testable. |
|
|
|
Are you talking about multi-key transactions?
Nope, just exploiting properties of ECC math to create a single key that both sides can agree on, but neither side knows the public key to, unless it has both private keys. Basically how it works: you are probably aware that to create a public key from a private key, you multiply a number (the private key) by a constant G (which is an ECC point). This step remains unchanged for the first party. The first party sends that public key to the second party. The second party also creates a private key, but instead of multiplying it by G, he multiplies it by the public key received from the first party. The result is a new composite public key for which neither side knows the private key. I believe (someone correct me if I'm wrong), the way to get the private key that corresponds to the composite public key, is to take the two private keys (which are integers), multiply them together, and mod them by some very large constant. The result (another integer) is the composite private key. I think I see what you're getting at, and your assumption that I have a fair grasp on ECC is definitely correct, I'm just not entirely sure how to actually implement that functionality in real code. Practically everything ECC-related I've dealt with thus far has been happily encapsulated in simple little libraries - I've never actually had to do the scalar multiplication myself. Perhaps some day when I have the time to do serious digging, I can implement this, but I'll be honest enough to say that I don't have the skillset to start on it just yet. |
|
|
|
Very awesome...
Where to take this next: a two-factor savings wallet generator for average folks - you're already pretty much there!
How that would work:
1. User chooses passphrase in your app. It generates a keypair just like your screenshot shows. You add a quick function to send the pubkey to an e-mail address so they can get it on their computer.
2. They do the same thing on their computer, possibly with a web-based application. They choose a second passphrase and provide the pubkey created in step 1. The web-based application produces a Bitcoin address, which is associated with two passphrases.
The user can have a high level of confidence that the Bitcoin address they just created is secure from hackers and malware, and can be recovered simply by providing both passphrases. A successful attack would require interception of the passphrase/privkey from both devices, which is pretty damn difficult!
Are you talking about multi-key or multi-signature transactions? I don't know enough about that particular functionality to implement it, even on the PC side, but I can confirm that adding sharing capability to some or all of the information on that screen is on my to-do list. I just wanted to put this in the public's hand ASAP, it'll be refined significantly in the future. |
|
|
|
|
Reserved for future updates.
|
|
|
|
So I've had this old Android phone laying around for ages and I kept thinking, what could I do with this? I decided one day that a simple app combined with airplane mode would make it an ideal offline brain-wallet, but no such utility seemed to exist. I finally got tired of waiting for someone else to get around to it and built it myself. I introduce to you, the Android Bitcoin Address Tool:   It's pretty basic, but it does exactly what it was built for - it produces a Bitcoin address and associated private key from the an SHA256 hash of a passphrase. I also went to great lengths to ensure that the operations are bit-for-bit compatible with Casascius' already existing Bitcoin Address Utility as you can see from screenshot #2:  Same passphrase, same results. It should be noted that this is very young code. I've done my best to trap for errors but it should be considered beta and just as with Casascius' utility, no warranty is implied. I also haven't implemented any code to validate Casascius-style SHACodes (Mini Privkey Format), so if you don't type your code correctly, that's on you.  Want to support the project? Donations of BTC are accepted at the address in my signature, or there's a 99 cent donation version available in the marketplace. Want to peek at the source and make sure I'm not some nasty trojan-planting H4XX0R waiting to steal your wallet? Go grab my code from the GitHub repo and poke through it yourself (or wait for / bribe someone else to do it). BitcoinJ et al carry their own licenses of course, but my own code (the stuff in the .java files as opposed to .jar) carries a "do whatever you want with it I really don't care" license. Questions? Comments? Feature requests? Shoot me a reply or PM and I'll do what I can - or in the case of feature requests, feel free to fork it yourself if you know a little Java. |
|
|
|
|
Never mind, I got M2E working in Eclipse and that seems to have taken care of things. Thanks for the attempt though, vuce!
|
|
|
|
I can't for the life of me get my BitcoinJ Android project to build. There's not much to it yet, I'm literally just populating a byte[] array and attempting to use Base58.encode on it. It will build and execute but when clicking the button that launches Base58.encode() I get the following: 06-07 18:20:13.742: D/AndroidRuntime(231): Shutting down VM
06-07 18:20:13.742: W/dalvikvm(231): threadid=3: thread exiting with uncaught exception (group=0x4001b188)
06-07 18:20:13.750: E/AndroidRuntime(231): Uncaught handler: thread main exiting due to uncaught exception
06-07 18:20:13.760: E/AndroidRuntime(231): java.lang.NoClassDefFoundError: com.google.bitcoin.core.Base58
06-07 18:20:13.760: E/AndroidRuntime(231): at com.CIMS.BitcoinAddress.BitcoinAddressUtilityActivity$1.onClick(BitcoinAddressUtilityActivity.java:41)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.View.performClick(View.java:2364)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.View.onTouchEvent(View.java:4179)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.widget.TextView.onTouchEvent(TextView.java:6541)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.View.dispatchTouchEvent(View.java:3709)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
06-07 18:20:13.760: E/AndroidRuntime(231): at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchTouchEvent(PhoneWindow.java:1659)
06-07 18:20:13.760: E/AndroidRuntime(231): at com.android.internal.policy.impl.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1107)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.app.Activity.dispatchTouchEvent(Activity.java:2061)
06-07 18:20:13.760: E/AndroidRuntime(231): at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchTouchEvent(PhoneWindow.java:1643)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.view.ViewRoot.handleMessage(ViewRoot.java:1691)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.os.Handler.dispatchMessage(Handler.java:99)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.os.Looper.loop(Looper.java:123)
06-07 18:20:13.760: E/AndroidRuntime(231): at android.app.ActivityThread.main(ActivityThread.java:4363)
06-07 18:20:13.760: E/AndroidRuntime(231): at java.lang.reflect.Method.invokeNative(Native Method)
06-07 18:20:13.760: E/AndroidRuntime(231): at java.lang.reflect.Method.invoke(Method.java:521)
06-07 18:20:13.760: E/AndroidRuntime(231): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
06-07 18:20:13.760: E/AndroidRuntime(231): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
06-07 18:20:13.760: E/AndroidRuntime(231): at dalvik.system.NativeStart.main(Native Method)
06-07 18:20:13.770: I/Process(67): Sending signal. PID: 231 SIG: 3
06-07 18:20:13.785: I/dalvikvm(231): threadid=7: reacting to signal 3
06-07 18:20:13.785: E/dalvikvm(231): Unable to open stack trace file '/data/anr/traces.txt': Permission denied
06-07 18:20:14.050: I/ARMAssembler(67): generated scanline__00000077:03515104_00000000_00000000 [ 33 ipp] (47 ins) at [0x47c838:0x47c8f4] in 380336 ns
06-07 18:20:14.070: I/ARMAssembler(67): generated scanline__00000177:03515104_00001001_00000000 [ 91 ipp] (114 ins) at [0x47c920:0x47cae8] in 471186 ns
I've tried following BitcoinJ's installation instructions, installed Maven etc but when I run "mvn install" it kindly informs me that it can't find a POM file and exits. I've never used Maven before so I've got no clue what that means or how to fix it. I've included junit-4.8.2.jar, slf4j-api-1.6.1.jar and slf4j-simple-1.6.1.jar along with bitcoinj-0.4-android.jar but feel like I have to be missing other dependencies. Has anyone seen this before and knows how to resolve it? |
|
|
|
Nice panel set, I love the portability aspect. Should be noted that it's only 13W though, which is certainly ample juice for charging a battery which can then recharge a laptop but it should be noted that peak energy consumption of a macbook is WAY more than 13W, so if you've got a laptop that sits in sleep mode with bursts of activity this is probably fine, but if you use it for work and heavy browsing 9+ hours a day (like I do) the screen alone eats up more juice than that  By Apple's own figures a 15" macbook uses 17.6 watts idle with the screen on. Assuming you get ~10 hours of sunlight per day, that panel array should provide 130 watt-hours of juice. Your jet ski battery is probably an 18-20 aH mode and so can hold 216-240 watt hours, so it won't be the weak link, unfortunately 130 watt-hours being consumed at a rate of 17.6 watts will last about 7 hours and 23 minutes, less if you actually do anything instead of letting it idle. We've already discussed the feasibility of mining with solar - even a BFL single, which is WAY more efficient than your average GPU rig could only run for about an hour and a half on a full day's worth of solar juice from this array. Even Spartan6-based FPGA miners which are almost twice as efficient would crap out pretty quickly - matter of fact to make that 130wH last 24 hours a day you'd need to pull no more than 5.4 watts, which brings your mining option down to the ZTEX USB-FPGA Module 1.15b which is capable of ~90mh/s. While purely solar mining would be cool as hell, the board costs $365, the solar array is another $165 and even a cheap jet ski battery is $50 for a total cost of $580 for a rig that performs less effectively than even a single Radeon 5830 - total cost $6.40/mh is not within MY acceptable tolerances... Don't take me wrong, I'm all for green, renewable and ESPECIALLY free and that's 130 watt-hours that you didn't have to pull from the grid, but at my local electricity rates, 130wH is worth about 1.5 cents meaning you'd have to pull that amount of juice from the sun every day for 8,862 days (nearly 25 years) just to break even  Where it really comes in handy is when I am camping and can charge my android which has a bitcoin app. As long as I can get a mobile signal I can still send bitcoins around. Now THAT is a very feasible use for solar power (and large batteries). The charger for my phone is 5V 1A (though for some inexplicable reason they list it as 1,000mA) and I can operate every single feature on the phone while it's on that charger and still have enough juice to trickle charge the battery, putting it firmly below the 5W of the FPGA I mentioned above and therefore completely feasible. Hmmm now I'm coming up with a dozen other projects I could run with 13 watts and a battery... Green PirateBox anyone? |
|
|
|
Nice panel set, I love the portability aspect. Should be noted that it's only 13W though, which is certainly ample juice for charging a battery which can then recharge a laptop but it should be noted that peak energy consumption of a macbook is WAY more than 13W, so if you've got a laptop that sits in sleep mode with bursts of activity this is probably fine, but if you use it for work and heavy browsing 9+ hours a day (like I do) the screen alone eats up more juice than that By Apple's own figures a 15" macbook uses 17.6 watts idle with the screen on. Assuming you get ~10 hours of sunlight per day, that panel array should provide 130 watt-hours of juice. Your jet ski battery is probably an 18-20 aH mode and so can hold 216-240 watt hours, so it won't be the weak link, unfortunately 130 watt-hours being consumed at a rate of 17.6 watts will last about 7 hours and 23 minutes, less if you actually do anything instead of letting it idle. We've already discussed the feasibility of mining with solar - even a BFL single, which is WAY more efficient than your average GPU rig could only run for about an hour and a half on a full day's worth of solar juice from this array. Even Spartan6-based FPGA miners which are almost twice as efficient would crap out pretty quickly - matter of fact to make that 130wH last 24 hours a day you'd need to pull no more than 5.4 watts, which brings your mining option down to the ZTEX USB-FPGA Module 1.15b which is capable of ~90mh/s. While purely solar mining would be cool as hell, the board costs $365, the solar array is another $165 and even a cheap jet ski battery is $50 for a total cost of $580 for a rig that performs less effectively than even a single Radeon 5830 - total cost $6.40/mh is not within MY acceptable tolerances... Don't take me wrong, I'm all for green, renewable and ESPECIALLY free and that's 130 watt-hours that you didn't have to pull from the grid, but at my local electricity rates, 130wH is worth about 1.5 cents meaning you'd have to pull that amount of juice from the sun every day for 8,862 days (nearly 25 years) just to break even |
|
|
|
That's a radio telescope, not a solar panel array. They're powering their OpenCL rigs with this:  That's a diesel generator |
|
|
|
|
In his defense, most of those conversations were about the feasibility (or lack thereof) of mining on solar/green power sources where this thread seems more interested in simply operating a general-purpose computer on solar, which is significantly easier.
Phinnaeus: nice looking solar laptop, though I can't imagine that suggesting folks should leave their entire (possibly powered on and running) laptop in full sunlight to charge (and overheat) is a good idea. A tethered solar panel seems much smarter, but perhaps there's an engineer somewhere on the forums who has better data than I do?
|
|
|
|
http://codinginmysleep.com/2012/06/57-of-users-admit-to-piracy/Found a BSA study (I know, lapdogs with erroneous data blah blah) and just had to do a writeup on it. Apparently world-wide 57% of PC users are, to one degree or another, pirates - and those are just the ones who would admit it on an anonymous survey. So my question, as has been applied to so many other realms, boils down to: Is it reasonable to criminalize something that more than half of us do? I get the feeling I know which side of the piracy argument most Bitcoiners will fall on, but I'm genuinely curious to see where certain peoples' chips fall...
|
|
|
|
Damn Matt, this is the BEST magazine I have ever read! LOVE it! Technology, cryptographic, finance, business, freedom... it has everything. Amazing work.
I am going to sign up for a subscription ASAP
+  +  FTFY  FTFY |
|
|
|
|
I'm extremely interested but I really need pics before I can talk the wife into it.
Also I need confirmation that this isn't a serial # / replacement scam.
|
|
|
|
I'd love to set this up at a small business I work with but they're a Microsoft shop and I'll be honest and say I get DNS as a concept but I know little about the implementation - how hard would it be to make this work with a MS DNS server?
Assuming you can get the php to work it should just be a matter of reformatting the output and importing it, you might need to turn it into some LDIF like format. Nobody sane uses a MS DNS server, certainly not to serve data to the Internet. It might be better to set this up on a Linux machine outside their network and query that. Fair enough, there are probably more/better general use instructions for bind anyway |
|
|
|
|
Show Posts
