|
A transaction is very little more than two lists. The first list is previously unspent transactions that are now being redeemed as inputs to the current transaction, the second list is new outputs that will be available in the future.
Note that being unable to specify multiple outputs means that change is impossible and you'd only be able to spend if you had a set of inputs that summed to exactly what you wanted to spend.
|
|
|
|
|
Is someone holding a contest to see how many ignores an account can pick up in a short time?
|
|
|
|
|
You need an ECDSA library for PHP. There is one available, but it doesn't have the curve we use. The constants are in the NIST guide.
Once you decode and verify the base58check encoding, you'll be left with 256 bits and an optional 8 bit flag.
The public key is made my multiplying he base point of the curve, g by the 256 bit private key. The public key is a point, two 256 bit numbers.
If the optional flag was not found while decoding, the public key encoding is chr(4) . $x . $y. If the flag was found, it is chr(2+($y%2)).$x.
From there, you hash the public key encoding, first with SHA256, and then with RIPEMD-160. Run that through a base58check encoder, and you have the address.
|
|
|
|
|
New-ish Intel CPUs have the RDRAND opcode that appears to be suitable for generating high quality random bits.
|
|
|
|
I don't know dude what about the fucking great depression? It's hard for me form an informative argument when you lack a basic understanding or education on the topic. Seems like the length of your understanding is regurgitating things you sought out with the intent of proving the thing you already believed.
Seriously, the great depression argument. You are on a bitcoin forum you should already know why that is unconvincing. Sorry, go read more papers and books, this time think critically about what they say and perhaps go read opposing points of view to get some ideas of why your claims are not accepted by others as "axiomatic". Only bitcoiners and internet libertarians think there is no Data. You're going to get more Data exactly the same as every example of what deflation causes and then ignore that too. Can you guys stop feeding this troll? He's already devolved the conversation to name-calling, you won. Ah yes anyone who interrupts the echo chamber must be a troll. Dude, grow up. These forums have a thousand threads on the deflation topic. You've added absolutely nothing to the debate. What was missing was not one more person repeating the premise. You will get nowhere by claiming that you don't need to make any arguments because your opinion is "axiomatic". Also, the great depression came after the federal reserve system was launched. Since the federal reserve's entire purpose for existing was to insulate banks from the negative effects of the inflation that they were causing, it seems a bit silly to claim that as a data point against deflation. |
|
|
|
Thanks for your reply, makes some sense now. Now can you explain this tx to me: http://blockexplorer.com/tx/f742aed8d29fbe102c48b0a6107acaf27e95244ca891150b367c0b6b2ac7f808Clearly when having received coins many times to the same receiving address, when one sends all those coins to a new address, there is a need to reference all the pieces of coins that piled up into that address. The blockchain repeats the exact same input address like 8 times to show where the whole balance came from in all its pieces. And why sign each of the 8 inputs (see script sig column on right, same pubkey, dif sigs) So, why does that sending address need to sound out where its balance came from and in each and every amount added? Take a look at the first "previous output" who's hash begins 7fba. That tx, which is the source of the 0.587.... btc was 50k blocks ago. Why trace it back so deeply? Again, couldn't the block chain just keep a running tally of all the output addresses with unredeemed coins on them (unspent outputs, aka "balances"). And only retain the input addresses and amounts for a period of time till they were buried under a few hundred blocks? Maybe i totally misunderstood all this. But what i see is extraneous information. The only need for these records is so that a person can import a wallet.dat on a new machine and d/l the whole block chain and then see all the tx's he sent and received from his addresses from day one. But we don't need the blockchain to do our bookkeeping, why have all that data and where the coin balances or individual unspent outputs came from? Doesn't his just inflate blocksize Again, there are no addresses. There are no balances. We make those up so that we can think more easily. At risk of repeating myself, I'll say again, in answer to all of your questions, bitcoin operates on transactions. Also, if you think about the idea of passing around lists of keys, consider for a moment that there may be more keys than you care to track or pass around every 10 minutes. How would you optimize that? Would your optimized version look like a list of transactions? |
|
|
|
can someone recommend a robust motherboard that would be suitable for solo mining with 3 avalons?
Avalon does not plug in to your motherboard. You set it for a pool. You can run your own pool and solo mine, with basically the same motherboard requirements as running bitcoind. i understand that. i'm trying to setup a solo mining server to point my avalons at as in here: https://bitcointalk.org/index.php?topic=162788.0Anything relatively current should work then. CPU speed is important, don't buy a Celeron or otherwise crippled CPU. Also, I can't recommend AMD at this time, but I was comparing a mid range Intel CPu to a mid range AMD CPU, with a decent price difference. I use 3770Ts since they were reasonably cheap, low-ish power, and include the RDRAND opcode that you probably don't care about at all. I run bitcoind, namecoind and p2pool on boxes with 16 GB RAM, using tmpfs for everything. I also use pxeboot for everything, but that is a plug for a different thread. |
|
|
|
can someone recommend a robust motherboard that would be suitable for solo mining with 3 avalons?
Avalon does not plug in to your motherboard. You set it for a pool. You can run your own pool and solo mine, with basically the same motherboard requirements as running bitcoind. |
|
|
|
::)There are still uses for outdated ASICs....by mining litecoins instead.
Yeah, except no. |
|
|
|
In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.
Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.
If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.
As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.
Do you see the problem now?
Dude i'm really having trouble understanding what in tar-nation you mean by this. Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them? Solidifying Gavin & co's benevolent dictatorship? You are new here.* Over time, you'll learn to discern 2112's pearls from his effluent. In this case, KFC's secret recipe is widely available for everyone to see, and both Coca-Cola Coin and RC-Cola Coin already exist, putting this post solidly in the latter category. * Yes, I know you registered around the same date as me. Not important. |
|
|
|
After how much time two 0-confirmation double spend transactions are deleted ? Or are they persistent for ever waiting to be picked up?
Transactions don't have a proper validity window. They do include a "not valid before" field, which is almost always set to zero. This means either "around the first moon landing", or "early 2009", depending on your point of view. But they do not include a "not valid after" field. The protocol does not define what a node does with transactions that aren't valid. This includes transactions that are waiting to become valid, as well as transactions that are invalid because they attempt to redeem an invalid input, for whatever reason. Since the protocol does not define it, each client is allowed to retain or discard transactions as the authors see fit. I may be wrong here, but I believe that the client which is currently the most popular discards transactions more-or-less at random if a new one comes in that would exceed the size of the buffer set aside for such things. |
|
|
|
I'm reading thru the satoshi white paper and i can't figure out a few technical points about how btc transfers value between addresses:
Lets say i start out with 25 mined coins sitting on a address. That address represents the hash of the public key associated with the private key sitting in my wallet. Now when i originate a tx to send 10 coins to a new receiving address i take the amount, and the receiving address and attach a signed message of those two and transmit that to a miner. how can the miner verify that signed message if he can only see the hash of the public key? Doesn't he need the whole public key, or is there some neat trick of cryptography going on here?
Also, if i send the next 15 coins to the same address later, the blockchain will retain the sig file for that tx as well. right?
So, when a tx is sent from that receiving address for 20 btc to a yet another new address, both "tokens" are then presented in the next block with a new sig right? I think they are called unspent outputs right? And 5 btc is then broken into yet another token as being sent back as change. (to a new address? or the sending address)
I don't understand why the blockchain doesn't simply keep track of the unspent balances. The input sig history should only need to be maintained until the blocks go deep enough that we are certain of the chain we are on (several days). All the tx's before these "recent blocks" can just be referenced by a much smaller table of output address carrying the total balances of all the coins they received. What's wrong with this?
Where does the need to have a complete history of all the sig files for all the fractional transactions comes from?
I am approaching this from the perspective of asking, what is the point of all this "extra" information. Why can't btc just track agreed upon balances on each address?
I highlighted the part where you first go wrong. There are no addresses, not really. Bitcoin operates on transactions. In step 1, you redeem the whole 25 BTC, not part of it. As for the public key vs. hash part, it works like this. You sign using your private key, and you include your public key with the signed transaction. So long as we all believe in ECDSA, we can verify that the public key that you provided matches the private key that we understand you to control, despite having never seen it. But why do we accept your public key as genuine? Because we can hash the pubkey and check to make sure that the pubkey provided matches the address (really an encoded pubkey hash) provided. |
|
|
|
Bitcoin already has an expert mode, and has had it for a while now.
It does ? I dont't see an "EXPERT MODE" button with a big, red, scary warning ( YOU MIGHT LOSE UR MONIES !!!!!!!!!) anywhere. How do I enable it ? Debug console. The warning is replaced by the fact that using it is hard. This indeed. Documentation can be found here. |
|
|
|
|
Bitcoin already has an expert mode, and has had it for a while now.
|
|
|
|
Are you using >= 0.8 without the -txindex option? See the release notes. |
|
|
|
|
Why not just parse them out of the files directly?
|
|
|
|
Can somebody please confirm something for a slightly confused noob:
Assuming I have a private key written down in old "uncompressed" format, does it matter whether I send BTC to the compressed or uncompressed public address? Funds sent to either are still controllable by the single uncompressed private key?
Or must I be sure only to send funds to the "uncompressed" public address, otherwise I lose the funds?
You can take a WIF of either format, add or remove the compression flag, and re-encode back into a WIF. The raw private key is just 256 bits of data, usually random. For example: 19fdab0668a2586da7bea56410c814b83be86a956bb8565aea78651c174bfc04
That private key corresponds to a public key with these coordinates: x: 82c3cb548fdfd632f622db534badc9dd6d68bf65cacc3297df4686ff8a8d83b2
y: df70ca968a53fc29e4163401eb953b49961b0539341b54748001c83c48f952d3
There are two ways of encoding that public key. One way is 0482c3cb548fdfd632f622db534badc9dd6d68bf65cacc3297df4686ff8a8d83b2df70ca968a53fc29e4163401eb953b49961b0539341b54748001c83c48f952d3
The other is 0382c3cb548fdfd632f622db534badc9dd6d68bf65cacc3297df4686ff8a8d83b2
These two encodings have different hahes, so their addresses are 1Nt6XLmq8k8noafGGFdfwue74uJTFu9vQC and 13pRRXkGVC9mhUSiw6xkYkMi1EX91VvsBE. If your program understands compressed keys, it should tell you something like: Private Key: Kx6EWgKRJ2GZuXbrDquQPAE8MWZLLdsT4YYgQs4hdF7rRL4jGLHx
Bitcoin Address: 13pRRXkGVC9mhUSiw6xkYkMi1EX91VvsBE
If it doesn't understand compressed keys, it should say: Private key: 5J1jV2CspMgKnS4N7zJJz8Xcej3Lngcu89WP53jXW4CXEGF9M3A
Bitcoin Address: 1Nt6XLmq8k8noafGGFdfwue74uJTFu9vQC
If you run those WIFs through a base58 decoder, you'll find: 8019fdab0668a2586da7bea56410c814b83be86a956bb8565aea78651c174bfc0401902f231b
8019fdab0668a2586da7bea56410c814b83be86a956bb8565aea78651c174bfc046ddddd0d Green is the prefix byte for a WIF. Red is the compression flag. Blue is the check code. Black is the actual private key. So, the private key you have written down can be used for two different addresses, but it might take some doctoring to get it into a format that your wallet can import correctly if you are using an address that doesn't match the WIF encoding used. |
|
|
|
FYI, this is the format used by vanitygen 0.22 when you specify -e. I had a hell of a time sorting out how to decode them, thought this might help someone else. I'm using PHP, but PHP is easy to read. I'm using an external PBKDF2 function. If you use the function included with newer PHP versions, you may need to adjust the parameter order. The mcrypt_cbc() is old too, check with the PHP manual for updated information, or use phpseclib. The $input value is the raw base58coded string. My base58decode function returns the binary output without verifying the check value. If yours checks it before returning, you can skip that part. The output value is either -1 (bad 58 check code), -2 (wrong password), or the private key as a raw binary string. <?php
function keydecrypt($input,$password){
$data=base58decode($input);
$style=substr($data,0,1);
$params=substr($data,1,1);
$ciphertext=substr($data,2,32);
$pwcheck=substr($data,2+32,8);
$salt=substr($data,2+32+8,4);
$code58=substr($data,2+32+8+4,4);
$check58=substr(hash("sha256",hash("sha256",$style.$params.$ciphertext.$pwcheck.$salt,TRUE),TRUE),0,4);
if($code58!=$check58)return -1; // Invalid 58 check code
$key=pbkdf2("sha256",$password,$salt,4096,64,TRUE); // 4096 is iterations, 64 is output length
$cipherkey=substr($key,0,32);
$iv=substr($key,32,16);
$hmac_key=substr($key,48,16);
$unprot=mcrypt_cbc(MCRYPT_RIJNDAEL_128,$cipherkey,$ciphertext,MCRYPT_DECRYPT,$iv);
$hmac=substr(hash_hmac("sha256",$unprot,$hmac_key,TURE),0,8);
if($hmac!=$pwcheck)return -2; // Invalid password
return $unprot;
}
?>
If using phpseclib, use this instead of the mcrypt_cbc call: <?php
require_once("Crypt/AES.php");
$cipher = new Crypt_AES(CRYPT_AES_MODE_CBC);
$cipher->setKey($cipherkey);
$cipher->setIV($iv);
$unprot=$cipher->decrypt($cb);
?>
|
|
|
|
Wow. Just, wow.
If this is not a joke, then it's a huge step forward for bitcoin.
I assure you, it's not a joke. The next step is for a municipality to step forward and ask us (E-Gov Link) to enable Bitcoin payments. And so if some citizens contact their local city hall / town hall / township / village hall administrator, and say "hey, why don't you accept Bitcoins", then maybe the progressive ones will give us a call. Feel free to direct them to the press release and to our website. http://www2.egovlink.com/press-release-bitcoin.cfmMy question is this... Why do you wait for them to ask for it? Did each government entity have to approve Visa, MasterCard and Discover individually? Or are you not converting the payment into dollars internally? |
|
|
|
|
Show Posts
