As a matter of convention, Satoshi established that the clients should display those totaled values with a decimal point in the middle of those 64 bits (32 bits form the value shown to the left of the decimal point, 32 bits show the value to the right of the decimal point). Said another way, the protocol has no concept of BTC's, but only deals in satoshis; but humans have a problem with dealing with numbers quite so huge, and this is why teh clients display the totaled values the way that they do, resulting in the (technically false) meme that there will only 21 million currency units. However you choose to look at it, the bits of those interger variables with the greatest values will never be used, because the entire monetary base can be stored into a single 64 bit integer using only 48 bits, as the actuall 21 M BTC in binary would look like this...
(111,011,101,011,111,000,001,011,010,000,001,110,100,000,000,000,000) Technical quibble... The radix is not in the middle of the 64 bit value. The 64 bit value is just an integer, and it is scaled by 100,000,000. 100,000,000 is not a power of 2, so there is no clean break between the bitcoin part and the fractional part in the value integer. log 2(21,000,000 * 100,000,000) is about 50.899, so we need 51 bits to represent the full range. We could change the scaling factor with a hard fork, and version x transactions could have more room at the bottom end for precision, but doing so means less headroom. Did I say headroom? Yup. We can do accounting beyond the limits of the money supply, just like we can estimate that the net worth of the US is into the hundreds of trillions while there exists nowhere near that many dollars. In the same way, an accounting package can use 64 bit integers to give satoshi-precise figures up to a bit more than 2 13 times the total bitcoin value. This is still, sadly, a small number, only about 2 trillion dollars, but that is (hopefully) an accident of history, not a permanent thing. I still think that we will switch up to 128 bit values to match future CPU-widths long before it makes any economic sense to do so. |
|
|
|
Erm. What exactly is stopping an attacker from doing the same math between the pubkey of each input and the list of known public keys to recover all of the transactions?
A, B and C are all publicly known, which means that d is known, which means that E is known. The attacker still can't spend them because b is unknown, but he can sure see them.
P.S. Diffie-Hellman is an online protocol. It requires (bidirectional) active participation from both parties.
To compute d an attacker would need to know either a or c. None of them is public. I define d= A* c= C* a. The fact that it's hard to compute d from A and C is the basis of Diffie–Hellman key agreement protocol. Ahh, I missed that it was A*c and a*C. To make this easier for non-cryptographers: g is the basis point (x,y) of the curve we are using. a and c are a secret 256 bit integers. (Keep in mind that in EC math, a point multiplied by an integer is a point.) A = a * gC = c * gA * c = a * g * cC * a = c * g * aEC multiplication is commutative, so A* c = a* g* c = c* g* a = C* a = E |
|
|
|
Heres what im getting: exception 'Exception' with message 'Unable to connect to http://mybituser:mybitpass@127.0.0.1:8332/' in jsonRPCClient.php:140
Stack trace:
#0 [internal function]: Slick_jsonRPCClient->__call('sendmany', Array)
#1 Model.php(427): Slick_jsonRPCClient->sendmany('Main Account', Array)
#2 Controller.php(20): Slick_BTC_Visit_Model->sendPayouts()
#3 index.php(46): Slick_BTC_Visit_Controller->visitSite()
#4 {main} it seems like any time any command to the bitcoin client fails it just gives me the 'unable to connect to..' error rather then giving me any actual error info.. seems kind of odd Hmm. That doesn't seem right. I'm almost positive that I've seen useful error messages from RPC calls from PHP before. I'll fire up your code on my box tomorrow if I get time, just to see. |
|
|
|
|
Hashing appears to be totally resistant to quantum attacks. Grover's algorithm can solve any circuit quickly, but circuit has a peculiar meaning, and it is a tricky thing. We don't have or expect to be able to have the capability in the foreseeable future to build a classical circuit for SHA, much less a quantum one. If you don't believe that, read up on the SHA algorithm, and then think about what you'd need to do to unroll that in the time dimension to a single flat circuit that doesn't use iteration or memory. Your VHDL compiler would stab you if it could.
An ECDSA break due to Shor's is likely to be a bigger problem, possibly even within my lifetime (say, the next 50 years or so). In 2001, a (maybe) quantum computer factored 15 into 3*5. This feat was achieved again in 2012, but this time with a computer that we are almost positive is actually quantum. They've moved up to factoring 21 now.
But keeping quantum systems stable gets harder as you add complexity, meaning that the issue isn't merely one of applying well known classical techniques to shrink and replicate gates. We sorta strongly suspect that quantum computing is possible, in the sense that our current understanding of physics doesn't explicitly disallow it, but it will be a long and ugly road getting up to useful scales.
|
|
|
|
|
I suspect that in a couple of decades (or less) we will have cheap common 128 bit CPUs. At that point, we might decide to widen the value field for aesthetic reasons. (Daddy, why is the bitcoin value field only half a word?) As already pointed out, such a change will have no noteworthy change in mining reward or total coin supply. It could even be exactly zero change, if we modify the algorithm to clip bits beyond the current unit place.
|
|
|
|
Currently, if someone publishes his Bitcoin address (to receive donations, for example), anyone can see how much money he got. I propose a protocol which can be used to receive donations without revealing all payments to everyone. A person who wishes to receive money would generate 3 keys:
1. Public key can be used to send money to the person, but not to see when others send money to him.
2. Semi-private key can be used to see all incoming transactions, but not spend them.
3. Private key is necessary to spend the money.
It is expected that the user will publish his public key, keep hist semi-private key on his online computer, and keep his private key offline.
Implementation
I will use lower case letters to denote ECDSA private keys and corresponding upper case letters to denote corresponding public keys.
Creating an address: to create an address, a user generates to pairs of ECDSA keys. Let's call them (a, A) and (b, B). Then, (A, B) is a public key, (a, B) is a semi-private key, and (a, b) is a private key.
Sending money: suppose that someone wants to send money to key (A, B), and some of it is currently owned by key C. He performs Diffie–Hellman key exchange between keys A and C to generate a shared secret d=A*c. Then he uses a type 2 key derivation function (used in type 2 deterministic wallets) to generate a new public key E from B and d. He than sends money to an address generated from E. Note that C must appear in one of the inputs.
Receiving money: on the receiving side, the user scans all transactions to see if they match his semi-private key (a, B). To do so, he iterates over all inputs that match send-to-address template. Let C be a key that appears in one of such inputs. He computes d=C*a and E. If E matches the address the money was sent to, then this money was sent to him.
Spending money: to generate private key e, the user generates d as before and derives e from b and d.
Why this is useful?
It would be able to publish an address such that no one would be able to see how much money was received.
If someone wants to send money owned by multiple keys, he can send it in multiple transactions that can't be linked to each other.
Finally, users won't need to have many addresses. They can send change to themselves using the same procedure.
Erm. What exactly is stopping an attacker from doing the same math between the pubkey of each input and the list of known public keys to recover all of the transactions? A, B and C are all publicly known, which means that d is known, which means that E is known. The attacker still can't spend them because b is unknown, but he can sure see them. P.S. Diffie-Hellman is an online protocol. It requires (bidirectional) active participation from both parties. |
|
|
|
blah, blah How the hell did you make it this long without your ignore button flashing red? |
|
|
|
Put print_r($senders); before the try block so that you can see exactly what is getting passed to bitcoin.
Array
(
[1GawMPab9B7Bbt5FXPVDbHt6T2NrfH2EgC] => 0.0016
[1MvX1RB5ERDx1xMaWQeH4zWZgCBB5i8BxD] => 0.00072
) should be the correct format right? That looks right to me. In your exception block, instead of just returning false, echo $e; first to see if you can get any useful information that way. |
|
|
|
|
Put print_r($senders); before the try block so that you can see exactly what is getting passed to bitcoin.
|
|
|
|
Unix shell quoting can be confusing if you aren't used to it. Try: bitcoind sendmany "Main Account" '{"1GawMPab9B7Bbt5FXPVDbHt6T2NrfH2EgC":0.0001}'
As for the PHP one, just hand the $senders array to $bitcoin->sendmany() directly, no need to pre-encode it. |
|
|
|
"out":[
{
"value":"1.00000000",
"scriptPubKey":"OP_DUP OP_HASH160 ad4c20d5b1956015ea626f02afdaebe8ed17e1a8 OP_EQUALVERIFY OP_CHECKSIG"[/b]
},
{
"value":"1.00000000",
"scriptPubKey":"OP_DUP OP_HASH160 ad4c20d5b1956015ea626f02afdaebe8ed17e1a8 OP_EQUALVERIFY OP_CHECKSIG"[/b]
}
]
}
Constructing a transaction like this is: 1. Either identical to sending the destination 2 BTC, in that clients consider the transaction to be adding 2BTC to the balance as one output (Bitcoin can't differentiate which output of these two might later have been spent, because they are identical with an identical transaction hash), or 2. A good way to lose half your money because Bitcoin can't differentiate between which output of these two might later have been spent, because they are identical with an identical transaction hash. https://en.bitcoin.it/wiki/BIP_0030So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. No, you are confusing transactions with outputs. Transaction with duplicate hashes are no longer allowed, but duplicate outputs are. The reason is that the transaction hash is the sole transaction identifier, while an output is identified by both the transaction hash and the output sequence number. In this case, even though the transaction has two identical outputs, one is named <TxHash>.0 and the other is named <TxHash>.1. In normal operation, the reference client hides the coin details from the user, and will present it to the user as a 2 BTC payment. But behind the scenes, it knows that there are two outputs there and will act correctly, fully capable of redeeming and spending them one at a time. |
|
|
|
|
The encoding is, in my opinion, an ugly hack. Sadly, this is the logical end point of the cleverness that people have been using to contort the base58 package.
Please stop the madness. If you want part of the text to be human readable, do it outside of base58. If you want "6" to mean "incomplete" and "P" to mean "encrypted", please do those comparisons in ASCII. Leave base58 to the binary parts that aren't important to people.
If necessary, extend the base58check system so that it can include non-encoded parts in the checked part.
|
|
|
|
It's not magic. It is called "fractional reserve banking" and it works like this:
Bank A has $1.
Bank A loans $0.90 to a customer who buys from merchant B, who deposits the money in bank B. Merchant B believes he has $0.90.
Bank B loans $0.81 to a customer who buys from merchant C, who deposits the money at bank C. Merchant C believes he has $0.81.
Bank C loans $0.73 to a customer who buys from merchant D, who deposits the money at bank D. Merchant D believes he has $0.73.
Bank D loans $0.66 to a customer who buys from merchant E, who deposits the money at bank E. Merchant E believes he has $0.66.
Bank E loans $0.59 to a customer who buys from merchant F, who deposits the money at bank F. Merchant F believes he has $0.59.
Bank F loans $0.53 to a customer who buys from merchant G, who deposits the money at bank G. Merchant G believes he has $0.53.
Bank G loans $0.48 to a customer who buys from merchant H, who deposits the money at bank H. Merchant H believes he has $0.48.
Bank H loans $0.43 to a customer who buys from merchant I, who deposits the money at bank I. Merchant I believes he has $0.43.
Bank I loans $0.39 to a customer who buys from merchant J, who deposits the money at bank J. Merchant J believes he has $0.39.
...
In the end, there is actually only $1 split among a large number of banks, but each depositor believes that they have the amount that they deposited and the fact that the depositors can withdraw their deposits at any time confirms it (as long as all depositors don't withdraw at the same time). The total amount of deposits is $9, so even though there is only 1 physical dollar, there are 9 additional virtual dollars which are nearly indistinguishable from the original $1.
Notice there is a time delay between the deposit and loan, so you must specify how long it takes for each step to happen, and all these steps have strict dependency You add up all the money you have made each year in a 20 years period and said that you have made 1 million dollar, and that makes you a millionare!!!  In reality the time difference between the deposit and the loan is negative. The bank makes the loan first, and then seeks deposits to cover their reserve requirements. Money is an idea, not a thing. It is not subject to physical conservation laws. |
|
|
|
Or as Inaba would say: "OK BFL sucks. But bASIC/Tom sucks even more".
Or like Hitler would have said: "OK I suck. But Stalin sucks even more".
I'm invoking Godwin's Law. This debate is over, please lock the thread.  |
|
|
|
|
SSL is allowed to suck because it tends to protect nothing important. In the real world, there is no such thing as an irreversible transaction. A credit card number that gets intercepted these days pretty much means you are going to spend a very annoying 3 minutes on the phone with the fraud department of your bank. Do you still look for the padlock icon before typing in your credit card number? I sure don't. Online stores use SSL because Visa and Mastercard make them use SSL, and the processors insist on SSL because it reduces fraud claims. You (the user) are never a factor.
My complaints with the SSL system are:
1. There are tools that can mitigate the security/fraud problems, but no one takes them seriously. Turn on strict OCSP checking in your browser if you want to see for your self.
2. The CAs actively participate in industrial MITM snooping operations. Your corporate IT department probably has a box that uses a wildcard cert issued by a legitimate CA to inspect all of your SSL traffic.
3. Race to the bottom! The whole point of having CAs is that they verify things, which is what you pay them for. Over the years, they've all decided to stop doing their job and just take your money for nothing. It got so bad that marketing had to step in and invent a whole new class of SSL certs (EV) where the CA actually does what it was supposed to have been doing all along.
That said, SSL is here and everywhere, and as badly as it sucks, every other option sucks worse. It really is the logical choice for this. Just remember, there is no chargeback in bitcoin. If you have a payment request for more money than you can afford to lose, think real hard about how much you really trust that cert. Odds are very good that no human has ever looked at any part of it before.
|
|
|
|
Blah, blah, puppetspeak...
Fuck off weirdo. I'm inclined to agree. That tool is going on my ignore list. |
|
|
|
I am not sure I understand how the resource usage is small. I understand a chain can be used to generate unlimited addresses. How should the software come to know that of all the addresses generated by party B (for example), the one with sequence number 10,000 has a transaction that needs to be checked for, even if all addresses 0 thru 9999 don't? I see no way other than actually generating all those addresses just in case and checking them all, and then there is no guarantee that 10000 or any other number is enough if you can't assume how the other party will be using addresses they generate. This. For occasional interactions, I think that each party should just accept the burden of keeping track of everything they need. For p2sh, it means keeping a copy of the completed redeemScript (which generally means having all of the pubkeys). The whole point of using pubkeys is that they can be public, so the service that collects keys can also distribute them when done. For regular interactions, and particularly when you want to define a stream, each party should generate a new set (seed and chain secrets), and then the problem is reduced a bit to merely passing around names and indexes. If ABCDEFGHIJK are keys in some complicated scheme, they can be taken to mean AiBiCiDiEiFiGiHiJiKi, when given i, so everyone knows how to generate their part of it. By the way, for regular X-of-Y multisig, I find it VERY useful to sort the pubkeys before assembly. In fact, I wish that the default behaviors of createmultisig and addmultisigaddress in the stock client were to sort, possibly with an option to not-sort. |
|
|
|
Hmm. Well, if you have a different box that you can test from, open that one in your firewall, and set that in your rpcallowip line. Also, on the server, check "netstat -nap | grep bitcoin | grep LISTEN". Look for a line similar to one of these: tcp 0 0 0.0.0.0:8332 0.0.0.0:* LISTEN 22327/bitcoind
tcp6 0 0 :::8332 :::* LISTEN 22327/bitcoind
tcp 0 0 127.0.0.1:8332 0.0.0.0:* LISTEN 22327/bitcoind
tcp6 0 0 ::1:8332 :::* LISTEN 22327/bitcoind
The pairs are IPv4 and IPv6 versions of the same thing. The first pair shows bitcoind has bound to every interface. The second pair shows bitcoind bound only to localhost. For remote connections, you need it to bind to every interface. |
|
|
|
You're acting like your responsibility is a joke, and that you don't respect the position you hold or what people expect of you in that position.
LOL. Isn't that what I've been saying about you? |
|
|
|
I haven't tried without SSL because the wiki says that for non-localhost connections ssl is the only option? the openssl s_client -connect localhost:8332 command outputs fine btw, again according to the wiki so it works locally, just for some reason can't get to it the allowed ip i checked like 10 times, and it's also for sure allowed in the firewall, together with both ports 8332 and 8333 just in case basically i'm out of ideas guys  what else might be wrong? p.s. has anyone made between server connections work without ssl? (not that i would like to run it like that) You need to do the check from the remote end, not localhost. Most likely your firewall isn't really open on that port, but possibly other things. Try using -bind=your_IP_address too. yes i know, but the checks from the other side don't work, i just know that it's setup fine on the host server because of this. do u mean to use the bind in the shell on the host server? what's your idea? I'm saying that you need to do some checks at a lower level. Use nmap from the client side to see if you can get any reply from the server. If it reports the port closed, you need to figure out why. Likely reasons are that your firewall isn't really allowing the traffic in, or possibly that bitcoind is binding to the RPC port on 127.0.0.1 instead of 0.0.0.0. |
|
|
|
|
Show Posts
