 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
|
You don't sound intelligent enough to be bashing the security of the bitcoin network which stores Billons of dollars in value just in the crypto currency that secures it alone. I doubt you've even gone through the source code, let alone interpreted it in any analytic capacity. If not bitcoin, block chains, are the future of asset transfer and ownership.
|
|
|
|
|
Truth? Slim chance? Based on what? How did you declare these as facts?
|
|
|
|
|
By 2030, a Dollar will be worthless, so you can't put valuations of BTC in that Denominations, the value of BTC in the future will be determined by usefulness and capability/resiliency of the blockchain. Watch.
|
|
|
|
You can wish all you like but there's absolutely no way to confirm a full node really is a full node and not just faking it. If full nodes were to get paid, then one could spoof as many full nodes as they like and get paid for each of their fake nodes. To prove they're full nodes you'd have to invent some kind of "proof of work" and add it to some kind of blockchain - congratulations you've invented mining and an altcoin blockchain.
This is incorrect. Although, you can't incentivize the process of just running a node, you have to incentivize both the speed and volume of the process of tx propagation. http://research.microsoft.com/pubs/172840/Bitcoin-Red-Balloons-SIGEcom.pdfRead that paper to learn more And here's a reflection on it by MIT Media Lab http://web.media.mit.edu/~cebrian/p78-tang.pdfNode incentives are important, and likely play a role in dismissing certain concerns regarding issues inherent in larger block sizes by potentially representing a more Symbiotic relationship between miners and the nodes that propagate the transactions to them. |
|
|
|
Was: Not possible. You can't call API's from bitcoin, they HTTP status codes have no place in a it  API call to bitcoin, not from. SC API determines certain variables, has quota for range of variables, and acts by broadcasting a signature to Bitcoin depending on whether or not the quota is met. |
|
|
|
excellent, thank you.
CLAM distribut(s|ed) its coins that way. clam? |
|
|
|
A wallet is an abstract construct, which contains the set of public and private key pairs randomly generated for the user. In a deterministic wallet, the keys are derived from a passphrase (a specific seed, masterkey or password) instead of a random seed.
seems like Danny is the only one that understands what I'm asking here, but thanks for the info on the deterministic wallets, I've been reading about how these are used in hardware wallets. |
|
|
|
A bitcoin "Address" is nothing more than a pairing of a public key (which you share with people to receive money, think of your public key as INBOUND ONLY traffic) and a private key (which cryptographically links to your public key, allowing you to spend said funds, OUTBOUND traffic). As im sure most of us would have no issue with money accidentally coming INTO our account, your public address can be shown to anyone. However, to spend/move those funds, you must possess the PRIVATE key. this is why they are named as such.
I didn't ask what the difference between Public and private keys, which, like you said, would be redundant since they're sort of self explanatory |
|
|
|
I understand that A public key is 140 char or something like that?
I suppose that depends on how you define a "char". When talking about a bitcoin public key, people are typically referring to the ECDSA public key from the secp256k1 curve. That public key is a pair of 256 bit numbers (x and y coordinates). That's 512 binary digits. In computer programming, a "char" is often just an alias for an 8 bit "byte". Using that definition of a "char", a public key would be 512 / 8 = 64 char. Alternately a byte is often represented as 2 hexadecimal digits. Using a hexadecimal representation, the public key would be 64 X 2 = 128 hexadecimal digits. It would also be possible to encode the public key in base 58 or base 64 (or just about any other base you like). Then, you could further reduce the size of the representation by using a compressed key. Since the curve that bitcoin uses for computing the public key is known, you only need the x value (plus one additional bit) to be able to calculate the y value. This cuts the size of the representation in half (plus one bit). I was told that a Shorthand Bitcoin "address" corresponds to (A very large number) of Public keys on the secp256k1 curve.
Correct. While there are 2 256 possible public keys, version 1 (pay-to-pub-key-hash) bitcoin "addresses" use the RIPEMD160 hash function. This reduces the total number of possible addresses to 2 160. This means that (on average) each address corresponds to 2 256 / 2 160 = 2 96 different public keys. How does one go about determining all of these public keys,
One does not. There is currently no known way to reverse the RIPEMD160 hash function and generate a list of public keys for a given hash value. and Are you able to send outputs to all these public keys and still end up with coins at the same bitcoin address?
Bitcoin doesn't generally send to public keys any more. Pay-to-pub-key was supported in the past (as well as pay-to-ip-address), but at this point in time the two output scripts that are generally used are pay-to-pub-key-hash (addresses that start with a "1") and pay-to-scrupt-hash (addresses that start with a "3"). The output script for pay-to-pub-key-hash doesn't make any reference to a public key at all. It doesn't "send outputs to public keys", it "encumbers an output with a requirement to supply a signature with a key that hashes to a given hash value" Danny, thank you, you've been more than helpful with my questions over the past few weeks. I've been trying to get a more in-depth understanding of how everything is working under the hood of this beast. May I ask who you are quoting "encumbers an output with a requirement to supply a signature with a key that hashes to a given hash value" In this circumstance, what is the given hash value's relation to the destination address? The signature you speak of is derived from the private key of the origin of the output, correct? The pay-to-pub-key-hash makes reference to the pub key hash, but not the public key itself? I guess that is the point of the pkh? Is there any resource you can suggest to me that covers this kind of thing all the way through? Thanks |
|
|
|
|
I understand that A public key is 140 char or something like that?
I was told that a Shorthand Bitcoin "address" corresponds to (A very large number) of Public keys on the secp256k1 curve.
How does one go about determining all of these public keys, and
Are you able to send outputs to all these public keys and still end up with coins at the same bitcoin address?
Thanks
Was
|
|
|
|
|
It is my understanding that it is possible to influence smart contracts with outside data coming from an API.
Say for example there exists a multi-signatory address, that could include sigs from an open source, automated verification of completion of task (say a decentralized uber service, that communicates via GPS to phone to determine if the contractor took you to within a certain region of where you wanted to go, that communicates with the blockchain via API, and sigs from the two parties engaged in the contract, the client and the contractor. Is something like this 1: Feasible, and 2: On the bitcoin network? upon completion of the contract, either by verification from the Automated API, or
I still don't under stand p2sh very well, but how could p2sh be utilized in this circumstance? Would it be more convenient or feasible than what i just described?
Was
|
|
|
|
|
Quick Spin on the question to anyone who feels obliged to answer,
If I created an Altcoin, and used the same algorithm (secpk256, i think) to generate the pub/priv key pairs, if I sent coins to an existing address on the bitcoin network, for example,one of Satoshi's, would the private key be the same for that address on the altcoin blockchain? i.e. would satoshi be able to spend these coins assuming he was aware of this?
thank in advance
Was
|
|
|
|
From the Bitcoin-core Debug Window Peers;
73.179.230.242:59060
via x.x.x.x:8333
Direction Inbound
Version 70002
User Agent /Satoshi:0.11.2/
Services NETWORK
Starting Height 237292
Sync Height Unknown
Ban Score 0
Connection Time 10 h 4 m 39 s
Last Sent 5 s
Last Received 38 s
Bytes Sent 1 GB
Bytes Received 3 MB
Ping Time 336874 ms
Time Offset 1 s
That is a prime example of a peer I would like to charge for providing my full node services to it.
Read "Red Balloons" by Zahar et al |
|
|
|
|
I believe that if we can address node incentivization, like Satoshi suggested, "[I suspect] we need a better incentive for users to run nodes instead of relying solely on altruism". (IN AUGUST 2015) Then we will have an easier time putting concerns about raising the block size at rest.
Perhaps the solution could present a Symbiotic relationship between nodes and miners, that would help with concerns regarding the propagation of larger blocks.
was
|
|
|
|
Besides, we all know the CIA funds ISIS.
Whoaa, that is quite a bold statement to make on a public forum. Do you have any source documents as proof of that? I doubt if the CIA will fund a terrorist organization to kill their own people. Why would they want to do that? It is more likely that ISIS is getting funding from extremist supporters from within 1st world nations, owning legitimate businesses. They also sell some oil and trade with raided goods. It was a joke. Really all I know for a fact is Vladimir Putin said G20 nations are funding, and somebody has to be buying oil from them. I don't understand why the US hasn't located them, and shut them down. |
|
|
|
|
Now I'm scared I'm gonna get picked up in a black van at 3AM
|
|
|
|
Help me get this straight... A single Public Key can have multiple private keys?
No. A single ECDSA public key on the Secp256k1 curve only corresponds to a single private key. However, each bitcoin address corresponds to (on average) 7.9 X 10 28 ECDSA public keys on the Secp256k1 curve. I mean, can I use Vanitygen and input an exact address, in hopes of generating the keypair?
thanks
You can. You would be wasting your time and your money, but you can try if you want. You'll spend electricity to run the computer for a few billion years, and you probably still won't find the exact address. Do you really think people will still be using bitcoin a few billion years from now? Thanks Danny, Appreciate the help. These are hypothetical questions. The answers to which help me (and others who view this) better understand the inner-workings of the software. |
|
|
|
|
