Bitcoin Forum
May 24, 2024, 04:34:26 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 [48] 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 ... 103 »
941  Bitcoin / Development & Technical Discussion / Re: Cold / Brain wallet security question on: October 24, 2013, 10:01:03 AM
If I have a private key written down somewhere and for further security change one or more of the digits and then have the public address from the resulting private key written next to it.  How secure is that?  Would a brute force attack or any other attack be easier or no?  
Now after you announced it; it is a security risk, but only if the attacker gets to know one of your private keys.
Then he will try to brute force the remaining ones by changing one or more of the digits.

Without disclosing any of your private keys, you should be safe; you can even use them in a sequence and it shouldn't matter.
I mean: assuming that there isn't any secret math behind ECDSA, that we don't know and they do.. which has been a concern.
942  Bitcoin / Development & Technical Discussion / Re: Raw Tx Tool - Use for coin control, and never accidentally pay a huge fee again! on: October 23, 2013, 01:00:30 PM

See BIP 10 for a transaction distribution format: https://en.bitcoin.it/wiki/BIP_0010

I'm not sure it's my favorite format, but it's the one concrete proposal right now.
Thanks.

To be honest, I prefer moving txs to/from my cold storage in a raw format.
Then I can easily check if a tx has not been tempered with, doing e.g.:
Code:
cat transaction.bin | openssl sha256 -binary | openssl sha256

Besides, before spending them my wallet app needs the original raw data anyway, to make sure that it has the expected ID.
So IMO, it is more convenient for a wallet app to have a tx (carrying an unspent output) as a raw data already.

And if I need to see whats inside a raw tx, I have a tool to display it in a human readable format.
I always use it on a signed tx, before moving it out from my cold storage. Just in case if my wallet would screw something up.

Code:
/*
gcc bctrans.c -o bctrans.exe -lcrypto -I /local/ssl/include -L /local/ssl/lib
*/

#include <stdio.h>
#include <stdlib.h>
#include <stdlib.h>
#include <strings.h>
#include <openssl/sha.h>
#include <openssl/bn.h>


static unsigned char addr_version = 0x00;
static FILE *f = NULL;

BIGNUM *bn58, dv, mo;
BN_CTX *ctx;


#define SHA256(p,l,o) { \
SHA256_CTX shactx; \
SHA256_Init(&shactx); \
SHA256_Update(&shactx, (p), (l)); \
SHA256_Final((o), &shactx); }


void readfile(unsigned char *p, int len) {
if (!f) {
int c, i;
char s[3];
while (len>0) {
for (i=0;i<2;) {
c = getchar();
if (c==EOF) {
fprintf(stderr, "File too short\n");
exit(1);
}
c = tolower(c);
if (c<='9' && c>='0' || c<='f' && c>='a')  s[i++] = (char)c;
}
s[2] = 0;
sscanf(s, "%x", &c);
*p = (unsigned char)c;
p++;
len--;
}
} else {
if (fread(p, 1, len, f)!=len) {
fprintf(stderr, "File too short\n");
fclose(f);
exit(1);
}
}
}

unsigned long long getle(unsigned char *p, int bytes) {
unsigned long long res=0;
while (bytes--) {
res|= ((unsigned long long)(p[bytes]))<<(8*bytes);
}
return res;
}

unsigned long long getvl() {
unsigned char b[8];
readfile(b, 1);
switch (*b) {
case 0xfd:
readfile(b, 2);
return getle(b, 2);
case 0xfe:
readfile(b, 4);
return getle(b, 4);
case 0xff:
readfile(b, 8);
return getle(b, 8);
}
return *b;
}


void prhash(unsigned char *p, unsigned int l) {
while (l--) printf("%02x", p[l]);
}


void hexdump(unsigned char *p, unsigned int l) {
while (l--) printf("%02x", *p++);
}


void printbtcaddr(unsigned char *p) {
static const char *chrs = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";
unsigned char mod;
char out[64];
int i=0, j=0;
BIGNUM *bn = BN_bin2bn(p, 25, NULL);
while (!BN_is_zero(bn)) {
BN_div(&dv, &mo, bn, bn58, ctx);
if (BN_bn2bin(&mo, &mod)==0)  mod = 0;
out[i++] = chrs[mod];
BN_copy(bn, &dv);
}
BN_free(bn);
while ((*p)==0) {
putchar('1');
p++;
}
while (i--)  putchar(out[i]);
}


int main(int argc, char * argv[]) {
static unsigned char buf[0x10000];
unsigned long long i, sl, txcnt, v;
unsigned va, vb;
int x;
long fpos;
char *fname = NULL;

for (x=1; x<argc; x++) {
if (strcmp(argv[x], "-t")==0) {
addr_version = 0x6f; // testnet
} else {
fname = argv[x];
}
}

if (!fname) {
printf("Enter transactions hexdump data:\n");
} else {
f = fopen(fname, "rb");
if (!f) {
fprintf(stderr, "File %s not found\n", fname);
return 1;
}
}

readfile(buf, 4);
printf("Version: %llu\n", getle(buf, 4));

txcnt = getvl();
printf("TX IN cnt: %llu\n", txcnt);
for (i=0; i<txcnt; i++) {
readfile(buf, 36);
sl = getvl();

printf("%6d) : ", (int)i);
prhash(buf, 32);
printf(" Idx=%2lld  sl=%lld", getle(buf+32, 4), sl);
readfile(buf, sl);
readfile(buf, 4);

printf(" seq=%x\n", (unsigned)getle(buf, 4));
}

txcnt = getvl();
printf("TX OUT cnt: %llu\n", txcnt);

ctx = BN_CTX_new();
bn58 = BN_bin2bn("\x3a", 1, NULL);
BN_init(&dv);
BN_init(&mo);

for (i=0; i<txcnt; i++) {
readfile(buf, 8);
sl = getvl();
v = getle(buf, 8);
va = (unsigned)(v/100000000LL);
vb = (unsigned)(v%100000000LL);
printf("%6d) : %7u.%08u BTC", (int)i, va, vb, sl);
readfile(buf, sl);
if (sl!=25 || memcmp(buf, "\x76\xa9\x14", 3) || buf[23]!=0x88 || buf[24]!=0xac) {
printf("  WARNING! Unexpected SIG_SCRIPT:\n"); hexdump(buf, sl);
} else {
unsigned char dat[25];
unsigned char sha[SHA256_DIGEST_LENGTH];
unsigned char sha2[SHA256_DIGEST_LENGTH];
dat[0] = addr_version; // version
memcpy(dat+1, buf+3, 20);
SHA256(dat, 21, sha);
SHA256(sha, SHA256_DIGEST_LENGTH, sha2);
//printf("  chsum:%02x%02x%02x%02x", sha2[0], sha2[1], sha2[2], sha2[3]);
memcpy(dat+21, sha2, 4);
printf("  to address "); printbtcaddr(dat);
}
putchar('\n');
}

BN_free(bn58);
BN_CTX_free(ctx);

readfile(buf, 4);
printf("Lock Time: %llu\n", getle(buf, 4));

if (f) {
fpos = ftell(f);
fseek(f, 0, SEEK_END);
if (fpos!=ftell(f)) {
printf("WARNING!!! File too long. Only %ld bytes expected (%ld too many)\n",
fpos, ftell(f)-fpos);
} else {
printf("File size checked OK - %ld bytes\n", fpos);
}
fclose(f);
}

return 0;
}
943  Bitcoin / Development & Technical Discussion / Re: Raw Tx Tool - Use for coin control, and never accidentally pay a huge fee again! on: October 22, 2013, 05:10:14 PM
BTW guys, maybe we should think of some kind of standard for such a "wallet balance" file.

Because I also have a wallet app which does quite the same things and it would be cool if it could import the data from other blockchain sources, rather than only the one I developed myself. It would be nice if it could also take a file that e.g. "Raw Tx Tool" fetched from blockchain.info. It's very useful, since then you don't need any bitcoin node, but just your wallet and blockchain.info webpage and you can still receive and send money using a cold wallet of your choice.


What I use is a zip file that contains unspent.txt, where each line has a format of:
Code:
<txid>-<vout> # comment (amount, b58 address, etc - not mandatory)

Besides the text file, inside the zip, there is a number of <txid>.tx files, that carry a binary content of the transactions mentioned in the unspent.txt
944  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 04:57:42 PM
Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

Yes, back when OCSP was designed, that didn't seem to be a big deal. Wallets don't use it anyway.
Wallets don't use it, but isn't it like: wallets use OpenSSL that uses parent certificates installed in the OS, and it is the OpenSSL+OS that eventually asks the revocation server, without leaving the wallet any control over the actual process?

Sorry - it might be a stupid question, I don't know how it works, so just asking.
945  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 03:38:41 PM
Anyway, all the revocation server does is look up the cert in a list and say "yep! it's revoked!". Your browser is free to ignore this and some of them will let you do so. Revocation is really a non issue, CA's don't have any real power to take back a cert they issued beyond issuing a new statement saying, "whoops our bad". And normally this is not controversial (i.e. the SSL keys were stolen).
Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.
946  Bitcoin / Development & Technical Discussion / Re: If one day, people find Bitcoin is no longer safe. How about the feature of btc? on: October 22, 2013, 03:04:21 PM
The whole security of ECDSA is based on the assumption that the sign function (which takes the hash, random R and private key D, calculating S that corresponds to the public key) cannot be reversed with far fewer resources, using some not yet publicly known algorithm.

The math behind it is quite complex and the mathematicians are not entirely certain whether it is in fact impossible to reverse the function.

Use a new address for every transaction (as suggested in the white paper).

Problem solved.
Not quite.
Because before your transaction gets mined, the public key and R is still exposed to the world and if someone can calc the D from it fast enough, he can spend your money before you.
947  Bitcoin / Development & Technical Discussion / Re: If one day, people find Bitcoin is no longer safe. How about the feature of btc? on: October 22, 2013, 02:48:10 PM
Bitcoin addresses can't be "cracked" by simply using a more powerful computer. Not now, not in 10 year, not in 1000 year. The amount of bruteforce computation power required would use up all the energy in the universe.
We are not talking about bruteforcing, per se.

The whole security of ECDSA is based on the assumption that the sign function (which takes the hash, random R and private key D, calculating S that corresponds to the public key) cannot be reversed with far fewer resources, using some not yet publicly known algorithm.

The math behind it is quite complex and the mathematicians are not entirely certain whether it is in fact impossible to reverse the function.
In other words: it has not been mathematically proven that it is impossible to calculate D, having the public key, the hash, R and S.

Moreover: we know for sure that if you reuse the same R with a different hash, the way to calc D is pretty straight forward.
Now, using a different R the only thing that makes calculating D not straight forward is a magic behind a shape of the curve...
And the curve has been shaped by people who don't tell us how they did it Smiley
948  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 02:37:07 PM
Isn't there something like a certificate revocation mechanism, that basically makes your PC to connect to the CA each time you want to use a cert?
949  Bitcoin / Development & Technical Discussion / Re: If one day, people find Bitcoin is no longer safe. How about the feature of btc? on: October 22, 2013, 01:43:49 PM
There have been uncertainties concerning the security of ECDSA.
We still don't know how they chose the curve params and it doesn't seem that they are going to tell us.

It would be useful to at least add support for RSA/DSA signed transaction, in parallel to the ECDSA.
Then people could at least diversify their savings - e.g. split it 50:50 between ECDSA and RSA protected addresses.

This kind of change needs a hard fork and so the sooner you put it in, the better.
950  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 11:05:06 AM
Linking a blockchain parser and (even worse) a wallet with any SSL lib is totally unnecessary and hugely irresponsible.
951  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 10:53:47 AM
Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.
It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess than the bitcoin at the current stage.

As we have learned recently NSA is probably actively trying to put backdoors wherever they can.
There are reasons to suspect that they had Google to put one into Android's RNG - also an open source code.
I would say that openssl would be one of their targets as well.
But it does not even need to be NSA - it can be just a bug.
All it takes is one bug that would allow to inject an exploit via a stack overflow (e.g. via a "broken" certificate) - and there goes all your money...
952  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 10:42:00 AM
You mean the core client that has a complete cross-platform GUI? It's a reference implementation. Even if not many people choose to use it, it gives developers something to test against and it allows us to verify that what we've designed actually works in the real world. Plus, there are plenty of users who may choose to run a full node wallet, anyone who has a computer switched on 24/7 is a good candidate for using Bitcoin-Qt. With this question, you're really asking "why does anyone bother to maintain the Bitcoin-Qt GUI at all?" which is a topic for another time.
Sure, that's a great point!
Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?

You know what, you guys keep doing what you do and in the meantime I will just go to buy some popcorn...
It's gonna be useful when one day I finally get to watch the show, after the great "let's mess it all up even more" approach to the bitcoin development blows right up into your face.
953  Bitcoin / Development & Technical Discussion / Re: Raw Tx Tool - Use for coin control, and never accidentally pay a huge fee again! on: October 22, 2013, 10:26:52 AM
Great stuff, man.

Think about adding an option to export the fetched inputs to a file - and then to get them from the file at another (offline) PC.

By this you will essentially turn your app into a nice cold wallet solution, that can work with bitcoind gateway, or even without it.
954  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 09:50:06 PM
Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?
nee - I would not worry about this; it won't happen, because people (bitcoin community) won't buy it.
still it's a shame that the precious dev resources are being so much wasted.
IMHO if someone had an intention to sabotage the actual useful development of the bitcoin software, he could not have done a better job.
955  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 07:48:08 PM
Well, there will always be a free market for cryptocurrencies under the Satoshi model, not to mention a free market for Bitcoin clients. And if people ever feel like Bitcoin development isn't sharing their ideals any more, the friction of dumping BTC for TrueSatoshi, or whatever it may be, will be way lower. As long as the catalyst isn't the removal of the ability to pay directly with a public key.

The mining pool operators will be the ones to watch, as they in fact run the most decisive nodes on the network, and there are less than a dozen.
Of course - luckily for us. Smiley

Nevertheless this topic is about "Invoices/Payments/Receipts proposal discussion" - and we are just providing our feedback..
956  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 07:33:02 PM
I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.
Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

Let's be realistic; already today, when we do any payment to a webshop, or whatever other commerce, we get a SSL signed payment address anyway, because every single one of these web services uses SSL.
And when we pay to an individual? Well, that's something that is definitely worth addressing, but not by "send your ID to CA and they will tell me that it's you". And definitely it is not so high priority to lock core devs in it for a year - are you out of your mind?
957  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 05:29:43 PM
I just don't understand what this SSL based payment processing has to do with bitcoin itself.
For me, and I am an active bitcoin user who uses bitcoins on daily basis, it is a waste of time at best.
Only big corporations will be using such a payment protocol, and since when we care about them?
Big corporations have enough money to invent their own payment protocols, on top of the already existing bitcoin client - which IMHO is exactly the place where a payment protocols should be, definitely not in the core where you are putting it now.

Mike - it is at least clear that he works for Google and his employer has a vast interest in putting hands on any new emerging IT, preferably driving its development into a direction that will make them lots of money in the future. That's BTW also a reason why they found Ripple interesting - because it is something that is supposed to be for bitcoin what fractional reserve system once was for gold; a great money maker.

Gavin - quite similar; he gets paid by "Bitcoin Foundation" - a cartel of a well known companies, that obviously want to comply with all possible NSA "standards and requirements". They don't want US gov to shut them down, so they will do everything to drive the development towards features that will make bitcoin payments "more transparent" and "NSA friendly". It's only logical.

But the rest of you, guys. If nobody pays you for doing this, then I can only ask, what is wrong with you?
Why aren't you working on increasing anonymity, performance, splitting wallet from the blockchain parser, making the core smaller and less dependent on other libs, thus more easy to audit?
Why the hell are you doing the opposite?

Do you really think Satoshi is proud of you today, seeing how you are handling further his great invention?
I don't think so, sirs.
958  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 02:19:12 PM
Do we really want CA support hard coded into the client? Worth some thought.
No we don't, but the core dev team obviously does, since they have paralyzed the bitcoin-qt development for almost a year already, just to give the bitcoin community this great new feature, that no sane person is going to use anyway because of the reasons that are obvious to everyone with a working brain.

Good job, guys!
How much longer are you going to be busy with this useless crap? Smiley
959  Bitcoin / Development & Technical Discussion / Re: Transaction with a message on: October 18, 2013, 02:18:01 PM
Is there the option to sign a transaction with a message, only readable for the receipient? (like in a bank transaction). It would make business much easier.

It is normally done the other way around.

You send the message to "the business" and the business gives you a unique receiving address associated with this message.

Now after you've sent the requested amount to this unique address - they've got the message "signed by a transaction".
960  Bitcoin / Development & Technical Discussion / Re: Worst case scenario on: October 11, 2013, 04:07:00 PM
This is exactly the reason why people shall be using cold wallets, to store their major BTC holdings.

It doesn't even need to be a bug or a backdoor in the actual bitcoin client - more likely it would be a virus/trojan/malware or just a bug/backdoor in the OS.

Keep your bitcoins offline and do not move any signed transaction from your cold storage without double checking whether it does exactly what you intended.
Just use your imagination combined with the already available technology and the worst case scenario would not be a threat to you.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 [48] 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 ... 103 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!