|
I know it works just fine in bitcoind, and I don't think that bitcoin-qt opens any different files, so I don't think it would be a problem.
|
|
|
|
|
Probably because headroom is useful too. It means that 64 bit accounting systems, for example, can be exact even when dealing with values many times larger than the bitcoin market cap.
|
|
|
|
A 64 bit int can hold the entire supply (8 decimals in all) in one integer, 8,700 times over. 4 more decimals could be added and still almost hold the entire supply in one int64 (18.5 vs 21 with a bunch of zeroes). If you limit the left hand side, you could go much further than 4 more decimals.
But why would you do that? Changing the way you interpret the integer is what breaks everything, not the size of the field. If you are going to make the change, make the change big. |
|
|
|
Requiring a hard fork to add extra decimal places is a significant, breaking change to the bitcoin protocol and should not be taken lightly or assumed to be part of the specification.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
Fair enough. In any event, it's difficult to imagine 8 decimal places not being sufficient. I still don't understand why it isn't possible to always be able to add one more decimal place to the right. The protocol currently uses integer math. Values are 64 bit. If I send 1 BTC to myself, in the transaction that shows up at 100,000,000. In other words, the fundamental unit of the system is 1/100,000,000 of a BTC (commonly nicknamed "one satoshi"). The software does all math in terms of satoshis, but displays BTC to the user by scaling. I sorta suspect that we'll switch to a 128 bit representation for technological reasons (wider CPUs) long before we need more digits for economic reasons. Such a switch would give us some combination of more headroom and more dividing room. It would also require a more-or-less hard fork. |
|
|
|
Except that this idiot thinks that people are holding dollars for trade. FOREX takes less than a second. If you want to make a major purchase, like a tanker full of oil, with dollars, but you don't have any, modern electronic currency trading allowed you to buy dollars and execute the trade in less time than it took to read this sentence. Hell, by the time you were done with that sentence, the guy that you bought your oil from turned his dollars into whatever it was that he really wanted too. Trade is not a "demand" on dollars that changes the price to any practical extent. Only holding dollars does that. |
|
|
|
A wallet with a single unspent output is certainly not optimal.
It doesn't take that much coinage to be considered high priority.
Take a user with 20 BTC. Lets assume it is all in a single output and old enough to avoid low priority fee.
He spends 8 BTC gets 12 BTC back as change. He now has to wait ~24 BTC hours or 2 hours before he can make a second tx without fee.
Compare that to a wallet same 20 BTC but in two 10 BTC unpsent outputs. He can spend 8 BTC using one output and then seconds or minutes make a 2nd tx of up to 12 BTC without pay a fee.
Yes, that's what I pointed out; because of coin age priority, one coin is not optimal (unless you got over 144 BTC in your wallet) That's why I think coin age should not be a reason to pay a fee. The whole blockchain would be a lot more efficient, if people had their wallet filled with new big coins instead of a lot of small old coins. This might be important when pruning works.. Once pruning comes around, miners will probably adjust their priority schemes to prefer transactions that have more inputs than outputs. My wallet is full of smallish transactions from p2pool. I'm working on a script to use the raw transaction API to sweep gobs of those into larger single transactions. Getting the balance right is tricky. |
|
|
|
Well I unzipped the file which gave me blk0001.dat and blk0002.dat. I downloaded fresh copy 0f 0.6.3 and started it, stopped it straightaway. I went to the hidden .bitcoin folder and deleted all files apart from wallet.dat. Put the blockchain down and started bitcoin-qt up again. It starts downloading from block 0 again! Seems like it is appending all the blocks to the end of blk0002.dat which is growing bigger in size. There was no blkindex.dat in the repository. Have I just wasted me bandwidth for nothing. Oh and another thing, if I'm having such tremendous difficulty, how is Granny Smith or Frederick Bloggs-Jackson going to be coping I wonder  Yeah, you wasted your bandwidth for nothing. You can't use these files the way you want to. If you are trying to avoid having your client download all of the blocks, you need the blk000?.dat files and the blkindex.dat, taken from a clean DB detach and copied at the same time. You should let your client download the chain the long way, or at the very least manage your blockchain distribution yourself so that you know it is right. (If you really want to download a working chain, there are some out there if you look.) |
|
|
|
Maybe before, but right now a typical txout in a generate looks like: "out":[
{
"value":"50.24250000",
"scriptPubKey":"OP_DUP OP_HASH160 740ecaf436d5867903c722d783fc994c25a29b15 OP_EQUALVERIFY OP_CHECKSIG"
}
]
Hmm. I checked latest bitcoin code looks like it is still paying to public key. Are you sure this coinbase output is generated by bitcoind not some pool's modification? Yup, blocks generated entirely inside the standard client do indeed push a key and OP_CHECKSIG. But, I don't think that many blocks end up in the chain using the standard client's CPU mining capability or getwork RPC calls. Maybe I'm wrong about that, but none of the random blocks that I clicked on in blockexplorer a while back were built using just the key and OP_CHECKSIG. And of course, as soon as I type this out, I click on a block from Slush, and sure enough, it is using key + OP_CHECKSIG. So maybe it isn't quite as rare as I thought. Maybe I'll turn my spare GPUs to cracking ECDSA when I convert to ASICs. |
|
|
|
Maybe before, but right now a typical txout in a generate looks like: "out":[
{
"value":"50.24250000",
"scriptPubKey":"OP_DUP OP_HASH160 740ecaf436d5867903c722d783fc994c25a29b15 OP_EQUALVERIFY OP_CHECKSIG"
}
]
|
|
|
|
Lockheed is setting up a Silk Road for their heroin trade in Afghanistan.
lol, I wouldn't be suprised I wouldn't be surprised if SR is run by a US government agency. 10% of every transaction adds up, and soon you own a majority of the BTC in existence (with a goal to keep those coins out of circulation). Easy way to kill it, if you're willing to wait for a slow death. Nah, governments never do anything useful. And taking a huge mass of bitcoins out of circulation would be very nice of them as well. I'd pay extra taxes this year, with a smile on my face, if they were really doing it. |
|
|
|
I tried to grab a ton of info from the USB key, with the write protect in both states.
idVendor 0x0b27 Ritek Corp.
idProduct 0x0165
Thank you very much. Ritek Corp. device 0x0165 is not on my shortlist of known fraudulent devices. (Fraudulent meaning: fake encryption plus maybe fake write protect and other misrepresentations.) I'm disappointed. I thought you were going to tell me how to override the write-protect. You've got me wondering how difficult it is to do it... On another note, I just ordered a male-male analog TRS cable (double-ended headphone jack). I determined that the audio coupling is now 100% perfect once you connect the headphone-out to mic-in with such a cable. The SNR should be fantastic, and if both sound cards sample at 44.1 kHz there's a lot of room to get at least 1 kB/s, which would make me happy. That's assuming that I can transmit and receive signal amplitude reliably. I don't have much experience with it, but I look forward to digging into it in the kind of near future. (I just ordered a couple double-ended audio headphone cables... whatever they are called...) The downside, is that if the user's online computer is their primary computer, they will be inconvenienced by having to swap their speakers around all the time. On the other hand, they can always get an extender, and keep both ends on their desktop, and just lean over and switch them when needed. Recommendations welcome! I always get nervous plugging a stereo headphone output into a computer microphone jack. The ring is connected in different ways in those two systems. In the microphone jack, it is usually tied to a current limited +5v source. In the headphone jack, it is a nominal +/-1V output. I haven't seen any get burned out, but I don't like connecting them together. Mono plugs are no better, since they have no ring, just a sleeve all the way to the tip insulator, which means that they are shorting the +5v bias to ground in the microphone, and the right channel output to ground in the headphone jack. I actually did that exact same thing tonight, took the PA output from a device and plugged it into a computer microphone jack. Worked just fine, actually, but I did spend a bunch of time in Radio Shack looking for an adapter that would let me leave the right channel and microphone bias floating. (No luck, the stereo to dual mono Y adapter didn't split tip/ring like a sane person would expect, it tied both to both.) But, yeah, you can totally transmit binary (mark=tone/space=silence) this way. Hell, you could probably even do fancy stuff like FSK or QAM. FSK is super easy to send, somewhat less easy to receive. QAM is less easy to send, and much less easy to receive. Are you going for bidirectional over two cables? If so, you can just pretend to be a modem, but without the messy shared channel. Start slow, handshake, then crank up until you start getting NAKs. If unidirectional, start slow-ish, and give the user a button to "stop and try slower". Have the receiver indicate errors fairly quickly, and make sure you can get it back into a start-able state ASAP. You can probably even find DSP libraries if you don't want to mess around with coding and signalling. |
|
|
|
|
This is for an analyst, an intelligence analyst. Exactly the sorts of people that need to keep track of potential new twists in the great game.
The good news is that Bitcoin got first billing and SL got second billing. Hope it wasn't just alphabetical.
Oh, and you can be sure that the Company will be using bitcoin extensively, just as soon as it is big enough for them to hide in.
|
|
|
|
I realize it takes time (way too much time, TBH). But during that time period, the state of the orderbook should be locked. Order execution should be fully atomic.
agreed, why to they allow orders to be pulled out of the way of 1 major buy? theirs no reason it should "take time" to lock the books and fill orders, for 1 big buy. its just a few numbers being moved around. i dont get it.... Exchanges are super easy, everyone knows exactly how they should work. Until they actually have to write one and they find out that things can get strange quickly. |
|
|
|
|
In the unlikely event that secp256k1 is ever totally broken, there is still the hashing problem to deal with.
As in, even if someone can find the private key for every possible public key, most public keys aren't known, only the RIPEMD160(SHA256(public_key)) is in the blockchain, unless you re-use addresses, which everyone has been warned not to do.
|
|
|
|
|
If you are on the internet, the odds are VERY good that your entire notion of money is as bookkeeping, rather than something physical. Cash is something that you use despite the inconvenience in the few cases when you must use it, it is not your default.
Bookkeeping is very easy to undo, and we all grew up in that world. The shift to bitcoin is huge, and we all have a lot that we must unlearn.
|
|
|
|
Seems interesting, will it be bitcoin lending or money printed out of thin air backed by pseudo bitcoin lending??
Well, they can't actually distribute more actual funds then they have on deposit. They can credit accounts with more, but the overage can't be all withdrawn at the same time. This is sorta how fractional reserve got started. Goldsmiths noticed that their depositors rarely asked for their gold back, so they could lend it out. And eventually they noticed that the people they lent it to also left it in the warehouse and just traded the receipts, so their practical limit for lending wasn't the amount they had on deposit, but the amount likely to be asked for all at once. And we never learn, so that could totally work still today with bitcoins. What I think will save us is that hauling physical gold around is a chore, but hauling bitcoins around is not. Thus, hopefully banks will lend out only a fraction of what they have on deposit, rather than a multiple. |
|
|
|
I don't know where to post this, so here it is :
are there any concerns about something like Y2K syndrome ?
are miners supposed to change something in their code ?
will the number of btc per block be the only thing that will change ?
one risk is the majority of pools not adhering to the rules "make block reward 100 BTC instead of 25 BTC" might something the "syndicate" could decide... bitcoin would drop to 0.0001 USD in no time, though. This is why I highly doubt a majority of pools ops would do such a stupid thing. More importantly, the rest of the network would reject those invalid blocks. |
|
|
|
|
You could make your own live distribution that has the serial getty lines properly disabled in the inittab...
|
|
|
|
You may think that the drive you use has a hardware write protect. But somebody who can read the Chinese or Russian documenation to the controller IC used therein will know that you are just couple of ioctl() calls away from disabling the write protect and enabling the USB CD-ROM drive functionality.
This. True hardware write protection doesn't really exist, and never has, outside of rare special hardware. It is always soft write protection. |
|
|
|
|
Show Posts
