Your session has timed out? Maybe this link would be more useful. Don't worry, it won't hold up. Federal courts have repeatedly ruled that generic terms can't become trademarks. If this Michael is as wise as the last one, he'll abandon it too, and do so before opposition proceedings start. |
|
|
|
|
Ditto. Not a peep from Avalon, but walletbit did confirm my order.
|
|
|
|
|
Just don't post in long dead threads, regardless of who started them or posted in them. Basic courtesy, not a cult.
|
|
|
|
Sweet! Now time to start calling Offical Payments and bugging them about accepting bitcoins too. I would love the "can't pay your taxes with bitcoins" line to die a quick and horrible death. |
|
|
|
Because BTC is actually propping it up?
From what I see BTC is mainly traded in Dollars... just like Oil.
If Oil wasn't traded in $ it would not be as strong. That's why the US don't like Iran as they trade in other currencies.
The notion of oil purchases propping up the dollar price would totally make sense, in a world without FOREX. |
|
|
|
The network is on v2 blocks right now, but those blocks are fully compatible with old nodes, as long as those nodes are not providing work to miners. v2 blocks look totally normal to pre-v2 nodes, but non-v2 blocks look different to v2 nodes. Not true. An old node that doesn't know about the 95% changeover rule won't realize that any v1 blocks it sees now are invalid. In principle this can be the basis for an attack. Yes, but someone has to generate non-v2 blocks faster than the network is generating v2 blocks. Translation: same attack has existed since day 1. |
|
|
|
Maybe not only the Staoshi client should have an option to hide the balance.
o show balance
o show balance after click
o show balance after password
All clients have the balance as the most prominent feature which is bad in a face to face trading situation.
The rubber hose always wins. Hiding your balance means that you have something to hide. If the guy was going to rob you when he sees your balance, you should also assume that he is going to rob you when he sees that you hide your balance. If you are putting yourself in physical danger, use a different wallet, one that only has the amount needed for the current trade. |
|
|
|
That wasn't a hard fork as only miners had to upgrade. Not quite. All non-mining full nodes had to learn about version 2 blocks first, and the rules about when version 1 blocks would no longer be valid before the miners were required to change. The hard fork started when clients which understood the changes were released and finished earlier this week when the 95% threshold was reached. Sufficiently old clients which might still be operating either can't see the most current branch of the blockchain or else can be fooled into accepting an invalid block. Uh, no. You are confusing two completely different things. The network is on v2 blocks right now, but those blocks are fully compatible with old nodes, as long as those nodes are not providing work to miners. v2 blocks look totally normal to pre-v2 nodes, but non-v2 blocks look different to v2 nodes. For example, I still have a pre-0.4 node running. It had no problems with the v2 transition. The recent fork was something totally different. |
|
|
|
|
Keep in mind that neither of these last two links directly address the original question, as far as I can tell. I didn't re-read the whole paper, but I don't recall it giving a count of generation transactions outstanding.
Also, with multi-output generation transactions (p2pool and others), the notion of "untouched" gets a little less clear. I suppose you could add the outputs individually...
|
|
|
|
Heh. Autorun.
Also, why do you assume that you have total control over what gets written?
Because you load whatever CD-writing software you prefer, then you manually add the transaction file. The disc must be blank in order to write to it, and unless the malicious code has also compromised your burning software, only what you specify to be written will be written. And once it's written, the disc is physically unwritable. Is this not currently the best method to transfer the transaction files thus far? How about it, etotheipi? Not just the writer software. Also the driver, the host interface driver, the driver's firmware, the host interface's firmware, the BIOS, etc. If we are assuming a clever attacker, we have to assume that one or all of those is owned. If we aren't assuming a clever attacker, then there are WAY easier ways to move files around. I still prefer the serial port approach. If a getty is running on a serial line, then armory won't be able to open it. And if armory can open it, then the getty can't run. If armory is the intended use, then the problem will be apparent soon enough. For extra paranoia, we could make an armory distro with a stripped down inittab. Hell, add a SE policy to disallow anything but armory from opening /dev/ttyS* |
|
|
|
|
Heh. Autorun.
Also, why do you assume that you have total control over what gets written?
|
|
|
|
|
Just out of curiosity, does that transaction show up in the bitcoin-qt ledger?
|
|
|
|
I wonder, why they didn't just pick a different first byte, like 0x81, or whatever makes a good base58-start.
There's little use for a wallet to import a compressed key when it doesn't yet know how to handle it correctly, and those that do know how to handle it, could easily check for a second prefix on import.
If the system processing the WIF doesn't understand compressed keys, it'll complain that it found 264 bits when it expected 256. Or it should. At any rate, it's been a while, the old software should be updated if it doesn't understand. You should pretty much always do compressed keys for new generation. There is no reason to ever use uncompressed keys, at least none that I'm aware of.
Brain wallets are by convention uncompressed. While I can now (with help of your answer) create a compressed key from a passphrase and import that into my wallet, I might have a hard time to reconstruct it later for another wallet when I don't have my scripts at hand. Also, vanitygen doesn't seem to search for vanity compressed keys (at least not the version I've got here). Unless you are computing EC multiply, SHA-256 and RIPEMD-160 with pen and paper, you are going to need tools either way. Using uncompressed keys causes a modest, but real, bloat in the blockchain and should be avoided whenever possible. Uncompressed keys offer absolutely no advantages over compressed keys, require no more special knowledge to process*, and take no extra effort to create. If there is some convention around using uncompressed keys for brain wallets, that convention needs to be die quickly, like a year ago. May I suggest that the convention change to "create compressed, redeem both compressed and uncompressed"? The private key is exactly the same in both cases, only the bitcoin address changes, and there are only two possible, so the redeeming system should have no problem checking both of them. The author of vanitygen has been ignoring requests on the forums for compressed key support for over a year now. I still have no idea why, since it should have very close to zero impact on key generation speed. * Well, I guess you have to remember "0x02=even, 0x03=odd" instead of remembering "0x04=magic", but that is close enough to nothing for me. |
|
|
|
Is there a tally of "unmoved" Bitcoins (never moved after they were mined) somewhere?
Well, the data is in the block chain that everyone has. I think some people pay attention to the early generation transactions and would mention it on the forums if they started moving, but I don't think I've ever seen an actual list or chart. |
|
|
|
what utter bull, mitty
I didn't see a single thing wrong with what he said. because you're both some brainwashed neoliberal **** wtf? |
|
|
|
Is there any way I can cancel them and resend them with the fee attached? probably not eh?
Not easily, no. But it looks like the amounts were pretty high, so they should be fairly high priority. Even if it was easy to remove the transactions and retry, it would probably still take longer than just waiting. |
|
|
|
You had bad timing. 20130327 103840 - 000000000000020ac70bbb8dad72073710a35d8fd0274f774f5efe1cde95b085
20130327 114035 - 000000000000002d01ceb1224d0aaa1feebebbdbbc1035e9fe2a87cf060699b8
20130327 114332 - 000000000000021c8ea416cd4c2faadd542e905b55d3e577e976776f3618dfb6
20130327 115043 - 000000000000023bc9543c9b4368b330e721298a9050b2df109f71613fcba12b
20130327 125534 - 00000000000001da79fdd3ca6730f466f4823edacf1d00c6ca3bf0f1e2413e06
20130327 131723 - 000000000000002fd7ca83970e6248a3639af9d34166dda080b0c7c83d9ba21b
20130327 132321 - 000000000000011dc7eacca2c18ff2390103da40dce651f5194abfd34544c946
These are date, time (central US) and block hash for the last 7 blocks. See that two of them have 1+ hour gaps? When that happens, transactions pile up in the mempools, and miners tend to favor fees over no fees, so it may take a while to clear the backlog before anyone includes yours for free. |
|
|
|
I understand it the way that once the amount of bitcoins at an address is changing the timer starts. So once you have paid in the 144BTC and you want to transfer it another way then you have to pay a fee.
Just to clarify, if I have a lot of dust, say 10 different addresses got 0.00001, and it has been only a few days, I can't "add" to those 10 addresses some BTC (like 144 BTC, for example), wait for 1 block, then transfer all those coins to another address? In order to consolidate all my dust?
Do you mean, each prior output is separate even on the same address?
The priority is based on the sum of value*# confs for each output that is being redeemed. To clean up small coins, you just need to redeem them in the same transaction as a large/old transaction to boost the priority. You don't need to send coins to the same address or anything like that. |
|
|
|
|
There is an option in your account settings to have that box checked by default.
|
|
|
|
So when you want to import a private key, the software has to know which of the public keys (with corresponding address) should be used. The solution is to add a flag bit to the base58 encoding of the private key, notifying the importer whether or not to use the compressed public keys. Typically, these get called compressed and uncompressed private keys - but it's really just a bit saying whether the corresponding public key is compressed or not.
Thanks for the explanation. Being in progress of writing my own library for BTC-stuff, I tried to "feed" it a compressed key (from my wallet) and an uncompressed key from vanitygen, and I got a leading (hex)"80" octet for both. The number from the compressed key was 8 bits longer, though. Depending on the length (essentially the "ceil(log_2(N))" ) appears a bit fragile to me, for the decision if the decoded priv-key is intended as a compressed or uncompressed key. Is software expected to check for leading 5 or L/K on the base58 string, or did I miss some sound discriminator within this larger N (maybe check it against the order of G in secp256k1 ?) If I intended to create a "compressed-key brain wallet", what do I have to do with the shaČ-output (before doing the chksum+base58 stuff) to get a priv-key that I could import into a standard (sufficiently new) wallet? Unfortunately, the bitcoin wiki-page about WEF-encoding priv-keys doesn't mention compressed keys. (hoping that you still have this thread monitored...) The private key is always exactly 256 bits, or 32 bytes. The exact same private key corresponds to two different public keys. One is uncompressed in the form of (x,y), and the other is compressed in the form of (x,p). The two forms have different representations, and thus different hashes, and thus different addresses. The compression flag just tells the system which of the two possible addresses to use. You should pretty much always do compressed keys for new generation. There is no reason to ever use uncompressed keys, at least none that I'm aware of. So, to create the WIF, suitable for importing later, you take the 32 byte binary private key, prepend the 0x80 bytes, and append the 0x01 flag for compression, then run through base58encode and the output is the WIF. For reference, to create an uncompressed WIF, just don't append the 0x01 before encoding. To create the matching address, calculate the public key as usual, but when you go to encode it, check the parity of Y. If Y%2 is even, encode it as 0x02 + x. If Y%2 is odd, encode it as 0x03 + x. (Uncompressed, it would be 0x04 + x + y.) Note that I'm using + to mean concatenation here. Then the address is created as usual. If you need to accept WIF as input, after the base58decode step, you'll always have 33 or 34 bytes. If 33 bytes, it is uncompressed, and the private key is the 32 bytes after the 0x80 header. If 34 bytes, it is compressed, the last byte must be 0x01, and the private key is everything between the 0x80 header and the 0x01 compression flag. Once you have the private key and know whether the compression flag was present or not, you can calculate the public key and address as above. |
|
|
|
|
Show Posts
