Show Posts
|
Pages: [1] 2 »
|
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.
|
|
|
After block 227930, it's information you can rely on.
|
|
|
You're probably thinking of Fourier. It was actually my little way of announcing to the world that I have no clue what I'm talking about
|
|
|
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/
|
|
|
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
|
|
|
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?
|
|
|
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
|
|
|
Yeah - At block 227930, the previous 1000 contained the supermajority of 950.
|
|
|
No guards, no nothing, that's correct. but you could write a nice little C# wrapper for it. 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? Ok, I used ILSpy. Here's Sign(..) /// <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 /// <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; }
|
|
|
Should anyone care, I use the following. Saves you from needing a managed C++ project: 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 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
|
|
|
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.
|
|
|
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?
|
|
|
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. Have any actually ended up in the block chain?
No. 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 besides my favorite xkcd reference, that is
|
|
|
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?
|
|
|
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.
|
|
|
Isn't cryptology different than cryptography?
Only when you take the SHA256 hash of it.
|
|
|
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 People who actually understand cryptology are like the evil chess grandmaster james bond villains.
|
|
|
Pssh. It was .NET bouncy not Java PS there's no "interpreting" going on after being compiled. Don't bash on JIT compilers C# = Savior of the uniprogrammiverse! But true, there's definitely no beating a hand-tuned optimized C/assembly implementation of anything!
|
|
|
Yeah - ...Sorta To be fair, it ranged from 200-1100ms on bouncy.
|
|
|
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 But so far I've verified blocks up to 77700 with it and its working just fine. 78100 now. 78200! ...Geez it's fast 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
|
|
|
|