Search content
Sort by
Showing 20 of 43 results by Qwedcxza1
I've probably given the impression that I know more about all of this than I really do and I think I might have made the wrong assumptions in some of my statements but I haven't got time to look into it all. I have a little knowledge which is a dangerous thing so I hope someone who is more of an expert will answer. 
I'm not a programmer so it's difficult to understand this without seeing a proper mathematical description of the encryption and decryption methods.
If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system.
There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve.
The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used.
Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there.
If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system.
There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve.
The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used.
Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there.
Let's say I want to encrypt 'hello' to your address
Quote
pubkey: your public key
privkey: your private key
privkey: your private key
I split my message in 32-char long chunks and put "0x00"s at the end of the last one to make it 32-char long too. That gives here only one chunk: 'hello---------------------------'. ('-' represents one 0x00)
Now each chunk is used as an X. Let's call the correponding point M (Two M's are possible but it doesn't matter as I never use Y)
Then I take a random N and calculate:
- G*N
- pubkey*N + M
Those points are the encrypted data to be sent to the recipient. As pubkey=privkey*G, M is easily calculated.
Note: Not all X values leads to a point on the EC. In such cases I just use offsets.
I'm not a programmer so it's difficult to understand this without seeing a proper mathematical description of the encryption and decryption methods.
If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system.
There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve.
The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used.
Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there.
If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system.
There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve.
The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used.
Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there.
Re: Bitmessage v0.2.0 - Now using Elliptic Curve Cryptography!
This is a major upgrade and includes these exciting features:
- Elliptic curve secp256k1 is used for Bitmessage's signing and asymmetric encryption.
What method do you use for asymmetric encryption?
ECIES?
Can you give more details.[/list]
ECDSA (elliptic curve digital signature algorithm) is a specifically designed signature scheme and, in some sense, signature schemes work in the opposite way to crypto systems.
If you use an asymmetric (public key) crypto system such as RSA then you can give your public key out so that people can encrypt messages that only you can decrypt with your private key.
It is possible to make a signature scheme from RSA but you turn things around and sign the message with the decryption rule, which you keep secret (this was the public key in the crypto system) and then make public the encryption rule (the private key in the crypto system) so that anybody can check your signature.
The ECDSA system is derived from EIGamal and works on different mathematics to RSA (discrete logarithm problem as opposed to factorisation difficulty) but the basic ideas of encryption and decryption rules and plaintext and cipher text are the same.
So really if you wanted to make a crypto system from ECDSA you would want to do the opposite and use the public key for decryption (and keep it secret) and the private key for encryption. However if you wanted to use this as an asymmetric (public key) system it wouldn't really work, as it stands, because the key which used to be private and we are now making public so that people can encrypt messages can be used to derive the other key (by multiplying the base point of the elliptic curve).
If you wanted to use it as a symmetric system and keep both keys private you would be better off using something such as AES. There are practical difficulties in using elliptic curve implementations of EIGamal type crypto systems which I won't bother going into but you can use systems such as ECIES (elliptic curve integrated encryption system) as public key crypto systems.
So I think the answer is no, not really, but there are lots of people who know lots more about this than me so I may be corrected.
If you use an asymmetric (public key) crypto system such as RSA then you can give your public key out so that people can encrypt messages that only you can decrypt with your private key.
It is possible to make a signature scheme from RSA but you turn things around and sign the message with the decryption rule, which you keep secret (this was the public key in the crypto system) and then make public the encryption rule (the private key in the crypto system) so that anybody can check your signature.
The ECDSA system is derived from EIGamal and works on different mathematics to RSA (discrete logarithm problem as opposed to factorisation difficulty) but the basic ideas of encryption and decryption rules and plaintext and cipher text are the same.
So really if you wanted to make a crypto system from ECDSA you would want to do the opposite and use the public key for decryption (and keep it secret) and the private key for encryption. However if you wanted to use this as an asymmetric (public key) system it wouldn't really work, as it stands, because the key which used to be private and we are now making public so that people can encrypt messages can be used to derive the other key (by multiplying the base point of the elliptic curve).
If you wanted to use it as a symmetric system and keep both keys private you would be better off using something such as AES. There are practical difficulties in using elliptic curve implementations of EIGamal type crypto systems which I won't bother going into but you can use systems such as ECIES (elliptic curve integrated encryption system) as public key crypto systems.
So I think the answer is no, not really, but there are lots of people who know lots more about this than me so I may be corrected.
I didn't mean to suggest you would have any interest in doing any such thing but I think you misunderstood what the paper was describing.
There are ways of using the encrypted messages in signature schemes to send extra information that is not detectable. This applies not only to elliptic curve signature schemes but other discrete logarithm schemes such as such Schnorr and EIGamal.
This paper is not really something you have to worry about unless you were trying to send yourself information in secret from the wallet that you could read from the blockchain. It is not any weakness in the signature scheme.
If you were trying to send yourself information then you would in effect have to brute force the encryption.
Think of it this way. Each time I sign a message with ECDSA I use a random number and iI come up with the signed message.
Now if I have a cipher that I have prearranged, say a simple substitution cipher so a->b, c->d etc. (this is our prearranged mapping function)
Now I want to transmit the message theeaglehaslanded this becomes uiffbhmfibtmboefe.
So I can keep trying different random numbers until the first part of the signed message says uiffbhmfibtmboefe. When the signed message is published then anyone with the substitution cipher can decrypt it.
Now it will probably take quite a few tries with random numbers to come up with this combination of letters. Look at the problem of generating vanity addresses and how much more difficult it gets as they get longer.
So you can split the message in to sections and send it bit by bit so you drastically reduce the amount of resources for encryption at the expense of sending more messages.
By the way this is not supposed to be a technical explanation so hopefully I won't get too many critical comments from Wikipedia experts. I'm sure someone on the forum will publish a white paper about it soon anyway.
So, yea, don't worry about it.
There are ways of using the encrypted messages in signature schemes to send extra information that is not detectable. This applies not only to elliptic curve signature schemes but other discrete logarithm schemes such as such Schnorr and EIGamal.
This paper is not really something you have to worry about unless you were trying to send yourself information in secret from the wallet that you could read from the blockchain. It is not any weakness in the signature scheme.
If you were trying to send yourself information then you would in effect have to brute force the encryption.
Think of it this way. Each time I sign a message with ECDSA I use a random number and iI come up with the signed message.
Now if I have a cipher that I have prearranged, say a simple substitution cipher so a->b, c->d etc. (this is our prearranged mapping function)
Now I want to transmit the message theeaglehaslanded this becomes uiffbhmfibtmboefe.
So I can keep trying different random numbers until the first part of the signed message says uiffbhmfibtmboefe. When the signed message is published then anyone with the substitution cipher can decrypt it.
Now it will probably take quite a few tries with random numbers to come up with this combination of letters. Look at the problem of generating vanity addresses and how much more difficult it gets as they get longer.
So you can split the message in to sections and send it bit by bit so you drastically reduce the amount of resources for encryption at the expense of sending more messages.
By the way this is not supposed to be a technical explanation so hopefully I won't get too many critical comments from Wikipedia experts. I'm sure someone on the forum will publish a white paper about it soon anyway.
So, yea, don't worry about it.
At least 2.71*2^x input values must be tried in order to recover x bits of data. This would make it completely useless for sending a 256-bit private key, provided that the key is truly random. It would be similar to bruteforcing the private key.
I think you may have misunderstood this
2.71*2^x are the input values that you would have to try to embed 256 bit of data in the carrier
However if you were sending 256 messages and only sending 1bit of data in each carrier then you would only need to try 2.71*2 (x=1) input values each time. i.e. it is a lot easier to send lots of little messages than one big one.
These are only the probabilities of the amount of input values you will have to try.
This illustrates the difficulty of encoding the message not decoding it which is done with a prearranged mapping function.
The problem here is whether your users trust you not to have embedded anything malicious in the wallet to reveal their keys. This would be a very interesting way to do it but I could think of lots of simpler ways.
I believe my understanding is correct but please get other opinions.
If you send a transaction with a script that restricts how it is spent then how do wallet balances handle this?
If I am required to sign with the private key (which I have) but there is a requirement for some further information which the wallet has no way of knowing whether I have or not then will it show up as available to spend? Then later when I come to spend it I find out I can't if I don't have the information.
Or will it not show up and I won't know I received it?
Or am I not understanding something about how scripts work?
Also I was looking for a good description of the mechanics of how wallets calculate and update the balances as I don't fully understand it. Is all the information from the database of UTXO's?
If I am required to sign with the private key (which I have) but there is a requirement for some further information which the wallet has no way of knowing whether I have or not then will it show up as available to spend? Then later when I come to spend it I find out I can't if I don't have the information.
Or will it not show up and I won't know I received it?
Or am I not understanding something about how scripts work?
Also I was looking for a good description of the mechanics of how wallets calculate and update the balances as I don't fully understand it. Is all the information from the database of UTXO's?
Re: Make Bitcoin More Valuable with Distributed Computing Projects?
you basically restated what I suggest at the beginning of this thread, but two days later.
Apologies, wasn't intentional, I just came across this and thought you'd done the same to me but I see your post was earlier
Re: Make Bitcoin More Valuable with Distributed Computing Projects?
The problem is that mining requires a work that is hard to find but easy to verify.
Prime numbers don't work because finding one is as difficult as verifying it's prime
Prime numbers don't work because finding one is as difficult as verifying it's prime
I've already discussed this idea on another thread
https://bitcointalk.org/index.php?topic=233750.msg2509289#msg2509289
There are ways of reconstructing the problem so that it satisfies the pow requirements such as changing the problem to finding a factor of a large number.
carefully designed to make the calculation of the hash quicker than accumulating transactions from the broadcast stream?
The idea of the hash is that sha256(x)->y is a one way function that gives out pretty random results
So if you know y you can't work out x
If you know x you can work out y but it will be a random result
So carefully designing your own x won't help you predict y so you have to use brute force until you come up with the y you are looking for or start experimenting with some of the SAT techniques
But you could turn it around into finding factors of a very large number to check whether it is prime.
Couldn't you just lie about this? Imagine "15" is such a huge number: I just claim that the only factors I could find for 15 are 1 and 15, thus making it prime. This still requires you to try to find other factors to debunk my claim...
A large number is proposed and everybody keeps dividing it by various primes until somebody gets lucky and finds a factor. It takes a lot of computational power to keep dividing but when you have found a factor anybody can quickly check whether it actually is a factor.
Then some formula using the previous number and the factor that has just been found is used to create the next big number to check.
Of course there is the problem that if the number is actually prime we never find a factor. This isn't an answer just an idea of what sort of thing the pow problem might be.
There is a lot of processing power out there working on hashing. What if a researcher wants to use this sort of distributed processing power for a useful research project? Everybody donates their processing power to the project and they are then entered into a lottery with the chances of winning related to how much processing power they donate. This lottery replaces the lottery of whether or not you come up with the right nonce.
Well I was thinking of something along the lines of producing large prime numbers. They can be useful in cryptography. The problem is that proof of work needs a problem that takes a great deal of computational power to find a solution and very little to check the solution.
If you are finding prime numbers then it takes a great deal of computational power to check whether it is prime. But you could turn it around into finding factors of a very large number to check whether it is prime.
Once you have found the useful problem that needs a great deal of computational power to solve but little to check there is also the problem of whether it could be pre-mined and somebody could save up solutions and use them for a double spend so each new problem would have to be created from the last solution.
I don't think there is any real reason why proof of work could be used on a separate problem to the blockchain as it does not necessarily have to be related. All we need is that it is in someone's best interest to use their solution to the problem to earn coins from mining rather than trying to double spend.
If you are finding prime numbers then it takes a great deal of computational power to check whether it is prime. But you could turn it around into finding factors of a very large number to check whether it is prime.
Once you have found the useful problem that needs a great deal of computational power to solve but little to check there is also the problem of whether it could be pre-mined and somebody could save up solutions and use them for a double spend so each new problem would have to be created from the last solution.
I don't think there is any real reason why proof of work could be used on a separate problem to the blockchain as it does not necessarily have to be related. All we need is that it is in someone's best interest to use their solution to the problem to earn coins from mining rather than trying to double spend.
But if somebody did find a quicker way of hashing and everybody started doing it then the difficulty would have to increase wouldn't it? So it would be pointless unless you kept it secret so you could mine faster than everybody else.
I think it would be interesting if the pow could be somehow be used to do something useful. I don't really know how though.
I think it would be interesting if the pow could be somehow be used to do something useful. I don't really know how though.
Re: Block Chain Based BTC Hedging - something like a Put Option.
There are a lot of different ways of utilising leverage. They do not necessarily involve the use of credit.
Puts and calls are terms used in traded options which was what I described. Options can be traded as separate entities. Have a look at the liffe market for stock options.
If I open an account at a stockbrokers, a forex account or a spread betting account I can use leverage but it is unlikely that I will be extended credit and I will only be allowed to lose what I have in my account at which point any open position will be automatically closed.
There is often confusion about whether money is actually being loaned in a futures contract. Elsewhere in this forum you can read statements such as
"Alternatively, you could open a $1000 long position in the BTC/USD pair on margin. This is an open trading position only and no profit/loss is realized until it is closed. There is no currency conversion and you don't own any BTC that you can withdraw"
But later they say
"To give a rough idea, the margin fee will work something like this. Suppose you open a $1000 long position in BTC/USD using margin. In doing so, you are borrowing the $1000 from us and we will charge an APR for this, but the fees will be assessed at least on a daily basis"
So I'm borrowing the money and being charged interest but can't withdraw it. The exchange wins every time.
If the blockchain did contain information on other currency transactions then it might be possible to operate a derivatives market. Imagine if the Litecoin and bitcoin blockchains were combined and the proof of work was applied to both combined blockchains. We could then build an exchange and a derivatives market between litecoin and bitcoin. If fiat currencies became available in digital format we could just have one big blockchain for all financial transactions in whatever currency.
Puts and calls are terms used in traded options which was what I described. Options can be traded as separate entities. Have a look at the liffe market for stock options.
If I open an account at a stockbrokers, a forex account or a spread betting account I can use leverage but it is unlikely that I will be extended credit and I will only be allowed to lose what I have in my account at which point any open position will be automatically closed.
There is often confusion about whether money is actually being loaned in a futures contract. Elsewhere in this forum you can read statements such as
"Alternatively, you could open a $1000 long position in the BTC/USD pair on margin. This is an open trading position only and no profit/loss is realized until it is closed. There is no currency conversion and you don't own any BTC that you can withdraw"
But later they say
"To give a rough idea, the margin fee will work something like this. Suppose you open a $1000 long position in BTC/USD using margin. In doing so, you are borrowing the $1000 from us and we will charge an APR for this, but the fees will be assessed at least on a daily basis"
So I'm borrowing the money and being charged interest but can't withdraw it. The exchange wins every time.
If the blockchain did contain information on other currency transactions then it might be possible to operate a derivatives market. Imagine if the Litecoin and bitcoin blockchains were combined and the proof of work was applied to both combined blockchains. We could then build an exchange and a derivatives market between litecoin and bitcoin. If fiat currencies became available in digital format we could just have one big blockchain for all financial transactions in whatever currency.
Re: Block Chain Based BTC Hedging - something like a Put Option.
Greetings Bitcoin People.
There has been much talk in the threads about Bitcoin Especially ways to hedge the future price of bitcoin. For non-Finance types, this means ways to place a bet(hedge) on the projected future price of Bitcoin.
There has been much talk in the threads about Bitcoin Especially ways to hedge the future price of bitcoin. For non-Finance types, this means ways to place a bet(hedge) on the projected future price of Bitcoin.
On the projected future price of bitcoin against what?
Hedges, puts, calls, traded options are all relative to something, it is difficult to see how you could use the blockchain for this type of financial speculation
I might want to place a bet on the future price of bitcoin against the US dollar, the blockchain gives me very little information on the current exchange rate with the US dollar
OK I pay a $5 fee to have the option to buy $100 for 1 BTC at anytime in the next two months.
If the exchange rate stays at about $100 for 1BTC it isn't worth using my option. I lose $5.
If the exchange rate drops to $50 for 1BTC then I can use my option and buy $100 for 1BTC and then, immediately, I exchange the $100 for 2BTC. Welcome to the wonderful world of financial speculation (gambling).
The hypocrisy of bitcoin is that it decries the centralised banking systems then emulates the worst facets of those systems. I see that most of the bitcoin exchanges are mostly concerned with introducing leverage and derivatives that have no benefit to anybody except those who wish to exploit gamblers (i.e. it benefits the exchanges)
There used to be a benefit to futures and commodity trading to farmers who might wish to insure against bad weather or crop failure. This system has become corrupted. The people who should be taking options on exchange rate as insurance might be exporters who are actually manufacturing something. Not just gamblers who will continue to be exploited by the exchanges (trading platforms) in the same way that casinos make their money.
How could you estimate what is the highest percentage of current hash rate that could be controlled by one entity?
I've been reading this
https://bitcoil.co.il/Doublespend.pdf
and I was trying to get a realistic idea of how many confirmations it is necessary to wait for.
Looking at the realities and complexity of mounting an attack it seems to me that just one confirmation will suffice in nearly all cases.
Is there a realistic present day scenario where a double spend attack is launched and I lose money because I only waited for one confirmation?
I've been reading this
https://bitcoil.co.il/Doublespend.pdf
and I was trying to get a realistic idea of how many confirmations it is necessary to wait for.
Looking at the realities and complexity of mounting an attack it seems to me that just one confirmation will suffice in nearly all cases.
Is there a realistic present day scenario where a double spend attack is launched and I lose money because I only waited for one confirmation?
Instead of having one secret i.e. a private key to your address
You now have secret 1 and secret 2
secret 1 is the encoded transaction with private key discarded
You would have to keep it secret as otherwise anyone could just initiate the transaction and we would be back to square one
Secret 2 is your private key to your address
If only secret 1 is completely stolen your coins are lost (unless thief is good enough to process transaction)
If only secret 1 is stolen but you have a copy your coins are still safe but we are back to square one.
If only secret 2 is completely stolen your coins are lost.
If only secret 2 is stolen but you have a copy then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen but you have a copy of both then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen and you have no copy of either then your coins are stolen.
If both secret 1 and secret 2 are stolen but you have a copy of secret 1 but not a copy of secret 2 then the coins are stolen
If both secret 1 and secret 2 are stolen but you have a copy of secret 2 but not a copy of secret 1 then it is a race to perform a transaction
Now we need to to assess the probability of a breach of bank security or super-spy-government-satellite attack or other such attack on each of the above scenarios in relation to the increased probability of key loss.
If we calculate the relative probabilities for each scenario and use this to calculate an overall weighted probability that should give us some idea of whether we would be better off using this system or not.
You now have secret 1 and secret 2
secret 1 is the encoded transaction with private key discarded
You would have to keep it secret as otherwise anyone could just initiate the transaction and we would be back to square one
Secret 2 is your private key to your address
If only secret 1 is completely stolen your coins are lost (unless thief is good enough to process transaction)
If only secret 1 is stolen but you have a copy your coins are still safe but we are back to square one.
If only secret 2 is completely stolen your coins are lost.
If only secret 2 is stolen but you have a copy then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen but you have a copy of both then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen and you have no copy of either then your coins are stolen.
If both secret 1 and secret 2 are stolen but you have a copy of secret 1 but not a copy of secret 2 then the coins are stolen
If both secret 1 and secret 2 are stolen but you have a copy of secret 2 but not a copy of secret 1 then it is a race to perform a transaction
Now we need to to assess the probability of a breach of bank security or super-spy-government-satellite attack or other such attack on each of the above scenarios in relation to the increased probability of key loss.
If we calculate the relative probabilities for each scenario and use this to calculate an overall weighted probability that should give us some idea of whether we would be better off using this system or not.