What is the difference between saying that will be 12,000 mBTC (where total # of mBTC is 21 billion) and saying that will be 12,000 BTC (where total # of BTC is 21 billion).
Right now things are priced in BTC because most items are full and fractional BTC (i.e. 200 BTC, 1.245 BTC). If the value of BTC rose to a point where 1 BTC was worth say $832 most items would be priced in mBTC.
"How much for that new Steam game?"
"24 mBTC".
Here's the difference: we are building a new currency called Bitcoin, not mBitcoin. Will you enforce a way for merchants to display prices in bitcoins? mBTC? uBTC? Look at how the prices are displayed everywhere; do you see prices like: this item costs 723 pennies, or here, big offer on the new car, only 22543650 m$. There are reasons why the decimal point is used the way it's used and I've already touched upon some of them. Enforce? Who would have the power to enforce something like that? The presumption is that vendors will mostly follow SI. |
|
|
|
I'm personally going to be very careful about dealing with securities. The SEC could get (easily) involved and that would get messy fast.
With a distributed record of ownership, a lot of things become possible. TOR-hidden exchanges, brokerages, and dealers, for example. And person to person transactions, which I'm almost positive are totally legal. |
|
|
|
Hmm. Looks like the wiki is out of date then. By the way, I'm sure that this was discussed at the time, but this seems like a really odd way to resolve the ambiguity. |
|
|
|
No, only one of both is used. There is no point is having both: which address/pubkey is used, is decided at key generation time, and only one address is ever exposed. There is no reason to expect payments to an address that was never given out.
But when you import a private key, the WIF doesn't tell the client which of the two (or maybe three*) addresses has been used with it. * Is the hybrid format also valid? |
|
|
|
|
Hmm. That's interesting. That means that the wallet has to keep track of both versions, and it has to be ready to use either one to redeem txouts. Or at the very least, it has to when importing a private key.
|
|
|
|
Bitcoin is not decentralized. It is actually very centralized. Bitcoin is not just the network and the protocol. Bitcoin is also about mining. A coordinated action in just 24 hours can shut down a dozen mining pools and that will be the end. In the original paper Satoshi talked about CPU mining, not GPU mining. Technically the weakest point is not the exchangers but centralization of mining activity!
Yes, you are right. The people that have invested their time and money in mining rigs would never think to try pool # 13, or p2pool, or solo mining. |
|
|
|
Well, there is really only one public key for a given private key. The two forms are just different expressions for the same thing. We start by picking a private key k which is just a 256 bit integer. Then we multiply (EC multiplication, not regular) a defined base point on the curve by k. That gives us a point on the plane, two 256 bit integers, x and y. (x, y) is our public key. It turns out that if we know x, we can almost calculate y pretty easily. I say almost calculate, because there is a square root, so we find two possible values for y, one positive and one negative. So, we can "compress" the public key by giving x, and the sign of y, 257 bits instead of 512. (In practice it is 272 vs 520, but whatever.) It is easy to calculate the full public key using either the compressed key, or the private key. Private keys are scalars, not points, so they can't be "compressed". To calculate the public key from the private key, it is just G* k. G is the base point defined in sec2 for secp256k1 (the curve we use). To calculate it from the compressed key, the magnitude of y is sqrt( x3+7). You already have x because it is stored normally in the compressed key, along with z which tells you the sign of y. The bitcoin address is calculated by hashing the public key. I think the hash is always performed using the full point, and I know that using the full point works, because I've calculated addresses using the uncompressed key, sent coins to them, and spent them using the corresponding private key. I don't think that starting the hash process using a compressed key will work, but it is late, and I don't feel like digging through the code to find out for sure. Hopefully someone will chime in. |
|
|
|
|
Interesting theory. Seems a bit pyrrhic though.
|
|
|
|
Here is my idea for a distributed chain for ownership: From a PM I sent a month ago... (I thought about sending something like this last night, but right now I don't remember if I did or not. Insomnia for the win! Sorry if this is a duplicate, been up late a couple of nights in a row thinking on this.)
So, I happened to be working on setting up litecoin mining on my rigs and registering for MPEX at the same time, and it gave me an idea. Mind if I bounce it off you before I inflict it on the world?
Basically, for all of MPEX's fancy cryptography, I'm still not buying shares, I'm buying entries in a ledger. This seems wrong, the world deserves better.
I'm thinking of an altchain for recording securities (stocks and bonds). For now, I'm thinking it should be called securitycoin, or S-coin, or STC.
Say we add a payload field to the TxOut structure. (It'll likely be a blob of DER)
If you want to create a new stock, you encode a bunch of information (the name of the issue, the number of shares, some other stuff and a hash of the prospectus) and call it the issue. Then you hash the issue along with a secret and call that a registration. Then you create a payload including the registration and burn a few S-coins in fees to embed it in the chain. Then, when you feel it is deep enough, you redeem the transaction with the registration to create a new transaction with the issue as a payload (also the secret, to prove that it was you. This is anti-front running stuff).
Now you can redeem the issue with a send to a bunch of brokers. The brokers can redeem those as usual, and send the shares to clients. Clients can redeem their transactions and send them to other people, if they so desire. *
Once the issue is done, every share has a provable owner, and the owner owns the shares, not the issuer, not the broker, and not some exchange. Even better, if we use regular bitcoin addresses on this network, the issuer can query the chain and get a list of addresses and holdings to send dividends to (on the bitcoin chain).
The system could even handle splits, merges and votes. The only trick there is to encode the payload in a way that the network can validate the payload cheaply. For example, in addition to enforcing coin_out < coin_in, it also needs to verify that shares_out = shares_in (paying network fees with shares seems silly, but replace the = with < and it can happen).
Since this system isn't for buying packs of gum at the store, we could slow the network down, maybe to 1 block per hour, to keep the size small. And we could keep the value of the coins high-ish, giving an incentive for people to merge-mine it, by charging high fees for things like registrations, issues and vote requests, and small fees (or none) for sends and votes.
* I don't think it is possible to take the brokers out of the system. I don't see any obvious way to make a pair of transactions on different chains that redeem each other. If there is such a thing, you and your broker could create such a contract and make the trade atomic. Until then, one of you needs to trust the other. Then again, if we are using the same keys in both places, maybe multi-sig can do it, don't know. At worst, it is no worse than any other bitcoin/world interaction, and you still get the benefits of recording stock ownership in the chain.
Also, see this thread and search for pybond. When I got to thinking about Open Transactions the other night, I was thinking it might be possible to do everything in a distributed provable exchange using that system. Talking to Fellow Traveller about it is on my todo list. |
|
|
|
I'm talking about next few years.
If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.
Why on earth would anyone make this choice? Are you confused about how mining works? Here's a hint to get you started: including transactions does not hurt your hash rate. Heh. It's the 1st time I see a person who can write but can't read. What if the state developed and sold a lot of ASICs that don't include any transaction? If these ASICs are better than anyone's else, then most of miners will use such malicious devices. The state can afford to hire the best scientists and the best engineers to create such ASICs. It can even sell these devices much cheaper than, say, Butterfly Labs. Was the mentioned functionality (rejecting blocks with not enough transaction) implemented?
Should I rewrite it MORE slowly?  How about you write it on this planet instead? In your hypothetical universe where the chip has the telepathic ability to refuse to hash blocks that include transactions, pigs will fly out of unicorn asses. In this universe, where the ability to get paid for a block is exactly the same thing, as far as the chip is concerned, as being able to include transactions, no one can force this choice on you. |
|
|
|
I'm talking about next few years.
If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.
Why on earth would anyone make this choice? Are you confused about how mining works? Here's a hint to get you started: including transactions does not hurt your hash rate. |
|
|
|
Wasn't that the one with the huge screencaps pointing out that the members of the Bitcoin Foundation have done business with each other before in other bitcoin-related ventures, and with the hilarious evidence-free accusation at the end that they're planning to create fake bitcoins and destroy the market? Don't be so hard on the guy. It looked like he put a lot of work into finding those public details that everyone already knew. |
|
|
|
Wow. A bunch of angry nerds pushing a false dichotomy. If you don't completely support Bitcoin, you are Bitcoin's enemy.
Yeah, that is the attitude that will encourage the greater public to adopt Bitcoin.. Nice job boys!!
Well, in fairness, the EFF has a point that they need to avoid being their own test cases. But... defending free use of technology by other people is kinda their whole reason for existing. I don't think EFF is against Bitcoin. I think that for whatever reasons, they are not particularly interested in it at the moment (surprising given their statements on the importance of transparency/privacy regarding payment processors!) and/or they don't have the resources to get involved with it yet. Their backing away from it does seem spineless to me - but that aside - it's the detrimental effect of their public and private statements upon uptake which is concerning. Bitcoin needs uptake from legitimate businesses/non-profits etc to balance out the common perception that it is mainly for 'black markets'. Perhaps because the EFF doesn't see Bitcoin itself as particularly important, they simply haven't taken due care not to cause 'Chilling Effects'. Sad. Like any organization, they have limited resources, and have to choose their battles. I hate to sound like I'm making excuses for them, but that doesn't change reality at all. I'll be sending them a donation soon, along with a letter asking them to reconsider their public statement. I'd do it right now, but I need to figure out a polite way to say what I want to say. |
|
|
|
ECDSA signatures are computed from a partial hash of the transaction, I'll call it the sighash. One very good reason for this is that the signature needs to be inside the transaction, but isn't known yet. So, at the very least, the place where the signature will be is replaced with all zeros before computing the sighash. There are opcodes that can change how the sighashes are made. For example, SIGHASH_SINGLE signs the input, and just one output, but not the rest of the outputs. When you compute the signature of that hash, you end up with two numbers, a point on the curve specified as (r,s). Turns out that the math that verifies the signature doesn't work only on (r,s), but it can also work on (r,(-s mod N)) too, and on several other points. This property is known as malleability, and is well known for DSAs. Personally, I had no idea, so I learned something cool today. This isn't a security problem though, since the points are all related, and none of them can be used to reveal the private key, and none of them can be found without knowing the private key. I'm not entirely sure here, but I think that what Sergio was getting at was that it would be possible to create a transaction that spends an output using the signature (r,s), and a second one that spends the same output with (r,(-s mod N)). You feed one to the network, and then the other goes to your target. Both signatures are valid, so the target sees a legitimate transaction, and the sighashes are the same so the target node won't ask for the network's version of that transaction to compare (because it thinks it already has that transaction). Remember SIGHASH_SINGLE? You can use it here to sign just the input and the change coming back to your wallet. That is what lets you create two different versions with the same signature. Since only your change is signed, the transaction given to the target has their address in it, but the transaction given to the rest of the world has another address that you control in it. Since they aren't included in the signature, they can be changed at will. So, why doesn't it work? Because transactions are identified by the full hash of the entire transaction, including all signatures, and not by the sighash. The target transaction signed by (r,(-s mod N)) has a different hash from the (r,s) version, and is therefor a totally different transaction. The target node will see both versions, and since they spend the same txouts, the double spend attempt will be noticed and rejected. Also note that wallets keep track of things by looking at the contents of transactions, not by recognizing their hashes. If you run the same wallet on two computers, when you spend from one computer, the second will recognize the txout in the transaction and mark it off based on that. (This came up in a different thread.) Sergio, let me know if I'm off target here. This is an interesting topic, and I wanted to try to clarify it for the people that have been asking about it. Obviously, I don't want to be putting words in your mouth if you are talking about something different. |
|
|
|
I'm only interested in the address.. not the owner..
I know this will not always resolve to an address.. but in most case it will.. I will just catch the errors of when it is not the case and handle it gracefully
Good to hear. Sounded like you were working on a website, but I like to give that reminder in these threads, so that when people go searching and find out how you did it, they also find out that it might not do what they expect. |
|
|
|
|
Just as a reminder, while this like it should work, the concept of a sending address does not exist in bitcoin. What this is doing is finding the last address to have received these funds. This is occasionally what you expect, but not always. If you are thinking that this address is owned or controlled by the person that sent you a transaction, you will be wrong fairly often.
|
|
|
|
|
Wouldn't the inverted s signature end up with a different hash? As in, the txID is the hash of the whole transaction, including the signature, right? So even if there are two valid signatures, won't they end up with different IDs?
Or am I wrong about that?
|
|
|
|
This might be also good to know:
DO NOT encrypt your wallet AFTER you made your backups (if you do this you should update your backups and delete all old backups)! If you do this you risk losing some/all of your coins if you send a transaction with your encrypted wallet.
Edit:
If you do it the way "kjj" suggested (set keypoolsize=0), I think you could encrypt your wallet after you made your backups.
No, if you set the keypoolsize to zero, and then encrypt, you'll have NO available keys in the pool. I'm not entirely sure where things go when that happens. It probably re-uses keys then, but just don't do it, there is no need to. The correct sequence is: 1) Encrypt 2) Backup (copy) 3) set keypoolsize |
|
|
|
|
Show Posts
