text:
Why isn't transaction replacement supported?
The wiki article on contracts talks about the best stuff you can do with delays and replacement. (Lock time and sequence numbers, respectively.) But according to the documentation, replacement isn't supported yet. Why not?
(If the answer is "it's not implemented yet", why hasn't it been?)

That's not correct. The nLockTime field is implemented. It was deliberately switched off some time ago in order to reduce the complexity of the protocol. The reason was a series of protocol-based attacks that had compromised the integrity of the system.
At some point the feature will be re-activated. Probably, after someone has written a comprehensive test suite and technical analysis showing that it's not risky to re-enable.

Presumably by "That's not correct" you mean Thomas' answer, but the Stackexchange format does not make the context at all clear and immutable.

Is nLockTime really deactivated? Could somebody provide a source?

You can do almost everything on that Contracts page without needing transaction replacement.  Lock time does work today (as of Dec 2013), transactions with lock_time can't go into the blockchain until the time is reached.
Transaction Replacement is not supported because the developers have said that the whole idea of nSequence-based replacement is problematic, and may never be enabled apparently it causes potential denial of service problems.  They discuss it here:
https://bitcointalk.org/index.php?topic=131443.0
However, I don't think transaction replacement is really needed because sometime recently the developers made so transactions using lock_time and version < UINT_MAX are "non-standard".  What this means is that transactions using lock_time won't be relayed on the peer-to-peer network until the lock_time is reached, at which point you can push the transaction for relaying and it will be considered standard and able to go into the blockchain.
The reason I think this takes care of most use cases is because replacement was only needed when the locked transactions were being relayed, and stored in the memory pools, so if a transaction came along that wasn't locked, it wouldn't be accepted because replacement wasn't implemented, and the locked transaction was already in the mempool.  Since the locked transactions won't relay and store in the mempools now until lock_time is reached, I believe replacement is far less important, so the fact that it doesn't look like it will be implemented anytime soon is not a problem.

it's not implemented yet.
The protocol has these feature defined so they can be implemented in the future, but currently more important features are being worked on.
Fork the repo and create a patch to add support :p

Heres a site that shows nLockTime code implementation
whether it works or not I have no idea
Some say its implemented, others say its not
http://brainwallet.org/#tx


text:
Knowing a single transaction can you track down a Bitcoin user?
I have used this transaction to donate to Wikileaks. I have applied no special techniques to obsure my identity. How much information can find out about me on the blockchain. What tools would you use?
Can you guess the following information? Can you prove it?

How did I get the bitcoins I was donating?
What else did I use my bitcoins for?
What was my total bitcoin balance at a given time?
What wallet am I using?

Please try not to violate other people's right to privacy.

Knowing the Wikileaks donation address, one knows every address
that contributed to them.
Knowing a given address we are interested in, we can try tracing the coins back to when they were created (which can be harder if they
were mined by a large pool, in that case you'd probably get a lot of
origin blocks).
Given an address we know when it received coins and from what address.
If the particular wallet contained more than one receiving address, sometimes the addresses would be used together. If you have more than one address in the "From address", you know the person had to have them together in on wallet.

And now a bit of knowledge one can gain from outside the Block Chain:

A lot of people put notes like "My Bitcoin Address is: 1HWbVLhxj7bhewhyapMZpyhqWAeAhJd51E" in places like the forum. Then you can link the addresses to particular nicknames, and in some cases emails, names, facebook pages and so forth. If you use one address for everything, one can know if you contributed to Wikileaks, or other known addresses.
If one would have a big node in the Bitcoin Network that by chance would be connected to your Client when it sends transactions using the known addresses, one could potentially trace the IP of your computer. If you have a static IP, this can identify you.

So all in all, with enough resources, time and determination, one can know quite a lot about a given Bitcoin address. A lot of it can be mitigated with enough diligence, but some of methods might be quite hard.

Addresses can be grouped as belonging to the same user (or, better, same "account") by grouping together the addresses that participate as inputs to a single transaction, and doing it transitively. This has been done in the recent paper by Shamir and Ron, by some previous researchers and can be done by znort's parser. This is not 100 % accurate since it is possible for different users to sign different inputs to the same transaction, but currently people don't do that very often. (But this may change in the future.)
Using this method, the above-mentioned research determined that certain bitcointalk users donated to WikiLeaks just from their self-published donation addresses (event though they might not have used the same addresses for the donations).
For doing this analysis, one doesn't even necessarily need to know a transaction you created, it might be enough to know just one of your public addresses.
Se also this question.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Are there studies about a Bitcoin-like economy with inflation?
Assume, we create an alternative cryptocurrency ("InflationCoin") based on the bitcoin software with one change to the protocol:

The Block reward is constant, e.g. 50 InflationCoin

Technically this would work just like Bitcoin while avoiding one of Bitcoin's most discussed characteristic, namely built-in deflation. The supply of InflationCoin would grow constantly, possibly leading to a controlled and predictable inflation if the InflationCoin economy does not grow as fast the supply of InflationCoins. Transactions are always cheap and therefore encouraged. Hoarding is dangerous due to the risk of inflation.
Since, both unsing Bitcoin and InflationCoin is voluntary, they could coexist and possibly attract different users or usage scenarios.

I don't get why you consider deflation a problem and why you would actually want an economy with inflation. Personnaly I want my money to get value over time not to loose some...

Inflation or deflation doesn't matter unless you have enough money that has enough value. If you have less money that values more, then you will be exchanging fewer no of coins. With inflation economy you will have more money, and with deflation economy you will have less but the value remains the same.

The alternative blockchain Freicoin is a solution to the "deflation-causes-hoarding-problem" (assuming that you think this is a genuine problem) using demurrage rather than inflation.
As for your proposal of making the rate of money growth linear and higher than the expected rate of InflationCoin economy growth, that would accomplish the same goal: punish those who put their savings in coin rather than something productive like stocks and bonds.
According to Gresham's Law, Freicoin and InflationCoin should flourish as a medium of exchange and Bitcoin velocity should collapse as people tuck those relatively scarce coins away in wallets like they're bars of gold.
Of course, this isn't in fact happening. Maybe that's because of network effects (who accepts payment in coin of alternative block chains?) Or maybe the deflation theory is wrong.

It doesn't happen because anything that makes someone want to hold a currency more also makes others want them to part with that currency more. You can equally well, and thus not very well at all, argue that people should offer incredibly good deals in exchange for those scarce coins, thus making them change hands even more often.

@DavidSchwartz, ok so basically you are saying that the deflation theory is wrong right?

@Pacerier As applied to something like Bitcoin that is almost free to exchange, has an open market, and is effectively infinitely divisible, yes. It just cancels out.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
What prevents Bitcoins for being used to avoid taxation?
Today, states can follow money trails and transaction histories, usually involving checking bank accounts. As as I understand, It's impossible for anyone else to read your Bitcoin transactions and current balance without your consent.
In a Bitcoin world, how can a state monitor bank account when it's impossible to check their transactions?

How does it do this where cash is used?

It fails (usually), but at least they can track cash retrievals.

Banks are regulated by the governments and they have to comply with certain regulations that help track criminals. If it weren't for the government the banks would give a damn as long as they got their "transaction fee" - Governments are mostly conservative or aggressive - there is no cyber government yet. If you offered any head of state a Bitcoin they would respond: "What flavour is it.. its one of those chocolate ones, right?" Our governments suck with cyberspace. We get spammed, hacked, stolen identities, bullied, black mailed - and no body can do anything about it. Police? Buhahahahahah

Theoretically, a purely bitcoin-based economy would be as difficult to tax as a purely cash-based. So, hopefully, governments will take a Georgian view and tax only over land value to encourage users to use it and never let it idle...

What prevents Bitcoins for being used by criminals to avoid
  taxation?

nothing.  thats the price of anonymity:  it can be used for good and for bad.

In a Bitcoin world, how can a state tax its citizens when it's
  impossible to check their transactions?

in a hypothetical purely bitcoin world, the state would have to find different ways of funding itself, if it existed at all.

Can you imagine the day your payslip is in BTC? :) Doesn't change the fact that you still would have to pay income tax and social welfare(if social welfare exists in your country)

I don't think the government will accept BTC as a legal thing, because it can't be legally defined since it's consensus-based anyway

As is, the US has a voluntary income tax.  You fill out forms, determine how much you owe, and pay it.  If the government suspects that you're wrong, you get audited.  So with bitcoins, it would be the same.  You would determine your income and pay Uncle Sam his due.  But you have to pay in USD, not BTC.
Cash transactions and bartering income already have to deal with this, but with bitcoins the scale would grow.

Agreed, in the current state Bitcoins are bartered for, and the US requests that we declare the assets we own.  However, voluntary doesn't mean optional, there are penalties for assets that aren't declared etc.

Nothing prevents criminals from dumping their money into bitcoins, doing a few transactions, and pulling it back out as "clean".
Though, I guess if the gov't was smart enough, they would watch the criminals. Wait for them to transact with a major exchange (might have the exchange have to tell the gov't about large transactions) then see they are trying to dump this money into btc and stop the exchange from completing the request. Either by arresting the criminal or shutting down the exchange. But that is a whole lot of work just to catch a single criminal. It would only be worth it if millions were trying to be laundered. If so, as a criminal, you would split that up to try and not get caught, or fly under the radar.

This is a stretch.
But if the government really wanted to gain control over bitcoin and the economy they would have to do it like everyone else and gain 51% control over the network. With their wealth and power it might be easy for them to do, but at the cost of millions of dollars not going elsewhere in the state/nation.
And still with 51% control they cannot do much. They can only fork the blockchain(+ something more I am not sure of). But once that happens everyone will get wise and just not listen to them when they try to declare a block.


text:
How to ignore balance check to cancel unconfirmed transaction (double spending)
I need to cancel a transaction that was sent without fee (using Blockchain.info). It is currently "Unconfirmed". The only way I have found is to do a double spend of the whole wallet, specifying a higher transaction fee.
However Multibit and probably bitcoin-qt will not allow me to send more than my "balance". How can I bypass this balance check?
Where can I request a miner to include a raw transaction in a block (against a bounty)?
Thanks for your help!


text:
How to convert a WIF private key to a BIP32 extended private key
I am trying to recover the extended BIP32 master private key from its extended BIP32 public key (which I already know) and a WIF private key (which I obtained by decrypting a BIP38 seed with a passphrase).
I followed the steps described in this article from Vitalik Buterin, but to use the crack_bip32_privkey function in pybitcointools, I need to have a private key in BIP32 format (not WIF). I can see how to obtain a BIP32 private master key from a BIP32 seed (with bip32_master_key), but not how to do the same from a private key in WIF format.
How can I convert the WIF Private key into a BIP 32 private key (with Python, .NET or Javascript)?

You've already asked this question, and it was closed as a duplicate of https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child .

I have edited the question with what he actually wanted to ask about: https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child/56921?noredirect=1#comment65158_56921

You can't. The BIP 32 extended private key format contains information which is not present in the WIF private key. The extended private key format contains the chaincode of the private key, the index, and the parent fingerprint. Those information come from the derivation of the private key itself and cannot be found elsewhere.

In order to get the parent public key, the only information that you need from the extended public key is the index of the child. This can be trivially found by simply brute forcing through all possible child indexes (2^31 - 1 indexes) until you get a master private key which has a public key that matches the parent public key, or until you have derived the correct child public key from the parent public key.
Here is code that will find you the parent private key. This does the first technique of cycling through possible parent private keys until one is found which has a public key that matches the parent public key. Note that this may be completely inefficient and may take a long time to find a key. Also note that this only works if the child key is directly derived from the parent, not some depth down in the derivation tree.
from pybitcointools.deterministic import raw_crack_bip32_privkey, bip32_deserialize, bip32_serialize, bip32_privtopub
from pybitcointools.main import decode_privkey, encode_privkey

parent_pub = 'xpub661MyMwAqRbcEnKbXcCqD2GT1di5zQxVqoHPAgHNe8dv5JP8gWmDproS6kFHJnLZd23tWevhdn4urGJ6b264DfTGKr8zjmYDjyDTi9U7iyT'
wif_key = encode_privkey(decode_privkey('KyqcQVzcp7cHEMEDHQaz5eaE5azsRHaE4ukkeqwM2vdiQwBYtxeb'), 'bin_compressed')
for i in xrange(2**31 -1):
    priv = (b'\x04\x88\xAD\xE4', 1, 0, i, b'', wif_key)
    pkey =  raw_crack_bip32_privkey(bip32_deserialize(parent_pub), priv)
    final_key = bip32_serialize(pkey)
    if bip32_privtopub(final_key) == parent_pub:
        print final_key
        break

Excellent, this is exactly what I needed. Any idea on how to make it complete faster (e.g. days)? Right now it is going to take years :(. I looked into Cython but I would have to cythonize all the dependencies where time is spent. If you knew how to do this directly with the standard Bitcoin C++ library instead of Python that would be awesome.

It shouldn't take more than a couple of seconds unless your key has a really high index. However if the key is at a depth of more than 1 (i.e. the key is derived from a pubkey that is derived from the parent pubkey and so on) or it is hardened, then the process will loop until all possible indexes are exhausted and it exits with no key found. I suspect that is the case here. To deal with that, you should make sure the key is not hardened, and make sure that you are at the right depth. If not, you will have to derive public keys until you are.

OK, thanks a lot for the advice. I am actually using the two seeds and pubkeys (with depth 0, and "Bitcoin Master Public Key" as per http://bip32.org/  provided by Coinbase when generating a multi-sig vault. For each seed, I have been able to retrieve the WIF privkey, but its associated address is not the same as the address derived from the pubkey (with derivation path "Simple: m/i" and the correct index i which I know). So it seems the privkey I have is not the "Master private key", which I would need to derive the private key that has exactly the same address as the pubKey.

Without the right private key, I am unable to sign a message proving that I own the address associated with the public key.

What are you talking about and how is it related to this question?

Sorry for the confusion. I am just trying to provide some background information about how the keys have been generated initially. The objective of my question is to obtain a privkey for which the address is the same as the address of the derived pubkey at index m/14.

Right now I have: (1) a master pubkey in BIP32 extended format (provided by Coinbase), (2) a derived pubkey at index m/14 that corresponds to the address for which I need to prove ownership, (3) a private key in WIF format (provided by Coinbase when generating the vault, I don't know if it is hardened, nor the depth).

I am not sure how to enter them in your script and which parameters to change in the line priv = (b'\x04\x88\xAD\xE4', 1, 0, i, b'', wif_key) to obtain the BIP32 private key that will have the same address as the derived pubkey.

This looks like a case of an XY problem: http://xyproblem.info/. Having the two pubkeys and the coinbase user private key should still allow you to get the information you need, just not with the method you want to use. Since this is kind of off topic now, I suggest that you make a new question asking exactly what you want to do, not what you thought would work to get what you wanted to do.

Anyways, I'm guessing (not sure as I don't have access to my coinbase account right now to check) that the user key they give you is a private key which is then used to derive the private key that corresponds to the master public key they gave you. That derivation is probably a hardened derivation and likely uses the BIP 44 derivation path. So you should be able to just derive the private key that corresponds to the public key by using the BIP 44 derivation path, and from there just derive the private key that you need.

You're exactly right. I tried to generalize my problem but probably shouldn't have. I have posted the more appropriate question here: https://bitcoin.stackexchange.com/questions/57207/how-to-derive-the-private-key-associated-with-a-coinbase-multi-sig-vault-address. Thanks a lot for your help.


text:
Multibit Private Key Restore
I backed up my private key and restored it into a new copy of Multibit (difference machine). The import was successful but the public key address has not been updated with my previous address.
I've done "Check Private Keys" which said it was successful as well as forced a resync with the blockchain. None of my old transactions are showing up.
Any thoughts? No doubt I'm doing something wrong.
Thanks!
Edit:
Thanks for the response! I verified through bitaddress.org that the private key I exported only matches the bitcoin address automatically generated when I created the new wallet.
But the old private key that I IMPORTED into this same wallet is nowhere to be found. Multibit says the import was a success. If this is true there should be TWO private keys in the export file; one for the auto-generated bitcoin address and one that matches the old imported private key.
I'd love to take the private key in my original export file and paste it into bitaddress.org to see if it matches my public address but my export file is encrypted. So I have to import into Multibit, enter the password and then export it unencrypted to obtain the private key.
Does anyone know of a way to decrypt an encrypted private key file without using Multibit?

You mean your bitcoin address is different? Than you must've backed up the wrong private key.

Thanks for the response! I verified through bitaddress.org that the private key I exported only matches the bitcoin address automatically generated when I created the new wallet. But the old private key that I IMPORTED into this same wallet is nowhere to be found. (see edit)

For multibit classic, you can install openssl and use it in command lines to decrypt an encrypted private key file:
openssl enc -d -p -aes-256-cbc -md md5 -a -in multibit.key  -out key.txt  -pass 'pass:myPassword'

You can use an offline copy of bit address.org to check private keys against addresses if you want. It's the wallet tab.

effectively, with an offline copy, you can compare the private keys with the addresses if you want. It has served me in the past.

If you have encrypted wallet file with .key or .wallet extension you can use openssl to decrypt it using password. Then you will have your private key and you will be able to compare them with each other.
Multibit Classic & HD is unfortunately no longer supported so I will suggest to import your private keys into other wallet like Electrum

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
WIF Format and Storing Private Keys
I'm writing an Android app which will be storing private keys for Bitcoin and a few Altcoins in an SQLite database. To store my private keys, I was initially using the WIF. When I take them out of the database, however, I just Base58 decode them back into the 32 byte private key. Is there any real advantage to using the Base58 format for storing the keys in WIF vs basic hex encoding (0x12 to "12")? I know the WIF is useful for human transposition, but I'm specifically wondering about storage here.
So far, what I've come up with is that the Base58 format:

 Takes slightly less space
 Tells me what coin type the address is used for
 Has error checking
 Tells whether the private key is used for a compressed or decompressed address.

Items 2-4, however, are things that I could get from other entries in my SQLite database, so they're not critical. How does the Bitcoin-QT client store its private keys? I know when it dumps them to the user it gives them in WIF, but I'm wondering what it does internally to save keys on the machine and if I should do it the same way.

The Bitcoin Core client stores private keys typically  in DER encoded format, at 279 bytes per key, for compatibility with older versions. There is no good reason for that though. For encrypted wallets, which are more modern, keys are stored using just the (encrypted) 32 byte secret plus the full public key. Compression is derived from the length of the corresponding public key, so it doesn't need to be stored separately.


text:
How do SPV get their transactions after being offline?
SPV nodes rely on their peers to send them transaction data that is relevant to them. When an SPV node sets up a bloom filter with one of their full node peers, doesn't that only tell the full node which transactions to send the SPV node from now on?
How do SPV nodes catch up after being offline? Which p2p calls can they use to get their transaction info from their peers?

Block fetching requests are also filtered, so the client requests every single block they missed out on seeing since the last time they were last online, sequentially. The client downloads all block headers from genesis up to the current head using getheaders, sets a filter on their peer with filterload, and then downloads filtered blocks with getdata until they are in sync with the network. filteradd may be used in deterministic wallets to extend the filter to include more keys as used ones are discovered in their scan. When they are in sync, they will only receive new inventory that matches the filter.

So if a filter is set, then getdata will return partially filled blocks, with only transactions satisfying the filter inside them?

Yes. BIP37 is a good place to start.


text:
Bitcoin GetBlockWork() function
The implementation of GetBlockWork() in the bitcoin v0.9.3 source (https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.h#L815-L822) seems strange to me. The code is given below for convenience.
CBigNum GetBlockWork() const
{
    CBigNum bnTarget;
    bnTarget.SetCompact(nBits);
    if (bnTarget <= 0)
        return 0;
    return (CBigNum(1)<<256) / (bnTarget+1);
}

Why the +1 in the denominator?
And shouldn't the numerator be the maximum possible 256 bit integer, instead of 2^256?

I would expect the implementation to be:
CBigNum GetBlockWork() const
{
    CBigNum bnTarget;
    bnTarget.SetCompact(nBits);
    if (bnTarget <= 0)
        return 0;
    CBigNum bnMax;
    bnMax.SetHex("0xFFFFFFFFFFFFFFFF"); // Max 256 bit int
    return (bnMax / bnTarget);
}

This appears to be a function to calculate the average number of hashes needed to generate a particular block. (This is different from difficulty.)
I think this function is correct. To explain why, imagine that Bitcoin used 4 bit hashes instead of 256 bit hashes. This would make the range of possible values 0 to 15.
If the target were 15, that would mean that any hash would be valid. Therefore, it should take 1 hash on average to find a valid proof of work:
= (maximum possible hash + 1) / (target + 1)
= (15 + 1) / (15 + 1)
= 1

If the target were 7, that would mean that half of the hashes would be valid. Therefore, it should take 2 hashes on average to find a valid proof of work:
= (maximum possible hash + 1) / (target + 1)
= (15 + 1) / (7 + 1)
= 2

Remember, a proof of work is valid if it is less than or equal to the target. See also CheckProofOfWork().
I can't tell if this is used anywhere. This function appears to have been removed in the latest version.

So basically, the +1 in the denominator is because there are target+1 values that are less than or equal to the target, which makes sense. And the numerator is `1+maxtarget', because there are 1+maxtarget values that are less than or equal to the max target. This clears it up, thanks!

Hi, so eventually, based on recent litecoin source, how to code for actually mine the genesis block?  For example, this is based on version 0.8 litecoin source. https://pastebin.com/du2XdxCC   From this, how should be changed? Thanks.


text:
Double Counting SigOps to Prevent CPU Exhaustion Attacks
In the bitcoin v0.9.3 source: https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp
ConnectBlock() calls CheckBlock() as one of the first things it does. https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L1756. And CheckBlock() does a count of the signature operations that doesn't include counting P2SH sig ops in the inputs.
But then ConnectBlock() goes on to do it's own nSigOps count, this time including the P2SH sig ops (https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L1810).
Why doesn't CheckBlock() just include the P2SH sig op count to avoid code duplication between the two methods? Is it for efficiency? Or maybe backwards compatibility?
Thanks!

There's something unintuitive about Bitcoin transaction SigOp counting. Normally, the signature count of a block is calculated by looking at the scriptPubKey of each transaction and counting how many OP_CHECKSIG operations it contains. In other words, the SigOp count is gotten by looking at how many outputs you create, not how many inputs you redeem.
However, you obviously can't see how many operations a P2SH script does by looking at its hash. Instead, the transaction that spends the P2SH script "pays" for it.
The somewhat awkward thing is that you can't tell if a scriptSig is spending a P2SH output unless you look up the outpoint it's spending.

Why doesn't CheckBlock() just include the P2SH sig op count to avoid code duplication between the two methods?

I don't think it's for backwards compatibility. While ConnectBlock doesn't count P2SH SigOps for transactions that appear to be P2SH but aren't, that logic could be implemented in CheckBlock instead.
I don't think it's for efficiency. Rejecting blocks with too many SigOps isn't very common, since it takes about seven thousand dollars of electricity to make a block. I suspect that you could remove the SigOp check from CheckBlock for a very minor performance increase.
I think it's partially because it would be irritating to change. Getting the P2SH SigOp count requires access to the CCoinViewCache object, which isn't passed to CheckBlock.

Thanks, the use of the CCoinViewCache was what I was missing. Don't want to bog the CheckBlock() quick checks down with this slower check.

Also, why bother counting the scriptPubKeys' signature operations, shouldn't the sig op count be just the approximate count of signature operations to validate the block? And scriptPubKeys of a block don't necessarily need to be validated that block, the previous scriptPubKeys and the inputs do need to be validated.

@StephenM347 I agree, that would have made more sense. I don't know why they did it that way.


text:
How can I recover access to Ripple wallet
I have been 'playing' with my account at ripple.com. Among other things I tried to access another Bitcoin issuer (server, gateway?) by typing and saving WeExchange address in Advanced, Options, Web Socket. I think I may have typed in the incorrect address.
I was logged out and when I tried to log back in, I get "loading" icon shown 'forever'. In fact, I can't even get to the login page.
All in all, I cannot access my wallet/account anymore.
What can I do now? I filed a bug report at client GitHub but am hoping I may get a response here faster, plus it is not a bad idea to have the solution documented also here.
I am using Chrome on Windows.

Can't site admins do anything about this incessant downvoting with no arguments?

You don't need to connect your client to a different server to use a different gateway. One has nothing to do with the other. When you say "when I tried to log back in", what precisely do you mean?

Means: typed ripple.com in Chrome address bar, on page that shows clicked on Open Wallet in the top right corner, then on next page Existing users, access your wallet here, clicked on wallet here. The next page shows loading icon and stays like that. However, I have found a solution by editing local storage of that page with Chrome Developer tools. I could log in again after I edited websocket_ip and set it back to s1.ripple.com. I'll leave bug report GitHub link because many users wouldn't be able to figure this out.

A gateway runs a Ripple server, rippled, to promote the health of the network and to have their own a trusted interface to the Ripple network. per
wiki so it is really not correct to say that one has nothing to do with another. Unless something changed in that respect?

That's how the gateway itself accesses the Ripple network. It has nothing whatsoever to do with how other people access either the Ripple network or the gateway.

I see (I think). Since gateway can be a shop down the street it doesn't necessarily have http(s) address and http(s) address of its ripple server doesn't necessarily serve gateway clients.

Why was this downvoted? This is a valid client usability problem whatever I was thinking I may be connecting to when changing Web socket address.


text:
How can I sell BTC on Ripple com?
I have just been helped by a friend and got 300 XRPs (which quickly became 299, thank you) and then I transferred 1 BTC from another address to my Ripple.com wallet.
First Ripple.com shows 299 XRP and has an exclamation sign next to it, which clicked says "Your current account is low. You must keep a minimum of 250 XRP to use all the features of a ripple."
Great! I am about to trust somebody for whom 299 < 250 ? Or is it advance warning?
But I digress, that is the new world of cryptocurrencies, some of the worst Web and UI and database programming seen in the recent history, so a site that clearly says it is beta must be excused.
Okay, so now I am trying to sell my 0.5 BTCs for some XRPs. Whether I place BTC sell order at the current bid, or in the middle between current bid and ask I always receive;
Error: Transaction failed
You don't have sufficient funds

Please don't solict donations. See this meta post for more.

Okay, anyway that donation request was a joke on spending on the service.

FYI, it didn't become 299. It became 299.999900; the display truncates XRP balances unless you hover over the number.

FYI, the initial poster now has sufficient XRP in their account. (In case anyone was thinking they needed to or could help with a loan).

Is downwoter maybe a website developer who can't take criticism of his creation?

@user4354 no, there are some malicious users who don't accept the community decision to accept ripple's questions as in-topic and always downvote them. Silly kids.

@Lohis or maybe someone just didn't like the rambling ranty nature that only eventually got to a question :)

Your current account is low. You must keep a minimum of 250 XRP to use all the features of Ripple.

That is a warning shown whenever your XRP balance is less than twice the current reserve requirements. The number in the warning will also change as you add/remove trust/credit lines or add/fill/cancel trade offers.
The amount of XRP required to in reserves are listed on the Ripple wiki. Basically, the 250 you see is 200 for your account plus 50 for your trust/credit line to Bitstamp (that you added to get Bitstamp-BTC into your Ripple account).
To make a trade offer requires an additional 50 XRP (which is just a reserve, it becomes un-reserved when the offer is filled or cancelled). Since you had only 299.9999 XRP (not 299 as you said) Ripple was unable to create a new trade offer as the new reserve limit would have been 300. Yes, the error message is not as clear as it should be.
Whoever sent you your initial 300 XRP really should have sent 300.1 or 350.1 (or more). Although it is possible to get more XRP from BTC on a new Ripple account with only 250.0001 XRP, it's requires careful management of the limited XRP that shouldn't be expected of a new user. It's really best to start a new account with at least 350.1 or more XRP.

Can't upvote you with this reputation. Not intuitive or user friendly behavior anyway.

It's in beta, I'd assume/hope they're putting most of their effort into making the back-end server better so that they can open-source it rather than worrying about every little error message in the client, which will only be one client of many (the client is open source so you can fix it or write your own if you want).

The wiki link given in the answer has the current reserve requirements; they are now lower that what is shown in this answer.


text:
How can I use the vanity name generator to look for an address?
How do you use the vanity name generator to look for an address?
Is there an estimate on how long it takes to find addresses of varying lengths and complexities?

Proper syntax for VanityGen is:
Usage: vanitygen [-vqrikNT] [-t <threads>] [-f <filename>|-] [<pattern>...]
Generates a bitcoin receiving address matching <pattern>, and outputs the
address and associated private key.  The private key may be stored in a safe
location or imported into a bitcoin client to spend any balance received on
the address.
By default, <pattern> is interpreted as an exact prefix.

Options:
-v            Verbose output
-q            Quiet output
-r            Use regular expression match instead of prefix
              (Feasibility of expression is not checked)
-i            Case-insensitive prefix search
-k            Keep pattern and continue search after finding a match
-N            Generate namecoin address
-T            Generate bitcoin testnet address
-X <version>  Generate address with the given version
-t <threads>  Set number of worker threads (Default: number of CPUs)
-f <file>     File containing list of patterns, one per line
              (Use "-" as the file name for stdin)
-o <file>     Write pattern matches to <file>
-s <file>     Seed random number generator from <file>

The important options to know are -i and -r which cause the search to be case-insensitive and use regex, repsectively. In its simplest format, you issue a command like:
vanitygen.exe 1david
Which tells vanity gen to look for an address with the exact prefix "1david." On a single core of my core i5 this runs at about 325,000 keys per second as shown by the status display (which does show a time estimation.):
[324.43 Kkey/s][total 15166208][Prob 0.1%][50% in 9.1h]
Using the -i option drastically decreases generation time. vanitygen.exe -i 1david produced the following results in just a few seconds:
Difficulty: 36384905
Pattern: 1david
Address: 1DAVid3iW7XhDBzdoj8FbnaSaqWCjeTgUP
Privkey: 5JvtXtpUbwbNNqRoQjF3w2nyXHhphJk6LX1pWkPYEkBr4nnnBeL

The -r option allows the specification of a regex value instead of the default pattern option. If, for example, I demanded that my address contain all lowercase letters but I don't care if the "D" in "David" is uppercase or not, I could use vanitygen.exe -r 1[Dd]avid. One downside to specifying a regex prefix is that you will not be given any estimated time or probability data since such calculations are not as trivial as matching a simple prefix.
The more specific your matching criteria (and the longer the pattern) the longer it will take to generate your address(es). This can be sped up considerably if you have an ATI/AMD video card since there is also an OpenCL version of VanityGen which can try millions of keys per second on a decent GPU.

Is there a Mac version of vanity gen?

I don't believe the author of VanityGen provides precompiled Mac binaries, but the code does include a MakeFile for OSX so you should be able to compile it: https://github.com/samr7/vanitygen

FYI: There is also a version of vanitygen supporting Litecoin at https://github.com/dasher/vanitygen available!

@qdoe vanitygen supports any bitcoin-based address as long as you know which number to put to the -x switch, e.g. primecoin via -x 23 Amyvanity


text:
how to capture only one part of the getrawtransaction
I want to capture just one part of what Getrawtransaction returns, but it returns an array within an array that i can't seem to process.
I.e when

$txid =
'4f52e7769fe23059a4f0fa2b66ca0ba9595812654b90cc0526ddb9703a3e1b33';
$txidarray = ($rpc->getrawtransaction($txid,1));

then I can grab the whole "vout" array element(s) with  :

print_r($txidarray[vout])

;
i.e that returns :
> Array (
>     [0] => Array
>         (
>             [value] => 0.077
>             [n] => 0
>             [scriptPubKey] => Array
>                 (
>                     [asm] => OP_DUP OP_HASH160 efe11230ccff2380c3115e2826098931bb76ccef OP_EQUALVERIFY OP_CHECKSIG
>                     [hex] => 76a914efe11230ccff2380c3115e2826098931bb76ccef88ac
>                     [reqSigs] => 1
>                     [type] => pubkeyhash
>                     [addresses] => Array
>                         (
>                             [0] => 1NsN84QPXSXEdojiC482PnJUGNfx9XduQ6
>                         )
>
>                 )
>
>         )
>
>     [1] => Array
>         (
>             [value] => 0.02636684
>             [n] => 1
>             [scriptPubKey] => Array
>                 (
>                     [asm] => OP_DUP OP_HASH160 ae57d86c288389e086eadf1bc50998d86ad2828a OP_EQUALVERIFY OP_CHECKSIG
>                     [hex] => 76a914ae57d86c288389e086eadf1bc50998d86ad2828a88ac
>                     [reqSigs] => 1
>                     [type] => pubkeyhash
>                     [addresses] => Array
>                         (
>                             [0] => 1Gtqoz4tNTLYBR13AxypwsXupsevcy5QPq
>                         )
>
>                 )

But how can i grab ONLY  "1Gtqoz4tNTLYBR13AxypwsXupsevcy5QPq"  ???
I just want to get that address from the getrawtransaction for an txid !!
I tried :

print_r($txidarray[vout,0,scriptkey[0]);

but does not work, no clue as to what the correct syntax is !! anyone can help me ? many thanks !

Looks like you're indexing the array incorrectly.
Try:
print_r($txidarray[vout][1][scriptPubKey][addresses][0]);


text:
Notifications to watch only addresses in bitcoind
I found a similar question, but rather outdated in my opinion: How to get instant notification of any Bitcoin transaction involving a specific public address as recipient without knowing the wallet or private key
I have a bitcoind running, however don't have any funds managed by it. I want to run a script by any transaction, which is going to one of my (many) addresses. All the addresses are not part of the bitcoind wallet.
The following I want to achieve:

Configure bitcoind with a list of my addresses (not part of the wallet), might be around 200
Remove some addresses (if not needed anymore) from watch notifications
Notifiy a script when a transaction to one of my addresses arrives (mempool transaction, no confirmations)
Notifiy when a transaction gets confirmed (first time, maybe also sixth time)

My Setup:

Newest version of bitcoin core (can be updated)
Scripts in PHP (could be other programming language with bindings to bitcoind)

Basically, I want to get the notification to the respective script. All relevant information can be crawled via the RPC API. However polling the bitcoind needs to be eliminated.

You can use the importaddress RPC to add addresses without associated private key to the wallet. The wallet code will now list transactions involve such addresses, and include them in balance calculations (though you may need to add an extra argument for includeWatchOnly to some RPC calls).
If you import an address that has existing confirmed transactions, you'll need to rescan, which is a lengthy and slow process. If you make sure you're importing before giving out the address anywhere (for example, because they're being generated on an offline treasure machine which you control), it's perfect though.
You'll get notifications in all the normal ways for these addresses, including using -walletnotify (with a shell script executed for each received or confirmed transaction), and ZMQ (if compiled and enabled).

authors: Дмитро Степанюк


text:
To create a new bitcoin address cloned Bit-Wasp/bitcoin-php code
I am using code from GitHub.
Once I run composer its gives error as:

C:\wamp64\www\bitcoin-php-master>composer require bitwasp/bitcoin
  Using version v0.0.33.1 for bitwasp/bitcoin
  ./composer.json has been updated
  Loading composer repositories with package information
  Updating dependencies (including require-dev)
  Your requirements could not be resolved to an installable set of packages.

Problem 1
    - The requested package bitwasp/bitcoin No version set (parsed as 1.0.0) is
satisfiable by bitwasp/bitcoin[No version set (parsed as 1.0.0)] but these confl
ict with your requirements or minimum-stability.

Installation failed, reverting ./composer.json to its original content.

Since Bit-Wasp/bitcoin-php has its own composer.json file, after cloning you should just run:
composer install

If there is still some issue, run the following command to diagnose the problem:
composer self-update
composer diagnose

Otherwise report it at the project page.

You have to clear composer.json and try again.

Hi
Thank you for reply.
Not able to understand correctly about clear composer.json.
What exacts i have to do.


text:
What prevents a knowledgeable person from modifying their bitcoin data?
The average person would not have the knowledge, but what is the mechanism that stops a programmer capable of writing a wallet, from modifying the local bitcoin file/data to be, for example, 10 bitcoins instead of 1? Or maybe it should be - what prevents modification and then use of the data.

Bitcoin aren't stored on a machine, but they are held in a distributed public ledger known as the blockchain. The blockchain is a database which is replicated over the machines of everybody who participates by running the bitcoin software. This means that the database you hold locally on your machine is just a copy of the one which the network as a whole agrees is the correct and undisputed ledger.
The process by which all participants agree as to which chain is the true valid chain is called mining, which uses a Proof-of-Work mechanism to enable one participant to commit a new block to the chain approximately every 10 minutes. The process by which a participant is selected is pseudo-random and probabilistic, based on the amount of work they do, which generally corresponds to the amount of electricity they irreversibly consume to perform computation on the current tip of the chain.
The cost of electricity to perform work is one of the game theoretic elements of Bitcoin which keeps it secure, because it means that any participant who attempts to adjust the ledger to favor themselves will have to spend money and consume electricity, but their chance of success is extremely small, as they would need perform more than 50% of the total global work being done on the current tip of the blockchain in order to keep ahead of the honest majority. The majority of participants are honest because it can be profitable to be honest, but being dishonest is a loss-maker unless you are certain to have more than 50% of the global work being performed on Bitcoin.
The chain is secured by cryptographic hashes, so that any attempted change to any part of the ledger produces different hashes. Each block in the chain explicitly refers to the previous block header's hash, and this value is also included in the current block header. This means every block commits to the entire blockchain history, and any attempt to rewrite part of the ledger would require rewriting the entire history of the ledger from the point of modification. Rewriting the history would therefore require an amount of work in excess of the total amount of work which was performed between the block which was attempted to be modified and the current tip of the chain.
The ledger itself is a linear sequence of blocks which each contain a set of transactions, where one of the transactions in the set is a coinbase, which collects the fees of other transactions in the block, and which releases some previously unused bitcoin as part of a predetermined release schedule. Currently around 35/40 of all bitcoin have been released and the remaining 5/40 will be released gradually over the next 120 years.
The other transactions in a block are regular transactions which have inputs and outputs. The inputs of a transaction refer to the output of a previous transaction. The outputs contain a locking script, which is a set of preconditions which must be met in order for that output to become spent. Once a transaction output has been spent, it may not be spent again. This means that there exists at any moment, a set of unspent transaction outputs (UTXOs) in the ledger which are where all of the bitcoin in existence are "held".
The relationship to a wallet is where this locking script comes in. For all regular transactions, one of the preconditions to unlock the output and spend it is to provide a digital signature matching a public key which is stored in the output locking script. Only the person who has the private key corresponding to the public key is capable of producing such signature, and the message they sign is a hash of the transaction which they are attempting to spend - which ensures that nobody else can manipulate this transaction because it would invalidate the signature.
So a wallet is fundamentally a set of private keys which are used to unlock some bitcoin held in some UTXOs on the distributed public ledger. A wallet will compare the set of corresponding public keys against the entire UTXO set of the public ledger to determine which bitcoins are essentially "owned" by this wallet. The amount of bitcoin in set of UTXOs which the user can unlock correponds to their balance.
A regular bitcoin software will obtain a copy of the entire ledger and will listen for new blocks being added by other nodes - who broadcast them over a peer-to-peer network. Multiple distinct connections are used to ensure that peers do not present false or outdated information. Each time a new block is created, approximately one every 10 minutes, the wallet will download the block and look through its set of transactions for any which the wallet has the relevant private keys to unlock. Any which it can unlock are added to the balance, and this becomes newly received bitcoin.
To spend bitcoin, a user must select one or more UTXOs which they have the private key to unlock. They create a new transaction referring to these UTXOs as inputs, and they create a set of outputs which contain new locking scripts - usually by including the public key hash of the person they wish to pay, which comes from the bitcoin address which they use for that payment. The bitcoin amounts in the outputs of a transaction must be less than or equal to the amounts of the input UTXOs referred to in the transaction, with any difference being paid as the fee for the transaction. The user will then sign this transaction and broadcast it over the peer-to-peer network.
A transaction must be valid for any other node in the p2p network to accept it. This means that the participant who receives a transaction will compare the accuracy of the UTXO set against their own copy of the ledger. If you modify anything in your local copy of the ledger, it will not produce changes to the copy anybody else has. If you attempted to spend some amount that other participants do not agree that you own, then your transaction will be invalid and rejected by the network. It will never be included in a block, and the intended recipient will not receive anything.
In other words - any attempt to modify data locally can only attempt to fool yourself, but it can't fool others. Nobody accepts anything you say as truth - they verify it for themselves by verifying the historical accuracy of the ledger.

Mark’s answer is great and extremely comprehensive, but I think it’s worth adding a shorter version as well:
You are correct that anyone can modify the code of their local bitcoin wallet/node. If you wanted to edit wallet files to display a balance of 1 million BTC in your screen, you could do so.
However, the problem is that every single node on the network independently verifies the state of the network, based on strict rules about how coins are created, and who can spend them.
So, quite simply: every other node on the network would reject your transactions, since they would be obviously invalid according to the rules that all other nodes are following.

even shorter: https://en.bitcoin.it/wiki/Protocol_rules :-)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Can the sender of a MtGox code see which account the code is redeemed to?
In other words, if I receive a MtGox code and redeem it to my account, can the person who gave me the bitcoins, via the code, see that my account was the account that redeemed it?

Nope.  Or, at least, unless you are law enforcement and have a subpoena.
Or, unless you redeemed it yourself (which would list in your deposit history).
You can tell if it has been redeemed by redeeming it yourself and seeing if it had funds, but that's about it.


text:
Ripple two types of trust. Or no?
I tend to distinguish two types of trust:
a) I trust you to lend me XXX in quantity up to N units.
b) I trust you to borrow from me YYY in quantity up to M units.
However, ripple documentation appears to not make such a distinction. At least not clearly and explicitly.
Using ripple.com client I can trust someone to lend me, but I see no way to trust someone to borrow from me.
Can you help clear this conceptual hurdle for me?
I've been lending & borrowing all my life and never, ever was I confused about who owes me and whom do I owe. Now, with the advanced mathematical currency & exchange system I am not sure about that anymore.

Trust is an important concept. If you have fiat in your bank account you trust the bank to let you borrow your own money when you want to use it outside the banking system. When you do that they change an IOU number on your account balance. They just owe you less of your money.
original comment to which this was a response was deleted

Correction: redeem their owing you your money instead of borrow your own money

As far as I know, you can only trust people to "borrow from you", while you can't chose who will trust you to borrow from them. I too am concerned about owing money to random people just because they trusted you.

@Lohoris well, I transferred some BTCs from Bitstamp to my ripple.com account. I had to create a trust to a ripple address @Bitstamp to receive those BTCs. Ignore for a second that it was me transferring BTCs to myself. My interpretation of this is that I had to create trust to someone in order for that someone to let me borrow his BTCs from him. Incidentally, when people just send me XRPs or BTCs to my ripple address at ripple.com, or when I do the same to them, no trust setup is involved. I am definitely confused.

Couldn't find, nor write, a simple explanation, sorry.

The only risk would be that somebody owes you money and doesn't pay you back. If someone lets you owe them money, they are taking all the risk. You have to choose to take a risk, but normally you'd have no reason to want to control whether other people take risks.

a) I trust you to lend me XXX in quantity up to N units.

This is the type of trust you extend when you create a pathway.

b) I trust you to borrow from me YYY in quantity up to M units.

If you mean you trust them to pay you back, they would have to agree to pay you back and you would have to accept and act on that agreement. That would take place outside the Ripple system. The Ripple system just tracks balances, the terms on which those balances are paid back is outside the system.
I'm not sure why you would worry about someone giving you money without you having any agreement to pay them back. All the risk is on them.
And to this comment:

Incidentally, when people just send me XRPs or BTCs to my ripple address at ripple.com, or when I do the same to them, no trust setup is involved.

No trust is required to hold or transfer XRPs. They're a native currency in Ripple. And no new trust is required for someone else to transfer balances to you where that money is held by someone you already trust. You set up trust in the first place so that payments will "just work".
It's basically this simple: If you want to hold BTC on Ripple, pick a gateway you trust and create a pathway to them. Set a limit. So long as you don't create any other pathways or reach that limit, people can pay you BTC is by making that gateway owe them to you. If you create only one pathway for each currency and it's to a gateway you trust, everything "just works". You can receive payments from and make payments to anyone who is reasonably well connected.


text:
What are the ways to create an offline Ripple wallet?
Do I have to download/compile my own version of the client? Is there a difference between the Ripple and Bitcoin wallet address creation methods, or can I use, say brainwallet, also for Ripple?
Note: even if it is not correct, I use terms wallet and address interchangeably. I assume that wallet is just a (possibly encrypted) container of addresses and corresponding public/private keys.

Actually a ripple wallet, unless I'm mistaken, contains only one address.

Possible duplicate of one of http://bitcoin.stackexchange.com/questions/7849/what-do-the-fetch-wallet-options-when-opening-a-ripple-wallet-mean or http://bitcoin.stackexchange.com/questions/9002/how-do-i-backup-my-ripple-wallet or http://bitcoin.stackexchange.com/questions/9783/how-exactly-is-my-account-wallet-at-ripple-com-secure

None of the links answer the exact question: how can I create (not copy and download from the site that gave it to me) my own secure wallet. Offline means that I don't want to be connected to Internet while creating a wallet - say like using brain wallet JavaScript offline.

There are two components of making a Ripple wallet offline:

The blob vault
This is what stores the private key that controls your wallet. Other people can try to guess your username/password over the network, and if the blob vault isn't trustworthy, then it can do a much faster attack against it.
Install instructions: There is an install script included (serversetup.sh), but it will only work on Debian-based systems. You can get it to work on others by installing node, npm, and mysql server. Be aware that you also need to edit the script and replace PASSWORD with your actual mysql root password.
The ripple client itself
Copy it to a local webserver, and point your brower at it.

Be aware that you need to be online to see the balance of your Ripple wallet.

I am getting a more complete picture now, but I really need this and all three links (possible duplicate above) for it. Ripple address is public key and secret is private key. Blob vault entry contains wallet name, passphrase, public key, timestamp and IP. Private key is somehow generated from name and passphrase, but, since vault mustn't be able to do the same, it is either unique even for identical name and passphrase, or vault's copy of name and passphrase are already encrypted with private key. If wallet contains private key, then one may not want it stored remotely.

@Bitripple I really need this and all three links (possible duplicate above) for it.  I don't understand what that means. Private key is somehow generated from name and passphrase, but, since vault mustn't be able to do the same Actually, if the vault knows your password and username, they can absolutely steal your money. wallet contains private key, may not want it stored remotely. You might not. I agree.

I really need this and all three links means that only by reading the source code and all 3 answers I managed to understand how this works well enough. I am now trying to use brainwallet to see if I can generate my private and public keys from wallet name and passphrase.

Okay, since there is no answer for days already, I think this link contains probably the closest to one:
Description of credentials Blob Vault
One can set up his own Blob Vault or use a public one. Where is the source code for it, I don't know yet. Also not sure of exact relationship with Ripple address.

https://github.com/rippleFoundation/Blob-Vault You're correct that most of ripple isn't open-source though.

Why didn't you post that as an answer?

As of September 25, 2013, all of Ripple is open source.


text:
Decentralized transactions between two decentralized currencies
Currently, bitcoins and namecoins are implemented using the Bitcoin protocol. And there might be several reason for new block chains to appear, but this is not the subject here.
As far as I know, Bitcoin was not designed with ‘cross-currency atomic transactions’ in mind.
For example, as of today, one cannot exchange bitcoins for namecoins using the Bitcoin protocol itself.
A partner might be willing to trade, but some trust is required: who will send their coins first ?
Given that the main interest in Bitcoin comes from its decentralized nature, accepting the need of a third party to arbitrate exchanges between two such decentralized currencies is rather disappointing.
Is there anything to be done to allow ‘decentralized cross-currency transactions’ using the protocol itself (scripts maybe)? or could it be achieved with some simple modifications to the protocol?
Is this theoretically impossible under some specific conditions?

I have actually been working on this exact problem. My motivation is to achieve a slightly different effect than what you're asking about.
I'd like to be able to "move" some Bitcoins to a different hash chain, allow them to be exchanged in that hash chain (as Bitcoins), and then I'd like the final holder to be able to "re-import" the Bitcoins back into the regular hash chain. The goal would be to create "side-chains" with faster block generation times useful for smaller transactions. (They could also 'expire' after a few months and be forgotten, reducing the size of the permanent hash chain.)
But the basic problem is the same. You need the legitimate holder of some Bitcoins to depend on a fact verifiable only outside the Bitcoin hash chain. In both cases, the existence of a transaction in another hash chain. (In my case, a Bitcoin hash chain but not the Bitcoin hash chain. In your case, another currency's hash chain. But the principle is the same.)
The problem is that the Bitcoin design requires every client to be able to validate every transaction, as they must track coins all the way back to their origin to confirm their validity. This means a transaction must be verifiable with only information every client should have -- and that means only information in the Bitcoin block chain.
A third party could put this information into the Bitcoin hash chain. But you'd have to trust that third party, defeating the point.
I have thus concluded that no solution is possible, unless someone has an idea that breaks my assumptions. I hope that will happen, but I am not clever enough to think of it.

Thanks for your answer. Interestingly, I had also been concerned with "side-chains"! For example in this thread.

Is this still the case? I could swear there was some technical solution to this problem.

There is an ongoing project called DarkExchange which aims to decentralize the trade process. It's not so difficult a thing to decentralize BTC<->NMC exchanges and the like, the real problem is exchanging for fiat, where someone has to be on the "edge" to make the actual transfer it still comes down to trust.

Should I read the source code to know what it does/how it works? As far as I could understand from the wiki page, it's just a way to make people communicate, not a way to issue transactions safely.

Yeah, it's somewhat less like MtGox or TradeHill and a bit more like #bitcoin-otc in that it matches individual offers. For example if I want to buy 100 BTC at MtGox and no single person is offering that much, MtGox automates the process of making the 10+ trades I might need to perform to get all 100 BTC. DarkExchange will show me all of the people willing to make trades at my price and it's up to me to pick and choose the trades I'd like to make. Not exactly fully-featured just yet, but it is a pretty young project still.


text:
Continuous integration setup using bitcoind regtest on travis-ci
Subtitle: travis-ci fails to run generate JSON-RPC method on regtest
I'm trying to setup CI process on https://travis-ci.org platform to install bitcoind and start new blockchain using regtest mode.
I want to do this to run unit tests of my applications which uses wallet data. Methods against bitcoind are working fine except the generate method which is needed to mine some bitcoins in regtest private chain.
It looks like some bitcoind/travis-ci related issue.

generate method is working fine in my local CI process (non-travis).
Travis-CI is working fine if I comment the generate method call in CI tests.

generate method call when using travis-ci fails with the following error:

{"code":-32601,"message":"Method not found"}

bitcoin.conf:
server=1
regtest=1
gen=1
rpcuser=someuser
rpcpassword=somepass

.travis.yml:
language: r
sudo: required

before_script:
  - sudo apt-add-repository ppa:bitcoin/bitcoin -y
  - sudo apt-get update -qq
  - sudo apt-get install bitcoind -y

r_github_packages:
 - jangorecki/rbitcoind

after_script:
 - cat $(find . -maxdepth 1 -name "*.Rcheck" -type d)/tests/tests.Rout

Is there any trick in setup I should use to make travis-ci capable to run CI on regtest chain, including generate method?
Leaving the build links just for reference:
- generate method commented - CI passed: https://travis-ci.org/jangorecki/rpc.generate/builds/77207297
- use generate - CI failed: https://travis-ci.org/jangorecki/rpc.generate/builds/77208666

v0.11.0 and after:
Check and make sure that your daemon version is v0.11.0 or greater. If it is, the generate method should work.
Pre v0.11.0:
The setgenerate true method should be used.
In a standard network (such as testnet or main), setgenerate true will turn mining on indefinitely. In regtest, it just mines one block. You can also do
setgenerate(TRUE, 10)

To mine 10 regtest blocks. The second parameter is called the generation limit.

according to the generate method reference the method should be used especially in regtest mode to mine blocks instantly without the computing cost, and that feature is a must for a platform like travis-ci. If you are asking for generate() body see this. It just works on two CI environments: ubuntu and vm ubuntu.

@jangorecki That must have been added in v0.11.0, I'm currently running v0.10.2. The release notes don't say that a generate method was added, though. What version of bitcoind are you running?

OK, I see I have 0.10.2 on travis, this is the reason of no method found. I'm using same ppa so it should get the latest version of bitcoind, isn't it? you can put info about version to your answer so I will accept it. Thanks

@jangorecki I guess the ppa is out of date. It's only one version out of date, at least. I have updated my answer to include version info.

https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin did they stop builds for ubuntu 12.04?

No, builds failed for 12.04, and they were never fixed.

@MattCorallo is it so difficult to make them work? this would allow any github project which uses travis-ci to run unit tests against own blockchain, quite a huge extension.


text:
How to find values of Prev_Hash and Tx_Root
https://bitcoin.stackexchange.com/a/13347/27951
Based upon the answer here, it seems there's values per block with each Prev_Hash and also Tx_Root
There doesn't seem to be much documentation for how to access these. How can I find the Prev_Hash and the Tx_Root of the most recent block for example?
Thanks

Do you want to access the values from code? Or just see them? You can see the values on a block explorer, but to decode the values from a raw block you'd need to understand the message protocol format.

I'd like to see them for now but additionally access them by code eventually. I've found the getblock method which can be used to display the merkle tree, but how do I find the blockHash parameter to pass to that method, for say the last block or last 10 blocks? Not sure where I can find those blockHashes

Look at a block on a block explorer.

Here the Prev_Hash is called 'Previous Block' and the Tx_Root is called 'Merkle Root'.
For more technical info, take a look at the Protocol Documentation.

Awesome, thanks. Can I use getblock to access this via the Blockchain API? And also how can I find the hash of the latest block? Thanks!

I'm not an expert on Blockchain's API, but their documentation is here: https://blockchain.info/api/blockchain_api. For the latest block, it looks like you can use: https://blockchain.info/latestblock.

Whoops, I meant to say use getblock to access this via the Bitcoin API, typo.

You mean the Bitcoin Core RPC command getblock? Yes, it reports those values.


text:
What is the proper way to authenticate to Bitcoind for multiple users?
This question was asked here: Bitcoind and multiple users but its answer is a link to a deprecated feature.
If I am running bitcoind on a server and want it to manage multiple users, what is the proper way to authenticate to that server and have separate user accounts, or should I implement user accounts on my own end which interact with a master bitcoind instance?

You should implement it as a separate layer.
Bitcoind doesn't really support multiple users.  It lets you set a single username/password to connect to the RPC server, as well as encrypting the (single) wallet with a passphrase.  But there's no way within bitcoind to have individual authentication credentials that will allow one to spend some of the coins in the wallet but not others.
So a typical way to do this would be to have bitcoind store all the coins of all the users, pooled in a single wallet.  Then your software has to track how many coins belong to each user, authenticating the users, and ensuring that they can only spend those coins which are credited to them.  (The accounts feature might have helped with the first of these, but not the others.)
Alternatively, you can run a separate bitcoind instance for each user, but this will require more resources.

Okay, that's what I was thinking. Sorry, I'm relatively new to the Bitcoin API, do I use it to create a new wallet address for each user, and then track deposits made to that address and use that to credit the user, despite the fact that all of the wallet addresses end up in the single pool?


text:
Electrum wallet shows zero balance
I sent bitcoins to an offline (air gapped) electrum wallet.  I have blockchain.info proof the transaction took place and verification of the balance in the wallet (i used a watch only address to view balance and transaction history of offline wallet)  BUT electrum online wallet synchronizes but does not show updated balance information.  Electrum can find the funding transaction from the blockchain by the transaction id (Tools->Load transactions-From the blockchain)
Electrum 1.9.8
debian jessie (kali 2 sana)
via socks5 thru tor
resources consulted - none have a working fix
1.
Why I am not seeing received money in my electrum?
wallet.clear_history() does not solve the problem for me
2.
https://github.com/spesmilo/electrum/issues/1525
3.
https://bitcointalk.org/index.php?topic=1221590.msg12943509#msg12943509

did you check that the offline wallet has the same addresses as the online wallet?
btw, please upgrade Electrum, version 1.9.8 is too old.


text:
Where can I find the current Ripple version number?
This page contains several milestones - versions 1,2,3.
How can I find what version is currently running on Ripple.com?

Wow, I never realized we had those!

Start the client at http://ripple.com/client, the version number is written at the bottom.
Currently it's 0.1.17


text:
Do the various Ripple clients leak any data about account names?
If I use the official client at Ripple.com, and add someone to my contact list ... does the information "I believe that X's Ripple address is Y" get stored anywhere in unencrypted form? Is it broadcast to any central server?
I assume the answer is No, but I want to get an official confirmation. (These days many websites log a lot of user actions, my expectations from the Ripple client is that it does not).

The answer is no. Notations are stored only in your wallet which is always encrypted using your username and password.


text:
CheckProofOfWork() Linux error on old altcoins
I've seen the following error on Linnux online with several old altcoins now, the one below is UFO coin. It will sync exactly 500 blocks and then throw the following error, if I restart the client the error on that block does not reappear and it downloads a further 500 blocks and throws the exact same error.
I'v added a few extra lines to get some additional debugging info. Before I spent time crawling through code I was hoping that someone else may have come across this same error and found the reason. UFO is several years old and current Windows clients are running OpenSSL 1.0.1h, services running were probably compiled around the time of that SSL release. The server with this issue is running OpenSSL 1.0.2g.
CheckProofOfWork() bnTarget.getuint256=000000050e650000000000000000000000000000000000000000000000000000
SetBestChain: new best=f7c2f4f28e66399bc17e0e35498300c20bf384d210ce8c5d640b70d9a3dfe372  height=17000  work=68218691770398  date=01/23/14 03:00:50  tx=2 ProcessBlock: ACCEPTED
received block 93f88d57ab19ae388e22
CheckProofOfWork() hash=bf82aa6e76ec014faf5bc9c347eb5ba8242545acdf09259ac753b8d264aec0f0
CheckProofOfWork() nBits=486629382
CheckProofOfWork() bnTarget.getuint256=0000000160060000000000000000000000000000000000000000000000000000
ERROR: CheckProofOfWork() : hash doesn't match nBits
ERROR: CheckBlock() : proof of work failed
ERROR: ProcessBlock() : CheckBlock FAILED

Edit: Compiled it with OpenSSL 1.0.1u and have the error.

That error simply means that the block is invalid as the proof of work is incorrect. That has nothing to do with OpenSSL versions. The difficulty of a block is specified by the nBits field of the block header, and the block header must hash to a hash that is less than nBits. What is happening here is that the block hash is not less than the nBits, so the block is invalid.

So is it fair to say he is doing nothing wrong and that warning will go away within time ?

No, it is not fair to say that.

so why would the blocks hash not be less the nBits ?

authors: Иванка Цогла


text:
Is Bitcoin's Economic Majority those who already own coins or those who will buy or keep coins?
The Economic Majority theory says that the power to control the Bitcoin protocol is held by those who [own] bitcoins.
But the article then goes on to read:

The ability for a protocol change to be successfully implemented
  ultimately rests with those who accept bitcoins in exchange for value.

So that refers to investors and those who accept bitcoins for income or revenue but then aren't immediately spending or cashing out the coins they received.
But that power doesn't lie with those who already hold the coins but instead it lies with those who are willing to accept the newly issued coins under the revised protocol or coins with taint from coins issued under a revised protocol.
So, is the Economic Majority those that already hold bitcoins or is it instead just those who will hold the bitcoins generated following a change to the protocol?  If so, how would that be best worded?

The economic majority includes both.
Components of the economic majority include those who hold bitcoins (who might be referred to as "old money") as well as those wishing to acquire bitcoins (who might be referred to as "new money").
Many who are "old money" will have lent out bitcoins.
The loan agreements will likely have the stipulation that if the rate of currency issuance varies, the repayments would need to be adjusted somehow -- affecting the principal and/or interest to be repaid.  If there were to be a fork in the protocol where repayment was attempted with devalued coins, the lender could insist on repayment of coins that follow the protocol that was in force at the time when the loan was agreed to. (Essentially, coins that have no significant level of "taint" that exists after the fork).  If the lender won't accept the devalued coins then the coins generated under the changed protocol are of no value to the borrowers.
So those who lend out their coins are essentially "buyers" of coins at future points in time (when the repayments occur) and thus are represented in the economic majority just as much as those considered "new money" who wlll buy from the next block of coins.

Each entity's weight in the economic majority is closely related to its ability to devalue the coins in the protocol version they are against.
People (and their proxies) who are willing to offer goods or services (including traditional currencies) for Bitcoin can refuse to accept coins of the "wrong" protocol, while people who hold bitcoins can sell coins of the wrong protocol.
A detailed analysis might reveal the impact each of these groups has, though I suspect the former group has an advantage.
(Personal note: It's been said that I coined the term "economic majority" in this context. When I originally used it I meant the former group.)

How is a transaction that spends on the "wrong" protocol not also a valid transaction that confirms on the "right" blockchain?

Oh wait, that's easy.  Simply include as an input a UTXO that doesn't and won't exist in the "right" blockchain ... e.g., one whose coinbase is from the "wrong" blockchain.


text:
Dumpprivkey or dumpwallet won't show my private key for the address in my wallet
Haven't opened my wallet in a while so it's not in sync with the network. 5400 blocks remaining as I write. The wallet is not encrypted.
Received some bitcoins to my address in this wallet. Now I want to get the private key of the address and import it to my wallet on blockchain.info
The output of pywallet's dumpwallet command shows a lot of address/private key pairs but none of them are the address I see on my address book which I received the bitcoins to.
Launched BitcoinQT's debug window, tried the dumpprivkey command. Result: Private key for address is not known (code -4)
Thank you.

There are at least two versions of pywallet.  If I remember correctly Joric's works with compressed public keys, JackJack's does not.

The problem was not a technical problem. More like stupidity.
The address I received the bitcoins to is not one of the addresses in the address book. The address book is like your contacts on your phone. Your actual addresses are under the receive coins tab.
So I saved someone else's address to my address book for whatever reason. Then I was trying to extract the private key of that address from my wallet which of course I could not.


text:
How does a time warp attack work?
I more or less understand how an attacker (with less than 50%+1 of the hashing power) can artificially lower the block difficulty by messing with timestamps. I also understand how such an attacker could, on his own chain, at one point "ramp up" the difficulty of his last blocks to match the current chain's difficulty (I've read the other questions containing the time-warp-attack tag). What I don't understand is how at one point his chain, with less total chainwork, can be accepted by the network.
Say we're at block 100 on the honest chain and an attacker crafted a fake chain starting from block 50. He's now at block 105 and his block 105 has the same difficulty (that he ramped up) as the honest's chain 's block 100. He decides to broadcast his chain and he "wins" because he succeeded with his time warp attack (the question here is not about the feasability, budget-wise, of pulling such an attack today on the Bitcoin network: it's about the technical aspect of the attack).
What I don't get is that the honest chain has more total chainwork from block 50 to 100 than the total chainwork on the attacker's chain from block 50 to 105. The attacker, in the case of a time warp attack, has less than 50%+1 of the hashrate. So it's impossible for him to come up with x blocks that have more total PoW than the y blocks that the honest majority have mined meanwhile (even if he has more blocks, without 50%+1 he simply cannot have more chainwork than the honest majority).
So how comes that this re-org is accepted by the clients? When there's a re-org of the chain of several blocks, ain't the total chainwork of both chains compared?

Does this answer your question? What is time warp attack and how does it work in general?

When there's a re-org of the chain of several blocks, isn't the total chainwork of both chains compared?

Yes, that's true. In fact, that's how a reorg of any size is considered. However, that wasn't always the case. In the first version of Bitcoin, the client compared purely by chain height. In version 0.3.3 (released July 2010) we switched to comparing by chain work. Today, you can't pull off a timewarp attack without a majority of hashpower.
However, let's say that you did have a majority of hashpower. What could you do with a time warp attack? You could mint an arbitrary number of blocks, and get more mining reward than you're entitled to. You could prevent the timestamp from advancing.


text:
Does Proof of Existence lose bitcoins?
http://www.proofofexistence.com/about -- "Use our service to anonymously and securely store an online distributed proof of existence for any document."

The document is certified via embedding its SHA256 digest in the bitcoin blockchain. This is done by generating a special bitcoin transaction that encodes/contains the hash via an OP_RETURN script. This is a bitcoin scripting opcode that marks the transaction output as provably unspendable and allows a small amount of data to be inserted, which in our case is the document's hash, plus a marker to identify all of our transactions.

Naïve question perhaps, but if the bitcoins are lost forever, this seems like an unfriendly use of the bitcoin protocol and the blockchain, and future versions of the protocol may prevent this type of transaction from being accepted into the blockchain?

Well, it's probably not an intended function of the block chain, but I wouldn't call it "unfriendly" because you're not really harming anybody (by reducing the total amount of bitcoins available you're in fact increasing the value of all other bitcoins a little).

[...] future versions of the protocol may prevent this type of transaction
  from being accepted into the blockchain?

No, because it's not possible. The transaction encoding the document hash looks exactly like any other normal pay-to-address transaction. The only difference is the address which is a representation of the document hash instead of a hashed public key, and therefore there is no private key associated with it (that's why it is unspendable). You can't go back from a hash to it's origin though, so you will never know whether it's spendable or not.

i think the key point is that there is no way of knowing (from the point of view of the miners including these transactions into a block) that the to-address (document hash) has no private key.

Just to give a quick update on this, it is no longer necessary to "burn" bitcoins when creating a proof of existence. The OP_RETURN opcode re-enabled in Bitcoin Core 0.9 can be used to carry 40 bytes of arbitrary data. The coin associated with it will be added to the transaction fee and can be claimed by the miner.
Reading the about page it seems proofofexistence.com are already using it.
Edit: According to Nick ODell's inquiry answered by core developer Jeff Garzik, this coin cannot be claimed by the miner.

added to the transaction fee Do you have a citation on that? I haven't heard anything like that.

I know it's not an "authoritative source", but seems pretty legit: "Interestingly, any value associated with the coin can be claimed as a miner fee."

I asked #bitcoin-dev, and Jeff Garzik said no. http://pastebin.com/5txuBhGP

Thanks Nick, I've edited my answer. Will ask the author of the cited article for further explanation.

Alright, the author of the article has acknowledged this and corrected it. Thanks again Nick, it's really important to get this right.


text:
If I were to generate an address and it happens to collide, legally speaking, would a transfer constitute theft?
Let's say that somehow I generate a new address which happens to already be "taken". I realize the chances of address collision are extraordinarily low as per Is it possible to brute force bitcoin address creation in order to steal money?, but let's just say that it happens.
For argument's sake, let's say I land on 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF (currently carrying a balance of about 80,000 BTC).
If I were to then sign a transfer to another address, would I be doing anything wrong or illegal? I think it'd be immoral, but does it constitute any legal wrongdoing?
I don't think this is quite like finding an ATM card and guessing the PIN, but more like walking into a Swiss bank, guessing a random account number and PIN, and walking out with whatever is in the safety deposit box, right? Is that "stealing" ?

Luckily, the chance of this so low that you're more likely to win the lottery several times in a row before you stumble upon somebody else's Bitcoin address.

@NayukiMinase True, but what about the recent incident where Blockchain.info was using the random.org error message to generate entropy? (ie the same entropy each time = the same address)

Ah, I did some research and it seems the Blockchain.info mobile app was misusing Random.org as an entropy source, not checking HTTP status codes, and other logic omissions: http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/

IANAL.
What you describe is the act of taking something that isn't yours in full knowledge that somebody else invested effort and money to accumulate it.
Just as with your Swiss bank example: The rightful owner would be losing the funds that you misappropriated. Taking someone's property without their consent is theft.
I feel that this is independent of the way by which you gained access to the property, but rather derived from the intent of your action.
Perhaps more ambiguous would be scenarios where somebody receives a transaction to a key that you also control, or when you stumble on a key that has a Bitcoin balance that hasn't been moved for decades and could reasonably assumed to have been lost by the rightful owner.

Adding my owner answer here thanks to some input from @Wats0ns and @Murch.
IANAL.
Let's say the following happened:

I generate a key pair that collided with an already existing address.
That address happened to have a balance.
I signed a transfer to a new address under my (and only my) control.
In that transfer I put my contact information (and proved after the fact that I had the private key and had done exactly as everyone suspects, crazy I know).

I'd expect:

The other owner to claim they owned the address via a digital signature (the only way you can claim to own an address).
The other owner to show either that they owned the previous incoming addresses or that they traded with others to result in the funding of the address in question.
The other owner to sue me for those coins back, and press criminal charges for theft.
I would use a "Claim of Right or Ownership of Property" defense for the theft charge.
I might lose the civil case and have to return the BTC.

For the theft charge, my argument would effectively be, "I thought I had just as much right to the coins as they did. We both generated a key pair, and the key pair is how you 'own' an address or any BTC the ledger says belongs to that address. I didn't act maliciously in generating the address, I didn't hack a computer and steal the private key, I just happened upon it."
I think that might be a reasonable amount of evidence to show "I thought it was mine" and hopefully that'd keep me out of jail.
I have no idea what a court would decide in the lawsuit as I don't know of any case law that comes close to this. Maybe it's like a bank accidentally adding you as a co-signer to someone's bank account (not heard of any cases involving this)? Or making an invalid deposit to your account (which does have case law, and you have to give the money back IIRC)?
Either way, I'd be willing to bet that the BTC would have to be returned, but it could be a coin flip...

Could you get away with it? Probably. Laws have not caught up to Bitcoin. It would be better to do the right thing, and just click one button and generate a new private / public key pair, and move along.
It's like finding money in the street, except you know that the person who lost it is walking back to find it. Can you grab it and run? Yup. Should you grab it and run? Nope.

Owning a private key is the way to control the spending of coins. It should not be defined as legal ownership.  People tend to give too much credit to the anonymity of bitcoin.
 But assuming you can find and take a person to court who hit the lottery by generating an already used wallet address, you can plead your case to the judge.  If you mine coins or purchase them you have documentation proving that they are yours by showing a chain of accumulation evidence.  That,imo, would be better proof than simply possessing the private keys and suddenly having thousands of coins.
Take aways:
1) better to steal smaller numbers of coins than huge wallets to get away with the theft.
2) better still, if it isn't yours, (ie. you mined, it was gifted, or purchased with your own funds...) then you know it's stealing to take it.
3) Lost coins/private addresses.  How would you know for certain?
If you found a paper with a private key written on it you may have a better defense for taking ownership. But does that ever happen?

I don't think so:

Theft :  the act of stealing; specifically :  the felonious taking and >removing of personal property with intent to deprive the rightful owner of it
  (from http://www.merriam-webster.com/dictionary/theft)

Stealing implies taking something that doesn't belong to you, but how do you define ownership of Bitcoins ? You own Bitcoins by owning the private keys, and only so.
So if you ever find the private key of this address (good luck, BTW), you'll become an "owner" of this address, and of the Bitcoins "attached" to it, so transfer wouldn't constitute a theft.

By similar logic, ownership of cash is defined by physical possession, therefore pickpocketing is not theft; it is merely a nonconsenual transfer of property.

Well I think I explained badly. You can easily define to whom belong money on a bank account or cash, but because Bitcoin is pseudo-anonymous, it's hard to define ownership. If OP find the private key of an address (without looking for it, otherwise yeah, that would be a theft), in my opinion this wouldn't constitue a theft.

The "owner" of address with balance is person who holds "Passphrase" and Private key!!! If you have private key and you don't have "Passphrase" for address private key in that case you're a Theft!

maybe i misunderstand. but: if you have the private key of your address you have access to your funds. also without any passphrase.


text:
Question regarding the number of bytes in an OP_RETURN transaction
I was reading this very useful explanation of what an OP_RETURN transaction looks like and got tripped up by part of it.
        "hex" : "6a13636861726c6579206c6f766573206865696469"

This first byte it followed by a byte which represents the length of the rest of the bytes in the scriptPubKey. In this case we see the hex value Ox13, which means there are 19 more bytes.

But there are 38 bytes following the hex value 0x13. Why the discrepency? I'm pretty sure I'm missing something obvious and I'd have asked in a comment on the answer itself but I haven't enough rep points. Thanks in advance.

I found the answer on Wikipedia:

One hexadecimal digit represents a nibble, which is half of an octet
  or byte (8 bits)

So two hex digits per byte. And a "nibble" for half a byte. I like that. :)


text:
A friend owes me cash, how can he pay that debt in btc?
A friend owes me some money and we agreed to settle that debt in bitcoins. How can he transfer some bitcoins to my account, without me having to pay him for it?

You and your friend need to agree on the bitcoin-to-fiat exchange rate, and assuming he/she is already in possession of the required amount of bitcoins, he can just send those bitcoins directly to your bitcoin wallet.
If you don't yet have a bitcoin wallet you can just download one, like multibit (https://multibit.org/), create a receiving address and give it to your friend so he can send the bitcoins to you.
Once you receive the transaction, and after 3 or 4 confirmations from the bitcoin network, you can assume the debt is settled.

You only have to do a simple transaction. You have to create an address (for example, this one (which is mine): 1CnCc2Dp35BZboHE8AZvoyrQXCFFaHUvTZ) and tell him to transfer Bitcoins to that address.
You dont have to pay anything for the transaction, but your friend need to pay the transaction fee.


text:
Is it computationally feasible to find two transaction IDs with the same first 20 bytes?
Transaction hashes uses sha256, so they are 32 bytes long. If I have to store a very large database of transaction hashes, only for the purpose of checking existence later on, is it really necessary to store all 32 bytes? If i store only 20 last bytes and I compare transactions using only those last 20 bytes, would the crypto guys get mad?

Is it computationally feasible to find two transaction IDs with the same first 20 bytes?

20 bytes is still 160 bits of security, which is considered very secure. If you are sure that you only need the IDs to check for existence, 20 bytes of the hashes should be fine.
Hard drive space is pretty cheap, though, and you might need the full TXID someday just for interoperability between other systems. So make sure 20 bytes really does satisfy your use cases. A 20 byte hash is sufficiently secure, though.

I guess it depends on what you want to do with it. If for example you're using those 20 bytes as keys in a lookup table, then you should be fine as long as you remember you might get an occasional false positive so you always double check if it really is the transaction you were looking for. For that purpose less than 20 bytes is probably already enough.
If 20 bytes is everything that you store while throwing away everything else, and you make important decisions based only on those 20 bytes, then you might run into problems at some point.
Remember that it's not mere chance. If your application plays an important role and an attacker knows about your 20 bytes limitation, they might try to forge 2 conflicting transactions IDs to and crash your system or scam you out of some money.

Is it really possible that there is an occasional false positive? Could the attacker really forge a transaction with a sha256 with 20 customized bytes?

I didn't do the math, but yeah seems pretty unlikely. I'd trust StephenM347's answer on that. I typed my answer before his showed up. I was just saying that it might depend on what you're trying to do (you might go lower than 20 bytes) and to keep in mind that active attackers might cause problems if you do go too low.


text:
Bitcoin adresses seem not to be collision resistant. Please tell me I am wrong
I am trying to understand Bitcoin addresses, but it does not seem to be easy at all.
As far as I know, a Transaction uses one or more addresses as input and one or more addresses as output. Is this correct?
As I understand it a bitcoin address is a hash of your public key. So it is not completely collision resistant. So how do you prove, that you are the owner of a bitcoin address?
Also, since everybody can make an address from your public key and the recipient of a transaction does not have to sign the transaction, how do you make sure no one can send you Bitcoins without your consent? (I don't really know if this is a problem to be honest)

The public key is derived from the private key. Generating a private key is pretty collision resistant as the space is huge. The fact that an address is in turn a hash of the public key doesn't change that.

So how do you prove, that you are the owner of a bitcoin adress?

By having the private key: only then can you sign transactions.
Consent of the receiver is not required to send a transaction. If the receiver really doesn't want free money, he can chose to not spend it.


text:
What is the current state of BIP 38 (encrypted paper wallet) integration with cell phone wallets?
Given current implementations, is there a wallet that I can use to scan a private key, then enter in the password as a PIN, and the wallet will send from the key and sweep the rest onto a key generated from the phone?
Android, obviously.
Also, what's the state of BIP-38 integration with wallets in general?

Blockchain.info works well, exactly as you describe for BIP38 encrypted keys.
I switched to Mycelium in late 2014 and have had good experiences since then.

what's the state of BIP-38 integration with wallets in general?

It is actually quite good now.
Only obviously missing wallet is Armory: https://github.com/etotheipi/BitcoinArmory/issues/131
(Armory pioneered many of these ideas with its own implementations, but it is not yet using standards like BIP32 and BIP38 which came later)
One can also use Bippy to work with BIP38 encrypted keys offline.
PS: I just added recommendations here for creating a paper wallet:
How to download bitaddress.org to use offline?

Mycelium is a well-reviewed Android wallet that seems to meet the criteria you've described.


text:
Gridseed Mac OSX software
Where can I find information on running a Gridseed miner on Mac OSX? Either BTC and/or LTC.
I'm looking for rather consistent information, by this I mean instructions with links that point to the software that works with the instructions or at least specifies the version of the software. One problem I see is that instructions are created and then the software is updated and no longer matched the instructions.

You can use MacMiner, either the CPU miner window for scrypt mode or the FPGA/ASIC window for BTC mode and the GPU window for dual mode - the last two both use bfgminer
There's more information here and Mac mining forums here with lots of detailed info in some of the gridseed posts.

For the 70Khs Dualminer USB miners, I found this post to work just fine.
If you're looking for help with the 300khs 5-chip miners on Mac, I'm stuck there as well. I can't find drivers for my Mac to recognize the "STM32 Virtual COM Port". I figure once I find those, the rest should be just like in the link above.

Hi @Lounge9, did you happen to find something on the 300khs for Mac?

@Walucas no, sorry, I don't have my rig anymore

authors: ابوالفضل عرب