Nobody cares about the status. Newbie, by name, no longer restricts anything you can do.
You cannot accelerate your "activity" rating any faster than to post at least once every two weeks.
Bullshit. Newbies have massive post limits. I can't reply to a post, then report another post. I have to wait like 5 min between each action. Because that was meant to identify spammers and scammers here. If that was allowed then all we can see here are posts full of trolls all throughout the threads. They didn't, but but now they do again, because new members unrestricted tend to do unsocial things like post signature ads to bump four-year old threads. |
|
|
|
Not as a GUI feature, but the building blocks are there: "contrib/spendfrom is a python-language command-line utility that demonstrates how to use the “raw transactions” JSON-RPC api to send coins received from particular addresses (also known as “coin control”)." |
|
|
|
If you are afraid others will see your password while you type, take your notebook with you to bathroom.  I highly doubt anyone would barge into bathroom while you "use".  Or take a clue from Edward Snowden - either paranoid enough or informed enough to only enter his decryption passwords when covered with a blanket. Keep even your use of Bitcoin secret from anyone who you do not completely trust. They tell their friends, their friends tell their methhead cousin... |
|
|
|
Isnt it great that the amount you transfer doesnt matter? Isn't it great that the monetary amount you transfer doesn't affect the data or processing cost to network members, or cost of disk space that nodes must allocate to store your transaction forever? Well, anyway, the commentary should be that if it was important to have processed quickly, then paying a larger-than-default fee would have been a much smaller percentage of this non-trivial amount. Post pretty old...very interesting. Thought the unconfirmed Transaction thing is a recent phenomenon. Think Op should update the post to meet current reality
My amendments below to the first post's points still stand valid - don't experiment with paying the lowest fees possible for important transactions: Notice: If you want a payment to go through in less than several hours, increase your Bitcoin client's optional/voluntary fee to something higher than 0.0001/kB default fees for all transactions. Priority is given to higher fee transactions.
..
The first-post instructions for removing a transaction and re-sending a new one with fees apply only if the original transaction was created with a "bad" client, or if it was sent while attempting to bypass Bitcoin fee rules. Removing a transaction record from your client and re-sending another transaction will likely do you little good. The network won't soon "forget" your original transaction if it is properly constructed, will recognize a new transaction as attempting to double-spend the same money, and will discard the new transaction anyway.
The Bitcoin white paper doesn't say anything about free or cheap transactions, this came from Bitcoin promoters while it was still true. In fact, reasonable and balanced fees are necessary to discourage trivial transactions and to replace the shrinking block rewards paid to miners. The economics of this are competitive and self-correcting - as more transactions pile up, more fees are needed for timely confirmation. What hasn't happened in the last five years is exponentially cheaper hard drives or processors that could have kept Bitcoin data growth less expensive. |
|
|
|
Any chance you can add a Coinbase feed to SC feed? Thanks
Coinbase appears to be available as a data source from bitcoincharts in several different local currencies. You can view the history files directory here to look at the available ticker names (SYMBOLS) that you would use as a command line option -sSYMBOLS when starting scfeed. Example usage: scfeed.exe -scoinbaseUSD,coinbaseEUR,btcexUSD |
|
|
|
|
Disable signatures and activity numbers on posts, to reduce the incentive for mindless garbage filling up neverending threads and driving long-term members away from the once-useful forum.
|
|
|
|
My signature site has what I feel is just the right amount of information to get started in understanding Bitcoin. There are Bitcoin topics that can go far beyond most people's understanding or desire to learn, such as when we start talking about Merkle trees, digital signature algorithms, hexadecimal math, or subjects that require college-level statistics. If you have a particular topic you would like to investigate further, you can start at https://en.bitcoin.it/wiki/Category:Technical |
|
|
|
|
BIP0038 is made very computationally difficult to encrypt/decrypt. It was specifically designed to be resistant to hardware-accelerated brute force attacks. That will not be a fruitful attack method unless you simply need to figure out which of 20 passwords was used.
Were you able to decrypt the wallets previously? Were the specific passwords trialed before use?
You might try time-traveling - get a old version of the github bitaddress code from the date of creation to replicate any code flaws and load it back up on the original distro and platform used to make the addresses.
|
|
|
|
Signature campaigns have contributed a lot in making bitcoin mainstream and in growing bitcoin community.Campaigns have also helped many bitcoin related business to establish.
That's BS. It has only ruined this forum by encouraging junk posting and keeping year-long pointless threads alive with banal content. The solution is just to turn off forum signatures completely. They add nothing. I created a thread with discussion of why disabling signatures is the only solution, and of course after a few pages and months even that thread was just signature spammers rehashing junk posts at each other. By inaction, Theymos has made this forum not worth the time. |
|
|
|
You should mention that you are talking about p2pkh outputs .... The public key is only published when a transaction spends funds previously sent to that exact address.
Only after an address has spent money can the public key be recovered from a transaction stored in the blockchain.
Not only. Let us take the genesis block and its coinbase transaction .. Well, you answered the OP's first question as "yes" (as long as that user is Satoshi). Not news to me, but informative to others: The original generation of 50 BTCs from mining was a pay-to-pubkey script.
OP hasn't really revealed a topic of curiosity though, unless you want to send someone unsolicited op_checksig payments. |
|
|
|
.... all we need to do is feed different text possibilities into the validator logically. It may be possible to programmatically find the private key with several characters mistranscribed or missing:
- Starts with "5"? No? Add "5" if missing characters; substitute "5" if right length; add "5" and drop other characters if right length;
- Correct Length: substitute alternate upper/lower case for one character, check all positions for one character wrong, then iterate for increasing numbers of multiple incorrect cases, incorrect letters, etc;
- Missing one character? Try adding all Base58 characters at all positions.
Missing two characters? It becomes a slightly harder problem. Adding two characters in all possible positions = 3,956,064 possibilities (if the 5 at the start is correct). Single-threaded python does about 300,000 SHA256 hashes a second on my PC, so probably less than a minute to try all.
This might be an interesting programming project, but I wouldn't bother until it's actually going to recover some Bitcoins.
It sounds like the private key may need more massaging to recover, whether programmatically, or by analysis of what was written down. I would start by analyzing how you transcribed the private key to paper, and think for yourself where you were and how it might have been written in error. Did you lose your place when writing it down, are there any letters close to each other that repeat? Did you make a mistake in lower/upper case when transcribing. Picture yourself with pen and paper in one hand and screen, you will be your own best resource for figuring out how it might have gone wrong. Programming a solution to "brute force" what was written down now needs to be informed about further possible ways that mistakes were made. |
|
|
|
|
When I see a thread like this, the first question - what is the OP hoping to achieve? Sometimes the question asked is not the real question.
A "Bitcoin User" doesn't have a public key, a Bitcoin address has a public key. The public key is only published when a transaction spends funds previously sent to that exact address.
Only after an address has spent money can the public key be recovered from a transaction stored in the blockchain. By recommendation, addresses are often never reused. Nothing about the address or its public key informs you about other addresses the user may have or use.
|
|
|
|
Start here: http://we.lovebitco.in/how-bitcoin-works/bitcoin-addresses/ and read the following page also. Bitcoin addresses traditionally are randomly generated, but they can also be generated by a random seed fed into a pseudorandom algorithm. This makes a deterministic wallet, so that all addresses that will ever be in a wallet can be recreated by a backup of just the seed. The only way someone will know a Bitcoin address of yours is if you give it to them. Many orgs use a single donation address, with the benefit/detriment being that others can see how much has been donated. The safest way to offer a new address for each contribution is to pre-generate them offline, and have web site software simply give a new one to each donator from a list of addresses. Putting full wallet software online for a web backend requires incredible security precautions. |
|
|
|
When I send you money, I am only sending it to a Bitcoin address; I don't know your public key.
I know that. Any public key that hashes to that Bitcoin address can spend the money.
But this is wrong. The public key is provided in the scriptSig, and that's what signatures are checked against. It's also how the hash is checked in the first place. You can find a public key that collides with the hash, and pass the first part of a p2pkh script. If the hash passes, all that's left is <sig> <pub> OP_CHECKSIG, which still wouldn't pass with the dodgy key. Bitcoin address balances are in the form of previous unspent transaction output (UXTO) payments they have received. A standard Bitcoin UXTO that would be in a wallet is a "pay to pubkey-hash", where money is sent to the RIPEMD160(SHA256()) hash of the public key (this pubKeyHash is the same thing as a Bitcoin address, without the Base58 encoding making it pretty). The output script in this UXTO defines the procedures that must be met to spend the money. A pay to pubkey-hash output script has instructions that basically say: if you can provide a pubkey, and the hash of that pubkey is the Bitcoin address included in the script, then you can spend the bitcoins with a message signed by the keypair. The output script doesn't care that you use a particular pubkey out of the many that might exist that create the same pubkey-hash, only that the hash (address) matches. The spender is the one that is sending the pubkey to the network, saying in effect with their transaction "this is bitcoins I am allowed to spend - here I'm signing a message with the instructions to spend it, and since you don't have the pubkey yet to cryptographically verify my signature, I'm providing the one I used to sign the message". Of course the signature has to be valid and the pubkey has to match the bitcoin address, but that is assumed. The original generation of 50 BTCs from mining was a pay-to-pubkey script. To spend those, you had to have the correct key. |
|
|
|
If a URL contains brackets, then the webmaster is a dummy. Unsafe:
Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (""") is used to
delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character "%" is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are "{", "}", "|", "\", "^", "~",
"[", "]", and "`".
All unsafe characters must always be encoded within a URL. For
example, the character "#" must be encoded within URLs even in
systems that do not normally deal with fragment or anchor
identifiers, so that if the URL is copied into another system that
does use them, it will not be necessary to change the URL encoding.
|
|
|
|
I expect the hash test is first is to avoid unnecessary resource consumption. If the hash of the public key doesn't match, it won't even try to verify the signature.
If two public keys can share an address, a signature from the respective private key is still required to actually spend funds, no?
P2SH might be worse off because of HASH160. P2PKH still requires an OP_CHECKSIG, whereas if you find a script tailored to you that collides with a script-hash address, you could spend those funds using your version of the script. Either case still requires a SHA256 collision however, making this prospect unlikely.
When I send you money, I am only sending it to a Bitcoin address; I don't know your public key. Any public key that hashes to that Bitcoin address can spend the money. Of course, even if there were 21 trillion addresses each having one satoshi in them (more than the maximum number of bitcoins that will ever exist), the odds are impossible-1 that you will ever be able to spend money for a Bitcoin address and key you didn't generate yourself. |
|
|
|
The first 1 comes from the address version and is always there for a normal bitcoin address. Every other 1 requires a byte equal to 0 is the pub key hash.
- 11: 1/2^8 = 1/256
- 111: 1/2^16 = 1/65536
- 1111: 1/2^24
etc
are you sure? It seems base58 would have a 1/58th chance for a '1' Base58 conversion always preserves leading 0 bytes by directly encoding them as a "1" at the start of an address. This is the reason all standard Bitcoin addresses start with 1, because of the hard-coded network ID byte of 00 for Bitcoin. A byte can store a value 0-255; the chance that the next byte (the first digit of the hash) is also 0x00h is 1 in 256, and so on. The Bitcoin address in it's native binary form (that you never see) is 25 bytes, it's parts are: byte 0: Network ID Byte (0x00 for main bitcoin network)
byte 1-20: ripemd160 hash (20 bytes) of sha256 hash (32 bytes) of 0x04+public key (65 bytes)
byte 21-24: checksum: first four bytes of sha256 hash of sha256 hash of bytes 0-20 aboveOnly after the leading byte preservation is the address then put through Base58-encoding. The other non-related "answers" seen in this thread are also wrong: because the largest Bitcoin address (all FFFFs for the hash plus checksum) is 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr, there are strange address probabilities. The chance of an address starting with characters 12 - 1P is about 1-in-23; an address starting 1R-1z must be a 33 character or less address, and chances are 1-in-1353. As we now know, starting in 11 is 1-in-256. |
|
|
|
from what I have read,
a private key is a 256 bit binary number.
private key ----------elliptic curve multiplication-----> public key
public key -----------sha256 + ripemd160 -----------> public key hash
public key hash -------base58 check encoding------> bitcoin address
now according to the above,
2256 private keys are possible
since elliptic curve multiplication produces a unique public key from each private key, an equal number of corresponding public keys are also possible. But, since the public key goes through RIPEMD160, the public key hash has only 20 bytes or 160 bits. Hence only 2160 bitcoin addresses are possible. Does this mean that each bitcoin address may be associated with more than one private key? Since, if each of 2256 public keys produce only 2160 hashes this means more than one public key produces the same public key hash.
I would appreciate if an expert could clarify this matter ?
A valid private key is not 2**256, it is between 1 and FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141, which is the order n of G on the Koblitz curve secp256k1 used in Bitcoin. The chance of a random 2**256 number not being on the curve is 1 in 267776665566007192515705986938822075895 or so, so pretty much the same thing as 2 256 for casual discussion. As you surmised, any given Bitcoin address is expected to have about 2 96 possible public/private keys. There are probably 2 160 Bitcoin addresses, but there is no proof that they all exist, and statistics about the chances they all exist aren't informed about how oracle-like ripemd160 might be when it is streamed 160+96 bits. |
|
|
|
|
The last page and a half is just signature spammers saying the same shit over and over again. Seriously, fuck you.
|
|
|
|
How can i select another platform for OpenCL?
I mean what will be the command for it?
The vanitygen client has command-line options -p for platform (if you have multiple versions of OpenCL installed), and -d for device to pick which physical CPU/GPU to run on. It also has a help option.
|
|
|
|
|
Show Posts
