i think we have fath for gold because it is unique on this planet,different from any other metal.
No it's not. Platinum is close in value and usage to gold. Gold is just used as currency because it's shiny, hard to mine, and easy to verify that it's actually pure. Sounds like something you know? PS: Gold is not even the most expensive metal. That honor goes to platinum-190, at around $1 billion per ounce. |
|
|
|
What do you mean, Bitcoin itself doesn't have addresses? A recipient in a tx is nothing more than an address, right? Regardless of how we represent it, but I mean it's not an actual public key or something.
Not always. There's either a pubkeyhash, or sometimes a pubkey - which is indeed an actual whole public key. E.g. the bitcoin miner when you solo mine adds a simple '<pubkey> OP_CHECKSIG' check in for the coinbase tx and doesn't use the hash. If you look at all of the initial blocks in the blockchain they're all like that for the coinbase tx, but it appears later as well. |
|
|
|
Recognize that it is not an address that holds a coin, but a transaction output. Most transaction outputs refer to an address, but this is not part of the protocol, but a convention that applies to the vast majority of transactions.
Consequently the client can have money that is not associated with an address.
The client owns those coins (transaction outputs) for which it is able provide input such that the associated script evaluates to true. This means for an output that looks like a regular pay-to-address that it has the private key for a public key that hashes to that address. You see the criteria for ownership of an address is more narrow than having a valid EC point (public key) for an address, but is also much wider in general.
I agree from a purist perspective. You should never assume money is yours unless you know for sure you can supply input that will satisfy the script. But is that what clients (like bitcoind) actually do before it claims ownership and display it as a balance in your wallet? It's much easier (and faster) to just hash down the OP_CHECKSIG pubkey to an address and see if it matches one in your wallet, so I can imagine that there would be a lot of software that takes this shortcut. |
|
|
|
|
Thanks.
For those crypto experts, is there a danger here? I assume a lot of software isn't going to check it either and just allow it.
EC is hard enough - I can't even begin to imagine the consequences of returning a point that's not on the curve. Does it just mean there is no private key? Or is there an infinite number of private keys?
The other issue is the address that it hashes to. I think that remains secure, but it now has an almost infinite number of more inputs that it used to if it just allowed points on the graph.
Is it possible/any easier to send money to a person's address, but give it an off-curve pubkey CHECKSIG that hashes to the same address but that they would in fact not be able to spend?
i.e. If a client doesn't validate the pubkey, yet still hashes it to an address, can it be tricked into thinking that it has money which it really doesn't have?
|
|
|
|
It's an output, and it's unspent. Bitcoin blockchain rules do absolutely nothing with the content of scriptpubkey until its spent.
Argh. Can I at least complain that blockchain.info reduced that to this address: 1EXpM1kseQJSudJEhMUT1SGzNrGtJADjp4 That address doesn't and can't exist - they just skipped the EC point validation. It should have said something like 'invalid key' instead. I was on a wild goose chase for quite a while thinking BlockChain.info is correct and my formulas were wrong. Didn't help that I was looking at the number in decimal and binary and didn't realize it was hex-represented pi  . EDIT: Just saw decoderawtransaction on bitcoind does the same thing. Also hashes down an 'address' without validation. Sigh. |
|
|
|
The following block: https://blockchain.info/tx/c94f41c1177b22ffff461808e62e31b3211352c78b6d550d445583c721eb48caHas a OP_CHECKSIG on n=1 for: 0431415926535897932384626433832795028841971693993751058209749445923078164062862 089986280348253421170679821480865132823066470938446 Taking out the '04' uncompressed form marker, and you've got yourself pi to 128 digits. (Sort'a. That's really a hex number. Whatever.) Not surprisingly, it fails the elliptical curve equation (and had me swearing at Bouncy Castle all night). How did this make it into the blockchain? |
|
|
|
It's not a duplicate transaction, the miner just assigned the outputs of the each of the mined blocks to the same address. No, it really is a duplicate transaction. Allowing this was a bug in the Bitcoin protocol. It's no longer possible for one transaction in the block chain to make another transaction in the same chain unspendable. However, a single transaction can still exist in more than one block if the older copy is completely spent before the newer transaction is added. Thanks for the answer! Is it legal for the second transaction to have different vins and vouts? i.e. When you say "a single transaction can still exist in more...", is it basically legal for a new transaction to just re-use any old (spent) transaction ids, or must the second transaction be identical to the first? |
|
|
|
How does the following happen? https://blockchain.info/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599This same transaction occurs as the coinbase transaction for both block 91812 and 91842. It hasn't been spent, but it's obviously not spendable from both blocks. So one of the mined blocks actually did not get any reward. I can imagine 1 miner screwing that up but I would have thought additional confirming miners would have thrown out the duplicate transaction, no? Is this a common occurrence that we need to take into account, or is it a weird anomaly? Obviously blockchain.info coded around that, by allowing the same transaction to be displayed in 2 blocks. |
|
|
|
The main benefit of using pay-to-pubkeyhash is that it allows for much shorter addresses (since a RIPEMD160 is much shorter than a pubkey); other than that it takes slightly more time and space than pay-to-pubkey. When mining, you don't need to share the address you're mining to except in the coinbase transaction itself, so there's no reason not to do it the slightly simpler way. (Historically, the reason is that pay-to-pubkey was originally the standard transaction type). The only benefit I can think of to mining to a pay-to-pubkeyhash instead of is the theoretical situation where a serious vulnerability in secp256k1 has been found; receiving via pay-to-pubkeyhash doesn't reveal your pubkey until you're in the act of spending from that address, and allows less opportunity for someone to crack your key. Of course, no one expects that to happen any time soon.
Thanks. That makes sense. So in Bitcoin I found that consistently older blocks are pay-to-pubkey and newer ones are pay-to-pubkeyhash. In Mazacoin however I find these randomly all over the place. Is it now generally the state of the world that pool software all use pay-to-pubkeyhash and individual -qt clients all use pay-to-pubkey? (I noticed all my solo-mined Mazacoin blocks are pay-to-pubkey for example). |
|
|
|
I was wondering how does a pool split this computationally difficult task into smaller tasks while at the same time preventing any individual miner to claim the reward if he happens to be the one hitting the correct solution?
The 'puzzle' that is solved contains, among other things, the Coinbase transaction that will assign the reward to the pool's address. It the miner happens to solve the block himself, and instead of submitting it to the pool, he submits it somewhere else, it wouldn't matter since the pool is going to get the reward regardless. And if the miner goes and modify the Coinbase transaction to assign the reward to himself, he will have to computed a new block hash... which, if you could do that, you should just always do that in the first place and skip the pool  . And if he ALWAYS changes the Coinbase transaction to assign the reward to himself "just incase", the pool will reject all his shares, and he wouldn't get any reward until he solves the block. Then might as well solo mine. It's pretty ingenious if you think about it. Was it Slush who invented it? Either way, hats of to whoever did. |
|
|
|
|
To TAKEICOIN devs.
You tried. It failed. Don't give up.
Please launch a new SHA256 coin - it is a great re-use of old BTC resources. You can still contribute to a good cause without violating his trademark.
|
|
|
|
TAK will have an extremely important update on Sunday - To Be Continued...
Launching 1 TAK per month giveaway program to any miner mining 10 consecutive blocks in a row! |
|
|
|
|
Selling for 3 Satoshi.
1m+.
|
|
|
|
|
A friend of mine (cough cough) may or may not have a whole bunch of Antminers S1's.
What is the best way to manage them? (Hypothetically of course).
If you want to e.g. move all of them to a different pool, it's an absolute nightmare to manage via the UI, logging into each miner, changing the settings etc. Same if you want to see which ones have x'd out ASIC's and need to be rebooted.
Was fun at first, but no.
Is there some sort of SNMP like management plugin available for micro-farms consisting of small miners like these?
|
|
|
|
If you used the pull requests I linked, I hope you split the reward you offered between the author and the people that have been rebasing it to keep it pull-able.
Not following you. Did you perhaps reply to the wrong thread? |
|
|
|
Remember about NSA? they can crack about anything,can enter/hack into almost anything
No they can't. If you look at all the Snowden releases, the NSA has tremendous reach and intercepted things that is shocking and disturbing. However, none of what they did was technically complex. It just requires a lot of money, power, and boots on the ground. Virtually none of what they discovered was done by physically breaking encryption - it was open phonelines, emails, unprotected servers, snitches, co-operation from telecom companies, co-operation from companies that release encryption software to introduce backdoors for the NSA etc. "Remember this: The math is good, but math has no agency. Code has agency, and the code has been subverted." - Bruce Schneier |
|
|
|
Until yesterday the average Joe was thinking that the CEO of Bitcoin went bankrupt, now the news are they found the founder. I'm sure a lot of people will be mind boggled Not only that, the CEO of Bitcoin was also found dead under mysterious circumstances. |
|
|
|
Ok, Now with all the talk about malleability. What is the proper way to make payments from a program with bitcoin-qt ? If one wants to make automated payments and be able later to track down the transaction what is now the current best practices to do that? Should one still just do: sendtoaddress <bitcoinaddress> <amount> Returns the transaction ID <txid> if successful. txid is usable with bitcoin-qt or totally unreliable? The value you got from sendtoaddress can change to something else in bitcoin-qt? Some say that you should keep the timestamp. How do you get that? And will the value be exactly the same on blockchain.info, or do you have to look around and find a transaction that has roughly the same value? Some say you should keep input addresses. How to get that? Better to use raw transactions? But it seems more difficult and requires a lot of manual work. And what to do if a transaction does not go through. -Just wait more? sendtoaddress will keep the transaction active in the net until it eventually goes through? Yes, it's much better to use raw transactions. It seems more difficult at first, but it's not. It's just a bit of a learning curve. Start from here, and send a few things to yourself (make sure you understand how change works, otherwise you're going to pay large transaction fees). https://people.xiph.org/~greg/signdemo.txtI've started doing everything using raw transactions now (even in the client when I'm just paying for my own stuff - debug window, createrawtransaction). The first one was a head scratcher. The second one was a bit easier. Third one dead simple. Now, it's like - why doesn't everybody just do this, it makes things so much more obvious? Once you only deal in raw transactions, the way to solve the malleability problem is trivial: Look for the TxId/vout that you're spending from to show up in the vin of any new (raw) transaction on the blockchain - that's your transaction. If it wasn't molested, it will happen to match your originating TxId. You won't rely on that anywhere though, so that would just be a nice coincidence. And if someone complains the funds didn't show up - just point them at the transaction that finally got accepted in the BlockChain. HOWEVER, just another attack vector to consider (even if it doesn't exist today). Even if you don't see your original Transaction, AND you don't see the TxId/vout spending pair in another transaction on the network, STILL don't just go and directly refund the money to whoever complains that their transaction never showed up. Maybe an attacker managed to really get your transaction excluded from the blockchain and is holding it back until after your refund. Maybe there is a new attack vector that nobody discovered yet. To be sure, instead re-spend the original Transaction(s) to your own account, wait for a whole bunch of confirmations, and then only re-initiate a new spending out. That way you're using the miners to go and validate on your behalf that everything is still fine with the world. So in that case if an attacker DID manage to hold back or somehow mutate the transaction, he would now just be holding a double spend that will get rejected. |
|
|
|
This essentially means that any old unencrypted backups of the wallet.dat file are useless.
No, your understanding is wrong. The Encrypt wallet isn't a function of the blockchain, it's a function of the local wallet. The encrypted wallet just lets you use your live wallet a bit more securely. If you still have an unencrypted backup of that wallet around, it's still as vulnerable as it ever has been. Similarly, if you lose a USB stick containing an unencrypted wallet, you cannot suddenly mitigate the damage by taking a backup file and encrypting that. |
|
|
|
|
Show Posts
