Nitpick: In the case of RSA, a general number field sieve will do it. Although, it will take thousands of years for large keys.
Nitpick 1: that's a search, not a calculation. Nitpick 2: searching for the keys we use would take billions of years. |
|
|
|
That can easily be solved with a proof of burn or some soft of proof of stake.
Ha! |
|
|
|
How would they look up an attacker's key if you have it in a decentralized environment? If they use your email they would get yours, if your private key is compromised then an attacker could read it, but can't sign on behalf of the store.
How do they know the email address they are looking up is mine? So lets explore this, I give them a fake email that is in the key server, I get a PGP message, that I can't decrypt and if I can decrypt it I can changed anything cause it is signed. So what is the attack? No. You give Mallory your email address, she gives the server her address. The server encrypts the message with Mallory's key, she decrypts it, changes is, signs it with her key, then encrypts it with your key. You then place the order with Mallory, and send the payment to her bitcoin address. The server doesn't know how to distinguish your key from Mallory's key, and you don't know how to distinguish Mallory's key from the server's key, because that is the problem we are trying to solve. |
|
|
|
How would they look up an attacker's key if you have it in a decentralized environment? If they use your email they would get yours, if your private key is compromised then an attacker could read it, but can't sign on behalf of the store.
How do they know the email address they are looking up is mine? |
|
|
|
Say I want to buy some hardware from bitcoinstore.com. I go to their website, prepare my order and check out. They send a payment request, signed by some PGP key. Now what?
So bitcoinstore's servers will look up a pgp key for you, which I am guessing since you supplied them an email would be easy in the key server. Ok, so the merchant's store software looks up the attacker's key and encrypts the store's key so that only the attacker has access to it. The attacker then decrypts it, and re-encrypts it using your actual key, then signs it using their key, which you think is the store's key. Got it.  Just kidding. What will really happen is that the attacker will look up your pubkey, encrypt their key with your key. Since you have no way to authenticate the store's key, you'll have no idea that it was swapped around. They take that public key and use it to encrypt the address, which they also signed. Your client takes this decrypts it and checks the signature, if it is good it displays a green box just like the current payment protocol.
Lets say you don't want your email hashed in the DHT. Then the bitcoind would have it's own public key which then can be sent to bitcoin store, and this would only allow a one way verification by the user and not by the site. These would be less trustworthy than the above but would still work.
Keep in mind that the problem we are trying to solve is how I authenticate a key that I've never seen before. You can't solve that problem with another unauthenticated key. |
|
|
|
|
The real problem is that WoT is a lousy model for widespread use.
Say I want to buy some hardware from bitcoinstore.com. I go to their website, prepare my order and check out. They send a payment request, signed by some PGP key. Now what?
The options boil down to:
1) I fly to wherever the hell they are and compare the key in person.
2) I get lucky and have a direct path of trustworthy and well known trust delegates between me and their cert.
3) The ad hoc certificate chain is of dubious value. This is amazingly similar to the SSL CA system, but the entity acting as the CA isn't necessarily obvious, may not even know that they are doing it, and are in no way accountable to anyone.
4) The market recreates the CA system, for real.
5) I proceed with absolutely no security.
While the CA system has huge serious problems, the alternative is much, much worse in 99.9% of actual use cases, and a vastly better 0.1% of the time.
|
|
|
|
|
If you write good patches to add PGP/WoT authentication, I suspect they would be merged in a heartbeat.
As far as I can tell, no one is opposed to such a thing, they just don't think it has a very good payoff to effort ratio compared to authentication using the global SSL PKI. Because of this, it is not a good candidate for being built first. If you disagree, feel free to write some code, or convince/bribe someone to do so.
|
|
|
|
|
Unless something has changed in very recent versions of openssl, your options are limited to creating new keypairs, or importing a privkey in certificate form. And I'm actually not positive about the second one.
One way or another, you'll need to install something else.
|
|
|
|
Is there some other thread where this inane prattling about altcoins can go to? This thread is for inane prattling about gold and bitcoin. |
|
|
|
|
When doing SIGHASH_ALL, each input script other than the current one is set to 0x00. With SIGHASH_ANYONECANPAY, the other inputs are removed completely.
Are you creating the transaction with both inputs first, then calculating both signatures? Or adding the ANYONECANPAY second input later, after the ALL has been signed?
|
|
|
|
|
Looks like you are doing things right so far. Personally, I use a different tube and a chunk of thoriated welding rod, but that's because it is what I had sitting around. After your A/B filter, you need to feed it through von Neumann's filter (1,0 -> 1; 0,1 -> 0; 0,0 ->discard; 1,1 -> discard).
Next up for your project is monitoring. Bias creeps in. You need to keep careful track or you'll end up with garbage.
Finally, you need security. Ideal would be an old line printer hooked up to a totally offline box. Every time you get enough bits, encrypt the privkey and print that along with the pubkey (or address).
|
|
|
|
It isn't signed. {
"hex" : "01000000039af55b1c4e611e44362bd3d514493b0a9fe752dcf0a9966bbc9991a7a565209900000000fc00473044022028dc5624d399ff224857df5c6007b481d7928bfcf8297c7ce22f42d2bc52bd1b022058d9d0ed3c81b144c90db885b85221eb001010d1d7ec9a8a24adad14938d42d701473044022032ce90e3c19d100b93d72e3c373e8e755ebed85555473c0ac2675bdd95f43e9802205c1ebaea573f2fb7b258cba1ee5c88350676b0c5cbec1b62eabee6c75c39cf6d014c69522102f637d58ccf8cca451a7c439ddb24c12fc08382dff1870c1d2d0a46676c24c995210363bdf25f91baea5d88579e6416cfe13037a764681b8b5533945a6094c3b01a442102227ce96d0e36c546514dd50aca46ed80702cdc16f61636d52bc6dbc50f1fdfab53aeffffffffc253dcd66d86a203f06a173527090d29d51101b509c906ec8e7617996c4716f700000000fc00473044022012b42707dd913618a6433be6541bdb09e02eea861d99601e9a6c2a2392e5f65f022024c22cb55c9d5e3994e8365b2c4a44b20ceade3913d161991fc44195425cfc470147304402203a7629b92d56d2eab2c170a8f9876b52b6012e410860972956be4e49da1461150220234f3959f60593560f2439f2d06371277030f50b7fe27aa3392dc84d0fe49ee2014c69522102f637d58ccf8cca451a7c439ddb24c12fc08382dff1870c1d2d0a46676c24c995210363bdf25f91baea5d88579e6416cfe13037a764681b8b5533945a6094c3b01a442102227ce96d0e36c546514dd50aca46ed80702cdc16f61636d52bc6dbc50f1fdfab53aeffffffff45140099501d392bf59a4f5cc261bdba6970066f53f1ff3018dc7e44ef41e48301000000fdfe0000483045022100ec6bbec08560f17d50c103846304559a2dd6585172d8be7db4bbedd9555cbb7002200b4b0fb7d76bb8e707f0e0a25e4209123e0eb485ad4920da9fe591058555daed01483045022100c058edd6375586eb215ae3b5b2f4d762e8463e7ed82b4834dc29f54b3107a5db022021d5e74d9032a71207f6a7aa10d3f4db216ece2ba55f235a2125f41dceafa0d2014c69522102f637d58ccf8cca451a7c439ddb24c12fc08382dff1870c1d2d0a46676c24c995210363bdf25f91baea5d88579e6416cfe13037a764681b8b5533945a6094c3b01a442102227ce96d0e36c546514dd50aca46ed80702cdc16f61636d52bc6dbc50f1fdfab53aeffffffff01a0860100000000001976a914600a47a134666a2e8e87858f99fb2cc7dd57e84488ac00000000",
"complete" : false
}
|
|
|
|
|
Awesome. Three contentless posts in a row from spammers padding their signature advertising numbers.
|
|
|
|
|
I've never tried this with namecoin. It probably should work the same way, but I've never looked at the source or anything else.
Just to be clear, is the key for the transaction being redeemed in your wallet?
|
|
|
|
|
If only there was some way to have a third party mediate certain transactions... This third party could manage the risks inherent in all transactions, and could smooth over the mismatch in risk preferences between fast transactions and secure transactions.
This third party could operate a computer network with terminals at each merchant's point of sale, and at each consumer's risk guarantor. Payers could identify themselves with plastic cards bearing magnetic stripes and/or tamper resistant CPUs...
|
|
|
|
|
FYI, this thread is hilarious when you ignore everyone with paid advertising in their sigs.
|
|
|
|
|
Under the current rules, no.
There have been, however, many silly suggestions in this forum that would (intentionally or otherwise) give such an incentive.
|
|
|
|
|
Key reuse considered harmful.
|
|
|
|
Resource Based Economy is also a form of planned economy, but there are no "Central Soviet"!
There was a time when Animal Farm was required reading in a lot of places... |
|
|
|
Most of you people arguing about this frankly won't be alive to see any of this happen (it won't even be in your grandchildrens' lifetimes) so I'm not sure what all the fuss is about.
Don't forget that technology advances by an exponential curve, so it can happen much sooner than you think! I'm almost positive that the logistic curve has already been linked in this thread. |
|
|
|
|
Show Posts
