Bitcoin Forum
June 17, 2024, 12:26:46 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / Re: And the next code line is: ? on: September 13, 2013, 02:51:45 PM
http://www.stringfunction.com/hex-decimal.html
http://www.calculatorpro.com/calculator/modulo-calculator/

Block #257748 hash in decimal: 227538544328062966004888208644466284604660868282826408848828

227538544328062966004888208644466284604660868282826408848828 mod 12222 = 196

Line 196 is:         BN_clear_free(this);


Can you comment a bit on this line of code, please?

BN_clear_free(this);   // sets the memory for the bignumber to all zeroes and frees the memory, thereby saving many trees and dolphins in the process.
2  Bitcoin / Development & Technical Discussion / Re: What's new in version 2 of Block header message ? on: September 05, 2013, 06:13:07 PM
Anyway, this is not an information we can rely on.

I notice many blocks pretending to be version 2 but showing bad height encode values

See
http://blockexplorer.com/block/00000000000005d024e86337ca13439b7f3dbd5e1a005b1dbe510150d45b6e98 is block 200433 and pretends to be 436591499
http://blockexplorer.com/block/00000000000003c6947e260dc80d6ab426771a7ba9d8d5fb58ff66a0db26c361 is block 199914and pretends to be 436591499

May be such blocks must not be accepted by the network as the BIP34 is now enforced?

After block 227930, it's information you can rely on.
3  Bitcoin / Development & Technical Discussion / Re: transfinite turing machines and paramagnetic states on: September 04, 2013, 06:04:31 PM
You're probably thinking of Fourier. Wink

It was actually my little way of announcing to the world that I have no clue what I'm talking about Tongue
4  Bitcoin / Development & Technical Discussion / Re: transfinite turing machines and paramagnetic states on: September 03, 2013, 06:28:26 AM
A quick study of Cantor, Goedel and Turing as well as a consultation of high school physics tells us that when we read/write from hardware, we are in essence instantiating or else transmuting the "paramagnetic states" for each magnetic spin. All this talk about ASIC computing is good and all, but we hardly see people in the community talk about simple RISC architectures. People hardly ever use ALL 32 bits, even on an average machine, and it's due to the mathematical physics principles of these magnetic states.

Since the Halting problem hasn't been solved yet and a computational system CAN simulate physical hardware in these paramagnetic states, you only need ONE daemon which can interface with OpenCL, where OpenCL provides the interface between the CPU/GPU. All the other load balancing and cryptographic functions are taken care of by gcc.


Edit: Compare solving an object called "block" with downloading pieces of a torrent file. You don't necessarily need 100 peers connected over the protocol to download an entire file, sometimes you can get the job done with just 10 peers in the same amount of time.

A quick study of Calvin, Hobbes and Watterson tell me that a transmogrification apparatus could perform the required adjustments and transformations relatively quickly/
5  Economy / Service Discussion / Re: Bitcoin Charts Web Site Contact on: September 03, 2013, 12:04:51 AM
Could just be a server setting to not waste time/cpu compressing a relatively small payload.

Or it could just be configured not to compress dynamic content.

Anyway - I dunno any contact info, sorry Smiley
6  Economy / Service Discussion / Re: Bitcoin Charts Web Site Contact on: September 02, 2013, 09:27:20 PM
Does anyone know how to get in touch or get the attention of the guys at Bitcoin Charts?  I have noticed that the json being returned from their API is not using gzip encoding and therefore consuming more bandwidth than necessary.  If I could talk to them about enabling this it would reduce the bandwidth used by the users of my Android App Bitcoin Prices and also decrease their bandwidth.

I have tried emailing info@bitcoincharts.com about this and with other suggestions in the past but I have never had a response.  If anyone here could put me in touch with them I would greatly appreciate it.

Thanks, J


I just looked:  It's gzip'ed for me.

What are you using to make the API request?
7  Bitcoin / Development & Technical Discussion / Re: Address stats on: September 02, 2013, 03:47:38 PM
Can the length and first character or characters be changed in an altcoin address?
(E.g addresses such as 123345 could be generated)

Altcoins could make whatever they wanted

If they want a Base58 address, then they can change the first byte, but no more, unless it's a vanity address.

First byte = version byte.  First byte doesn't necessarily equate to first character - depends on the first byte they choose - it's the version byte.

See: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
8  Bitcoin / Development & Technical Discussion / Re: What's new in version 2 of Block header message ? on: August 31, 2013, 03:49:39 AM
Yeah - At block 227930, the previous 1000 contained the supermajority of 950.
9  Bitcoin / Development & Technical Discussion / Re: Sipa's secp256k1 for .NET! on: August 28, 2013, 10:22:42 PM
No guards, no nothing, that's correct. but you could write a nice little C# wrapper for it. Smiley

Just for the fun of it, would you mind running your .dll through reflector to get a peek at the generated code?

Sure, but why me? Tongue

Ok, I used ILSpy.

Here's Sign(..)

Code:
/// <summary>Signs a message and returns the signature.  Returns null on failure.</summary>
/// <param name="message">The message to sign.  This data is not hashed.  For use with bitcoins, you probably want to double-SHA256 hash this before calling this method.</param>
/// <param name="privateKey">The private key to use to sign the message.</param>
public unsafe static byte[] Sign(byte[] message, byte[] privateKey)
{
if (message == null || privateKey == null)
{
throw new ArgumentNullException();
}
if (privateKey.Length != 32)
{
throw new ArgumentOutOfRangeException(Signatures.PrivateKeyLengthError);
}
if (message.Length != 32)
{
throw new ArgumentOutOfRangeException(Signatures.MessageLengthError);
}
int messageptr_3D_cp_1 = 0;
int keyptr_46_cp_1 = 0;
byte[] nonce = new byte[32];
byte[] nonceptr_59_cp_0 = nonce;
int nonceptr_59_cp_1 = 0;
byte[] signature = new byte[72];
byte[] signatureptr_6A_cp_0 = signature;
int signatureptr_6A_cp_1 = 0;
int signaturelen = signature.Length;
byte[] privateKey2;
for (int x = 0; x < 1000; x++)
{
Signatures.Randoms.Value.GetBytes(nonce);
int result = <Module>.secp256k1_ecdsa_sign((byte*)(&message[messageptr_3D_cp_1]), message.Length, ref signatureptr_6A_cp_0[signatureptr_6A_cp_1], &signaturelen, (byte*)(&privateKey[keyptr_46_cp_1]), ref nonceptr_59_cp_0[nonceptr_59_cp_1]);
if (result == 1)
{
if (signaturelen == signature.Length)
{
privateKey2 = signature;
}
else
{
byte[] smallsignature = new byte[signaturelen];
Array.Copy(signature, 0, smallsignature, 0, signaturelen);
privateKey2 = smallsignature;
}
return privateKey2;
}
}
privateKey2 = null;
return privateKey2;
}

And here's Verify

Code:
/// <summary>Verifies that a signature is valid.</summary>
/// <param name="message">The message to verify.  This data is not hashed.  For use with bitcoins, you probably want to double-SHA256 hash this before calling this method.</param>
/// <param name="signature">The signature to test for validity. This must not be a compact key (Use RecoverKeyFromCompact instead).</param>
/// <param name="publicKey">The public key used to create the signature.</param>
public unsafe static Signatures.VerifyResult Verify(byte[] message, byte[] signature, byte[] publicKey)
{
if (message == null || signature == null || publicKey == null)
{
throw new ArgumentNullException();
}
if (message.Length != 32)
{
throw new ArgumentOutOfRangeException(Signatures.MessageLengthError);
}
int messageptr_27_cp_1 = 0;
int signatureptr_30_cp_1 = 0;
int keyptr_39_cp_1 = 0;
int result = <Module>.secp256k1_ecdsa_verify((byte*)(&message[messageptr_27_cp_1]), message.Length, (byte*)(&signature[signatureptr_30_cp_1]), signature.Length, (byte*)(&publicKey[keyptr_39_cp_1]), publicKey.Length);
int signature2 = result;
Signatures.VerifyResult message2;
if (signature2 != -2)
{
if (signature2 != -1)
{
if (signature2 != 0)
{
if (signature2 != 1)
{
message2 = Signatures.VerifyResult.Error;
}
else
{
message2 = Signatures.VerifyResult.Verified;
}
}
else
{
message2 = Signatures.VerifyResult.SignatureFailed;
}
}
else
{
message2 = Signatures.VerifyResult.InvalidPublicKey;
}
}
else
{
message2 = Signatures.VerifyResult.InvalidSignature;
}
return message2;
}
10  Bitcoin / Development & Technical Discussion / Re: Sipa's secp256k1 for .NET! on: August 28, 2013, 02:00:47 PM
Should anyone care, I use the following. Saves you from needing a managed C++ project:

Code:
...

It's probably a little bit slower when signing a transaction because of the pinvokes when looping to find a correct nonce, but other than that, it's pure C# instead of managed C++.


Edit: actually, now that I looked at the code a bit closer, this is just as fast, if not faster than the managed C++ version, since it's calling managed and unmanaged code in the loop, so it needs to do a pinvoke in the loop too.

Managed C++ is a fickle beast, you never know where it goes managed or native (those transitions are murder). At least with the code above, you know for certain when it happens.


Every call into one of the C++ methods I provided does 1 native call, so there's 1 transition per call.... unless you count a call into the RNG.  Same with the p/invoke code you posted. 

Your p/invoke is awesome Smiley  It'll work just as good as my library.  Just be careful.  I made the C++ library so that I could write "guard" code around the calls.  ie: make sure keys/signatures/messages are the right length (if not, they cause access violations), handle the nonce so I don't screw it up elsewhere, etc. If you don't need all that junk, then cool Tongue
11  Bitcoin / Development & Technical Discussion / Re: Measuring the protocol version (client/node) share on: August 27, 2013, 10:39:16 PM
Hi all,

In regard of growing interest and the involvement of more and more political parties.

Chances are that within the next few months and/or years we'll be seeing controversial philosophical/political changes being proposed to the protocol that will take effect at a later date or only in specific circumstances. The good thing is, that it's free for everyone, from the miners to the individual nodes, to decide whether they are running it.

There will be campaigns trying to convince the >50%.

Some questions:

  • Is it possible to measure how divided the installed Bitcoin-software versions actually are?
  • We already have a wide range of versions of clients and full nodes running. How would we know exactly which source is dominant and which percentage share the other software clients/nodes have?

You wouldn't want a growing share of a 'dangerous' versions of the protocol (distributed by a party whos ideas you don't agree with) and only notice it when it's too late.

For example: Let's say The Bitcoin Foundation decides to implement a version where miners get 25BTC for another 4 years, instead of 12,5BTC to "keep the economy going". And I believe this is absolutely the wrong thing for Bitcoin so I want to sell all my bitcoins if this becomes the bigger network. How would I know whether I should do this?

Well first, there's no way to know for sure.  There's a user-agent string passed during handshake.  But I could change it to whatever I want.  example:  /BananaBread:1.0/... Or I could just set it to be the same as the mainline client, or anything else for that matter, and you'd never know whether I was actually using the client I say I'm using.
12  Bitcoin / Development & Technical Discussion / Re: How does the Blockchain store so many records without being too big? on: August 27, 2013, 02:35:38 PM
How does the blockchain store a record of everything without being so large as to require scientific notation to denote it's size?

Mostly sorcery.

...That, and it's not exactly like there's a huge amount of data yet.  Most transactions are 1k or less? 
13  Bitcoin / Development & Technical Discussion / Re: Transactions with input & output count == 0?? on: August 27, 2013, 11:55:01 AM
Quote from: TierNolan
Heh, true.  Are 0 input/output transactions actually valid.  I thought at least 1 input and 1 output was mandatory (or 0 inputs for coinbase).  You can have 0 valued outputs though.

Meh.  According to spec, no, they're not valid.  But they get serialized fine, it's just nothing happens with them.

Quote from: TierNolan
Have any actually ended up in the block chain?

No.

Quote from: sebastian
2: Malwritten clients, when served with a amount to send = 0 BTC by the end user (propably by mistake, user simply forgot to enter amount), do not validate that the clients amount exceed 0 Before attempting to create a transaction. When the client attempt to create the transaction, it finds out that theres no need for inputs anymore ("do until"-loop) because the amount has been fulfilled. And theres no outputs to add, because the client automatically deletes any outputs with amount=0.
Then it ends up with a "empty" transaction, and sends the "empty" transaction.

...All sounds good.  except... ZOMG ZE END OF ZE WORLD!@@!   A "DO UNTIL" LOOP?#^%#$^)   kill me now%!##  I'm having flashbacks to my pascal/delphi days lol




....And Piotr, wtf is a "correct horse battery staple" input Smiley  besides my favorite xkcd reference, that is Tongue
14  Bitcoin / Development & Technical Discussion / Transactions with input & output count == 0?? on: August 26, 2013, 05:21:57 PM
I've been receiving "tx" messages across the wire with 0 inputs and 0 outputs.  Literally the payload is 10 bytes { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 }.  (Version = 1, 0 inputs, 0 outputs, LockTime = 0)

Any idea what those are all about?  It's just occasionally.  Do they have special purposes or are they just a misbehaving client?
15  Bitcoin / Development & Technical Discussion / Re: Grease Payments to Miners on: August 25, 2013, 04:11:42 AM
They could send the transaction using an ANYONE-CAN-PAY signature type.  But I don't know of any software which makes those kinds of transactions.  But it would allow you to add additional inputs, even if the transaction was already fully-funded.

It's probably not what you're looking for.
16  Bitcoin / Development & Technical Discussion / Re: Sipa's secp256k1 for .NET! on: August 24, 2013, 01:59:07 PM
Isn't cryptology different than cryptography?

Only when you take the SHA256 hash of it.
17  Bitcoin / Development & Technical Discussion / Re: Sipa's secp256k1 for .NET! on: August 24, 2013, 01:45:26 PM
But true, there's definitely no beating a hand-tuned optimized C/assembly implementation of anything!

I should add, this isn't just a hand-tuned, optimized implementation of general ECDSA signature verification:  it's hand-tuned and optimized for the specific elliptic curve that Bitcoin uses (secp256k1).  The curve is actually one of the simpler ones blessed by NIST, and sipa is an optimization ninja Smiley 

People who actually understand cryptology are like the evil chess grandmaster james bond villains.
18  Bitcoin / Development & Technical Discussion / Re: Sipa's secp256k1 for .NET! on: August 23, 2013, 02:01:17 PM
Pssh.  It was .NET bouncy not Java Tongue

PS there's no "interpreting" going on after being compiled.  Don't bash on JIT compilers Cheesy  C# = Savior of the uniprogrammiverse!

But true, there's definitely no beating a hand-tuned optimized C/assembly implementation of anything!

19  Bitcoin / Development & Technical Discussion / Re: Sipa's secp256k1 for .NET! on: August 23, 2013, 12:54:45 PM
Yeah - ...Sorta Smiley  To be fair, it ranged from 200-1100ms on bouncy. 
20  Bitcoin / Development & Technical Discussion / Sipa's secp256k1 for .NET! on: August 22, 2013, 10:19:14 PM
https://github.com/joshlang/Secp256k1.NET - A managed (.NET) wrapper around Sipa's secp256k1 implementation.

I only threw it together a bit more than an hour ago, so obviously I haven't thoroughly tested it Smiley  But so far I've verified blocks up to 77700 with it and its working just fine.  78100 now.  78200!  ...Geez it's fast Smiley  SIPA = INCREDIBLE.

If anyone finds any issues or has questions, feel free to get in touch.


EDIT:  HOLY MOLY.  100,000 VERIFICATIONS in 9.8 SECONDS!
EDIT AGAIN:  ...ON A SINGLE PROCESSOR!(@!1(&!(!(@!$(&#@!%
EDIT ONCE MORE: ...Doh, I think it caches results.  That test was verifying the same signature over and over again.  On the blockchain, signature verifications are taking about 10ms on average.  Still 100x faster than Bouncy.
EDIT FOR LIFE LIBERTY AND HAPPINESS:  Without a debugger attached, I'm easily getting <1ms per verification with Sipa Cheesy
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!