|
Many of the languages listed are not functional, or are, at best, barely functional. For example, you'd have a hell of a time writing a functional exchange in C++, but writing an objected oriented exchange would probably be fairly easy.
|
|
|
|
Ok, it is just that I didn't know. Thanks for the explanation. Is it possible to choose which address I want to send from in Bitcoin-Qt? Is it possible to see address balance there? (not only the total balance in the main tab).
Coins do not come from addresses, and addresses do not have balances. Please see any of the other approximately 9000 threads on these subjects. |
|
|
|
Any collection of 256 bits is a private key. For best results, use a high quality source of random bits. Also, those things that start with a 5 are called WIFs. They are used to encode the binary private key in base58check. https://en.bitcoin.it/wiki/WIFNote that if you are doing this for real, you'll need to read up on public key point compression. |
|
|
|
|
1. The node uses whatever criteria it wishes to use when building the block. The reference client prefers fees first, but tends to also include a few free transactions of high priority. Also, (approximately) no one uses the reference client to build blocks for mining.
2. Depends what you mean. Different orderings will give different merkle tree hashes, so the header calculated for a given ordering is only valid for that one ordering. But as long as the block matches the header, all valid* orderings are acceptable to the network.
* There are validity rules specific to order: The generation transaction must be first, and the first transaction must be generation. If transaction B spends transaction A and both are in the same block, A must come before B. Why are these in a footnote? I consider the generation transaction to not be in the permutable set, and UTXO->A->B in a single block is rare and unusual.
|
|
|
|
I reposted, If you could sign message with the address you send such high transaction fee, you might get some tips, but I doubt about the 20 BTC
how's this: -----BEGIN BITCOIN SIGNED MESSAGE----- This is aliens_exist_1 of the 20 bitcoin tx fee sob story. I posted my story on reddit here http://www.reddit.com/r/Bitcoin/comments/1t1nvl/i_accidentally_sent_a_brainwallet_transaction/-----BEGIN SIGNATURE----- 1Jt35Ww1GjM9iGyTM8mAyBmCPPdPz7Z35A G2GI3yhycdNoQqJQgFr+JvRsq2eSnNuKiLnRl5ZoD0JJpgBKPzKKA1JC9+uQRH1uMEg3webgh+tBQO/ihoSw4uc= -----END BITCOIN SIGNED MESSAGE----- Is that pseudo-PGP ASCII wrapper common now? |
|
|
|
A number of replies are coming from people who feel the need to disprove something I'm not arguing. I pointed out that their is NO CRYPTOGRAPHIC SECURITY FEATURE that controls the scarcity of BTC, THAT IS ALL! Joel was spouting BS when he implied their was and while peons on this forum will say that blithely a hundred times a day I find it detestable that someone who knows how to program makes the same mistake.
You go off your meds again? He implied no such thing, no matter how many times you repeat it. Bitcoin's scarcity is guaranteed by mathematics.
Which math?
int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees;
}
|
|
|
|
|
It is a fine distinction, true enough, but we are talking about whether or not an intangible idea can be destroyed or not...
|
|
|
|
I reposted, If you could sign message with the address you send such high transaction fee, you might get some tips, but I doubt about the 20 BTC
This. There's no way to proove you are that guy, though I sure wouldn't admit to that! Signing the address that sent the 20BTC fee would prove that you are that fool. People here call fake beggers scammers, so that would shut them up. What does it matter? The address here in the thread corresponds to the key that signed the errant transaction. |
|
|
|
My father locked his wallet. The BTC address he is using is tied to an Electrum client wallet. We recently updated his Electrum client and that program removed all the old receive addresses and made up all new ones. The obvious question, how do we work around in getting his payout address changed if it is locked? If the answer is you cannot change it (which is what I think it is), he would have to create a new account or something, correct? Since he would be unable to continue to use his original Electrum address.
I'm still waiting for the Electrum devs to answer on where all the receive addresses went to after the update. All the transaction history is still there, and even in the details of the transactions you can see the original BTC address, just don't know how to get the originals back.
I don't know Electrum, but I have a hard time believing that they'd throw away the keys to old addresses. Try doing a manual payout that is small enough that you won't be upset if it vanishes into a black hole. |
|
|
|
...and people who've been mining on p2pool all year have made something like 12% more than they expected
How the heck is it possible to calculate that? Is this a sampled figure? you can calculate the total number of hashes in the year and the expected number of blocks. You can then count the total number of blocks actually found. You do that, and you get +12%. How do you calculate the total number of hashes in the year? Aren't you just estimating this from the number of blocks/shares found? What is really calculated is the number of hashes you'd have to perform to have a good chance of finding the same number of (different) blocks at the same difficulties. That's cumbersome to say, so most people just shorten it. Or they are confused. Either way, when you see people say things like that, you need to expand it to the full phrase in your head when you read it. |
|
|
|
G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Red - encoding marker. 04 = x then y. 02 = x only, y has even parity. 03 = x only, y has odd parityGreen - XBlue - Y |
|
|
|
Way back on post #5 gmaxwell explains it pretty well. Again, it is possible to solve this problem by other approaches. For example via MAIN_CHAIN_MIN_POW as suggested above - it does not compromises decentralization. We know when Bitcoin was released, we know current date - we can calculate upper bound for block count in any chain. When somebody tries to send us old chain - we ask it to sent block headers sorted by difficulty, starting with the most expensive one and continue in descending order. 1% of top block headers should have at least 0.01*MAIN_CHAIN_MIN_POW accumulated difficulty, if it is not - then it is fake, else continue, and so on. Cool. When can we expect your patch? |
|
|
|
I totally agree, but those addresses are special corner cases. They are in a class all by themselves and it would be pretty hard to argue that 1BitcoinEaterAddressDontSendf59kuE belongs to the same class as those two addresses, right? If you go by Kolmogorov complexity, all zeroes and all ones are the two minima, but the bitcoin eater is much closer to them than it is to "normal" addresses, or even to the best vanity addresses found so far. |
|
|
|
Way back on post #5 gmaxwell explains it pretty well. Yes, you are correct. They are there so some quantum computing farm (doesn't exist, but...) can't come out of nowhere and roll back blocks by mining a long chain from far in the past. Thats not really what they're for— though that have the effect too. Most of their usefulness is that they prevent a dos attacker from filling up bitcoin node's disk space with long runs of low difficulty blocks forked off low in the chain. e.g. you start off with difficulty 1 blocks at block 0, now mine-able by the millions by a single asic— _MAYBE_ a chain that starts off that way could eventually turn out to be the longest so absent the checkpoints a node would happily follow an endlessly long chain of them. They also make is so that an attacker who has complete control of your network (and thus can prevent you from hearing the longest chain from the honest bitcoin network) from putting you on a fake (low difficulty) isolated chain unless they can also trick you into running replaced software. With the checkpoints such an attacker hast to have a ton of mining power in order to continue the chain. |
|
|
|
Saying we "hope" is exaggerated; it is like saying Bitcoin users are just hoping nobody generates their private key and steals their coins thus the whole Bitcoin network runs on "hope". Cryptography is always based on probabilities however we use really really reallly really really large numbers so the probability of certain events approaches 1 or approaches 0 but never is known to be 1 or 0 before the event. In theory I could randomly bang on my keyboard right now and produce a private key which allows me to impersonate Google's SSL cert on the first attempt. It "could" happen but Google doesn't really need to "hope" it doesn't happen because while the odds are not 0 they are for all practical purposes ~0.
The difference is that an address derived from a key is known to have a matching pubkey and a matching privkey. If we ignore physics and math, someone searching all possible private keys will find at least one that matches the address in my signature, eventually. Will they also find a key that can spend the bitcoin eater? How about the key to 1111111111111111111114oLvT2 or 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr? No one knows. Those last two should make you pause, and that is why I consider coins sent to them to have a higher level of destroyedness than bitcoins sent to addresses for which the key has merely been lost. Of course I think the best way to sum it up is that if I ever notice funds are transferred out of the "Bitcoin Eater" address I am selling coins first and asking questions second. It is a good canary in the Bitcoin mine.  Indeed. |
|
|
|
Bitcoin is decentralized. And no small group of people should decide which branch is correct and which is not.
Checkpoints hardcoded in code were selected by small group of people.
But if Bitcoin is still claimed to be decentralized, not controlled by government, small group of people (who can be blackmailed, or forced by thermo-rectal cryptanalysis) - then only majority of users should have right to make decision.
Users should vote on which branch is correct and which is not. Bitcoin already has such voting mechanism - vote by computing power.
Of course hidden fork crunched at high speed in shadow is unlikely, and maybe checkpoints do not harm due to low probability of such fork.
But they harm in other way - they compromise Bitcoin decentralization, which is in my opinion is the biggest attractive feature of Bitcoin.
Today they add checkpoints, tomorrow they could freeze BTC on your address, by adding small tweaks to validation routine (just like checkpoints validation).
Checkpoints add almost no value - they do not prevent offensive usage of high computing power, but they trading off fair amount of credibility.
Nobody except majority should have control over blockchain, and Bitcoin's definition of majority is computing power.
Otherwise users must know that blockchain is controlled by small group of human being.
You didn't actually read this thread before posting, did you? |
|
|
|
Coinjoin will be worthless in court. Your case is not going to prosecution when the sole evidence is a bitcoin transaction. Instead, that transaction is going to be used as the basis for collecting gobs and gobs of further evidence. At that point, the coinjoin isn't going to help you in court, it is going to hurt you, since it will be evidence that you knew what you were doing was wrong and tried to bury the evidence. What??? Aaaa, sorry - I forgot that you guys are form US. In your courts words like "wrong" or "evil" are the daily bread You've spent a lot of time in our court system, have you? I was speaking informally, but the point remains. Covering up the evidence of a crime never looks good. You rarely hear "wrong" used in the moral sense here, and about the only time you'll ever hear "evil" is during closing arguments and victim impact statements prior to sentencing. |
|
|
|
IMHO, it is rather a legal advise to use a plausible deniability in a possible legal cases against you.
...
CoinJoin does not give you any additional anonymity. At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.
Coinjoin will be worthless in court. Your case is not going to prosecution when the sole evidence is a bitcoin transaction. Instead, that transaction is going to be used as the basis for collecting gobs and gobs of further evidence. At that point, the coinjoin isn't going to help you in court, it is going to hurt you, since it will be evidence that you knew what you were doing was wrong and tried to bury the evidence. We need massive large scale joining for two reasons. One, if joining is routine, then you doing it isn't going to be evidence of wrongdoing anymore. Two is to muddy the waters for mass surveillance. Right now, it is nearly trivial to trace transactions back and forth until it lands on a discoverable point. Assume for the moment that the NSA has total visibility into some exchange's HTTPS traffic and can see every deposit address they provide to users. When your chain of transactions lands on one of those addresses, the FBI knows they just need to request the customer info for whichever account uses that address, and they've got you. Now imagine the world with coinjoin. Your coins break up and land in a dozen joint transactions. From there, each one hits a dozen more, and a dozen more, and so on. Now there are thousands or millions of things to track, and almost all of them will not be yours. |
|
|
|
I believe that given there will be on average 296 public keys per Bitcoin address we can be fairly certain there is at least one public key that hashes to any given address, including this one.
You are assuming a uniform distribution in the output of the hash functions. This is something that we hope is true, but don't really know. |
|
|
|
|
The problem with this thread, and the many others like it, is that definitions get pulled out of asses, and it turns into a fight over which rectal definition is right.
I urge you all to read some actual published works from proper economists that have worked on this problem and see how they use the term.
|
|
|
|
|
Show Posts
