text:
What is Ripple and how does it compare to Bitcoin?
What is Ripple, and how does the system compare to Bitcoin?

This is answered in the official wiki:

Like Bitcoin:

ripple is a distributed peer-to-peer payment network
ripple transactions are irreversible, sent over the Internet, and counterfeit proof
ripple uses the same underlying cryptography as Bitcoin
ripple has multi-signature support
ripple has low to no transaction fees
ripple servers can be run by anyone

Unlike Bitcoin:

ripple can send any currency
ripple can automatically exchange currencies
ripple transactions are fully confirmed in seconds
ripple allows nicknames and gravatar icons for accounts
ripple's reference client is a Firefox and Chrome add on
ripple has no block chain download, clients are ready in seconds
ripple has no mining or direct monetary reward for running a ripple server
ripple has no currency risk as people can hold whatever fiat they want
ripple solves the double spending problem with consensus instead of proof-of-work

I wish that there were more technical details.  How did they get around proof-of-work?  How did they get around block chain download?

@Eyal I've linked the wiki, did you try to search there for details?

Ripple is trying to replace SWIFT, the protocol for inter-bank transfers. To me it makes sense because, those systems are (according to my understanding) quite antiquated. So blockchain hype has provided the impetus for banks to consider trying something new such as Ripple. It was started by the guy who created MtGox.
Bitcoin is a mechanism for exchanging value online between any two (or more) persons who have accounts and something to trade.

There's nothing in common, essentially.
Ripple is a simulacrum of Bitcoin repeating some of its external features, adding naive stuff like gravatars and missing the basics: immutability, independence from human factor, and any appeal to general public which is needed for any social-engineering tool to take off.
https://medium.com/@Knowledger/the-blockchain-is-already-beautiful-please-dont-create-your-own-89b13dd35793#.trgkqp6lz

Linked article is by answerer and doesn't mention Ripple…

It's not accurate to say that Bitcoin is independent from human factors - for example, who decides whether a softfork is implemented? Humans. 2) Why is Bitcoin's colored coin system better than Ripple's asset issuance system?


text:
Can Ripple exist without ripples?
Can a system like Ripple exist without a currency like ripples? As they are not used to pay the peers in the system, and their supply / fee ratio is so large they do not appear to be stopping the system from being spammed, could the system work without them? What is stopping the Ripple system from abandoning ripples, asides them being mandated by the protocol?

How it this question different from that one? http://bitcoin.stackexchange.com/questions/7641/what-use-are-ripples

I've answered that other question and I think that the answer covers this one too. What do you think @ThePiachu?

@Lohoris The difference is like asking what do blocks do in Bitcoin, and asking whether a system like Bitcoin could exist without blocks. One defines the purpose of an object, while the other is discussing a new concept. I know they are kind of similar, but I am hoping for different focus on answers.

@D.H. While it does cover what ripples are used for in the system, I was hoping for a potential debunk here of why Ripple without ripples could not work, or some analysis of why it could work.

Not with its consensus mechanism: you need the scarce ripples to prevent abuses to the network precisely from spam and DoS.
But there is the older two phase commit design to implement the ripple concept as a decentralized protocol (that wasn't implemented) and didn't need ripples or any kind of "HostCoin":
http://archive.ripple-project.org/Protocol/Protocol
It has some advantages and disadvantages over the current implementation:
+Better privacy
+Even faster transactions??
-All intermediaries in a Ripple transaction must be online
-Lack of thin clients, people that can't be always online are expected to use a server as a service
Privacy is not a priority for the current implementation right now, but there's plans to improve it through obfuscation.
The ledger could even act as the "register" for "hidden transactions" more similar in properties to the ones of the old 2pc protocol. So it may be more convenient to extend or modify the current protocol than to implement the old one.

source: Stack Exchange

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

sort: votes


text:
Is there any consensus over specific improvements Bitcoin needs?
There has been some criticism from cryptography experts about the current Bitcoin algorithm(s). Now that Bitcoin has been released to the wild and everyone has had time to study it, is there any consensus for improvements that could be made to make Bitcoin better?
If it was possible to start over knowing what we know now could Bitcoin be designed any better?

please link to criticism(s). also maybe too general of a question...

David Schwartz links to some of Dan Kaminsky's criticism(s) in his answer here: http://bitcoin.stackexchange.com/questions/367/have-any-crypotography-experts-vetted-the-bitcoin-source-code

There is no consensus. I think part of the reason for that is that many people involved in the Bitcoin project have a vested interest in maintaining that there is nothing wrong with Bitcoin.
In fact, there really is nothing wrong with Bitcoin, but there is lots of room for improvement. However, most improvements suggested have corresponding costs, and there is no consensus that the benefits outweigh the costs for many of the improvements.
Here are a few areas where improvements are likely possible:

The mining algorithm is only computation hard. It is not memory hard or decision hard.
Anonymity is limited by the inability to publish a receiving address without revealing how many coins are transferred to that address.
There is no good way to prune the block chain.
There is no good way to reverse a transaction or indicate acceptance of a transaction.
Transaction fees are not predictable long-term.
Mining pools have centralized the decision of which transactions to include and which chain to work on, defeating some of the protection diversified mining was supposed to provide.
There is no way to recover lost coins.
There is no good way to manage the currency if that turns out to be needed. For example, the block payout algorithm is all but fixed in stone but may make no sense in a decade.
There is no good way to pull coins out of the block chain such that they can be put back in.
A 51% attack can revert as much of the chain as desired, up to the last checkpoint.

My own opinion is that it's way too early to talk about Bitcoin 2.0. We don't know enough about what's really right and what's really wrong yet, and such efforts would actually work against broader adoption of crypto-currencies by reducing stability.

I would also add that some people can consider the Bitcoin transactions to be a bit slow (taking on average an hour to get 6 confirmations needed for your transaction to be "fully" processed).

I think the only real downside to Bitcoin is that proof-of-work is terribly expensive (energy-consumption wise) and it is not clear if it really works (i.e. provides assurance that no single or few people can control the blockchain underwriting) in the presence of mining pools, bot nets, and the fabled 51% attack. Seeing that miners, while powerful, cannot do really critical things like arbitrarily increasing the coin supply, spending other peoples' money, or lock down other peoples' accounts (the three main reasons why people want Bitcoin as opposed to a fiat currency), maybe a cheaper, trust-based version is acceptable here.
Other problems like scalability and confirmation delays can be taken care of by services layered on top of Bitcoin. There is for example no real reason why all everyday consumer-level transactions need to happen on the blockchain (as opposed to between and inside wallet services). You obviously still want to be able to store significant amounts on your own computer without any third party involved, but you'd be trusting some services with some amount of money, and that can be leveraged. Think PayPal, but using Bitcoins instead of Dollars. MtGox seems to be going that way.

The least burdensome but most useful change IMO is that you should be able to send a message along with a transaction. It would make things so much easier - ordering products or services could become a 1-step process, and email back-and-forth would be considerably reduced.

Keep in mind that the blockchain has to contain all transactions ever made, so allowing arbitrary-length messages would bloat it beyond control.  If you're willing to store just the hash of your message in the blockchain I'm sure you can embed it in a script.

Also the legal risk of censorship in a given country.  If someone were to include arbitrary text, and it was distributed to all the wallets, then the government could take action against those wallets.

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


text:
Why hasn't my bitcoin transaction gone through?
So about 3hrs from now I made a transaction to a different wallet of mine and the money didnt come through in 20mins I checked the blockchain and the number of confirmations kept rising and its up to 13, why is that? How long it can take?

What wallet are you using? Is it up-to-date, i.e. synchronized with the network?

Im using an official wallet where I originally bought the btc and trying to transfer to a mixer wallet, atm its 64 confirmations

@Vytautasbrah it doesn't matter about confirmations if we don't know the exact details of your wallet, and preferably OS (Windows? Mac?).

trying to transfer to a mixer wallet You mean a mixer service, I'm assuming. If this is the case then you don't own the private keys to the interim addresses, so you cannot be certain this mixer service has not stolen your funds, which is highly probable. EDIT: Now that I think of it, you'll need to clarify whether the other wallet you're talking about is a virtual wallet with the mixing service

OS is android. I can log in to both wallets no problem . Its an virtual wallet with a mixing service. Then what other ways can I mix my bitcoins what wallets/mixers I can trust and/if you guys are using one how do you do it to recieve the funds? (Name of the mixing servise and a few simple steps would be really appreciated). And thanks for the replies its nice to see that my question is not just ignored.

You've sent Bitcoins like so:
WALLET1 ==> mixer ==> WALLET2
The problem here is that you can't be certain the middle part will work, be it for technical reasons, or more likely, they've been lost or "lost". By nature, mixers are run for clientele operating in the "very dark grey area". So it's extremely unlikely you've got any recourse, other than contacting their tech support. I'm sure you know all this.
Fundamentally, mixers in charge of your funds cannot be trusted. Theoretically, the only way I can see around this would be for a service to pre-mix the required amount, and then for you to withdraw it after you know it's safe, which would likely need to use BIP65 and/or BIP16, or perhaps a combination therein with message signing, to prove address ownership. I don't know there's any mixers like this, because quite frankly, I believe their profits come moreso from scamming or selectively scamming.
Because mixers are out, your options are either CoinJoin or DarkWallet, but I have not got experience with either of them.
This probably isn't the answer you're looking for, but unfortunately this is where it stands. Good luck.


text:
How does one send and receive Mastercoins?
I don't really understand how the Mastercoin mechanics work, do I need a special client when operating with Mastercoins? And how should I proceed with the initial investment?
If I were to recieve MCSs would I use my BTC wallet and if so how do I know the amount of MSCs in my address?

It is a good question.  The presentation, video, etc on mastercoin.org is incomprehensible.  The questions here on Stackexchange consist of a bunch of trolls voting every question down.
Mastercoin says it is bitcoin on steroids, but there is no documentation and no exchange.  It seems rather to me like bitcoin in a wheelchair.
An answer to this question by a non-troll would be welcome.

To send or receive MSC, you only need a Bitcoin wallet when you have control over the private keys. so web wallets don't count

How so? In many web wallets you do have access to private keys.

authors: Алексей Посельский


text:
Multibit client synchronizing since 10 Days now
I can not access my wallet, since 10 days now, I have downloaded the bitcoin-qt multibit version 0.5.13. On my HP-window 7- 32 bit laptop successfully and I immediately received 2 transactions simultaneously which was successful too, I could only rehearse with my transaction on the screen for just few hours, since ten days now.
I have been trying to open my wallet and make some transaction with my coins, but when I launch the multibit client platform as usual the screen start downloading blocks and synchronizing with network, this will go on for the whole day and stop at a particular point without access to my wallets, it has finally stopped at synchronizing with network 119 blocks to download.
I had mistakenly created 3 more empty wallets with my first and original wallet while looking for means to bring back my wallet to life. The four icons of the wallets are visibly displayed on screen, I have even tried to reset my block chain and transaction to see if any of the wallets can pop up, but they seems to be clinically dead, because the synchronizing therein always stop at 88%.
The download and synchronizing manner of this multibit client platform had finally exhausted my internet bandwidth for the month, I think the slow performance of my computer may have contributed to this drama also.
MY COMPUTER: HP LAPTOP CORE 2 DUO T5750 - OS WINDOW 7 ULTIMATE SERVICE PACK 1, 32 BITS, 2GHZ, MEMORY RAM 1GB, I am using a 3G broadband HSDPA 7.2MBPS network.
disk transfer rate 4.8mbp/s, graphics 4.0mbp/s, ram 4.5mbps/s, processor 4.7mbps/s and the total base score 4.0
Computer troubleshooting report -- programme compatibility details --incompactible application -- (multibit) detected.
I am not too familiar with IT technical jargons, but this information might be usefull to whomever would help me out.
I do not even have the address of my first and original wallet off-head, but the wallet was protected with a password before it disappeared.
Questions: how can I recover my address and my first wallet, and how can I migrate with my wallet to a light client or hassle free web-wallet.
Concerned people, if there is anything like going to the 'file' in my download to recover my wallet there, please help explain in details as am new to the whole computer stuff. thanks in advance.

I haven't used MultiBit, but according to the Exporting private keys page in the documentation, you should be able to get the private keys. You can then import them to another client (local or web) and sweep the coins. For an example of how to do this with blockchain.info, see the Moving a wallet between MultiBit and blockchain.info.


text:
How to implement cold storage payments using bitcoind
I wonder what APIs of bitcoind I can use to sign a transaction without actually publishing it. I read that createrawtransaction (in conjunction with signrawtransaction) is a bit risky and for sure poorly documented. Are there any alternatives?

possible duplicate of Manually creating transactions

Using bitcoind, sendrawtransaction is one of the steps normally performed.  So to not broadcast, simply omit that command.
For an alternative, you might want to look at SX>
SX is a set of modular Bitcoin commandline utilities that admin types can engage with Bitcoin functionality without having to write code.

http://sx.dyne.org
http://bitcoinmagazine.com/6234/what-libbitcoin-and-sx-are-and-why-they-matter/

Using the Mycelium mobile app has to be the easiest method to spend funds from a paper wallet. From the app, select Cold Storage. Then scan the private key from the wallet. Then scan the QR code for the Bitcoin address to send the funds to.


text:
What happened to my bitcoin? 0 balance
I logged in to my blockchain.com  wallet to find my bitcoin are all gone. The log of my bitcoin transactions is also wiped clean. The only thing that is still there is a log of my past ether transactions. When I use the blockchain explorer to search for the two public keys that were used to transfer the bitcoin to my account it says both public keys are "unspent". I've tried opening a support ticket with blockchain.com, but no response. What has happened to my bitcoin? Is this some sort of technical glitch?
I still have the notification on my phone from when I received the BTC last month

I have seen reports of this from many blockchain(dot)com wallet users in recent days, it appears to be a glitch in their wallet interface. You should contact their customer service for more info, and then I would recommend choosing new wallet software that doesn't have a long history of issues like this.

Hi @Eric, I think is a interface glitch.
If you have the 12 or 24 mnemonic words you can restore your wallet on another app to check your balance.
Remember take the mnemonic words absolutely private!

any recommendations on which wallet to switch to?

BRD, Electrum, CoPay, Mycelium are all good wallets, any would do. (I've used all of them except Mycelium; my favourite is BRD though you can just compare them and use the one you like the most.)

@aqquadro I have no idea how to use the mnemonic words to restore a wallet. how can I be sure where ever I enter the words is not compromising the wallet entirely?

The amount of trust of the wallet software is the main risk, but is only a trust matter: the software can steal your bitcoins. There isn't any technical problems, at the same time you can have multiple wallet software that manage your keys. Obviously more software have your keys and more your keys are exposed :)
If you are able to BYOB surely is the best way using official software available on https://bitcoin.org/.
Btw simplified but also secure solutions are https://www.ledger.com/ and https://tezos.com/.
The best way to start choosing is https://bitcoin.org/en/choose-your-wallet.

@Eric never enter the mnemonic words (recovery phrase) online. It is safe to enter them on a computer (PC, phone, hardware-wallet etc)  that is disconnected from the internet (no Ethernet, no WiFi, no 3/4/5g data). To get the balance the computer would have to be reconnected to the internet but this should be relatively safe if the computer is checked free from viruses/malware and you are using a well-known wallet program downloaded from the proper website (beware fakes)

@RedGrittyBrick So are you saying all of these wallet websites like blockchain.com are not safe? The only safe thing to do is to have an offline wallet and only enter my password while disconnected from the internet? PS I still have not heard back from blockchain.com regarding all my btc being gone.

@Eric: your wallet's password is not the mnemonic-words. The mnemonic-words are a recovery-phrase also known as a seed-phrase. You use the wallet password every time you run the wallet program. You never use the mnemonic words except when you need to re-create a wallet - usually after a disaster of some sort. And yes, wallets based on websites (custodial wallets) are the least safe form of wallet, Google MtGox and Quadriga. The safest wallet for long-term storage (months or years) is a hardware wallet (Trezor, Ledger, etc) purchased directly from the manufacturer and factory-reset by you.

One way to categorise Bitcoin wallets is into two main types of wallet - custodial and non-custodial.
A custodial wallet is where you pay a business to look after your money for you.
If you have a custodial wallet that isn't showing the expected balance, you must resolve this by communicating with the business that owes you your money.
In this case it is likely there was a temporary problem (a "glitch") with the custodial-wallet software provided by the business.

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


text:
Read only blockchain in bitcoind , patch ideas
This question is related to to the ( already nearing 2 GB and always increasing size ) blockchain download needed to use the bitcoin network, and is referencing this previous question :
Is "Reclaiming Disk Space" already implemented? How effective will it be?
 Please read it before answering
Currently if I have bitcoind running on 20 machines, or 20 bitcoind running on the same machine, each of them need to download and store 2 GB blockchain, total 40 GB diskspace used and much bandwidth to dowload it 20 time.
I think the easiest way to make it better would be to have a "read-only" blockchain, one of the bitcoind writes it and the others only use it read only to check transactions.
This could be used to be my own trusted blockchain provider, for all my machines and bitcoind running, on the same machine or remotely using sshfs or other mounting options.
Now the questions :
1- How to implement this in bitcoind ? easiest way to do this ?
2- can this be a problem for the bitcoin network itself in any way ?
Rules : I dont want answers like "try poolserverj" or "you dont need that" please ;)

My question would be, what is the reason you are running bitcoind on 20 machines? You could run it on one or two machines (two if you want to have a backup) and make every other communicate to those two with anything they need.

many possible reasons, I want to have more than one backup, I want to povide ssh wallets to my friends, I have small devices who dont have enough diskspace to store the blockchain locally.

anyway "why I need this" is not the question, and "20 machines" is just an example, another why is bitcoin scalibility, and the need of trusted blockchain providers, see http://www.slideshare.net/dakami/bitcoin-8776098 particularly the slide 12 ;see also a comment in bitcoin code, main.h around line 1855 : "// FAT32 filesize max 4GB, fseek and ftell max 2GB, so we must stay under 2GB", this could be another reason

I think this is a good idea for further research and development. An untrusted blockchain provider is interesting too, but perhaps so much harder to do as to not be worth it. (How do you prove an output wasn't spent?)

I believe a good solution to this problem will soon be using one node that does not prune, and others that prune blocks aggressively (only keep the last few hundred) that bootstrap from the non-pruned one.

I already did working prototype for one bitcoind (with one copy of blockchain) managing multiple wallets: https://bitcointalk.org/index.php?topic=71542.msg96212 It is IMHO easiest thing to to with current codebase and it would fulfill the goal to provide for multiple users' wallets independently while using resources for only one running bitcoind.
But the discussion around it died somehow, looks like nobody tried the prototype and I got only some private inquiries.

The problem comes down to trusting a third party.  The current client only trusts the designation of the genesis block - you can independently verify all the other blocks derive from that, and have been secured by the highest difficulty.
In theory, you could merely store the sequence of hashes of the blocks (32 bytes per block).  But when you receive a Bitcoin transaction, you need to have proof that there is:

Sufficient funds coming from the Bitcoin source ("input transaction").
That those funds haven't been spent previously.

The proof that a Bitcoin address has funds is pretty short - you just need to know the block that contains the transaction, and the proof that the transaction hash is part of the "merkle root" of the block (I think this generally requires just a few hundreds of bytes of data, and you don't have to trust the source of the provider - since you verify it yourself against your stored block chain hashes).
But the 2nd part, knowing that the input hasn't already been spent is much harder - you have to "prove a negative".  The only way to know that an input hasn't already been used is to look at ALL transactions since the input was created, and verify that none of them spend the input already.
I think you would have to rely on a trusted source, then, that does retain the entire block chain.  You could rely on a signed "statement" from a trusted service (or perhaps multiple independent trusted services), that a particular input has not been spent up through a given block.

"The problem comes down to trusting a third party", in this case I ll be my own "third party blockchain provider" and I trust myself, I also have a very good PGP and OTC wot, so many friends can trust me too ;)

Also, as I understand it the "light" client I want can check everything he needs, he do have the full blockchain , but its read only


text:
How is it possible to launder bitcoins?
Some services, such as bitcoinlaundry.com, claim that they can launder your bitcoins.
Since all bitcoin transactions are publicly logged, how is this done? Wouldn't it be possible to trace back the transactions and find out the initial address?

Say I received 10 bitcoins on a Bitcoin address I publicly advertise for donations. Anyone looking at the blockchain can put that address in a search engine and find me. Now say I want to use those 10 bitcoins to buy drugs. If the drug dealer's bitcoins are traced, they'll point right back to me.
Now I can create a lot of accounts if I want. And I can pass the 10 bitcoins I received through those accounts and then to the drug dealer. But likely because those accounts aren't used anywhere else, the trail would still lead right from the drug dealer to me.
Now suppose I put my 10 bitcoins in an account created just for me by a Bitcoin laundering service. And you and Fred do the same thing. Then the service sends my coins to Fred and your coins to me. Then I spend the coins I got on drugs. Now the trail looks exactly the same as in the non-laundering example, except the  trail leads straight to you instead of me -- a pretty good deal for me, not so much for you.

but more likely that you and Fred and 50 other people will receive small amounts of each others coins' plus freshly mined coins spread out over multiple transactions. It is still possible to trace all those links, but more difficult, with multiple layers of plausible deniability.

If you have a good mix of people, you can create a confusing mess. The downside is that many "bad trails" will lead to you. The upside is that hopefully it will be clear that they're trying to read through a mess and thus not seeing anything useful.

"fine me"? Do you mean "find me"?

@DavidSchwartz, From your answer, doesn't that mean that all of the people involved with the launder service are now "blackmarked" and subject to legal action even though some of them are completely innocent?

@Pacerier Precisely, which makes the black marks provably meaningless. If you can cast suspicion on lots and lots of people, most of whom are likely innocent, that suspicion becomes very, very weak.

@DavidSchwartz, Then your answer should include that info it... as it stands, the answer looks like a severely incomplete story. Also the time delay  is an important mention.

If you purchase a bunch of Bitcoins with dirty money, and then sell the Bitcoins for clean money - you have essentially laundered your money with Bitcoins. You can then claim that your income came from Bitcoin mining, and it would be difficult to investigate.
It is exceedingly difficult to anonymize your Bitcoin transactions. I think the appeal is that it adds an extra hoop for the IRS to jump through.
Not only is it possible and proven that people can trace transaction origins, but it will likely be easier to do in the future if the Bitcoin core remains unchanged in this respect.
Bitcoin anonymity is a fallacy.

That doesn't mean Bitcoin cannot be used to effectively launder money. It is probably more effective and efficient than traditional methods.

@AlexWaters, *"Bitcoin anonymity is a fallacy"? Then why is BTER Hacker still not caught?

Likely because either A) The people investigating aren't using the latest methods to triangulate users or B) the hacker used additional measures (such as tor) which are outside the scope of what comes in the bitcoin package.

Carl Force and Shaun Bridges thought the same way you did… They are now in jail.

@user2284570 just to clarify: I am in no way endorsing money laundering.
This website is for technical discussions generally of a scientific nature. Your reasoning would imply that I support some kind of ideology; when I am just describing my understanding of it.
Having an interest in WWII does not turn a historian into a Nazi.

What I mean is when they tried your answer they ended up getting caught. So the way you’re describing isn’t a real way to launder Bitcoins.

I'm just describing a method of money laundering, I'm certainly not saying it is effective or a good idea.
Similarly, I could describe how people sell controlled substances -- but that doesn't mean that I'm prescribing a way for people to sell controlled substances.

It will always be possible to trace a transaction back to its initial wallet. This is a design choice by the Bitcoin team, and could have been avoided (see the answers to this question for more). However, there could be some legal ways of avoiding this, because if they money goes through several wallets, even if you can't hide the wallets, you could deny ownership of the earlier ones, and argue that this was a random gift somebody gave to you.

It's also possible to perform "offline" transactions such as exchanging BitBills or otherwise exchanging keypairs rather than coins. Since these transactions do not appear on the network until the BitBill (or other device) is "redeemed" by sending coins to a new address, they are no more traceable than cash transactions. Even purchasing a bitbill with one wallet and then redeeming it on another adds plausible deniability.

@David that is a good point, I was just trying to separate the technical part of tracing transactions from wallet to wallet, with the legal part of trace-ability.

Simply transferring bitcoins into an exchange or large private Bitcoin service has the net effect of breaking the trail of Bitcoin addresses. If your real identity is associated with an address you can send your bitcoins to an exchange and then send them back to yourself at a new address. It will appear that you cashed in the bitcoins at your first address, because you sent them to a known currency exchange address. The Bitcoin trail of the coins after that are clearly not associated with you. As long as you don't associate your true identity with your second address, it is indistinguishable from anyone who's bought bitcoins on that exchange even if you got some of your own coins back.
However, it's important to note that even this would probably not thwart a dedicated legal investigation. It just makes it more difficult to jump back and forth between the money trails in different currencies. Law enforcement could get a warent to search the records of the exchange which would quickly reveal the transaction. This would work just as well for a Bitcoin laundering service. If the service didn't retain your identity and a record of the transactions then they would be guilty of money laundering laws in most countries, so those services are highly motivated to maintain accurate records.

Interesting thought: money laundering laws apply to services that actually handle money, but Bitcoin is not legally considered "money" anywhere yet. Governments probably do not want to legitimise Bitcoin by calling it money but will still want to apply AML laws.

@Joshua, Citation needed for "If the service didn't retain your identity and a record of the transactions then they would be guilty of money laundering laws". As it is, it is completely false. There's a lot of bitcoin washers out there and none of them asks for your identity, even those that don't run on .onion addresses.

@Pacerier.  By whom is citation needed?  It is well documented AML law.  You might try googling first if you are in need of citations. You may also try here: https://en.wikipedia.org/wiki/Money_laundering, and https://en.wikipedia.org/wiki/Know_your_customer.

It's funny, but Bitcoin laundering services are most likley used by people wishing to do illegal activities.
So all the Bitcoin transactions on that laundering site are probably illegal and are criminal. Even though Fred would be caught for buying marijuana for Bob, whilst Bob would be caught for buying coke for Fred.
So all the police have to do is target everyone on the Bitcoin laundering website instead of one person. Then everyone will be caught paying for someone else's criminal transactions.
Unless the Bitcoin laundering site also had a twin sister site that did legal exchanges, and they mixed both of them up together.
It seems very much like normal money laundering services that banks offer.
The key is not having your real identity connected to any of the transactions, and then when exchanging your bitcoins for real money, using a fake ID to do so.

There's totally legit reasons for anonymity. Indeed, the world would be a better place when people can expect privacy with how they spend their money. Aside from the humorous example by bitlaundry, some legit reasons for anonymity: 1) a normal company who doesn't want people knowing how much salary they are paying their employees, or how much money they are paying their suppliers, and etc. 2) People donating to certain political/religious parties or nonprofit organizations may want to do it anonymously.

3) People who like their health records to be anonymous would also want to ensure that payment to healthcare services are anonymous, as it can be used to deduce their health problems. 4) Just like health privacy, people can expect anonymity for other goods/services that they purchase. Say you purchase a shoe, or a house, and you don't want people to know how much you paid for those items.

5) People hosting political sites which airs their political views may not want to be associated with their political views. Some indeed may have real need to be anonymous. 6) David Shwartz above has listed another example: anyone asking for donations are exposing themselves to black money. Instead of wasting time and money dealing with the FBI (clarifying with them that you are a legit person), it can be much cheaper to just spend x% of the donation on washing.

Bitcoin exposes many flaws in the current financial system, as it was designed to be an ideal. Yes all transaction are always visible after laundering - however the problem of matching entry and exit points is "computationally irreducible", to borrow a phrase from Stephen Wolfram, so the efforts of KYC and AML are kind of hopeless once funds go into any of the the blockchain systems and get pooled.
More funds in private hands would be a good thing. A notable reason why we labor under a top heavy world is because of ever growing state plunder by an entity that is answerable to nobody :
"Warfare, Welfare, and the State by Robert Higgs" http://www.youtube.com/watch?v=b7SA_5WeGZ0

You get bitcoins from 2 or more sources and give their bitcoins to each other.  Now expand that and do it many times and you can launder bitcoins.

It is actually much easier to launder Bitcoins. Just transfer your Bitcoins to an exchange site like cryptsy or btc-e, then exchange your Bitcoins into another currency like Litecoin for example. Now transfer these coins to another exchange site and exchange the coins back into Bitcoin. I think no one can find out the inital source now :)

Unless they are able to get your account information for both sites.

I think that this actually does work, however it'll require time washing for the anonymity to be strong. Also, either one of Exchange1 or Exchange2 must cooperate by not keeping logs that associate the same trader account with both the bitcoin address and litecoin address.

@Murch, He's saying to create a new account on the exchanges and access them only with Tor.

@Pacerier: In fact, he does not mention Tor.

If you send bitcoin through a good bitcoin mixer then one cannot directly see what mixer input address is linked to what mixer output address (nowadays dozens of output addresses have equal values). However, it's the users behavior which often makes it possible nevertheless. A friend of mine recently linked 22% of a wasabi mixer transaction output addresses to their inputs. This is possible if the user mixes the pre- and after-mixing coins. Assume you have before mixing funds on addresses 1a...., 1b... and 1c.... and analytics can group the three addresses together. And now you put 1a... as input into a mixing transaction, the output might be addresses 1d.... and 1e... . Then the user might do some traceable transactions with 1c... resulting in a change address 1cc.... and with 1e.... resulting in a change address 1ec.... . After a year the user lost the overview what belongs to the pre- and what to the after-mixing world and uses 1cc.. and 1ec.. as co-spend in a transaction. Then analytics can link 1a... and 1e... and traceability is possible through a mixer on the end of the day. So it's not very easy to keep traces hidden.
There is another risk if you use mixers for laundering. E.g. if you want to launder your drug bitcoin before cashing out. If the mixer has an operator (non-decentral solution) you cannot know if not your local police is or pays the mixers operator and can link directly your inputs and outputs in the mixer.

There is a website called BitCoinCache.com that lets you launder bitcoins . I think they only charge like a .9 % commission rate too.

The site seems to be down.......

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


text:
When is a Bitcoin Adress considered even and when odd?
When is a Bitcoin Adress considered even or odd?

What do you mean by this? When does it matter?

Nobody seems to have heard of this notion, so maybe you should say where you heard about it, and in what context.

A bitcoin address is considered odd when the Y value in the public key is odd. This is useful to know because public keys can be compressed by replacing a really long odd Y value such as 23324234324675756756742983749 with a small odd value such as 3, which accomplishes the same thing.

Are you thinking of public keys? The uncompressed public key consists of two values x and y. For a given x, there are only two possibilities for y, one even and one odd, so sometimes the public key is given just as the x plus a digit to indicate if the corresponding y is even or odd. This is the compressed form of the public key.

Bitcoin addresses are nor even nor odd. I suppose you have been confused by someone, but there is no such concept of an even or odd address.
It might be possible that someone called an address odd, meaning it is a "strange" address. Addresses may be considered strange when they have an extraordinary format. An example may be an address starting with a different character than "1".
(If you would really want to classify addresses as odd or even, you could look at the last bit of the hash160 of the address. But an address being either even or odd doesn't have any implication.)

authors: Павел Малков


text:
How do Cloud Mining Websites Divide Profits?
I have a simple question. Suppose that I sign up with some cloud mining service. I would like to know a bit more about how the system works. Let's say that the cloud mining service I use has n users, N = 1,...,n}, each user i contributing w_i> 0 CPU cycles to creating the block. In order to complete a block, T cycles are needed (this is a simplification, I assume that the number of cycles needed is a random variable; however, you can reasonably talk about the expected number of cycles).
We managed to create the block and got a reward R for it (R = 0 is reasonable, that just means that resources were committed, but we failed at getting the block).
How is R shared? Is it proportional to the number of cycles? Is it just equal division? Is there a more clever method involved?
Bonus question: what is normally the ratio between the amount of work invested and the actual work needed? Is it the case that the number of cycles committed is much greater than the number of cycles needed? Is there even a need to commit cycles, or is it the case that once a block is done, the pool moves on to mining another block?
I have tried to find an answer online, on the websites of the big cloud mining companies, but all they offer are promises of revenue, rather than an explanation of the revenue division mechanism.

There are various reward systems used by pools. See https://bitcointalk.org/index.php?topic=32814.0 and https://en.bitcoin.it/wiki/Comparison_of_mining_pools.  Which is used by a particular cloud mining company should simply depend on what pool they're using, e.g. cex.io (cloud mining) is tied in with ghash.io (pool), which uses PPLNS.

There are many different reward schemes used. One thing almost all of them have in common is that they base the rewards on "shares". Each miner earns one or more shares by producing hashes that are sufficiently low. Essentially, miners prove they're actually trying to find blocks by providing a sample of their best attempts to the mining controller.
Reward schemes generally try to do two things:

They try to even out the reward so that miners have less variation in the rewards they get if they mine at a constant rate.
They try to prevent people from strategically joining or leaving different mining pools to prevent schemes that give miners more than their fair share.

The simplest scheme is called PPS (pay per share). With PPS, each share earns a fixed reward, regardless of how well or badly the pool as a whole does. This provides the least variation to miners, but gives the pool operator the most risk.
One of the most common sharing mechanisms is called PPLNS (pay per last N shares). With PPLNS, when a block is found, the reward is divided among those who earned the most recent shares, proportional to the number of shares each miner found during that window.
Other schemes can get fairly complex.

So it seems that it is usually the case that people are paid proportionally to the effort they put in. Thanks!


text:
bitcoin mssql decimal/money storage size
What's the decimal storage requirement in ms sql for bitcoin?
GAAP standard quotes decimal (13, 4) for money.
Is decimal (13,8) preferred for bitcoin or something else?

It's interesting that GAAP would say DECIMAL(13,4) as the largest amount representable is $999,999,999.9999.  Every company in the Fortune 1000 has revenues higher than that.

Since Bitcoin's precision is 8 decimal numbers, decimal (13, 4) won't cut it. So you better go with (13, 8).

excellent thanks, currently future proofing a web site and I've managed to sneak this in. they'll thank me later :D

The first number is the total number of decimal digits available, and the second number is the number to the right of the decimal point.  So DECIMAL(13,8) will fail should you ever encounter an amount of BTC 100000.00000000 or larger.  As the other answer says, DECIMAL(16,8) would be safe until/unless the protocol changes to further subdivide the bitcoin or expand the money supply.

Just as a side note, if we're already going that direction, even DECIMAL(16,8) might not be enough, theoretically speaking. For example, you may want to express a debt of 25M bitcoins, regardless of the total amount of bitcoins out there. Just like you may do so with any other currency. So, a better metric would probably be the maximum number you think you may want to use in your application.

I would take a different approach and simply use an 8-byte integer value.  This is because all bitcoin transaction values are stored as integers and since float decimal math can vary from architecture to architecture, I'd recommend using integer values whenever possible.
Bitcoin has a fixed decimal place of 8-digits.  If you want to display this information to an end-user just format the integer value to represent the appropriate number of decimals, when the value needs to be displayed.

While using an integer variable representing satoshis is a perfectly viable option, please note that the discussion here was considering Decimals, not floats. Unlike float/double types that are commonly used for scientific calculations, Decimal types have a perfectly clear and deterministic precision, intended to be used in financial applications where fixed decimal precision is desirable. Floats should never be used for this purpose. So, it is OK to use Decimals when we're in fact dealing with them :-)

Regardless, your type is still converted from a base-2 number to a numeric type that is a data structure containing a mantissa, an exponent and a value. Since bitcoin values are stored in ints, you will have to convert to decimal and then back to int if you intend to use these values within the client. I still recommend using an int type in sql and only format the value when it needs to be displayed to the end-user. Surely any accountant within any computational background would recommend the same approach. Especially if they've worked int he field of transactional processing. ;)

Actually, you're wrong here. Decimal types do not use base-2 representations with mantissa and exponent, but rather encodings like BCD. They're specifically designed for accounting purposes, and thus should be preferred over other types. For one, there's no hidden logic behind them - what you see is what they mean (this is a good thing in sw engineering). Also, they're far more flexible; say you want to increase the precision in your application - you can't do this without rewriting all the old records if using integers.

Slip-of-the-finger-- yes I know  decimals base-10, not 2. My point is simple. If the bitcoin "eco-system" operates in a integer world, why would you diverge from that? The only exceptions that I see are two context-- you need to store values at the sub-satoshi level, or you are calculating LARGE values like market caps which can potentially be larger than the total number of BTC in existence.  Within finance, numbers can get very large and very small.  However, within BTC, we have a fixed range of values if you are dealing with transactional numbers that are part of the blockchain.

I wouldn't go as far as saying that the Bitcoin ecosystem operates in an integer world. Yes, it was the implementation choice for the original client written in C, which makes sense for that particular language. From a higher level point of view though, I would incline to natural types. Another argument pro can be the formatting - if it's a Decimal, than the right decimal separator can be automatically used everywhere in your frontend, according to your user location/language settings. The same goes with default rounding (if needed) and so on... But I agree it might be a matter of preference.


text:
How can I build litecoin from source in Visual Studio (2010 or 2012)?
I am curious if anyone has successfully built and linked all dependencies for litecoin and, finally, built litecoin in Visual Studio.
If so, could someone please provide some instructions on how to do this?  I'd like to run some tests and I'm quite familiar with the Visual Studio debugger.

its a fork of bitcoin so this should be the same https://bitcointalk.org/index.php?topic=24670.0


text:
mobile app which stores wallet locally
From what I understand, both the CoinBase and BlockChain iOS apps store your wallet on their servers.   There doesn't seem to be any iOS app (or perhaps Android either) which stores your wallet locally on the mobile device.
I understand why it may be impractical to download and store the multi-GB blockchain locally on the device but the wallet is usually very small.  I understand that by storing the wallet locally you risk losing your coins if your phone is lost or stolen but that could be mitigated by offering features to encrypt your wallet with a passphrase and also back it up over USB to your computer (or choose to assume the risk of loss).
Is there some technical reason why a mobile app can't be developed that stores the wallet locally (and obviously does not transmit it to the server) but stores the blockchain on the server?

Bitcoin Wallet
Electrum
BitcoinSpinner
All of the above mentioned store the wallet file locally on your phone

Technically there is no reason you can't have a wallet on an iOS device, but it appears (according to this article) that Apple isn't allowing Bitcoin wallets into the App Store.

I don't think so. As long as the blockchain is safely elsewhere, a client like Electrum (which locally stores the wallet and uses a seed, but trusts an external server for the blockchain) should work.
Note that there may be issues in joining a local P2P network since mobile networks don't work that way. However, there should be nothing preventing a mobile device from joining a node on the larger network (For example one of these).
I guess that nobody has really seen a market here, that's all.


text:
How is the previous transaction found efficiently?
When a new block is being created, all the transactions must be verified. In order to do that, the outputs of the previous transaction must be found in the blockchain.
But the new transaction only refers to the previous transaction by a hash. How is that transaction located without searching the whole blockchain?

Bitcoin clients maintain a list of the current unspent outputs in a hash table.


text:
How was the overflow bug of 2010 detected? Should UINT64_MAX value transactions be considered suspicious?
The overflow bug of 2010 was a result of a client that summed two values together and reaching INT64_MAX instead of UINT64_MAX.

Should transactions of INT64_MAX (or any similar constant) be treated with suspicion?
How was the overflow bug of 2010 detected?
Are there provisions in place for similar, future large transactions that may involve larger sums?  (128 bit values (if possible in the network))

Something similar exists in the Bitcoin client - if you create an output larger than MAX_MONEY, (which is equal to 21 million Bitcoins) the transaction will be rejected, before the check that @DavidSchwartz talks about.

Your first question is kind of a pointless retrospective question. Sure, now that we know that overflow can be a problem in this way, we should consider transactions that attempt to overflow to be suspicious.
The bug was detected by inspection of the blockchain. The bad transactions stood out. Had it not been detected by inspection, sooner or later it would have been detected by the presence of too many Bitcoins circulating.
There are no issues any more. Each individual output is now checked in a way that ensures that their sum cannot exceed the input to the transaction. Overflow is, so far as we know, no longer possible.
Your question seems to be asking if there's some "magic bullet" that can solve similar future problems that are presently unknown. The thing is, if there was, we wouldn't know it because we don't know what the future problems are likely to be. Sure, in retrospect, there are many things that could have been differently that would have made this particular exploit impossile.

Perhaps I need to read the source code.. I thought the issue was a UINT64 field was filled in with INT64 data.  Based on this, I would think that any similar value might indicate a client/peer bug.  Sure it was fixed in that one version of the client, but it's possible for ports to be made that exhibit the same bug.  In this case, should peers treat that value with suspicion?  My bet is yes, and since UINT64 > INT64 we may see this again in the future.  What do we do if we see it?

There's no need to treat it with suspicion. It will just be rejected since it's an output whose value exceeds the total input.


text:
Validate a payment using bitcoind and json rpc
I need to implement a BTC payment system on my web-store. But I'm still not sure about the mechanisms I'm supposed to use for payment confirmation.
For example, a user registered on my store and I created a new address for his account by using getnewaddress('user-name').  I also generate a new address for every new transaction. How can I track the status of a payment made to this address?

I would start by looking at the mempool. See getrawmempool, getrawtransaction, decoderawtransaction api calls.  Once you see the transaction your looking for in the mempool you could consider that status #1
Once this transaction is confirmed in a block it will show up as part of the getbalance for that account and other RPC calls like listunspent etc..  You could consider that status #2
Then it's up to you how many confirmations you want for the payment to be considered confirmed.


text:
Can secp256k1 be implemented efficiently on a 8-bit processor and very limited RAM?
We are trying to build a much simpler version of Trezor. We do have an finished PCB design from a previous project and would like to know whether this design can be modified, without changing the processor, to sign Bitcoin transactions. The current processor is a TI CC2540. Is it possible to get a minimalistic secp256k1 implementation to run on it, or are we just out of luck?

I don't see why not.  Most of what you need to do is just modular arithmetic with big integers (around 2^256).  There's no obstruction to doing this on an 8-bit microprocessor, it just takes a few more instructions.  You might even find some existing code for arbitrary-precision arithmetic.  256 bits is 32 bytes, so 8K of memory seems like plenty.


text:
Are there any fundamental security vulnerabilities in Bitcoin?
Although Bitcoin does its best to prevent double-spending, could it still happen in practice?  Is it just very unlikely that fraud could happen, or is there a mathematical proof that it could never happen?

As David Schwartz said in 367; Dan Kaminsky has spent some time auditing the Bitcoin core . He is a respected security professional, and his opinion on these matters is highly regarded.
He came to the conclusion that there weren't any concerning security vulnerabilities, but scalability is something that will have to be tackled as the project grows. Essentially; nothing the developers didn't already know about.

https://en.bitcoin.it/wiki/Weaknesses has a listing of the potential downfalls of Bitcoin

Well, he came to the conclusion that there weren't any vulnerabilities other than the two he mentioned and the ones that were already known at the time (and that were accepted in the design phase).

Here you can find a nice article about it: http://codinginmysleep.com/bitcoin-attacks-in-plain-english/

The only known fundamental vulnerabilities are double-spending and 51% attacks, which are closely related. It doesn't seem likely that there are any significant unknown fundamental vulnerabilities, though of course there could be exploitable bugs in the client. (The underlying algorithms will get weaker over time, but that's not a problem.)
Double-spending can definitely happen. If someone controlled 51% of the network's hashing power, they could double spend at will. How much you actually have to worry about that is a tough question though.
A deeper question is whether these problems are truly fundamental or whether they could be worked around without changing the fundamentals of Bitcoin. To my knowledge, these are open research questions. Proposals have been made to reduce the impact of the 51% attack, but they introduce their own vulnerabilities that while harder to exploit have even more disastrous consequences (such as network states that are inconsistent, persistent, and require manual intervention -- and perhaps a de facto central authority -- to resolve). You can argue that with some of these suggestions, it's not Bitcoin anymore.

There are a number of attacks which have the potential to allow an attacker to double spend but none of them are successful when the recommended practice of accepting payment only when the transaction has six or more confirmations against it.
For instance if a merchant accepts payment immediately after 0/unconfirmed, a "race attack" can sometimes be successful at double spending by an unsophisticated attacker.
Additionally, there is the Finney attack which requires a little more effort (possible only when mining and has successfully solved a block). http://en.bitcoin.it/wiki/Weaknesses#The_.22Finney.22_attack
There is another attack that requires a little more sophistication where a merchant accepting even with 1/unconfirmed can easily find the funds lost due to a double spend: http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391
There are suggestions as to how most merchants can still accept payment immediately on 0/unconfirmed with minimal risk to a double spend occurring though they require some additional processes that have not yet been developed, tested and refined.
Additionally, there are other approaches to this problem so that there is no confirmation delays though their implementations are external and do not benefit from the decentralized architecture of Bitcoin (i.e., each requires trust given to some other party):

Use some other ledger system or Open Transactions
Use an intermediary e.g., Instawallet's Green Address: http://bitcointalk.org/index.php?topic=32818.0 or Mt. Gox redeemable code (voucher).

This is an update, as of NOV-2012, since the answers are outdated.
Are there any vulnerabilities right now?
Probably not. But a new vulnerability could be created by mistake in future versions of the standard client.
Were there any in the past?
Yes, check https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures and you will see that there has been many vulnerabilities fixed. Almost 50% of the nodes are still vulnerable to CVE-2012-4682 and CVE-2012-4683.


text:
What security features are built in to the standard Bitcoin software?
I have read much of the Bitcoin algorithm and its encryption basis, however little has been said of the software's inherent security.
What solutions are already built in to the software, and what is planned?
Problems I see:

At the moment it uses IRC networks for locating others. (IRC is fairly insecure and easily taken out with simple DDoS)
Wallets have not been encrypted by default. (Physical or remote access to the hard drive provides anyone with the wallet without even so much as a passphrase.)
Wallets are complex data structures with no backup tools. (They cannot be easily backed up to a physical hard copy or a secured digital copy. At least not without using 3rd party software such as PGP or TrueCrypt.)
The server communication protocols default to plain text instead of SSL or some other encrypted traffic.

Essentially, almost none. But all of the problems aren't really particularly serious or the proposed solutions don't really help anyway.
The latest version of the client doesn't use IRC by default, though it's still supported to help older clients find newer clients. Instead, DNS is used. But these really aren't points of failure because a list of known working legitimate nodes is hard coded into the client. And as soon as you can find one node, it can send you the current list of working nodes anyway.
Wallets aren't encrypted by default, but if they were, we'd be flooded with "I forgot my wallet password" complaints and people would lose their Bitcoins anyway. Also, there are complex technical reasons why password-protecting the wallet won't actually work against the typical threat model (mass distributed malware with specific Bitcoin knowledge).
The client supports a 'backup wallet' command. But the wallet is in BerkeleyDB format. I wish the client had a native wallet format specifically for backups. There is work on fully deterministic wallets, so you can 'backup' your wallet just by knowing a passphrase even with no backup files at all. This is a legitimate issue and one that's being worked on.
The server does default to plain text, but it also defaults to localhost communication only and you must configure a password to run it in server mode. (There's no issue in GUI mode.)
These issues are all being worked on. The client is pretty raw at the moment, definitely.

One thing to add is that wallet encryption is often seen as the one cure to cure everything, when it's actually not. The reason being that elaborate virii can still steal the unencrypted keys from memory, if the have elevated privileges, and several other exploits exist, so providing encryption might result in a false sense of security. Nevertheless the new 0.4 line of Clients will have an encryption feature, which is off by default.

Viruses in the first place are a single point of failure you really cannot defeat. Anti-virus software only catches them after they are out in the wild, and very rarely a few heuristics catch something. You can write code to protect against many attack vectors, but you can almost never find them all. My concern is more deliberate access, theft of computer, or some such, that is what wallet encryption is good for.


text:
What does the Bitcoin client do when it receives conflicting transactions?
I've been assuming that the second transaction will simply be discarded as invalid, while the first waits at 0/unconfirmed until it actually gets into a block (requiring a "-rescan" or similar if the second one actually ends up in the blockchain instead).  But is this the case?  What actually happens in the default client when two conflicting transactions are received?
For simplicity's sake assume the person running the client is the recipient of at least one of the transactions, and is not mining.

I know that what is supposed to happen is that it ignores all conflicting transactions and keeps the first one it received until a conflicting transaction gets in the block chain. Then it's supposed to forget the original transaction and stick with the one that got in the chain, even if that chain subsequently is invalidated. Kind of quirky, and that's what it's supposed to do! It is agreed that the client doesn't handle this well and may not even do what it's supposed to.

But what does it do right now?

I don't know, that's why I commented rather than answering.

I can't speak for what it does every time but I just tested Mr. Schwartz's comment, so I can speak for what it did this one time. I remote controlled a geographically distant machine running an identical copy of Bitcoin on it and my local PC (with identical wallets). I sent identical conflicting transactions for my entire balance within a few milliseconds of each other (atomic clock sync & timers - don't ask) and just as expected, both transactions showed in both clients at 0/unconfirmed and only one made it into a block. The other disappeared after a -rescan
Curiously, after the -rescan the second transaction doesn't even show in a bitcoind listtransactions dump which seems odd to me. It seems like such erroneous transactions should be recorded and marked with a special status, similar to how orphaned block rewards are - this is an accounting system after all and under certain circumstances this could be "destroying evidence." I'll make a comment next time I'm on GitHub and see if someone bites.

Thanks. I 100% agree that the client should store such transactions in a special state (invalidated, conflicted, whatever). It just doesn't currently have any code to do that. This should probably be filed as an enhancement request on GitHub so people looking for things to work on have a chance to see this issue.

I actually did not expect both transactions to show up on both clients because a client won't pass a conflicting transaction. But I now know why it happened and where my reasoning went wrong -- each client got both transactions from different clients it was connected to. While every client not involved only kept and relayed the transaction it got first, a client will keep two conflicting transactions if they involve addresses in that client's own wallet (at least until one gets into a block).

BitcoinCharts did show the correct transaction in its unconfirmed list almost immediately, however and ONLY showed the one which did eventually confirm, so it seems like best practice might be to check with such a third party rather than trust the local client for 0/unconfirmed transactions.

They were only 'right' by luck. Until one or the other transaction is confirmed, there's no way to know which one will 'win'. If you want to take unconfirmed transactions, it is a good idea to check several different points in the network.

Has this ever made it into the standard client? Or is there any other means to detect lost transactions?


text:
Given the recent <0.8 bug, when can we safely have larger block sizes?
Given the <0.8 bug and subsequent fork happened because of a particularly large block, does this mean that large blocks can not be used until the large majority of the community switches to 0.8?
Also why was the solution to push the 0.7 chain instead of 0.8?

I don't think anyone known exactly what the problem is, yet (note to future readers: the flaw was discovered just few moments ago).
I found this on the #bitcoin-dev IRC channel:

sipa:  Diablo-D3: just saying that the breaking block had 1700
  transactions, but affected over 5000 block index entries

It's probably is a problem with "Berkeley DB" (0.8 use LevelDB and this is could be why 0.8 isn't affected).

Also why was the solution to push the 0.7 chain instead of 0.8?

The 0.7 chain is accepted by both 0.7 and 0.8 clients/miners. The 0.8 chain is only accepted by 0.8 clients/miners. So to avoid creating a (larger) fork, most 0.8 mining pools have downgraded to 0.7

I thought the network was supposed to take care of things like this? Is it because this block was so large?

It's crucial that the whole network follows the same rules, or else we will get forks. It this case, both 0.7 and 0.8 follows the same rules, but an underlying flaw in 0.7 means that 0.7 can't accept the 'flawed' block, so 0.7 will classify it as a invalid block. 0.8 can accept it, so it will accept it, and now 0.7 and 0.8 follows different rules ( = fork ).

oops. so because more people use the flawed 0.7 they will go with that? I suppose this will prevent people from upgrading to newer versions

actually 0.8 had most mining power, but because it's way smarter to get the 0.7 blockchain to become the 'master' blockchain, most mining pool prompty switched back to 0.7, so now 0.7 has the most mining power (and will soon become the 'real' blockchain). Right now 0.8 is the highest blockchain.

Yeah I was a bit confused on why they didn't just leave 0.8 as the longest chain. It seems like it would have been a huge PR disaster and a bad precedence to set, but seems like the more idealistic solution.

The solutions for next step might be works, ex 0.8.1, might be:
First limit the block size generate by miners, with the same size of 0.7's DB, other are the same with 0.8.
After all client are upgrade to 0.8.1, then upgrade to 0.8.2 with the feature:
remove the limitation of the block size 0.8.1's miner can generate, and the 0.8.1's DB can accept the larger block size, require that there is almost no 0.7 client now.
My opinion about the limitation is:
The block size miners generating should separate from which clients accepts(sync).
So, The upgrade for miners should also separate from common clients.


text:
What is the algorithm used to sign data within Nxt?
I understand that Nxt uses Curve25519 to generate pubkeys for user accounts, however, I can't find a reference that states what which signing algorithm/process is used for transactions and blocks. (Sorry, I also don't have access to the source at the moment.)
How does Nxt sign and validate transactions and blocks?  Note, I'm not interested in discussing POS.  I'm strictly interested in how Nxt signs and verifies its data.

I found the answer.  It uses EC-KCDSA.


text:
Is there a lite wallet for Bitcoin Cash
Free money, is free money.  Last week I transferred my distributed BTC funds to a BTC lite wallet so that I could be holding funds before the Bitcoin Cash fork.
I now have some BCC sitting in a BCC account, but I need to move it to an exchange.  I've searched and searched, but I can't find a simple, straightforward answer.
Is there a lite wallet or a (moderately) safe web wallet that will allow me to import my keys and withdraw my funds?
Also, I'm well aware of security risks with web wallets.  I've already deposited all of my funds back to their respective exchanges and the BTC account is empty, and I plan on never using it again.  Now, all I want to do is access my Bitcoin Cash funds as painlessly and quickly as possible.

http://www.electroncash.org/
But you may have problem to setup this wallet if you use non-english windows 10 version. For example with cyrillic letters

How about the local wallet Coinomi running on Android which supports Bitcoin Cash and others?
You can also run Coinomi in the Android emulator Bluestack on your Windows PC.

I use a Mac and Bluestack has never properly worked for me.

What about Droid4X or Andy OS based on Virtual Box?

I've not tried Droid4X but AndyOS hasn't worked either.  I don't know why, but I've always had the worst of luck with Android emulation.

OK, buy a cheap Android phone ;) Or use a wallet for iOS. Coinomi should be there soon.


text:
How do I convert Bitcoin to cash at my bank via Mt. Gox?
If I use Mt.Gox to do this, what are the specific steps I need to take?

Edited the title to be a question.

related: https://bitcoin.stackexchange.com/q/17239/5406

The factors that matter for any cash-out decision are:

Where are you located (country)?
How much are you looking to trade?
What type of cash are you looking to receive?
How soon do you need access to the proceeds?
Is privacy important?

You are specifically asking about Mt. Gox but there are numerous methods for transferring value from bitcoins to your bank.  In some instances, Mt. Gox will be a good choice or the best choice, and in other instances it may not be.
In the U.S., for instance, Mt. Gox does not directly provide ACH withdrawal.  ACH transfers are a method for inexpensive bank transfers.  They do support withdrawing of funds to Dwolla and Dwolla can be connected (via ACH) to your bank account.
Here's the article for Mt. Gox on the Bitcoin Wiki:

http://en.bitcoin.it/wiki/Mtgox#Direct_Deposit_2

And here's the article for describing most of the various cash-out / withdrawal methods:

http://en.bitcoin.it/wiki/Selling_bitcoins


text:
When was MyBitcoin created?
MyBitcoin used to be an online Bitcoin shared eWallet. It was the go-to place for easily handling bitcoins. The site eventually shut down with a major loss of coins, widely suspected to be perpetrated by the service operator.
Its time of closing down is well known (July 2011) but I could not find a reference for when it was opened.
(Potentially relevant reading: What is the story behind MyBitcoin?, How much Bitcoin was lost in the Jul. 2011 MyBitcoin site shutdown incident?)

The mybitcoin.com domain existed no earlier than 2010-04-25, according to the domain name registration record (whois).
According to the mybitcoin.com history at archive.org, the domain first appears to have useful content sometime in early February 2011.
In case the above archive.org url doesn't work (seems to have a problem for me), copy and paste it from here:
https://web.archive.org/web/20110315000000*/http://www.mybitcoin.com

Thanks. Upvoted since it's good to know, puts a lower bound and an anchor on the date. But not accepted since it doesn't fully answer the question.

The above problem with a clickable archive.org URL has been reported on meta.stackoverflow.com.

Feb 2011, interesting. Much later than I thought, only a few weeks before I knew Bitcoin.


text:
 What are the dangers of MtGox's trademark over Bitcoin?
If anyone trademarks bitcoin, shouldn't it be Satoshi, Gavin or one of the people who actually made it instead of some exchange site that's trying to profit from it and faces competition from other exchanges?
I mean, if Mt.Gox wanted, wouldn't they be able to shut down Tradehill or at least charge royalties if they were able to enforce their trademark? A very dangerous prospect.

It might be helpful if you actually linked to the background of exactly what you're talking about. Also your question lacks specifics and sounds a bit more like FUD than an actual inquiry.

Possible duplicate: http://bitcoin.stackexchange.com/questions/1031/why-is-mtgox-trying-to-trademark-bitcoin

If anyone trademarks bitcoin, shouldn't it be Satoshi, Gavin or one of the people who actually made it[.]

You'd have to take that up with them. Thus far, they haven't.

I mean, if GOX wanted, wouldn't they be able to shut down Tradehill or at least charge royalties if they were able to enforce their trademark. A very dangerous prospect.

If that's true, then had Mt. Gox not filed their Trademark, someone else could have and the problem would have been the same (except they could blackmail Mt. Gox as well, which would make things worse). So your issue is not with Mt. Gox.

TradeHill is dead. ...


text:
Best way to get the OID of an order created at TradeHill?
I'm working on my first trading script using the TradeHill API.
I find it pretty annoying that the OID of an order isn't returned to you when you create a new buy/sell order.
How exactly can you get the OID of a freshly created order? I'm thinking that you will have to have a list of orders before it is created and compare this with the new list after the order.
You must then find the new OID in the list?
Is this the only way?

Write tradehill (support@tradehill.com) and suggest they return it in their API call. The more they hear this, the more likely it is to happen.

You must keep a record of your orders and compare them with the returned list. Alternatively, you can sort the returned list according to date. The order you posted is the most recent.


text:
Why MultiBit replays transactions from internet on every startup?
I've installed MultiBit version 0.5.14 and every time i start it, there is a synchronization happening with network:
Replaying blockchain from date "Aug 3, 2013"
Stopping Bitcoin network connection...
Synchronising with network...
Synchronising with network, 15,253 block(s) to download. Block date : "Aug 4, 2013".
...

My assumption is that it holds on to a block generated on 2013-08-03 as a genesis block, in order to save space. But then, it updates. Why not hold on to the updated block instead of initial one? Alternatively, if keeping transaction history is important, why not cache downloaded data locally and replay it from disk instead? I have a pretty fast connection, but there's so much internet traffic happening, that even for me it takes minutes to start.
EDIT: Apparently, I was wrong. It does not replay transactions anymore on startup. I don't know what am I doing differently this time.

MultiBit remembers the last blockheight that it saw in the wallet.
There are various times where, if it sees discrepancies across the wallets (or compared to the Bitcoin network) it goes back in time to get the transactions again. This is is to prevent inconsistencies and to deal with forks etc.
It goes back in time using a checkpoints file, which is included in the installer. As 0.5.14 is a couple of months old now it goes back a bit further in time than is ideal. I update the checkpoints file in every build.


text:
Can bitcoins be counterfeited?
Traditional currencies have anti-counterfeiting features designed to make them hard to copy, but despite this attempt counterfeit money is a real threat.  Since bitcoins are digital, it's trivial to copy them.  Does this mean that bitcoins can be counterfeited?

Care to comment on a (very late) downvote?

Sorry @eMan. I downvoted because I think this question is too basic, appropriate for a FAQ or an introductory site, but not for a SE site. Asking such a thing means you know nothing about Bitcoin, and you'd better at least read up some wiki before asking anything here.

(I guess this must have been some sort of feeder question asked during private beta, but this is irrelevant concerning my previous comment)

@Lohoris No question is too basic for an SE site. We want to be reference material, we don't accomplish that goal by telling people to RTFM.

@ArdaXi: if someone didn't try some effort to solve his problem, then he shouldn't expect SE to solve it

@Lohoris I re-iterate. We want this site to be reference material. When someone has a basic question and searches for it on Google, we want to be the first result. How can we do that if we discourage simpler questions?

Upvoted to undo Lohori's unjustified downvote. This is an interesting question and certainly not too basic.

@Lohoris FWIW, reading Q&A on Stack Exchange is my way to be introduced to what bitcoin is and how it works.

Related: https://bitcoin.stackexchange.com/q/95564/5406

There is no such thing as a "bitcoin" that can be copied. Rather, there is a list of all the transactions that have taken place on the bitcoin network and the order they have taken place. Every client has a copy of this list. Essentially, the only way to counterfeit bitcoins would be to spend them in more than one place. This is called a double-spend attack. However, because of the design of the bitcoin block chain (the list of all the transactions) and the way that list is secured by mining, this requires a tremendous amount of computer power.
http://en.bitcoin.it/wiki/How_bitcoin_works#Double_spending
See also the question about how mining works
What exactly is Mining?

Just a slight correction--not every client has a copy of this list.  The BitCoin network was designed from the beginning to allow for thin clients who don't download the whole blockchain and just rely on the pieces they need.

true, perhaps more correct to say every client could theoretically access that list.

If the list is secured by mining, which has to occur long after the actual transaction, and if thin clients don't have access to the whole list, then wouldn't a double-spender (or 1000-times-spender) have a lead time to convert their BTC into another currency and get away with massive fraud?

@Kevin Laity This type of attack is why people accepting bitcoins typically wait for at least 6 confirmations (additional blocks) before completing a transaction.  Some wait for as many as 30.  A double spend will eventually be rejected and the block that includes that spend will be ignored, essentially treated as if it had never happened.  So if for example you accept 1btc for your used car, and you give away your car without waiting for any confirmations then yes, it's possible you will lose your car and your btc.

As others have said "copying a bitcoin" is trivial but of no value.
Your wallet consists of addresses and each of those addresses has a certain value.
When your wallet says you have "20 bitcoins" it simply an abstraction.  Currently your wallet file consists of multiple addresses and the combined value of those addresses according to the bitcoin block chain is 20 bitcoins.
When you transfer bitcoins to someone you don't hand over "a bitcoin".  You submit a transaction to the network.  The network makes sure your address is valid and has the proper value.  So there is no risk of counterfeiting because there is nothing to counterfeit.
There is a risk of double spending.  When I transfer bitcoins from me to you the network prevents me from doing it again (and again and again ...).  When you submit a a transaction the network verifies that each transaction is valid before including it in the next block.
IF hypothetically you had enough computing power you could cheat.  You could include your invalid transaction in the block and sign it as valid.  The strength of bitcoin comes from the size of the network.  Currently ~17Thash/second.  An insane amount of computation power.  As long as the network remains large enough and diverse enough that one entity can't control 51% there is very little risk of double spending, so long as the recipient waits for a confirmation.

Like your answer especially for explaining the abstraction the wallet poses. Also like "~17Thash/s is an insane amount of computation power", to remind one just how insane the current 460Thash/s are.

Now over 2.6 million TH/s : )

A Bitcoin must, by definition, be an entry in a valid Bitcoin public block chain. The block chain rules allow each Bitcoin to be present only once in a block chain, or else that block chain is not valid.
Think of the Bitcoin block chain like a ledger listing every Bitcoin's origin and present location. If you make a copy of the same Bitcoin, the ledger isn't valid. Invalid ledgers are ignored by all Bitcoin users.
So, if you copied a Bitcoin, you could show one copy to each of two users. But then they'd just both know you have a Bitcoin, which is true, so no harm done. You can't show both Bitcoins to the same person, because it would be obvious they are identical. And you can't transfer one of them to Fred and one of them to Abel, because there's only one public blockchain for transfers and the same Bitcoin may not appear in it twice (other than once as an output and once as an input).

There is a period of time before a transaction has fully confirmed where a tactic similar to counterfeiting could be successful.
A race attack is one -- where at the time of purchase two transactions using the same bitcoin are sent.  The first spend transaction is sent to an address the attacker controls, but is announced only to nodes of miners.  At about the same time (milliseconds) a second spend attempt is sent to the merchant's bitcoin address and is announced to a wide number of nodes.  The hope by the attacker is that the second transaction beats the first in getting relayed to the merchant's node.  When that happens, the merchant accepting on 0/unconfirmed will deem payment as received but the transaction will never confirm later as the mining nodes that saw the first transaction will have rejected it and instead will confirm the first spend.
There have been no claims published as to how successful this race attack would be and no reports of merchants getting defrauded from it but few merchants accept 0/unconfirmed thus far.
In a way then, the second spend was an attempt to perform a counterfeit bitcoin transaction, and there is some (well above zero) likelihood of it being technically successful.
The Finney attack is another method to attempt a counterfeit against a 0/unconfirmed.
- https://en.bitcoin.it/wiki/Weaknesses#The_.22Finney.22_attack
And, if the merchant doesn't take precautions, there is a variation on the Finney attack where even a 1/unconfirmed can be a counterfeit:
 - http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391

You can not copy bitcoins because there is nothing there copy. A bitcoin is not a file nor an object. It is a simple number associated with an address. The blockchain dictates which addresses contain which coins.
Note that this doesn't apply to physical objects that represent bitcoins, such as bitbills. You can try to recreate a bitbill just like you can try to recreate a dollar bill. The security measures employed by the bitbills' manufacturer have nothing to do with Bitcoins.

A "simple number associated with an address" can be copied.

Bitcoins can be "counterfeited" if an impostor coin is misrepresented to be the real thing.  In addition to what is listed here:

Test network coins may be forged and offered as production network coins
A local instance of the Bitcoin network can be created, and as long as it doesn't communicate with the rest of the world, the coins will last in isolation in that private bitcoin network.

Only Physical Bitcoins can be Counterfeited currently . It would be extremely expensive to counterfeit a Virtual coin .


text:
What is meant by "releasing code tells the hackers what to attack"?
I came across this statement from a SolidCoin developer:
Can anyone explain this statement?

[06:48] gavinandresen: I came here to ask RealSolid to be responsible
  and report problems or vulnerabilities to the core bitcoin dev team
  before releasing code that fixes the exploit (because releasing code
  tells the hackers what to attack).  RealSolid, I'll ask again:  are
  you willing to do that?

The user "Gavin" asked RealSolid to first report vulnerabilities and only then fix them, because "releasing code tells the hackers what to attack". The conversation is archived in this chat transcript.

It might be best to quote from the original transcript to allow people behind firewalls who can't access the link, and link decay to be able to answer

@Gary - right you are. Done.

I reformatted the post to put the focus on the actual question rather than the chat transcript and the two participants. If I missed any of the salient points, feel free to edit them back in.

This is not a Bitcoin question (and hardly a question at all). It's about security in software development. Plus, I'm not sure discussing about how valid what somebody said is, is appropriate on a Q&A website. Such a discussion would be more appropriate on a forum.

It would appear that Gavin is advising against providing zero-day attack vectors.
Essentially, if someone gives fairly precise instructions (e.g. a code sample) on how to exploit a vulnerability then anyone monitoring that discussion can exploit it. This is the zero-day exploit because no-one has had time to react, create an appropriate patch and disseminate it widely. Until the patch overtakes the exploit then the affected systems are vulnerable.
Consider the famous "Java Double of Death" (see http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ for details, Oracle fixed it here http://www.exploringbinary.com/fpupdater-fixes-the-java-2-2250738585072012e-308-bug/).
Imagine if a malicious coder decided to put that magic number into a request against your web API that and exploited the fact that you haven't patched your JVM? You'd be seeing an awful lot of unexplained JDK downtime and lost business.
There is a fair amount of discussion about this topic over on Security StackExchange which references this Wikipedia page about responsible disclosure.

What Gavin is asking for is a coordinated response to vulnerability discovery. Ideally, if someone discovered a vulnerability in the Bitcoin client software, they'd notify responsible parties for each crypto-currency. They'd all develop and test fixes, then the person discovering the flaw could announce it, and then every currency could release a fix simultaneously. Otherwise, it becomes a race to fix the bug before it's exploited as each crypto-currency happens to discover it, has developers who don't know about the problem, has to race to test a fix during an exploit event, and so on.

What David said.  Creating a patch to fix a potential security exploit almost always gives attackers enough information about what the problem is to create an exploit.


text:
How to instantly give people a pre-filled wallet to introduce them to Bitcoin?
As a Bitcoin evangelist I like to introduce Bitcoin to my friends, and if possible even get them involved by having them own a few coins themselves.
The settlement of a personal debt through Bitcoin would be the perfect excuse to give someone their first coins. Who hasn't balanced expenses with their friends after a night on the town? Why not gain some new Bitcoin users in the process!
So, is there a way to securely set someone up with a new wallet and transfer some BTC to that wallet at the same time, without requiring any action from the receiving party?Ideally, the BTC.USD exchange rate is taken into account because such debts are unlikely to be denominated in BTC already.
Imagine the following conversation taking place:

Alice: I've paid the restaurant $100. So Bob, you now owe me $50.
Bob: Is it OK if I pay in Bitcoins?
Alice: Sure, but how does that work?
Bob: Don't worry, I'll just [PERFORM_MAGIC] so you'll have the equivalent amount of BTC in a brand new wallet straight away.

I can think of the following (slow, complex, frustration-prone) process to substitute PERFORM_MAGIC with:

Bob emailing some custom instructions telling Alice to install a
Bitcoin client
Alice following these instructions and possibly
having problems with the process
Alice emailing Bob her receiving
address
Bob transferring the coins to Alice.

Is there a way that requires less interaction, preferably accessible from my phone?

I sure wish you owed me $50 back in 2012 and I had the foresight to keep around the ~11 BTC as BTC. :)

I would suggest starting a wallet at My Wallet (blockchain.info).

It's dead simple, all you have to provide is a password
You don't have to enter any personal info about the person that you want to give the wallet to.
As opposed to e.g. Instawallet your friend can change that password so that you no longer have access to the wallet.
It is "mobile friendly" so you can do it from your phone, as you requested
It has a sleek and professional look so it won't scare away new users

I realize now that this might look like an ad for My Wallet so just to be clear - I'm in no way affiliated with the site.

Simply print out a paper wallet "check" using BitAddress and fund it.
It includes their public key (on the left) and the private key (on the right) allowing them to "deposit" the funds into a Javascript wallet (such as My Wallet) or into an account on an exchange (Mt. Gox, for example).  Version 0.6.0 of the official Bitcoin client will also allow them to import the private key into their own wallet using the importprivkey <bitcoinprivkey> [label] bitcoind command.
If they don't personally want to redeem the check they can trade the slip of paper with someone else who does.
Of course, there is the risk is that the code is exposed and any party that sees the code could spend it.  But if you are describing transaction of just a few dollars, and given as gifts or payments to friends then a check like this works quite well.

A simple alternative is to provide the URL for an InstaWallet that you've funded.

Or, a paper wallet from walletgenerator.net

You could open them an account at a web-based wallet (such as StrongCoin or MyWallet), and send the coins there.
Of course, they are supposed to generate a new address themselves later and move the coins there.

Set them up with an account on an exchange
You pop over to an exchange, make a new account, deposit the appropriate amount in BTC and then securely provide them with the account credentials. They are then able to either cash out (and experience the joy of fiat) or get themselves a Bitcoin client and contribute to the growing Bitcoin economy.

Give them a few physical bitcoins from Casascius or BitBills.

For the stated purpose of evangelism I don't see why this warrants a -1. +1 from me.


text:
Is it possible to recognize conflicting 0-confirmation transactions with the Bitcoin client or other available software?
Is there already a way to detect conflicting 0-confirmation transactions? I'm assuming at least one transaction goes to my wallet.
I would expect the client to list the transaction as conflicting but from what I understand from What does the Bitcoin client do when it receives conflicting transactions? it currently does not do so? Is there any other way available?

How about conflicting n-confirmation transactions? What does the client do when it finds two heads for the block chain? Any alerts to the user?

@Thilo: the longest chain always wins. I would expect a block with conflicting transactions to be invalid. Currently there are no user alerts, conflicting transactions will simply not be relayed.

A merchant can lessen the risk of being defrauded in a race attack (on 0/unconfirmed) by:

Using an explicit list of peers to connect to (with most of the known IP addresses of miners)
Not allowing incoming connections (turn off uPnP)

this still leaves the merchant vulnerable to a 51% attack that all transactions below 6 confirmations are subject to but also to the Finney attack and another type of attack even where 2 confirmations is required (as described by vector76 here: https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 )
What you are asking for is a solution that would be useful for merchants who can absorb some risk that comes with accepting a bitcoin transaction at 0/unconfirmed.  Currently there is only a trivial number of merchants that accept bitcoin at a retail establishment.  And thus, no solution provider -- yet.
There is an API to the service http://transactionradar.com which might make it possible to monitor for double spend attempts.
Some useful conversations related to this topic:

http://bitcointalk.org/index.php?topic=36788.0
http://bitcointalk.org/index.php?topic=39562.0
Has there ever been a successful double spend attack on the Bitcoin network? If not, is it really necessary to wait for confirmations?
http://sourceforge.net/mailarchive/message.php?msg_id=27899173
http://sourceforge.net/mailarchive/message.php?msg_id=27964471
Can bitcoins be counterfeited?
http://bitcointalk.org/index.php?topic=69520

Thanks for the info and the links. From what I learned it is not possible with the bitcoin client as such because conflicting transactions will not be relayed. Listening to lots of nodes and analyzing their stand like http://transactionradar.com does seems to be what comes closest to detecting conflicting transactions.


text:
Bitcoin core 0.19.1 RPC, 'sendtoaddress' not working!
Suppose this scenario:

There are 2 wallets called wallet1 and wallet1 on the same node in testnet blockchain.
wallet1 balance: 0.001 BTC
wallet2 balance: 0 BTC

I am trying to send 0.001 BTCs from wallet1 to wallet2; so I use the sendtoaddress command like this:
bitcoin-cli -testnet -rpcwallet=wallet1 sendtoaddress <wallet2 address> 0.001 "" "" true.
This gives me a txid which none of the blockchain explorers like live.blockcypher.com/btc-testnet can't recognize it!

It deducts the coin from wallet1 and I don't know where does it go!?

For solving this, I tried to get the transaction hex to broadcast it via some other platforms to check if the raw transaction is correct and it was OK and after broadcasting it via the other platform, blockchain explorers could detect the transaction id.
Here are my question:

Isn't just using sendtoaddress enough for sending coins?
Why the broadcasting process doesn't complete on my node?

Here is my bitcoin.conf:
[test]
prune=600
blocksonly=1
maxconnections=15
testnet=1
regtest=0

deprecatedrpc=accounts
deprecatedrpc=addwitnessaddress
deprecatedrpc=signrawtransaction
deprecatedrpc=validateaddress

minrelaytxfee=0.0001
maxmempool=200
maxreceiverbuffer=2500
maxsendbuffer=500
dbcache=16000

rpcbind=0.0.0.0
rpcallowip=--

rpcuser=--
rpcpassword=--

server=1
rest=1
daemon=1

If it works when you broadcast the same transaction via explorers, then there is likely an issue with how your node connects to the testnet - your peers might not be broadcasting/accepting your transaction, or you just might not be connected at all

@RaghavSood I think its connected because when I send bitcoin from an external wallet to my node based wallet, after confirmations, it detects the correct balance. I have searched about my problem and I think it might be because of the bitcoin.conf. I have used blocksonly=1 in test block. Can it be the reason?

The main problem is the parameter blocksonly=1 in bitcoin config file. This prevents the node to broadcast transactions to the netwrok. I removed it and it works fine!