Search content
Sort by
Showing 20 of 32 results by Martin P. Hellwig
Hi all, I am a bit confused here:
According to the spec and main.cpp the version message should be first me and then you:
(line 2364)
int64 nTime;
CAddress addrMe;
CAddress addrFrom;
uint64 nNonce = 1;
but from what I see over the network it is more the otherway around, as net.h would suggest too:
line 743
void PushVersion()
{
/// when NTP implemented, change to just nTime = GetAdjustedTime()
int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
CAddress addrYou = (fUseProxy ? CAddress("0.0.0.0") : addr);
CAddress addrMe = (fUseProxy ? CAddress("0.0.0.0") : addrLocalHost);
RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,
nLocalHostNonce, std::string(pszSubVer), nBestHeight);
}
As I am not proficient in cpp, I don't really know now what is going on.
Could someone shed a bit more light on this please?
Thanks,
Martin
According to the spec and main.cpp the version message should be first me and then you:
(line 2364)
int64 nTime;
CAddress addrMe;
CAddress addrFrom;
uint64 nNonce = 1;
but from what I see over the network it is more the otherway around, as net.h would suggest too:
line 743
void PushVersion()
{
/// when NTP implemented, change to just nTime = GetAdjustedTime()
int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
CAddress addrYou = (fUseProxy ? CAddress("0.0.0.0") : addr);
CAddress addrMe = (fUseProxy ? CAddress("0.0.0.0") : addrLocalHost);
RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,
nLocalHostNonce, std::string(pszSubVer), nBestHeight);
}
As I am not proficient in cpp, I don't really know now what is going on.
Could someone shed a bit more light on this please?
Thanks,
Martin
Seriously though, how is a mugger going to get bitcoins off your android if you dont' tell him the password? This will take a very sophisticated mugger.
[/quote]
Never underestimate the persuasive power of a baseball bat :-)
Am I missing the point or do I not understand your question?
What do you actually mean by filling the void? As I interpret it as: All fiat currencies have gone to smithereens and people lost all value in it and need to start again from scratch, perhaps by using bitcoin? Yes of course in that scenario bitcoin can fill the void, as can seashells, garden peas and whatever else you can convince other people to accept for trading.
In any other scenario, it would be the same question as; Can pesos fill the void in a bank run?
What do you actually mean by filling the void? As I interpret it as: All fiat currencies have gone to smithereens and people lost all value in it and need to start again from scratch, perhaps by using bitcoin? Yes of course in that scenario bitcoin can fill the void, as can seashells, garden peas and whatever else you can convince other people to accept for trading.
In any other scenario, it would be the same question as; Can pesos fill the void in a bank run?
So with this in future I can replace bitcoind+JSON or this is just API for bitcoind?
As far as I can read the code (I am sure that Sam will refactor the code ones he is happy with the functionality, so it is easier to read/maintain/extend for mere mortals
), this is aimed to be a full implementation of the reference c++ bitcoin implementation. So in other words, where you used to run the bitcoin client downloaded from bitcoin.org, you can alternatively use his python one instead.
Good to see I am not the only one working on a Python implementation, a little bit of competition is a good thing :-)
Cheers Sam, good work!
Bitcoin; Trusted by more paranoids than any other currency.
Bitcoin; You don't have to trust me, just that 1+1=2.
Bitcoin; Don't bother if your happy not to own your money.
Bitcoin; When was the last time you where happy with your bank?
Bitcoin; When was the last time you where happy with your governments financial ruling?
Bitcoin; You don't have to trust me, just that 1+1=2.
Bitcoin; Don't bother if your happy not to own your money.
Bitcoin; When was the last time you where happy with your bank?
Bitcoin; When was the last time you where happy with your governments financial ruling?
Probably americans can buy all the software they want and it costs to them less than they spend on dinner in restourant. But for some people not so lucky to born in developed country and rich parents, the software costs are too high. For example MS Office Enterprise will cost me about 2 years of income. And none want to use inferior alternatives. Yes, I can use Open Office and I like OOo, but I also like to have both MS Office 2007 Enterprise and OOo on my computer. If OOo will have problems with some docs, I will use the MS Office with the sucky ribbon.
You might want to consider looking for a technet subscription, in 'non-developed' countries MS usually throws it in free if you ask them nicely and say that you are a starting developer on 'their' platform. With that subscription you can pretty much download every piece of mainstream software that MS has ever produced and get 10 official full commercial usable product keys, per product version. Though after three years or so they probably going to require payments, for renewed subscriptions (your keys will continue to work).
Re: Why not make Bitcoin more Secure with a PIN and TAN System?
if you would be very secure, you would make a physical device with a small LCD screen, which prints out the addresses, and the amounts.
on that device the transaction will be signed. and the private key will never leave the device. this would be the only secure thing.
on that device the transaction will be signed. and the private key will never leave the device. this would be the only secure thing.
Hmmm, me thinking about those nfc enabled smartphones ...
At the moment I am just parsing wireshark dumps for my protocol decoder, so I would be very interested in this too!
I can get a bit of a wiggle on with my python stuff so you can at the protocol level decode it (well assuming I did it right), for decoding I more or imitated the look of a raw representation of blockexplorer. I am about 2 weeks away before I can release anything decent but I should be able to put something halfway working on within a couple of days, if anybody is interested.
I can get a bit of a wiggle on with my python stuff so you can at the protocol level decode it (well assuming I did it right), for decoding I more or imitated the look of a raw representation of blockexplorer. I am about 2 weeks away before I can release anything decent but I should be able to put something halfway working on within a couple of days, if anybody is interested.
It would be nice if you could write notes about what you discover. AFAIK, the protocol is only partially documented and mostly resides in "oral tradition" (if I may say so it's obviously not oral). You could e.g. contribute to the Protocol specification page on the wiki, that still has strong tying between the network protocol and the internal structure of the original implementation (see "variable length strings", data types all over the document, etc.).
I have a couple of goals set:
- Split out the protocol in a pure daemon part (which does the communication and storing of the blocks/transactions) possibly with an optional SQL back-end.
- Have everything PEP-8 and Python 3 compliant.
- Have unit tests with a 100% coverage.
- Be able to have a local "blockexplorer" that does not depend on the c++ client but instead uses the code of the above daemon.
- Create a 'thin' CLI client that interacts with the daemon (in essence this will just hold the private keys and have some UI code).
- The same as above but a GUI client.
For me when coding, the most important part is readability and maintainability, this is also the reason why I am at try number 3 because the other tries, although successfully parsing the tcpdump of an interaction, was not readable enough. So ultimately I want my implementation to be working 'pseudo code'. As I have particular strong feelings on how the Protocol Specification should be written, I think that I am not the appropriate person to contribute to that page.
As the approach I am taking is painstakingly slow, I wouldn't hold my breath, though I do intend to release the source under the new revised BSD license.
And I am sure that when I at least have reached my 4th goal, I can be persuaded to (help) create a RFC with the intention to submit an Internet Draft to the IETF.
While I am quietly in my limited spare time building a python implementation of the bitcoin protocol I am increasingly charmed about the ingenuity of the protocol itself.
Sure in the beginning I had of a lot of things* that I found strange but what is even stranger is that I am continuously discovering that the choices made might not be pretty, or particular easy but they share one common trait so far; the alternatives have far worse implications**.
So I would like to take my hat off and say three cheers to everybody that is working, designing and building the protocol, the software and community!
Thank you, it is truly appreciated!
* )
1 The constant byteswapping. Well once (:-)) you have it subclassed you hardly notice it anymore.
2 Only ~21 million BTC available? Yeah but it is easy enough to increase the divisibility
3 What about lost coins, can we not have a system in place where forgotten coins are available for reminig? Neat, but this ultimately leads for regular users to a dependency on an external service provider, which opens a whole other can of worms.
4 The use of secp256k1, Well ones you look into it, it is kinda neat and there is not a clear and obvious advantage to other curves or public key algorithm, so this falls in the category why not.
5 The lack of a python implementation. Well, I am working on it, so that one is my fault for not moving my behind faster :-)
** )
My opinion, thus the validity of the made statements are not universal.
Sure in the beginning I had of a lot of things* that I found strange but what is even stranger is that I am continuously discovering that the choices made might not be pretty, or particular easy but they share one common trait so far; the alternatives have far worse implications**.
So I would like to take my hat off and say three cheers to everybody that is working, designing and building the protocol, the software and community!
Thank you, it is truly appreciated!
* )
1 The constant byteswapping. Well once (:-)) you have it subclassed you hardly notice it anymore.
2 Only ~21 million BTC available? Yeah but it is easy enough to increase the divisibility
3 What about lost coins, can we not have a system in place where forgotten coins are available for reminig? Neat, but this ultimately leads for regular users to a dependency on an external service provider, which opens a whole other can of worms.
4 The use of secp256k1, Well ones you look into it, it is kinda neat and there is not a clear and obvious advantage to other curves or public key algorithm, so this falls in the category why not.
5 The lack of a python implementation. Well, I am working on it, so that one is my fault for not moving my behind faster :-)
** )
My opinion, thus the validity of the made statements are not universal.
Re: Transaction verification in Python (with M2Crypto)
Hi,
Thanks for the snippet it is greatly appreciated!
Yes, that is correct, as you already figured out bitcoin only sends the xy position of the curve, however for openssl also needs to know which curve is used and of course what type of public key it is, since this is all DER encoded I opted for recreating the DER package. As you can see I used the same key to check if it works. Although in my code I only have a dependency on openssl directly (via subprocess) and thus do away with m2crypto or any other crypto wrapper, I do have a new dependency on pyasn1 http://sourceforge.net/projects/pyasn1/ though.
The relevant part of my code:
Thanks for the snippet it is greatly appreciated!
My biggest problem was with M2Crypto: it doesn't seem to implement o2i_ECPublicKey from openssl, which is used by bitcoin to set the public key. I also looked at using pyOpenssl and pycrypto, but it looks like neither of these libraries can handle elliptic curve cryptography...
To make M2Crypto work for this I had to use some magic, which I'm really not happy about:
This string I got by making new public/private key pairs with M2Crypto and printing them out: I noticed that this part is fixed and never changes. I assume this string defines the parameters used (NID_secp256k)
To make M2Crypto work for this I had to use some magic, which I'm really not happy about:
Code:
pkey = pubkey[::-1] + "0042030a0004812b050601023dce48862a070610305630".decode("hex")
pkey = M2Crypto.EC.pub_key_from_der(pkey[::-1])
As you can see, I need to add a fixed string in order to load the public key. Without this it fails to load it and I get an exception (ValueError: Received a NULL pointer.)pkey = M2Crypto.EC.pub_key_from_der(pkey[::-1])
This string I got by making new public/private key pairs with M2Crypto and printing them out: I noticed that this part is fixed and never changes. I assume this string defines the parameters used (NID_secp256k)
Yes, that is correct, as you already figured out bitcoin only sends the xy position of the curve, however for openssl also needs to know which curve is used and of course what type of public key it is, since this is all DER encoded I opted for recreating the DER package. As you can see I used the same key to check if it works. Although in my code I only have a dependency on openssl directly (via subprocess) and thus do away with m2crypto or any other crypto wrapper, I do have a new dependency on pyasn1 http://sourceforge.net/projects/pyasn1/ though.
The relevant part of my code:
Code:
from pyasn1.codec.der import encoder
from pyasn1.type.univ import Sequence, ObjectIdentifier, BitString
# http://www.oid-info.com/get/1.2.840.10045.2.1
OID_EC_PUBLIC_KEY = "1.2.840.10045.2.1"
# http://www.oid-info.com/get/1.3.132.0.10
OID_SECP256K1 = "1.3.132.0.10"
def ec_public_key_in_der(xy_curve):
"Create the DER public key part using the XY curve values"
oid = Sequence()
oid.setComponentByPosition(0, ObjectIdentifier(OID_EC_PUBLIC_KEY))
oid.setComponentByPosition(1, ObjectIdentifier(OID_SECP256K1))
xyc = BitString("'%s'H" % xy_curve.encode('hex'))
tmp = Sequence()
tmp.setComponentByPosition(0, oid)
tmp.setComponentByPosition(1, xyc)
return(encoder.encode(tmp))
if __name__ == '__main__':
XY_CURVE = "0447d490561f396c8a9efc14486bc198884ba18379bcac2e0be2d8525134" +\
"ab742f301a9aca36606e5d29aa238a9e2993003150423df6924563642d4afe9bf4fe28"
XY_CURVE = XY_CURVE.decode('hex')
PUBLIC_KEY = "3056301006072a8648ce3d020106052b8104000a0342000447d490561f" +\
"396c8a9efc14486bc198884ba18379bcac2e0be2d8525134ab742f301a9aca36606e5d2" +\
"9aa238a9e2993003150423df6924563642d4afe9bf4fe28"
PUBLIC_KEY = PUBLIC_KEY.decode('hex')
if ec_public_key_in_der(XY_CURVE) == PUBLIC_KEY:
print(True)
else:
print(False)
from pyasn1.type.univ import Sequence, ObjectIdentifier, BitString
# http://www.oid-info.com/get/1.2.840.10045.2.1
OID_EC_PUBLIC_KEY = "1.2.840.10045.2.1"
# http://www.oid-info.com/get/1.3.132.0.10
OID_SECP256K1 = "1.3.132.0.10"
def ec_public_key_in_der(xy_curve):
"Create the DER public key part using the XY curve values"
oid = Sequence()
oid.setComponentByPosition(0, ObjectIdentifier(OID_EC_PUBLIC_KEY))
oid.setComponentByPosition(1, ObjectIdentifier(OID_SECP256K1))
xyc = BitString("'%s'H" % xy_curve.encode('hex'))
tmp = Sequence()
tmp.setComponentByPosition(0, oid)
tmp.setComponentByPosition(1, xyc)
return(encoder.encode(tmp))
if __name__ == '__main__':
XY_CURVE = "0447d490561f396c8a9efc14486bc198884ba18379bcac2e0be2d8525134" +\
"ab742f301a9aca36606e5d29aa238a9e2993003150423df6924563642d4afe9bf4fe28"
XY_CURVE = XY_CURVE.decode('hex')
PUBLIC_KEY = "3056301006072a8648ce3d020106052b8104000a0342000447d490561f" +\
"396c8a9efc14486bc198884ba18379bcac2e0be2d8525134ab742f301a9aca36606e5d2" +\
"9aa238a9e2993003150423df6924563642d4afe9bf4fe28"
PUBLIC_KEY = PUBLIC_KEY.decode('hex')
if ec_public_key_in_der(XY_CURVE) == PUBLIC_KEY:
print(True)
else:
print(False)
Not round? Just sayin'
they are not round just look like it because they have an indefinitely amount of corners.Hi,
The problem is an organizational one, if you don't trust the exchange in holding the money, the only logical alternative is that a user must make a manual effort to verify the transaction before it is processed. This more or less defeats the purpose of an exchange service that gets its added value because it can act on behalf of the user and large amount of transactions are automatically processed. Otherwise you end up with an ebay for bitcoins.
But perhaps I misunderstood your paper or exchanges in general.
Cheers,
Martin
The problem is an organizational one, if you don't trust the exchange in holding the money, the only logical alternative is that a user must make a manual effort to verify the transaction before it is processed. This more or less defeats the purpose of an exchange service that gets its added value because it can act on behalf of the user and large amount of transactions are automatically processed. Otherwise you end up with an ebay for bitcoins.
But perhaps I misunderstood your paper or exchanges in general.
Cheers,
Martin
I think the utility of wallet encryption in absence of a smartcard is very limited, if at all exists.
As the wallet is only needed when sending an transaction it is perfectly alright to encrypt it and prompt the user for a password to when needed.Re: Semi-Related: How difficult is it to "hack into" a default ubuntu install?
It has always perplexed me that the bitcoin core users seem to prefer ubuntu/debian over Redhat/Fedora/CentOS linux when they are supposedly "security conscious" elites of some sort ....
... industrial users who "need" security go the enterprise RH, Novell, suse linux direction not the other way ... just saying, seems weird.
... industrial users who "need" security go the enterprise RH, Novell, suse linux direction not the other way ... just saying, seems weird.
*ahem* (FreeBSD user) ducks for cover, waiting for an OpenBSD user to reply.. :-)