 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Not quite sure how you worked this out. If 6% of coins were stolen from Gox, they're still very much in circulation. If Gox lost the keys, then you'd be correct.
It's not clear at this point whether the coins were stolen or Gox just lost the keys. If the keys are lost, then I would expect the price of bitcoin to rise. |
|
|
|
|
I bought an Amazon gift card from shiunsai. No problems.
|
|
|
|
So actually this won't work. An attacker can just add an input with a public key that is the multiplicative inverse of your public key. So if A = y and B = (1/y) the signature is verified as: g^m = (A*B)^r * r^s g^m = (y/y)^r * r^s g^m = 1^r * r^s g^m = r^s which is trivially forged. Doing a little more research I believe it is possible to use elliptic-curve arithmetic to add the private keys together to create a "master" private key for signing and this master private key can be verified by adding the public keys together to form a master public key.
And in elliptic curve arithmetic, you add the inverse, yielding the identity element. An attacker can then add their own public key to avoid the point at infinity. The combined "master" public key is insecure. So this doesn't work. |
|
|
|
|
So the question is... Is it possible to have a single signature that requires two public keys to create it?
ECDSA is based on ElGamal signatures. There are several variants, but let's just consider the basic signature scheme:
Given:
Generator g
Private key x
Public key y=g^x
Message m
A signature (r,s) on message m is valid if g^m = y^r * r^s
As gmaxwell points out, it is possible to compute y (public key) from the signature and message as y=(g^m/r^s)^(1/r). To validate the signature, you would of course have to check that this public key is the one you expected.
It seems possible to make a signature from two public keys A and B, such that g^m = (A*B)^r * r^s
Obviously this would be incompatible with the current bitcoin protocol, but it does seem possible in theory. I'm not entirely sure of the security implications of such signatures. I'd have to think about it some more.
|
|
|
|
|
I placed an order with esadee and got my stuff in 2 days. Great!
|
|
|
|
|
Is there a mining pool that will generally take free transactions? Even if such transactions are given low priority, it seems it would be useful to prevent these situations.
|
|
|
|
|
I tried this... During checkout it gives me a total of $0.00, then says:
Your order cannot be completed at this time as there is no payment methods available for it.
|
|
|
|
|
Successful trade with live627
|
|
|
|
|
With Amazon, you can sometimes tell the origin of the code. The scratch-off cards they sell in the stores are 15 characters and usually start with the letters AQ. The ones bought online with a credit card are 14 characters. However, the ones from the coinstar machines also have this 14-character format. If someone claims to have a code from coinstar, ask for the receipt.
|
|
|
|
Acer Aspire One AOD270-26Dkk 10.1" LED Netbook - Intel Atom N2600 1.60 GHz- im gonna get a cheap laptop for armory, this is the cheapest one, netbook will work too right? i dont no the diff between laptops n netbooks.
That doesn't have enough RAM to run Armory. Bitcoin-qt will work, although it'll be a bit slow. |
|
|
|
bitcoind uses (256-bit) ecdsa keys, so i would expect the bleeding of signing key via prime factors, which is specific to rsa, to be irrelevant. i could, of course, be wrong  Blind signatures, as described by David Chaum, are based on RSA. Anyway, the basic idea is that someone buys a blind signature from the mixer, then some time later uses that signature to get money back, but the mixer can't connect the two. The blind signature is not used to directly sign bitcoin transactions. |
|
|
|
|
There's a limit to RSA blind signatures - if someone signs a bunch of small prime numbers, then multiplying these together yeilds a valid signature on the product. Collect enough factors and you can sign anything. So, if too many blind signatures are made, it effectively leaks the signing key. Thus, the signing key needs to be changed each time, and you can only mix a limited number per batch.
|
|
|
|
That might work, though I'm worried that with such rules blocks would become gradually larger and over time the number of full nodes would shrink dramatically as weaker computers get separated from the network. For example, dial-up nodes would get separated right away. No one would care that dial-up users can no longer run full nodes, and they would themselves mostly just say, "Oh well, I guess my setup is too slow to run a full node. Time to switch to a lightweight node." This is probably reasonable for dial-up, but I think that it might over time spread to most people. As blocks become larger, people on average PCs would have to switch to lightweight nodes, then even hobbyists, and then even small businesses. We're a long way from that. Even something at the scale of Paypal (~85 tps) could run on an average desktop PC with 1mb/sec internet connection. The post from Gavin that I was referring to is here: https://bitcointalk.org/index.php?topic=140233.msg1503099#msg1503099 |
|
|
|
That is a lot. That would be more than 1.5 transactions per day for each of the 15,000,000 users. That's higher than the per capita volume of credit/debit card purchases in the United States. I think I use bitcoin more than most people, and my average number of transactions is still under 1 per day. Maybe that is peak volume and not average. |
|
|
|
|
I like Gavin's proposal. (I mean his actual proposal, not the "half-baked thought" quoted above.)
No hard limit, but nodes ignore or refuse to relay blocks that take too long to verify. This discourages blocks that are too large, and "spam" blocks containing lots of transactions not seen on the network before.
This might create an incentive to mine empty blocks. To discourage this, in the case of competing blocks, nodes should favor the block that contains transactions they recognize, and ignore (or delay relaying) the empty block.
|
|
|
|
Thankfully Casascius is that guy. I have seen a half dozen threads like this and they all ended up being typos. It is pretty easy to do since the writing is very small. A good magnifying glass helps. It would be nice if clients and websites stated "this is an invalid private key" as opposed to incorrectly stating the "balance/value is zero". There is a reason for the SHA256 check (ignored by AFAIK every website and client).
bitaddress.org does check. |
|
|
|
So... I start from "more transactions == more success"
I strongly feel that we shouldn't aim for Bitcoin topping out as a "high power money" system that can process only 7 transactions per second.
If bitcoin operated at the scale of PayPal, ~87 transactions per second, that would require roughly 20MB blocks. That's large, but not unmanageable. People paid PayPal US$ 5.6 billion in fees last year. There's no way the bitcoin network is going to cost that much. |
|
|
|
|
