text:
How relevant is the Chinese Great Firewall in the blocksize debate?
Mike Hearn said the following:

The reason the true limit seems to be 700 kilobytes instead of the theoretical 1000 is that sometimes miners produce blocks smaller than allowed and even empty blocks, despite that there are lots of transactions waiting to confirm — this seems to be most frequently caused by interference from the Chinese “Great Firewall” censorship system.

Also, he mentioned on another occasion that the bandwidth through the GFW, is only about 50 KB/s, sometimes less. In the best scenario you can get 3 MB/s, according to Scaling Bitcoin Conference.
Mike put lots of accusations towards the Chinese regarding blockchain development, but how much of that is true and if there's some solution, what will be the solution?

It seems to me that the title and the body of your question are somewhat disconnected. The title seems to ask whether there are any Chinese Bitcoin developers, while the body appears to talk about the relevance of the GFW for the Blocksize debate. Please clarify your question.

Thank you for your help @Murch, I was asking about the relevance of the GFW for the Blockchain debate.

There was a bit of work done on this by Jonathan Toomim, at SB/HK, using testnet - so it's not exactly an analysis of live bitcoin, but it's informative. Here are his slides; http://toom.im/files/Jonathan_Toomim_BIP101_block_progapation_on_testnet.pdf And here is the video of him presenting this; https://www.youtube.com/watch?v=ivgxcEOyWNs&t=2h25m30s

Hello @DavidManheim you should make an asnwer and explain with more details.

Yes, data has shown, that GFW has effects on packet propagation, but not much. The major cause of delay is distance. As you can see here, the median propagation time is comparable for various locations.Complete details can be seen here.
Interestingly, this issue highlights that more than the effect of GFW, it is the effect of large blocks propagation delay & rather serves as a case for even smaller blocks, which Mike was against.
Possible solutions:

O(1) block propagation : "If memory pools were perfectly synchronized and all miners had exactly the same policy for choosing which transactions to include in their blocks and in what order to include them, then miners could just announce new blocks as the fixed 80-byte block header and the coinbase transaction; there would be no need to include any transaction data at all, it could be reconstructed from their peers' memory pools."
Blocktorrent : "a leech(node) will begin to upload chunks of data as soon as it gets them and confirms both PoW and hash/data integrity instead of waiting for a fully copy with full verification."
A miner backbone network : "a hub-and-spoke network, which consists of servers set up in eight well-connected Internet traffic hubs: New York, Seattle, Amsterdam, Beijing, Tokyo, Singapore, Hong Kong and Novosibirsk (located in central Russia). Additionally, the relay network uses a fairly basic compression algorithm. Any Bitcoin node can connect to the nearest hub on Corallo's relay network, and send and receive transactions and blocks to and from other connected nodes."
Cache transaction validation : memoization of transaction validation
Surprisingly enough, blocks smaller than 1 mb!

A duplex payment channel abstraction
Lightning Network

on top of bitcoin would enable off-chain transactions & be like the visa protocol over the fiat layer.

Stratum Mining : The miner in china delegates the block header creation to a server outside china. Probably, the best short-term solution.

The proposition number 6, is it possible? What are the chinese comments about that?

Seems the Chinese government could with DPI definitely decide to block Bitcoin network if they wanted with the Great Firewall Source: Anonymster

If you could effectively block the bitcoin nodes from talking, you'd basically end up with two chains, one building in the rest of the world, and one in China. It would be interesting to see the results, most of the hashpower is in China, if their chain grew longer, and communications were reestablished, it would wipe out the other chain.

authors: Александр Авдеев

authors: Музафар Саидов


text:
What are the advantages/disadvantages of a continuously decreasing block reward compared to the current method?
The current method to control the bitcoin supply to a maximum of 21 million BTC is to reduce the block reward (currently 50 BTC/block) by 50% every 210000 blocks. In this forum post there is a discussion about "why doesn't the block reward decrease continuously?".
The OP writes:

So I personally wish that Satoshi had instead implemented a continuous block reward decrease.  With that approach, the reward will decrease ever-so-slightly with each successive block but still converge to 21 million.  That would avoid potentially disruptive discontinuities.  It's too late to change that now but, still, does anyone know why he chose a block reward function that looks like a staircase rather than a smooth curve?

This gets rid of the discontinuity (block reward going from 50 to 25 BTC) at the 210000 block mark and at each subsequent block reward readjustment. Would this be better than the current method? Are there other advantages to this method? Are there any disadvantages to a continuously decreasing block reward?
One disadvantage I can possibly think of is that this would favor "early adopters" even more than the current bitcoin implementation.

The main advantage of the staircase rewards is simplicity. It's easier to implement; easier to describe; easier to plan with.
The main disadvantage is that it is less mathematically elegant. It will not be very disruptive in practice because it is known in advance and can be planned for.
The early adopter advantage is not a consideration, as it can trivially be controlled with the timescale parameter.

One severe disadvantage is that the hashrate will plunge dramatically right after the last 50BTC block instead of decaying slowly.
In the long run (i.e. over multi-month horizons) people will mine if the reward per share exceeds their cost of electricity per share.  Most miners know their electricity cost, and a lot of them will see in advance that the 50BTC->25BTC drop will put them "in the red", where it costs them more in electric bills to mine 1BTC than it would cost them to buy 1BTC on an exchange.  These miners will be ready in advance and will switch off within a day of the 50BTC->25BTC block.  I'm not convinced that the community, the network, or the developers are prepared for this, and having it happen over the course of a few days is going to make dealing with it harder rather than easier.
One advantage is that it probably helped bootstrap the network hashrate more quickly.  It's easier to say "oh, I'll investigate this mining thing next week" if you know that each week's reward is only slightly less than next week's.  On the other hand, if you know the rate will be cut in half at some point, waiting a week to get started means you're sacrificing (approximately) a "50BTC/block week" of which there are a limited supply.  I know it certainly got me to prioritize starting my mining experiments above other stuff that could wait a few weeks/months.

The hashrate drop will not be dramatic, for several reasons.

The decreased supply (and anticipation of it) will increase the price, thus increasing profitability at a given block reward.

People who are considering buying mining hardware before the halving will avoid it anticipating the reduced profitability, so the difficulty will be less than it would otherwise have been, improving profitability.

The hardware cost and varying electricity costs mean there will be plenty of people for whom the expense is a fraction of the revenue, so they can handle reduced profits.

indeed, i have to agree with meni here. market participants will adjust their actions well in advance, since the information about future block reward is known with certainty.

Uh, no.  Of course they'll see it coming.  But there are a huge number of miners for whom it is profitable to mine the last 50BTC block but unprofitable to mine the first 25BTC block.  They will leave en masse at the same time.  Ability or inability to predict the future has nothing to do with this.

Here in the future, the hash rate doesn't seem to have been impacted by the reward halving at all.

I think most likely the thinking was basically short term. The fear of the sudden drop was probably expected to create significant interest as people wanted to get in as soon before the drop as possible. Also, the hope that the drop in mining rewards would trigger a significant sudden increase in value was probably calculated to help fuel speculation.
There are a lot of aspects of the design of Bitcoin that appear calculated to increase adoption. The catastrophic drops in mining rewards appear to be one of them.

source: Stack Exchange

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

sort: votes


text:
How do you make a good choice of server host to run an exchange on?
I was looking at Amazon Web Services recently but they are based in the US - maybe not a good idea following what happened with mtgox.
I then looked at Linode as they have a pretty solid reputation, but I am concerned with the security issues they have had (bitcoinica lost all their funds because someone hacked the actual Linode admin panel, and I am still seeing security issues on their news in 2013).
I have what I think is a novel idea for an exchange and want to try and get a toy hobby project up and running... but how do you choose a server with good ram so it handle a surge in traffic? The ones I listed above are examples of what I don't want.

If you don't know what you're doing (which you obviously don't), don't start an exchange.

@Jacob Torba: I re-focused the question to deal with how to choose a good service, relegating "individual" services to the role of examples, and wonder if the question can be reopened it is current form.

First of all, don't even consider using VPSes for these things. As long as there's a layer above the OS that can be hacked, the data cannot be safe.
Also, if things are going to be safe, you're going to need at least several machines. The machine that stores the bitcoin wallet information shouldn't be connected directly to the internet, and should not run on the machine that also handles the website.
As long as your server is an actual physical server at a company you can trust, you should be fine hardware-wise, as long as you don't run out of resources.
Of course, software is a far more important factor here. VPSes should be considered untrusted, as there's software running on the machine that you cannot control. As I already mentioned, don't run the webserver on the same machine where the wallets are stored, because a programming error can probably allow attackers to access those wallets.
Don't assume that network traffic between your servers is safe: a routing error or packet interception can cause a lot of trouble for you. Always encrypt traffic between the machines.
Don't trust closed-source software, and don't use beta quality software. They tend to contain more bug than open source software used by lots of people.
Always assume that your own code sucks. This is a very important part. Even if you're an extremely good software developer who has ten years of experience with security, you're going to make mistakes in your code. These things can be code injections that allow attackers to steal password, exploits that allow attackers to view the source code, etc.
But the most important part is that if you read this answer and learn new things about security, you shouldn't be starting a bitcoin exchange. You are dealing with people's money here, and if this answer taught you anything new, you definitely don't know enough about security to start a bitcoin exchange.

Thanks for the answer! I plan to store most of the coins in cold storage is that what you mean by not having the webserver on the same machine as the wallets are stored. If bitcoind isn't on the same server as Apache, isn't that going to cause overhead and latency having bitcoind on a separate machine?

Also, if you could recommend a trustworthy company to supply a dedicated server I could hire that would help me. What do you make of dedipower/pulsant in the UK? :)

Websites like Facebook and Twitter aren't served from a single machine either, do they seem slow? ;-) About cold storage: I mean storing them on different servers. And of course as little in RAM as possible, even when stored on another machine.

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


text:
How can "undo" bitcoin transactions be "private"?
BitUndo private transactions:

If you choose to make your undo transaction private, nobody will be
  able to see that you tried to undo a transaction, unless it succeed.
  You have to know that a private undo transaction has less chances to
  succeed, as is not distributed in the whole bitcoin network.

From what I know, for a undo transaction to even stand a chance of competing with the main transaction, it has to be broadcasted to the public network.
If so, then how does Bitundo "private transactions" work?

The failed transaction won't get stored in a block on the blockchain, so it will be hard for an average person to find them.  I think most of the Bitcoin nodes will delete them from memory eventually.
Also, these sneaky undo transactions are probably not broadcast so publicly in the same way that normal transactions are; they are probably sent to a smaller network of miners who want to participate in this undo system.

But isn't it rather counter-intuitive? I mean for it to be undoed successfully it needs to be broadcasted to the public network right? Or is it such that this small pools of private networks actually have a non-insignificant chance of getting their transactions to win?

Even if that's the case, it would be inaccurate to say that "nobody will be able to see it". The miners in question would see it.

Nate, actually, the BitUndo system doesn't have to distribute the actual undo transactions to the miners immediately, it can just distribute hashes of transactions.  Then when the miner succeeds in finding the block, they would have to query Bitundo and prove they have a block and ask Bitundo to fill in all the undo transactions in that block.  From my reading of http://www.bitundo.com/developer.html , it appears they are not doing it this way, but I think they could.

Actually, only the public ones are available on the websocket server; I don't know how the private ones actually work but maybe it's something like I suggested in the last comment.

@DavidGrayson, But that seems theoretical... I mean practically speaking most miners don't do that right?


text:
How does one "authenticate" a bitcoin user?
What is the minimum standard for authenticating a bitcoin user. Would it be enough, for instance to verify that someone named "Tom Au" will answer to that name at this email address? Or are more detailed checks required?
Edit: Authentication would mean that I am what I say I am, that I am a human being and not a robot,and that I can do what I purport to be doing (trading Bitcoin).
Is there a public, or central registry for computer users?
In this event, would something as strong as "hashing" be needed for data storage and retrieval?
Would a web of trust concept work for the bitcoin community?

"Authenticate" can mean a lot of things, and I'm unaware of any standards in this direction.  In what sense would checks be required?  Required by whom?  Perhaps you should explain in more detail what you are trying to accomplish.

This is the same problem that CAPTCHAs want to solve and there is not a good solution to this problem.

There are different KYC (Know Your Customer) laws in different jurisdictions, but generally it takes information that is difficult or very time consuming to falsify. License/ID scans, utility bills, and SSNs are examples
Suggesting "hashing" as a KYC solution suggests you do not know what hashing is (unless you were referring to the way a server should store such confidential information). I suggest you use the search function or explore bitcoin wikipedia to learn more.


text:
What GUI clients support multisig transactions?
Are there any major current UI wallets (desktop/mobile/web) that support creating / spending multisig transactions?

See also http://bitcoin.stackexchange.com/questions/4739/how-can-i-use-multisig-split-keys-using-my-wallet

...and http://bitcoin.stackexchange.com/q/11563

possible duplicate of Do some Bitcoin wallets fail to support sending to multi-signature addresses?

Armory is a client for advanced users that has support for multisignature
https://bitcoinarmory.com/

The DarkWallet wiki states that DarkWallet supports "creating and spending multisig funds". However, the text there further specifies that "at the moment spending and communicating the funds is quite manual, transactions have to be copy pasted from one user to another".
An answer on How can I create a multi signature 2-of-3 transaction?, features code to generate and spend 2-of-3 transactions presumably with Bitcoin-Core, as Gavin created the script.


text:
Is there a future-proof method of encoding messages in the blockchain?
There are several "reasonable" modifications to the Bitcoin protocol that would make some methods of encoding messages break (e.g. pruning).
Are any of the existing encoding methods future proof, in the sense that they are likely to continue functioning even after "reasonable" changes to the Bitcoin protocol?

With pruning as envisioned today, only spent outputs are pruned. By making a small transaction and never spending it, you can keep the encoded data intact.
In the future it may be that unspent outputs will still be pruned if they're old and low-value, for example as suggested here, in which case you can still extend the life of your message by putting it in an unspent transaction with a high enough value.
If the encoding is in the receiving address itself, this will also resist modifications such as forced consolidation of outputs - but if you want to also be able to salvage the committed coins, the message should be short and the address should be generated with a vanity address generator.

You're missing a link (suggested here).

@ripper234: Thanks, I must have deleted the reference when I edited the answer.

Bitcoin headers are probably never going to be changed much, so you can try encoding messages there. You only have limited space in Merkle Root (with partial hashing collisions) and Nonce, so you won't be able to encode much there. You could try encoding something in the hash of the block, but that would make it very expensive (storing n bits would mean creating about 2^n blocks before a message would be encoded).
If you believe the coin generation transactions would not be pruned, you could try using them for encoding your messages, which would be quite cheap if you mine your own blocks, or have someone that would let you encode some messages in their blocks.
After that, there aren't that many places that could be safe from potential pruning. Then again, some people will probably be keeping the entire block chain, so message encoding in the traditional way might not ever go away...


text:
What is GLBSE? How does one use it?
What is the Bitcoin Global Stock Exchange?
How can one use it effectively?

GLBSE has closed.

GLBSE is a website where companies and individuals can issue and sell stocks, bonds, and options via Bitcoin. Anyone can create an account and issue any contracts he wants - a contract is just some text, signed by him (For example I created this bond as a proof of concept where I promised I will pay X amount of Bitcoin in the future for a loan of Y amount of Bitcoin today).
You can use GLBSE as an investor, transferring Bitcoins there and placing BUY and SELL orders on the various assets, or you can use it to sell parts of your company. It is a small scale version of a stock exchange (e.g. Nasdaq), with much lower fees and (almost?) no regulation. To create an IPO at an official stock exchange would probablly cost you at least a few thousand dollars, on GLBSE you can do it for half a bitcoin.
Although GLBSE has a command line client and an API, the easiest way to use it would be the javascript client. You can see a list of assets here, and follow this blog for posts about new assets. An updated list of transactions is available via Twitter, and you can find graphs of the assets prices here.

Where can I find a detailed explanation of how GLBSE works?

@MeniRosenfeld - I don't know of a better resource than this question, although odds are there is one. You can try posting a link to this question, with some explanation, on the forum: https://glbse.com/forum/index.php


text:
How can you find out what is the latest block number?
When running a fresh client, or after not being connected for a while, the client takes some time downloading new blocks. How can you find out what is the target block number (the id of the newest publicly available block)?

Block Explorer displays the latest block.

Did anyone happen to implement a patch that integrates this into the official client? Should I post a feature request? (It seems like an obvious feature, so someone must have thought about it by now).

Bitcoinwatch also displays it. And here is a more direct link for blockexplorer.

You could also use Biteasy.com to find out.
The latest block is always visible at the top of the blocks list and it includes a date or if you need to find out via API then you can use the following API call which will return the latest one (in JSON format) since they are sorted by date (newest to oldest):
https://api.biteasy.com/blockchain/v1/blocks?per_page=1


text:
What is the Alert system in the bitcoin protocol? How does it work?
I understand Bitcoin has an alert system. Can someone explain what it is, how does it work, and what was it designed for?

TL;DR:

As @Alex Waters has stated, it's a centralised alert system to allow
  people to shutdown their clients in response to a threat to the
  overall Bitcoin network, pending a client patch to resolve the issue.
  This was intended as a short term measure to counter-act perceived
  problems in growing the software.

This thread on the forum has some interesting information about it (I've fixed the links to cover the moved forum):

Yes, it appeared in version 3.11. Here's the thread discussing it:
"Development of alert system"
  https://bitcointalk.org/index.php?topic=898.0;all
But I think Satoshi took it out of recent builds, to avoid accusations
  that he was a point of central control (because his key would be used
  to sign the alert). If I can find the reference to that announcement,
  I'll post it.
edit: here's the announcement about the removal of "safe mode". It's
  not clear to me whether the alert itself was removed, or whether the
  ability to have the alert shut down transaction processing was
  removed:
Removed safe mode (0.3.19)
  https://bitcointalk.org/smf/index.php?topic=2228

Clearly, Satoshi intended it to be a centralised mechanism to issue alerts that would result in clients stopping transactions (not block generation). This would act as an effective mechanism to cause clients to upgrade as a result of a bug, but a naive interpretation is that it is also a good way to shutdown an economy.
Anyone can build a standard client and replace the key requirement with one of their own, thus negating the efficacy of a system-wide shutdown due to a compromised key. Essentially, this would cause a fragmentation of the standard client as nodes seek to protect themselves from external compromise.
Satoshi notes this himself in this comment:

It can't do arbitrary actions remotely.  Maybe some of you are
  responding to other posters who suggested the alert system should do
  more?
If there is an alert, the following json-rpc methods return an error:
  sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel
  listreceivedbyaddress listreceivedbylabel
The remaining 14 methods function as normal.
I believe the safer option should be enabled by default.  If you want
  your server to keep trading and ignore an alert saying the money its
  receiving might be like the money from the overflow bug, then you can
  use the switch and not blame anyone else if you lose your money.
Worst case if you leave alerts enabled, your site stops trading until
  you upgrade or add the -disablesafemode switch.
Getting surprised by some temporary down time when your node would
  otherwise be at risk is better than getting surprised by a thief
  draining all your inventory.
Someday when we haven't found any new bugs for a long time and it has
  been thoroughly security reviewed without finding anything, this can
  be scaled back.  I'm not arguing that this is the permanent way of
  things forever.  It's still beta software.

Given the ongoing backlash of misunderstanding over the concept, it appears that it was decided to remove the feature and rely instead on detecting a dodgy blockchain that is longer than the longest valid one:

Removed "safe mode" alerts "safe mode" alerts was a temporary
  measure after the 0.3.9 overflow bug.  We can say all we want that
  users can just run with "-disablesafemode", but it's better just not
  to have it for the sake of appearances.  It was never intended as a
  long term feature.  Safe mode can still be triggered by seeing a
  longer (greater total PoW) invalid block chain.

Builds:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

So, now it's definitely not in the client?

Well, I had a quick rootle through the source code of 0.3.24 and there is a reference to it in rpc.cpp so that the JSON API continues to enter safe mode. Also in main.cpp and main.h there are classes that reference the alert mechanism. This is just the result of a quick skim over the code, my initial thought is that it would benefit from a CPP developer more familiar with the standard client to look it over more thoroughly to give a definitive answer.

Turned this into a real question: http://bitcoin.stackexchange.com/questions/636/is-the-alert-system-still-in-the-main-clients-code-will-it-be-removed

My understanding is that it can operate as a method for warning people about security breaches. Thereby instructing people to patch/update their client.
I'm sure there are other potential uses for it, but my primary interest is in its use as a warning system.


text:
How can I send bitcoin from one address to another through the Bitcoin client/API?
How can I send bitcoin from one address to another via Bitcoin client/API ?
There exist an API call called:
sendfrom   <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to]
can I use it? And replace <fromaccount> with the <bitcoinaddress> to send bitcoin?
Editing:
i means i want transfer bitcoins from one address in my wallet to another address in my wallet ?
i used it in website each user have bitcoin address and balance so i want transfer just money exist in this address to another ?
i search for accounts in bitcoind but i found issue on it :

The accounts code does not scale up to thousands of accounts with tens
  of thousands of transactions, because by-account (and
  by-account-by-time) indices are not implemented. So many operations
  (like computing an account balance) require accessing every wallet
  transaction.

how can i resolve this issue ?

I think you answered your own question in a way. That command will send from a specified account to an address, I'm sure you don't want to bother with accounts and just send bitcoins.
You can send from an address to another using a similar command.
sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]
Where <bitcoinaddress> is the address you want to send to and <amount> is amount of Bitcoins (up to 8 decimal places). The other two that are in brackets are optional and cosmetic.
You can issue these commands in a command line or using one of the many libraries for various languages. Check out the Bitcoin API reference.

command sendtoaddress transfer from my wallet to another address, i want to transfer from only one address to another address in my wallet ?

move - <fromaccount> <toaccount> <amount>

The move function will allow you to move funds from one address to another within your wallet. In regards to the scaling of accounts issue this could be resolved by connecting your own back end tracking system such as a database that stores and indexes by account.

but it require also create accounts in my wallet that not exceed thousands ?

Yes that is exactly you do it however [minconf=1] [comment] [comment-to] is not mandatory


text:
What are acausal blocks?
In this forum post the poster (2112) writes:

It is my understanding that at least Eligius pool isn't a "honest node" and intentionally produces acausal blocks (or at least as close to acausal as they deem practical).

What is an acausal block? Or at least what did the poster mean by "acausal block". From reading the thread I get some idea that it is something to do with messing with the timestamp of the block but don't really understand it.
Perhaps this should be a separate question but does the block miner determine the timestamp that is recorded in that block?

It allows the pool to avoid making new work for every single request. Instead, it just increments the time by a second and gives that to the next miner. Under heavy load (longpolls), Eligius might use the same work for up to 7,200 miners, meaning the last miner gets a work timestamped 2 hours into the future. This helps reduce stale shares significantly.

He's talking about blocks with timestamps before the previous block.
Miners do determine the timestamp, though it has to be within a certain range. See:
https://en.bitcoin.it/wiki/Block_timestamp

is there some advantage to be gained by the miner from doing this? or is it just a case of the miners clock being inaccurate?

Pools with Roll-NTime like Eligius allow their miners to change the time a little. The time is then used as an extra nonce. This can be desirable for pools/miners. Acausal time can also happen when a node with a too-slow clock solves a block, or when the network corrects after a node with a too-fast clock solves a block.


text:
How do I connect my online store to the blockchain?
I have an online store for which I want to be able to accept bitcoin.
I believe that what I need is an API that will connect my store to the blockchain. If not, the question below would relate to what I need.
I need a developer who can handle both ends of the project, that is identifying or building the right API to connect to the blockchain, and connecting the API to my storefront. How would I find the right application and a reasonably good developer?

If you want to accept payment by Bitcoin or Bitcoin API in your application then you can use "blockchain.com" 's API in your application. So that you can build function and module as per your requirement and also if you want to build your eCommerce platform from scratch then you can use "CryptoWoo.com".

Hard Solutions would be building your payment system from scratch e.g. generating bitcoin addresses and checking them for payments and then confirm the order.
but if you don't want to get your hands dirty then you may use some third parties such as blockchain.info.
the problem with third parties is stability. blockchain.info is free and has a nice API.

The other suggestions already cover a couple of providers with API's.
Much of what will need to be done depends on your storefront frontend/backend. For example, if you use CubeCart there are payment gateway extensions, some of which may enable Bitcoin. (I am not affiliated with any)
https://www.cubecart.com/extensions/payment-gateways

When you say 'put your store on the blockchain' and 'accept bitcoin', these are two different (but closely related) goals.
In order for your store to accept bitcoin, it is as simple as setting up a particular payment processor which will accept/convert bitcoin, such as coinbase.com (very popular).
In order to 'put your store on the blockchain', this is an entirely different beast than the former (bitcoin) concern.
By applying the principles of decentralization/triple ledger accounting, you are fundamentally shifting the way that your business operates.
Also you must decide the extent you would like to decentralize: You can have a web 3.0 store-front which asks very much like a traditional e-commerce platform (while accepting bitcoin), you can create smart contracts to automatically fulfill orders when purchased with bitcoin, you can decentralize the principles behind your supply chain, and much more.

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


text:
How good a "take off" on the block chain is Factom?
An advertisement for Factom says that it improves on "speed, cost, and bloat." And it apparently provides a decent "proof of existence" for people who want to "copyright" their work.
What is it that Factom can and cannot do, especially with reference with the original block chain? Put another way, what are its advantages and disadvantages?

Factom provides a general purpose data layer secured by the Bitcoin blockchain.
Factom is a protocol run by a set of Federated Servers that allow users and applications to create their own "chains" of entries, which are really just whatever data the users and applications wish to track.
Factom then secures those chains by hashing them together with all the other data from other users, and a single hash is written to the Bitcoin Blockchain every 10 minutes.  Once data is entered into Factom, it cannot be changed, modified, reordered, or deleted.
One way to look at Factom is that it allows applications and users to create whatever data structures they need, then secure those structures with the blockchain.   So Factom provides a way to create audit trails that cannot be modified in any way.  Or ways of insuring entries in databases are both 1) secure, and 2) entered on a certain date.   Ways of creating audit trails for traditional banking that are as transparent and unalterable, and secure as the blockchain.
Because the history cannot be modified, Factom provides some interesting security features.  Identities can be verified and validated, and secured by time; nobody can insert a fake identity into the past.
The use cases are many, and go far beyond copyright.


text:
How is it possible to modify bitcoin source to change behavior of a newly-created altcoin?
In creating a new SHA-256 based coin, I have a few basic questions that I hope someone can offer some help with (I do not have development background):

Is bitcoin-0.6.3-linux.tar the latest and newest source available? Is this updated on a regular basis?
Can the following modifications be done to the code (a simple yes/no answer would be great):

All coins are pre-mined.
All mining is done by only one central point, not the general public.
To accomplish above, keep network difficulty at zero or less than one, and never changes.
To accomplish above, limit number of confirmations required for transactions to one or two only?
Automatic deposit of a changeable amount of coins (after a changeable mandatory waiting period) in every new wallet activated.

Can these changes be implemented, and if so, how?

Primarily opinion based because difficulty in these terms is relative.

@Jacob Torba: I made the question more objective by editing "how hard" to "how," and wonder if it can be reopened in its current form.

@TomAu I'd say that's really broad for a question. Someone would have to write pages on this and spend hours putting together an answer, not to mention multiple possibilities to answer with.

This seems kind of pointless. Bitcoin makes a lot of design sacrifices and tradeoffs to support decentralized mining and an initial distribution that can't be gamed with no need for a central authority. It sounds like you just want balances maintained by a central authority.

You first need to understand some concepts on how Bitcoin and its descendants work.

As of now, Bitcoin 0.9.1 is the latest stable version. For newest source-code with latest changes by the core developers (updated almost daily!), you can connect to the repository and download a snapshot from the master development branch. To understand the difference, I recommend reading this book or this one.
You do can premine (mining coins before announcing the software to the public), but it's more efficient to insta-mine: configure the altcoin so that first mined blocks yield an insanely high number of coins and then mining reward drops.
You can tweak a lot of parameters in an alt-coin: target block generation time, reward in coins per block, how much and when will such reward fall down (if ever), final total amount of coins (some coins don't have a hard limit), etc. Nothing stops you from setting a hard limit on coins, setting the genesis block (the very first one) to generate all the coins that will ever exist and the coin reward for all subsequent blocks to zero.
Network difficulty is set by the network so as to keep the average time between blocks as close to the pre-defined one as possible. It cannot be directly configured when designing the coin, much less be fixed, and will never be zero. Difficulty should be free to go up when a powerful miner enters and down when only a few miners are working.
You're never 100% sure your coins are really yours, you get degrees of certainty. The more confirmations you get, the more likely you'll not fall for a double-spend attack. Nobody forces you to wait for 1, 10, or 100 confirmations, you cannot limit that number in any way. You do can change the number of blocks for a newly-minted coin to "mature" and be spendable - but since you want all your coins to be premined, makes no sense in this context.
There's no "wallet activation". You never know, from the trillions of possible addresses, which ones already have a public/private key until their owners send coins to/from then. And no way to know until then. The closest I can think of is how Nxtcoin works: you must send at least one coin from a newly created wallet to mark its address as yours.

Have a look at that coin, NXT. It's not a Bitcoin descendant and has a number of the properties you seem to want.


text:
Confirmed transactions lost in my synchronised node
I tried to get a transaction information using RPC method getrawtransaction in my synchronized node, but I got no information about the transaction.
I did it in another node, and I could get the transaction information. How could this be? Maybe the database is corrupted? But I would think that when starting bitcoind, bitcoind would check the database. Maybe I am wrong. Can anyone can tell me how to figure out this case? Big thanks.

There could be a few possible reasons for this:

The most likely problem is that you don't have -txindex=1 enabled. By default, the core client doesn't keep track of all full transaction details unless you tell it to with -txindex=1 when starting it. If you want to maintain the full index, shut down and restart with that flag. It will give you a message about needing to reindex everything, that could take a little while.
It may also be possible that one of the daemons was actually in testnet, unintentionally. Make sure they are both on the same network.

The daemon will keep an index of full transaction data for all of your own wallet transactions. That might be why one of your nodes knew about it and the other didn't.


text:
Safely transferring bitcoins from wallet.dat to cold storage
A similar question was asked by me in 2014, but I did not find the answer satisfactory back then, and I hope some things changed since in the last two or so years.
I have a wallet.dat file with some bitcoins on it. I would like to move the bitcoins on the file to an offline paper wallet.
Is there a convenient way to make the transaction without connecting the computer with the wallet.dat file to the internet?

The problem here is that creating a transaction requires 2 things:

The utxo (unspent transaction output) set of your addresses. This is basically a record of all bitcoins sent to the addresses in your wallet.dat file.
The private keys to actually sign the transaction.

Generally, when you use an offline computer to store the private keys, you will be using an internet connected computer to do (1) and the offline computer to do (2).
Unfortunately, the bitcoin-qt client does not have the concept of watching-only wallets for (1) which would be required for you to create such a transaction. That said, there are some ways you can achieve this, but it's definitely not going to be easy.
Here are some options:

Manually grab the utxo set for your addresses using a block explorer (like blockchain.info), then manually create a transaction spending those bitcoins to the paper wallet address, then sign the transaction on your offline computer and finally broadcast the transaction online.
Download the blockchain on an online computer (about 50 gb), then transfer that over to your offline computer, then create the transaction you need on your offline computer and broadcast the transaction online.
Dump the private keys of the addresses on your offline computer and create paper wallets of the private keys that have any bitcoins in them. (This can be achieved using something like bitcoinpaperwallet.com and entering your own private key)

1 is going to require some programming experience. 2 is going to take a while to download the blockchain and transfer it. 3 is probably your easiest option depending on the number of addresses you have. The nice thing about bitcoinpaperwallet.com is that you can download the source and use it on your offline computer.

If you use an old/unused computer and install Talis/Ubuntu on it (over USB stick after verified the SHA256 sum) and never connect it to the internet, I would count this as a "cold storage".
You could install Bitcoin-Core on that computer (over USB stick after verifying the SHA256 sum) and use it without downloading the blockchain to dump your private keys to a txt file and print it.
Dumping the wallet (private keys) is possible over the "Console" in Bitcoin-Qt or over RPC (with the bitcoin-cli command line tool).
You need to call dumpwallet <filename>
Also consider using a hardware wallet.


text:
The End of Mining
According to Wikipedia, here's a projection of expected future Bitcoin supply:

Is there any effect to the dynamics of the system beyond the valuation of Bitcoins?
For example, is mining required to produce computations to support the system, and if so, how would the system manage a massive decline in mining with a surge in transactions?

@David Schwartz: I rolled back your edit because it made the question look as if the question had been CLOSED as a "Possible Duplicate", which it hasn't. Here's the link you provided, which is normally been on my experience is placed as a comment unless the question is closed: What happens once mining speed gets close to zero?

A surge in transactions would mean a surge in transaction fees. So it does not follow that there would be a massive decline in mining.
In any event, we have about a decade to work out what changes, if any, are needed. Nobody has a crystal ball.
One interesting issue though -- right after a block is mined, all the 'juicy' transactions will be taken, and the available transaction fees will be low. Miners might wait a bit (especially if they can save power/money by pausing mining) until the possible transaction fees reach a higher level. The consequences of that "off and on" surging in mining power need to be considered.

Surge mining is an interesting concept however I think the behavior of the network won't be uniform.  Some miners maybe operating highly efficient (in terms of watts per block) FPGA or high end custom build cards likely would run 24/7/365.   Sometimes they will get the small blocks but sometimes they won't and as the pending transactions grow more miners join in because it hits their cost/reward ratio.  Likely mining software will be much more sophisticated capable of doing realtime analysis to predict best times to turn on and off based on various factors.

"right after a block is mined, all the 'juicy' transactions will be taken" - can you please explain this sentence? What are "juicy transactions" and why the available transaction fees will be low?

Juicy transactions are ones with high transaction fees. The miner of the previous block likely will take them.

I have read a lot about bitcoin,and It seems by design, That as popularity and usefulness grows that the miners will be paid by transactions fees equal x number of bits by continued mining for the last infinite bitcoin which will never be reached.........by design to go on forever.

I would like to add some other effects not mentioned yet. The income of newly mined bitcoin to miners will get less over time. The costs don't outweigh the benefits, so miners drop out. This results in longer processing time per block. Then it would cause the difficulty to drop, making it less expensive to mine a block.
So there won't by a mining stop, there will just be less miners mining against a lower difficulty. At the level where the benefits outweighs the costs. And since the amount of new coins mined is halve every 4 years, the changeover is not abrupt.
Partly this will be compensated by the transaction fee, but people will also be able to change to other crypto-currencies if those provide lower fees. This could effect in a price drop of BTC, which would make it less lucrative for miners to continue, again re-establishing the balance.
Miners don't hold an absolute monopoly.
In real live economy: The consumption of milk is going down, so there are too many milk farmers. The price of the milk goes down. Some milk farmers won't be able to feed their cows and will close doors. Some of them do things smarter / cheaper and will survive.

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


text:
How would SPV proofs be verified when moving assets back in 2-way pegged sidechains?
I've seen similar questions posted all around, but haven't found an answer I can comprehend.
Ok, so the process of 2 way pegging is:

I move some coins to OP_SPVPROOFVERIFY on the parent blockchain.
I wait for some time (e.g. 1 day)
I get coins on the sidechain, transact.
Now, I want to move some of those coins back to the parent/main blockchain.
I send them to a special address on the sidechains, and they are now locked on that chain.
... magic magic
Now I can "SPV prove" that the coins are done with on the sidechain and are now free for transacting on the main chain.

How does step 6 work?
Assumptions

Only a subset of the parent chain miners & spv & full nodes are aware this sidechain even exists
The sidechain may use completely different proof of work, block format, address scheme (Or rather: what can a sidechain change compared to Bitcoin, and what is fixed?)

Under these assumptions, how can a full node running the parent chain recognize that the coins really vanished from the sidechain (of which they are not explicitly aware)? Remember, the parent full node isn't aware of the type of proof of work (if any) that happens on the sidechain, address scheme, really it only knows and speaks the language of Bitcoin, not the sidechain. So how does step 6 work?

Your question is spot on and poses the main problem of sidechain interfacing: How to prove to some chain (call it the "mainchain") that an event (such as a deposit) took place on a remote chain (call it the "sidechain").
As far as I'm aware there is as of yet no precise specific of how this works, but there are several approaches that can be taken. The approach usually taken here is to allow for a set of "functionaries" or "fishermen" to observe the transaction on the sidechain, wait for it to become confirmed there, and then vouch for the fact that it took place by signing off a statement (a "certificate") which attests to the fact that the transaction in the sidechain really took place. This can work well if there are some honesty assumptions about the functionaries, e.g., that the majority of them is honest. In that case, in practice, the withdrawal can really be a multisig check. This approach would work with the existing bitcoin implementation. This approach is very compatible with sidechains whose consensus is permissioned/byzantine, e.g. Plasma, Polkadot, Elements.
If you don't want to remain within the realm of bitcoin, there are more elegant solutions with different trust assumptions that can be realized. If you dislike the threat model of a centralized group of functionaries (or a "federation" thereof) and you want to go completely trustless, you need to produce a proof of a remote event in a decentralized manner. This proof will need to have the form of a simple string which attests to the fact that something happened on the remote chain, even if the local miners do not connect to that remote chain and do not know how its consensus works.
If the sidechain has Proof-of-Work consensus, then these proofs make a claim which attests to the fact that sufficient proof-of-work took place to bury a transaction on the remote chain. As they prove that proof-of-work took place, they are "Proofs of Proof-of-Work" (PoPoWs). The verification of such proofs is not a trivial manner and bitcoin does not have an opcode to do this currently, nor is there any support being planned. Hence, such schemata would be possible when the mainchain is a Turing-complete blockchain or supports a PoPoW opcode (unlikely).
On the other hand, the sidechain has to support the generation of these proofs too. This can be built-in to the chain, like ERGO, WebDollar, or Nimiq. A blockchain without PoPoW support can add it without soft forking and without miner approval by conducting an appropriate velvet fork.
Finally, these PoPoWs have to be produced by sidechains maintainers in a "one-shot" attempt that generates a simple string and they should not require interaction, i.e., they should be Non-Interactive Proofs of Proof-of-Work (NIPoPoWs). Given these ingredients, you can do it in a completely trustless manner.
All of the above constructions pre-suppose that the sidechain and mainchain survive securely independently. For example, the sidechain needs to have honest majority computation power if it's PoW-based.
To summarize, bitcoin does not currently have a way to do what you're asking in a trustless manner, but there are federated / cothority ways to do it. If you're willing to work on new systems, you can do it in a decentralized manner.
Disclaimer: I am one of the co-authors of the Non-Interactive Proofs of Proof-of-Work paper.

The first important thing to understand is that this method is one of two different ways of moving coins back and forth between two chains. The other is called Federated Peg, which I believe will be more successful despite being less technically sophisticated and more centralized.
General concept
The first step is that you send a transaction on the sidechain that locks your money in place. Once that transaction has a few confirmations, you create the SPV proof to send to the mainchain.
Let's go into more detail about that last step:
When you run an SPV client, your client doesn't download full blocks. It downloads headers. Then, it downloads the transactions to or from your wallet. Then, it downloads the merkle branches to connect your transaction to one of the block headers.
When you create an SPV proof, you take those block headers that you downloaded, and those merkle branches that you need to connect to your transaction, and your special coin-locking transaction, and you serialize them into a single datastructure.
Why do we need to serialize the SPV proof at all?
…can't the nodes checking the SPV proof ask nodes on the sidechain to provide the SPV data?
No, because the sidechain nodes might reply differently to different mainchain nodes. That would result in a fork of the mainchain. A serialized SPV proof will be evaluated the same way by all mainchain nodes.
Some complications
SPV proof might not match sidechain network
If I have lots of mining power, I don't need to have money on the sidechain in order to withdraw money from sidechain outputs on the mainchain. (i.e. I can fake a sidechain withdrawal.)
This is how it works: I create a transaction from a fake output on the sidechain. If I broadcasted this to the sidechain, all of the nodes would reject it. However, I mine a block containing this transaction, and I keep going until I get enough blocks that the mainchain will trust my SPV proof.
Mitigations

Require more confirmations before moving money from sidechain to mainchain
Create a grace period where someone can block your withdrawal by creating a 'counter SPV proof,' which shows a longer chain of proof of work that does not include your block header.
When the sidechain detects that someone successfully stole money, it marks down all future withdrawals to avoid a bank run.

What you're depositing won't match what you're withdrawing
If you're using the sidechain for transactions, you're going to wind up with more or less than when you started. However, this is a softfork, so we can't just deposit all of the incoming funds into a single pot. All of the funds are spread around many different outputs, and in Bitcoin, you need to entirely spend any output you claim. (You can't partially claim an output.) There are two solutions to this:

Lock up the exact amount of money of an output on the mainchain, then claim that. Potentially do this many times. This is simple, but has two problems: first, it uses more blockchain space than nessary; second, if there is no set of outputs that add up precisely to what you're withdrawing, some of your money will be stuck in the sidechain.

Allow people to claim one or more outputs, and optionally send change to another OP_SPVPROOFVERIFY output. This solution is much more flexible, but has some hidden teeth. (Can you accidentally send an 80 BTC miner fee because you screwed up your javascript? Will people have an incentive to avoid the dust outputs, leading to a bunch of outputs that nobody wants to pay to redeem?)

Things that aren't complications
Nodes on the mainchain that don't understand OP_SPVPROOFVERIFY
Since this is a softfork, not all nodes have to upgrade.
What can be changed in a sidechain?
Since we're supposing that we're designing a new opcode from scratch, we can make it support many different things. It could support Scrypt, X11, whatever hashing algorithm we want. It can't support pure Proof of Stake in a meaningful way. It could support multiple different target times, address types, etc.
However, it can't support unanticipated changes, so if someone comes up with a brilliant change that's visible to SPV clients, it won't work with the above.
Well, that's not entirely true. You could create two instructions, OP_SPVPROOFCHECKERREGISTER, and OP_SPVPROOFVERIFY. The first one would register an ethereum-like script that could keep state, and would check all incoming redemption requests. The second would commit a sum of money until the former script said that it could be unlocked. That would allow arbitrary SPV proof systems (although it still wouldn't allow pure PoS systems) at the cost of increased complexity.

+1 this is a very thought-provoking answer that definitely added to my knowledge.  Why was it at -2 votes?  Well, it's at -1 now, FWIW

authors: సతోషి నకమోటో


text:
What are the key differences between different ways of embedding messages in the blockchain?
Are some possible ways to embed messages in the blockchain better in some sense than others? What are the important differences?
(Followup on this answer)

There are multiple places one can embed messages in the block chain. Any field that takes arbitrary values can be used.

Nonce - nonce is a field in the header that can take 4 bytes of data. Not the best place to embed much, but it does not bloat the block size
Coinbase string - probably the best place to embed messages. It takes an arbitrary length and doesn't have to adhere to any rules. Main problem is that there is only one coinbase string per block, which usually means one would have to mine the block oneself in order to encode the string. Another important thing to note is that one should not use the exact same coinbase string all the time, as it might make the output irredeemable (if the transaction hash is duplicated)
Transaction outputs - The Tx message outputs can be used to encode messages in the form of output addresses and possibly Bitcoin transfer amounts. This can create irredeemable transactions (if the transfer amount is higher than 0). The overhead of encoding transactions in this way is not too big, in case of 0BTC transactions it would be 10 wasted bytes for about 23 bytes sent (total transaction size is about 33 bytes).
Transaction script - Probably the best way to encode messages, although it is not widely supported (requires custom transaction script creation). Messages are created by adding two script operations - OP_PushData and OP_Drop in the output script of any transaction, and adding the message body in between the two operations. In order to embed messages in this way one would add just a couple bytes in order to send fairly large body of text.

One could also try creating partial SHA collisions that would encode to some short message, although this method would require a lot of computing, yielding short message encoding.

The most correct way is to create a merge-mined message tree.
If you just need a short number (a transaction id, for instance), you can embed it in the transfer itself.
Then there's abuses... these cause excessive bloat the to must-be-stored-forever-by-all-full-nodes blockchain and harm Bitcoin. Please don't do these:
You can embed it as the "address" of a transfer, with a zero-amount output.
btcmsg goes to an extreme and embeds it in the amounts of the transfer.

You should really explain why you consider anything like that as "Abuse". What do you care what 3rd parties are doing? They are paying the fees or mining the blocks, just like everybody else.
In my book there is no "abuse". Perhaps some ways are better than others in a technical sense, but the word "abuse" implies being morally in the wrong ... what's the moral problem here?

My post already explained why they are abuses: "these cause excessive bloat the to must-be-stored-forever-by-all-full-nodes blockchain and harm Bitcoin"

Excessive is a matter of interpretation. If the protocol allows it, it's ok by my book. Well, not wasting any more time on this, you say Tomato, I say Tomato.

The bitcoin blockchain is a massive beast to maintain. Miners are paid for their efforts to secure it, but all other full nodes in the bitcoin network are not, and collectively they do carry a very large cost in doing so. Their operators voluntarily pay this price, as the cost is outweighed by the benefit: a currency called Bitcoin, which they find valuable. When people start using the blockchain for other purposes however, this cost will increase without further benefit to them, possibly making people less inclined to pay it.


text:
Is the HashOfThingToSign (used in signature generation) the same for each input of a transaction or is it different for each input of a transaction?
Does a transaction with 50 inputs have 50 different hashofthingtosign, one for each input, or does it just have one that is used for all the input scripts?

It is different for each input. Each input's hash preimage contains that input's previous output's scriptPubKey in that input's scriptSig. All other inputs have empty scriptSigs. This means that the preimage for each input is unique, and thus has a unique hash.

A large portion (but not all) of the hash preimage consists of the serialized transaction where all inputs except the one being signed for have empty scriptSigs.

I don't know if this is something I'm allowed to ask, if not, totally erase it.  Is there a way I can just pay someone to make a python script for me where I put in the transaction id and it sends the hash of each "input script" from that transaction to a file?  I've got some serious OCD on this.  Its a puzzle I must complete!

Sure you can, but this is not the right place to ask for such a thing. Such a script would require having the entire blockchain and know where each transaction is in the blockchain.

Where would be the right place to ask for something like that?  and blockcypher.com has stuff that gives people access to such stuff within python, they could have it kick back the whole data set for a particular transaction if I have read it correctly.

Try asking on bitcointalk.org or in the various Bitcoin subreddits (r/bitcoin, r/jobs4bitcoins)

take a look here: https://bitcoin.stackexchange.com/questions/41209/how-to-sign-a-transaction-with-multiple-inputs - this explains, what you are looking for (and the referenced links). I had a set of shell scripts to do the same, but not python... but there are many python tools out there as well. Check with bitcointalk as well.

Not to drag out the conversation in comments, but if you have any such shell scripts I would be interested in any context.  I'm just using python as one of the easier examples I can actually use.


text:
How do you do point multiplication in bitcoin associated with the ecdsa algorithm?
I have posted a similar question recently, but not this specific.  I have found that a lot may ride on the idea of "point multiplication" yet all explanations I have found lack explanation or are in code that not everyone (especially myself) can decipher.
Supposedly you "add point G to itself k times". Most examples of point addition or point multiplication show multiple x,y coordinates in the same equation but in this situation, I only have an integer to apply to the equation.  Secondarily, many equations that show this also show that you do something such as "Qy - Py" (aka: Q's y-value minus P's y-value).  This is a problem if the only x,y value I'm working with is Q.  If I subtract Q's y-value from Q's y-value I get zero, thereby nullifying the value of the equation.
I think the criteria for the correct answer to this question are as follows:

It is explained such that anyone who has mathematical experience less than Calculus can at least stumble through it by cutting, pasting, and using a basic calculator that can handle exceedingly large numbers,
Programming experience/understanding is not needed (code can be used but must not require pre-understanding/experience thereof by anyone reading it),
Must show or enable people to show themselves how a K value of 18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725, and a Gx value of 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 and a Gy value of 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 equals x and y values of 36422191471907241029883925342251831624200921388586025344128047678873736520530 and 20277110887056303803699431755396003735040374760118964734768299847012543114150.  (Note: whether the answer is in Hex or Decimal is not significant as converters are readily available on many websites),
Criteria 4 is applicable such that the point multiplication is truly applicable to the question (IE:  that I have asked the proper question in the proper manner).
Whomever meets criteria 1 through 4 must also post their Bitcoin address to permit a donation.

I know this seems complicated and perhaps odd (what with me adding actual answer criteria when I'm essentially a beggar) but I want to be clear such that others who read my post and may be wondering the same thing have a better chance of understanding what I'm asking and the answer.  I also want to filter out, as best I can, answers which don't truly answer the question (as I have seen too many of them on this forum and others).  I am not promising any particular amount of bounty but if someone meets all these criteria I will be sufficiently grateful that I would feel guilty if I failed to provide them with some value.  If your answer to my question meets the criteria, please do not hesitate to leave address for alt-coins you may have as well.

I think the detail you're missing is that point doubling uses a different algorithm than ordinary point addition.

Doh, you're completely right, gotta edit my post to address that part (as I still don't know how to do 3 * (9,8) either)

2 * (4,3) = (56, -419) on what curve? The point (4,3) is not on the "bicoin" curve and the operation is dependent on the curve.

3 * (9,8) = [2 * (9,8)] + (9,8) So if you can do point doubling and you can do addition of two different points, you can do point tripling.

David, I think you may be the one who understands this.  So if we went with your 3 * (9,8) what would the be resulting x,y value?  And is that the same setup/equation for the conversion of the bitcoin private key to public key?

I'm not exactly sure (because I've only scratched the surface of the topic--it's a Calculus 2 topic generally), but I'm pretty sure you need to know the G value to calculate it. At least I could calculate it, given the value of G.

KJ O, the "G" value that is mentioned is: 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8 but that is the Gx and Gy I already gave combined and starting with a 04.


text:
bitcoin wallet validation/vetting
Is there any validation service that tests/validates/vets wallet implementations?
I use bitcoin-qt on the desktop and I'm not worried about that wallet, I assume it's been well vetted, but if I were to get a wallet for my (Android) phone, is there a way I can be assured the implementation is correct, secure, and not malevolent?
Added elaboration: It seems feasible for a trusted 3rd party to be in the business of validating wallet implementations. Wallet implementers would submit their implementation to the service, the service would run the wallet through a test suite, examine the code, etc. and if the implementation passed the service would publish a hash of the wallet. When you get a copy of the wallet implementation you could check its hash and against the published hash so you'd know it hasn't been tampered with.
Likewise an online wallet service (Mt. Gox) could submit its implementation for 3rd party validation to increase its trust factor.

It is pretty much impossible to verify 100% if an implementation is correct.
See for example https://backdoorhiding.appspot.com/ or "The Underhanded C Contest" at http://underhanded.xcott.com/ - in both of these, people compete to write code that looks secure, but isn't.
Similarly, there are theories that the NSA has put back doors in various random number generators, even open-source ones. It is, however, very difficult to test this theory.

Thanks.  I understand the difficulty with 100% verification, but it seems an expert group's best effort at verification would be worth something. A combination of code (source code, byte code, and/or machine code) analysis, plus an execution test suite, would go a long way towards fighting mischief.

Third party audits cost a lot of money, especially if done right. I am sure that, if you wanted to pay, bitcoind would LOVE an audit.

Short answer: no. Imagine this scenario: a developer writes a closed-source Android wallet that becomes extremely popular. At some point the combined worth of the user wallets is $100M. The developer could have purposely left an open vulnerability, and claimed that a hacker exploited it. There would be no way to know if he was telling the truth.
Rule of thumb: keep the bulk of your BTC in cold storage. Online wallets should be treated like the wallet in your pocket. How much cash are you comfortable carrying around, knowing that you could lose your wallet and it's gone? That's how much you should have in an online wallet.

Thanks.  I don't use online wallets, like to keep things local.  I elaborated on my original question.

I think, in this case, "online" means "on a computer with an internet connection", not "a website".

Yes, that's what I meant by online. Presumably your phone is online most of the time, and as such it's vulnerable to a wide array of exploits.

obelia: google "air gap" for a great way to keep your bitcoin safer. It is a hassle though.

@AMADANONInc. re: air gap - I wonder if there's an easy to do that, like keep wallet.dat on a flash drive and only plug it in to transact.

My wallet is encrypted/pass-phrase-protected.  I was under the impression that that is fairly secure as long as my pass phrase is kept secret.

The main threat are keyloggers in viruses / trojans. Cryptocurrency has made hard drive contents potentially valuable to malware authors. Before this, the best they could do was turn your computer into a bot to click on ads or crack passwords. Now they can directly steal significant money. If you have a significant amount of money in bitcoins, cold storage is the way to go. Why risk it?


text:
How do I find the transaction ID of what I just transacted?
If I send or receive something (with Bitcoin-QT), how can I get the transaction ID of that transaction?
context: I'm playing satoshi bones and they have verification code I can run to make sure they're playing by their own rules.  The game is based on a hash of the transaction ID of what I send them, so I just want to give it a check but I need the transaction IDs of my transactions with them.
verification code supplied by satoshi bones that I want to run:
import hashlib
import struct
def verify(txid,secret,lessthen):
   sha512 = hashlib.sha512()
   sha512.update(secret+txid)
   b = sha512.digest()
   result = struct.unpack("<H",b[0]+b[1])[0]
   if result<lessthen:
      print "win!"
   else:
      print "lose!"

With bitcoin-qt you can look in your transaction history and right click your transaction to find more info, including the txid.
When using bitcoind, the client gives you the txid as the response for a successful send.

So simple. What you have to do is to get the wallet address of the person you transferred to and visit blockchain.info, then click on home and you will see the a  search box, paste  the wallet address there paste and on the next page you will see long string of characters with oldest has at the top. immediately of that copy the long string character that is all. Read here http://www.guruscrib.net/bitcoin-create-bitcoin-wallet-blockchain-info/

You probably mean "newest at the top" not oldest? Otherwise the instructions wouldn't make sense.


text:
Why would a transaction take 90 minutes to get confirmed?
I'm just starting out with alt-coins, and have executed a few transactions with both bitcoin and dogecoin and they all seem to "go through" in less than a minute. I've transferred small amounts between wallets (my own) done some gambling and everything seems to transact within 2 minutes tops.
I just made a small deposit to cryptsy and it took 90 minutes to get confirmed. I'm wondering why it took so long this time. (FWIW I do have 3 wallets up right now, Bitcoin-QT, Multibit, and Dogecoin-QT, if that matters.) My network connection seems to be working normally.
My wallet indicated it was confirming (1 of 6, 2 of 6, etc.) and I've never seen that before.
Any clues, anyone?

Cryptsy probably required 6 confirmations.  With Bitcoin, it may take an hour or more for 6 confirmations.

@Murch I sent 0.01 bitcoin to test. Definitely took more than 90+ minutes.

@ChrisW - Thanks.  I didn't know different places required more/less confirmations.  Learning.

@ChrisW That seems to be a likely answer. As in, put that in an answer, not a comment. ;)

@Murch It took 90 minutes for my wallet to indicated confirmed (with the green checkmark) and for it to show in my Cryptsy account. My wallet indicated the confirm count, to 6, as it went, I've never seen that before.

On occasion, deposis I've sent to Cryptsy start confirming immediately but take thousands of confirmations (1-2 days) for them to appear in my Cryptsy account. According to their support, that happens when they have way too much deposit/withdraw operations :(

Bitcoin has longer confirmation times than many altcoins like Litecoin or Dogecoin, and different services make their own choices about how many confirmations to require before a deposit is made available for use.
While you can see a new transaction on the network almost instantly, many services require six confirmations to prevent double-spending.  With Bitcoin, six confirmations will commonly require an hour and perhaps more if no transaction fee was added.
Given the description, it leads me to believe that Cryptsy wanted to see six confirmations before making your deposit available to you on the Cryptsy site. It's not really unusual to see that take the 90 minute wait you experienced.

Also Worth Mentioning network propagation, and that the speed of transactions can also be affected by what peers you are connected to and how they have their systems configured.  E.G. a mining pool with more bandwidth may accept a greater variety of transactions and more transactions without fee's however smaller pools may configure options such as:
-blockminsize=
-blockmaxsize=
-mintxfee=<m.n>
In order to optimize their throughput for the most efficient use of their resources.  The servers that pools run on will aslo impact this as RAM and CPU also play a key role here.


text:
Could bitcoin "survive" a definitive hard fork, spawning a new currency?
What happens if two different groups have a definitive disagreement about the evolution of the bitcoin protocol? I have read is several places that the "majority" somehow would win, but is this really true, or could two different branches (A and B) of the blockchain (now tree) survive indefinitely in parallel?
I imagine that since the coins can be spent twice, once in each branch, they would somehow have their effective value halved. Suppose I'm a supporter of branch B, I would want to sell the A versions of my coins to buy more B-coins. The exact exchange ratio between the two new type of coins would depends on the relative size of the two communities. Is this scenario plausible, or is it economically unstable?

So far, when a new crypto-currency arises to test a new idea, they start with their own chain, their own genesis block, etc. Crypto-creators would earn almost nothing by reusing Bitcoin's blockchain, and potentially could get a lot of damage for that. Your question could be generalized into "could bitcoin survive a fork that continues indefinitely?" which is in itself a more interesting (and relevant) question.

That was actually my question, so I reformulated following your advice.

The question should be reopened. Especially now after it was edited, it is a technical question with a definite technical answer.

Just because the answer is obvious to you doesn't mean that it shouldn't be reopened.

You've described it very accurately. When there's a protocol change that not everyone adopts, you'll have essentially two different currencies, with any coin in the original currency turning into a coin in each of the new block chains. The total value of the coins in both chains will be roughly equal to the total value of the coins in the original currency. The division of value between the two currencies will depend on the respective demand.
However, if both currencies use the name "Bitcoin" to describe themselves, it will be very confusing, and will make both less usable because it's hard to know what someone means when he says "Bitcoin".

Ok, so I understand the blockchain aspect of that situation. However, this leaves open the question of whether the system would be economically stable. What if one community is much smaller than the other?

@madjophur: At first you will just have two currencies with one smaller than the other.
If the gap is big enough, eventually the users of the smaller currency will realize that it's not working and grudgingly ditch it in favor of the dominant currency.


text:
Multisig doesn't work unless all keys were generated from the current wallet?
I tried to create a multisig in both the Bitcoin network and the Bitcoin testnet. It seems to work only when all public keys are from the current wallet. That means when I call listunspent after I send coin to the multisig address, it didn't show up as a multisig address unless this multisig address was created from the current wallet. I tried it in both real coin and testnet. What is problem?
Note: I use Bitcoin-qt 0.9.2.1
Why "listunspent" dosen't show multisig address ?
How can i check balance of multisig address and get txid and vout and scriptPubKey for multisig address ?
Edit 2:I try to search for software(tool) can be track bitcoin address (balance and transactions) i found bitcoin-abe, but  when i search for it i found i can't search for bitcoin address to retrieve it balance and transaction ? anyone know tool like blockchain when i request about bitcoin address give me balance and transactions ?

no answer !!!!!

Give it a little more time, it was in the middle of the night on half the planet. Alternatively, you can try to give your question more exposure by linking it in social networks or such.

The built-in multisig support in the reference client is only a proof-of-concept. As until recently (and still) the wallet did not deal well with coins being spent outside of its control, it was decided to only allow spending multisig coins when you have all keys. Of course that completely defeats the purpose of multisig, but proper support for it requires separate tools anyway (to pass the partially signed transactions around, etc).
However, the planned watch-only wallet support does allow watching multisig addresses too (in fact, any script at all), which will appear in listunspent. Clearly, the regular sendtoaddress & co RPCs cannot spend these coins, but it does give the ability to track them.

how can i know the balance of multisig address ? is there any api RPC to get balance and transaction of multisig address ?

if there isn't api RPC to get balance of multisig address and its transactions, is there exist blockchain.info api to get balance of multisig addreess and its transactions ?

No, to know the balance, you need the wallet to track the transactions. The current wallet implementation in the reference client does not consider a transaction 'ours' when it pays to a multisig address you don't have all keys for. The planned watch-only functionality will allow this, by consider a transactions 'ours' without the ability to spend from it.

What is means of "The planned watch-only functionality" ?

Pieter Wuille: i want know know how can i get multisig balance and txid and vout and scriptPubKey to send fund from it ? what is steps ?

How to do it now? Use software that supports it. The reference client's wallet currently doesn't, but it is far from the only wallet client out there. There is a planned feature that will likely make it into the next major release (watch-only wallets) that will allow you to track transactions crediting arbitrary scripts, which will allow you to do that.

what is software that supports it ? can you give me example please ? thanks your efforts for answering my question

Pieter Wuille : can you please answer my question ?

bitcoin-cli getreceivedbyaddress. you can use this command to get the balance of any address @Dev777

@Vivek no. It tells you how much your wallet received on that address. It does not list a balance, and it does not work for addresses outside your wallet. You can import addresses without corresponding keys now though, through importaddress.

You may want to look at APIs that support both multisig address and building multisig transactions as support in Bitcoin Core is still partial. For example:
http://dev.blockcypher.com/#multisig


text:
Is there any way to move the Blockchain?
I'm using a solid state for my boot drive, I'd like to make sure the blockchain goes to my data drive, any way to acomplish this?
Edit: I am using easyminer and bitcoin-qt, it is about moving the blockchain. I looked for something similar. When you don't know what you're looking for it's hard to find answers about it.

Can you explain what you mean by "the hash"? What client software are you using?

Sounds like you're talking about the blockchain, not the hash. Which is the blocks sub-directory of your bitcoin data directory. There are plenty of questions already answered about this.


text:
Are Namecoins obsolete with the upcoming Bitcoin 0.9?
After I have read this article (Smart Property, Colored Coins and Mastercoin) on coindesk I guess that Namecoin is obsolete. I have read the possible use cases for Namecoin and as far as I understand coindesk, it tells that Bitcoin version 0.9 will have the same features.
Difference: Bitcoin will use 80 Bytes of message data where Namecoin will use 520 Bytes.

Is that true, that Bitcoin 0.9 will have the same features Namecoin has?
Will Namecoin still have any special quality compared to Bitcoin, that justifies Namecoins’ continued existence?
Or in other words: Is the low value (compared to Bitcoins) of Namecoins the only advantage over Bitcoins, because messages, notary acts, votings etc. are much cheaper and therefore only affordable with Namecoin?

Well, the fact that it will be possible to implement features similar to Namecoin that it will become obsolete.
Bitcoin is intended as a currency and a payment system, while Namecoin is designed specifically as a DNS provider for .bit domain names.
The fact that Namecoin would be able to handle .com domain names, doesn't mean the currently employed centralised DNS would become obsolete either. (OK, some may argue it does, but Namecoin is not going to replace centralised DNS providers.)
Namecoin is intended for a very specific goal. Be a decentralised DNS for .bit domains. Existing proxy applications exist to map .bit domain names to IP addresses using the Namecoin network. The fact that it would be possible to replace all those programs with an alternative program using Bitcoin makes little sense. Why would a payment system take over the functions of a DNS system?

Well, Namecoin is not only a DNS system, although it seems to be the only use case that has been “widely” used. And Bitcoin has a lot more reputation and fame and if it has the same features …

Hmm, it seems like the Wikipedia entry for Namecoin defines it differently then the Namecoin wiki does. Wikipedia mentions "Namecoin is a cryptocurrency which also acts as an alternative, decentralized DNS, which would avoid domain name censorship by making a new top level domain outside of ICANN control, and in turn, make internet censorship much more difficult, as well as reduce outages." Myself, I believe Namecoin would benefit from more tightening their purpose.


text:
Can old wallet.dat (offline long time) still receive money?
I have an old wallet.dat file (from a backup) and no client installed since a very long time. Recently some transactions have been made (BTC have been sent to my address).
Will this old wallet.dat file allow me to be the owner of the new money? I’ve read that 100 private keys are generated in advance and are in stock of the file. Does that mean, that I can receive 100 transactions after taking my client (it was bitcoin-qt/bitcoin-core) offline? Or what are these 100 keys for?

Can old wallet.dat (offline long time) still receive money?

Yes. If you have the addresses from that wallet, coins can be sent to those addresses.

I think that I remember that 100 private keys are generated in advance and are in stock of the file. Does that mean, that I can receive 100 transactions after taking my client (it was bitcoin-qt/bitcoin-core) offline?

An address can receive coins more than once, although it's considered best practice to try to avoid that. But, in practice, you can receive many transaction that pay to any of those 100 addresses.

In my wallet I have currently 2 addresses. Do you say that I can only have 98 more addresses? Maybe I have to ask a new question regarding the specification of a wallet file.

No, you can have as many addresses as you want, the wallet always creates new addresses to have 100 unused addresses in store. You can receive unlimited transactions to each address, it is just for privacy reasons that one should only use addresses once.


text:
Is proof-of-stake a viable alternative / augmentation to proof-of-work?
Meni mentioned Proof of Stake as a possible way to augment Proof of Work as the underlying mechanism powering Bitcoin confirmations.
Is it viable? What are its downsides? Who has analyzed it? (I don't see a lot of people on this thread)

This answer might be enough to make proof-of-stake not needed.

Your question is a good question, but this is not an answer to this question. Again, please do not move random discussions which are not backed up with some solid theory to this site (Especially using two levels of redirection).

I did mean it as an answer. If proof of stake is not needed (as I currently believe might be the case), then the whole viability question is moot.


text:
Is there a remote, trustless bitcoin API that doesn't require anything (blockchain/SPV headers) to be stored locally?
This question asks about how to work with bitcoin via an API without requiring a local blockchain. The only answer is about blockchain.info's JSON API, but it appears that unlike the web version of blockchain.info, the JSON API requires the account passwords to be sent to the server.
Is there another remote API that allows one to perform various bitcoin operations without compromising security - without sending private keys anywhere, but rather signing transactions locally? The API should not require any downloads - SPV does not fall under this category - but should just be a remote API to the bitcoin network that doesn't require any state / bootstrap from its client.
If I recall correctly then Stratum was supposed to be this API. Did it ever take off?

Also on bitciontalk - https://bitcointalk.org/index.php?topic=144347.0

I'm not sure how you want it to be trustless if you don't want to validate anything locally?

@PieterWuille - I am willing to trust that a remote node is not lying to me (I need to carefully choose that node/s). However, I do not want that node to know my private keys - instead, I'll sign transactions locally and send the signed tx to the node.

See also http://bitcoin.stackexchange.com/questions/7855/sending-bitcoins-programatically-without-running-a-node

The BOP Enterprise Bitcoin Server is an open source full node implementation with remote (that is client side) wallet. The server downloads the block chain does the transaction and block validation and routes transactions signed at the client.
The client connects to the server via a message bus. There is a Java and other APIs available with added client side features. Source code: https://github.com/bitsofproof/supernode
Commercial support and hosted instances available at http://bitsofproof.com

BOP is not yet "enterprise grade". In fact I could not even compile it on my new Win64 system. I feel it is a bit unstable as of now. Hopefully this is improved.

but the original question specified "without blockchain"

There are quite a few answers in the bitcointalk thread. This is what I consider to be the best option:

Using blockchain.info for queries
Using bitcoinj to sign transactions
Using blockchain.info broadcast API to broadcast transactions

This class from the the android version of My Wallet is supposed to implement this scheme.

There is a simple and customized Git repo available (Node.js).

Github Repository Link
This code allows you to do things such as:

balance - Retrieves the balance of a wallet.
fees - Gets a list of
current fees based on the BitCoin network going rate.
utxo - Pull a
list of unspent transaction outputs.
pushtx - Push a raw transaction
onto the blockchain.

bitcore-wallet-service by Bitpay seems to satisfy your conditions, in that it does not require you to log in or send the private key.

As a client that doesn't download the whole blockchain, you must trust the bitcoin network more than one that does. That being said, there is only one question you absolutely need the blockchain to answer:
"How much money do I have?"
Such clients are called SPV, which was a method described in the original bitcoin whitepaper. Electrum is one such client.
It doesn't have an API, but it is open source, so, if you want, you could write a python wrapper for it.

SPV still requires downloading headers. I am seeking an API that 1. Requires you trust something (e.g. that the server won't lie to you regarding how much money you have) 2. But that will not require you to download anything and 3. will not require your private keys, so will not be able to steal from you.

So, you're looking for an API that does everything but the signing for you, right?

The API should include a client library that does the signing. The remote API should indeed do everything except the signing.

What do you mean Electrum doesn't have an API? What is Electrum-server then offering?

@JanusTroelsen It offers an undocumented interface.


text:
How is a Butterfly Labs Bitforce Single powered?
Its website says it uses 80W of power, so that's too much for a USB port. How does it receive it's power?
Can it run on a 240V power supply, or does it need 110V?
Note I'm not asking about the newer "Bitforce Single (SC)", which hasn't been shipped to anyone yet. This the older (FPGA?) hardware that has been sold for some time.

It uses ~70W @ 12V of external power. The stock power brick is cheaply made, giant, and inefficient (PF=.5,efficiency~.8). Fortunately, the power brick can run on 240V.  Many people make their own cables to use an ATX or bench PSU (with higher powerfactor and efficiency)
source: https://bitcointalk.org/index.php?topic=67819.msg796852#msg796852

Yes it can. IIRC, it's the standard 100-250V 50-60Hz


text:
How do I report a bug in the Bitcoin client application?
I just installed the v0.4 client and have a bug to report... where can I do this?
If you could also describe how to check if the bug has been reported already, that would be great too.

You can use the issues page on github. https://github.com/bitcoin/bitcoin/issues?state=open
You can also search through the issues to see if yours is already reported.

In addition to the github issue tracker, if you're a fan of real-time communication, you could also try dropping by the #bitcoin-dev IRC channel on freenode and chatting to the folks on there about your issue.


text:
Programming and the ECDSA equation
I've been implementing point addition into a c++ program I've written but I don't see how this can be done right.  When I do slope = (y1 - y2)/(x1 - x2) I get a freaking decimal, which doesn't produce the proper points when applied to the other parts of the equation due to  it not retaining its fractional qualities.  Anyone have any ideas how how to get past that?
Point Addition being defined by the following equation:
slope = (y1 - y2) / (x1 - x2)

xsum = slope ^ 2 - (x1 + x2)

ysum = slope * (x1 - xsum) - y1

Whereby Private Address x02 with x,y coordinates respectively:
89565891926547004231252920425935692360644145829622209833684329913297188986597
12158399299693830322967808612713398636155367887041628176798871954788371653930

with the Point Addition of Private Address x01 with x,y coordinates respectively:
55066263022277343669578718895168534326250603453777594175500187360389116729240
32670510020758816978083085130507043184471273380659243275938904335757337482424

applied to the above equation produce the result of Private Address x03 with x,y coordinates respectively:
112711660439710606056748659173929673102114977341539408544630613555209775888121
25583027980570883691656905877401976406448868254816295069919888960541586679410

http://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication
EDIT:
I put this C++ program together, and I've modified in every way I can think of (moving %p around, doing it too many times, breaking up the equations and the like).  I can't get it to result in the proper results.  Anyone mind checking it out and see what you can find please?
http://coliru.stacked-crooked.com/a/26f9ed24ed5a86ed

You should probably give a pointer to the description you're reading, since those I have seen don't have anything called slope.  At a guess, though, perhaps the division is meant to be done using modular arithmetic?

Wow, first response and its already challenged my limited understanding of c++.  how would I make it a ..."pointer"?

Sorry, I just mean a URL to the description of the algorithm.

you use  ph1^2  which is XOR in C++,  you should write ph1*ph1,

and you use way to many brackets. and the %p applies only to (gx1 + gx2), not to the whole expression

and you use unsigned ints, i think you need signed integers.

and the while (a>1) in your mul_inv  should be: while (b!=0)

On the bottom right corner of the website there is an "edit" button anyone can use to try it (then you compile and share it, the share will produce a new url u can share).  http://coliru.stacked-crooked.com/a/7368ec065cd78b8c is the newest one.  I tried all your suggestions (any many variations thereof) to no avail.

http://coliru.stacked-crooked.com/a/3f9112304c3c9c44

Wilem, tyvm, I can't even make sense of why one of my variations didn't work (as I "know" I tried that).  Maybe I'm making a mistake where my programs aren't compiling in an updated form or something....  would you by chance mind showing me how you'd get the proper y coordinate too in that program?  i really don't understand it; but mine isn't working for the y value.

http://coliru.stacked-crooked.com/a/fdaee6a813614d51

Okay, I got it....I don't get why I had to do y2 = (ph1 * gx1) - (ph1 * x2) - gy1 with %p of each parenthesis rather than y2 = ph1 * (gx1 - x2) - y1 and then y2 %= p.

your ph1 result somehow has the wrong sign,  if you replace it with 'p-ph1'  you do arrive at the correct result.  maybe something is wrong with your mul_inv still?

That seems possible suddenly, I just checked some of my results, the program spits out the proper x,y coordinates for only a couple addresses.  It suddenly gets the wrong y coordinate, then that skews all subsequent values. I'm assessing it further

http://coliru.stacked-crooked.com/a/74648b16c2692525 Resulting values of x are valid up to 0x05, at 0x06 they are wrong.  Values of y are only valid for 0x03, and for no others.

The magic phrase on that page is in a finite field.  Here the finite field is the integers mod p, where p is the number 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1 (see here).  So all the arithmetic in your equations isn't ordinary arithmetic of integers or real numbers; it needs to be done mod p.   See http://en.wikipedia.org/wiki/Modular_arithmetic.  For addition, subtraction and multiplication, you can use ordinary integer arithmetic and compute the remainder mod p at the end.  For division, you will need something like the extended Euclidean algorithm.  Of course, you will also need to be using arbitrary precision arithmetic if you are not already, since numbers of this size are much too large for standard C++ types like long int and double.

So basically there is no single short simple method by which to achieve this?

No, I don't believe there are any shortcuts that simplify it significantly more than what you've already read.  In particular, you can't avoid the use of modular arithmetic.


text:
How to get the Z value aka Hash of the outputs to be signed
I get it that the "OP_CHECKSIG" does this, but I can't see how to recreate it.  I tried SHA1 and SHA256 of some of the info in a given bitcoin transaction but it didn't give me confirmed values of Z.  Can someone please select a transaction, tell me which one it is and show me what I need to cut and paste into a SHA1 calculator to get the actual Z value?
The hash value of TX 9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1 is supposed to be z = c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
and also z = 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc but I do not see how the z values are achieved.

0) read How to redeem a basic Tx?
1) take your transaction as array of bytes
2) replace all input scrips to empty scrips
3) replace one input script to original "OP_DUP OP_HASH160..."
4) append "hash code type" SIGHASH_ALL
5) take sha256 ( sha256 ( data ) )
that's all
Have a look on my code
const MyKey32 Transaction::getRawHash ( const int n, const QByteArray& scr ) const
{
  MyByteArray ret;                                    // create empty array
  Stream stream ( s );
  ret.putInt32 ( stream.readU32 ( ) );                // version
  ret.putVarInt ( stream.readVar ( ) );               // input count
  for ( int i ( 0 ); i < inputs; i++ )                // copy all inputs
  {
    ret.append ( stream.readHash ( ) );
    ret.putInt32 ( stream.readU32 ( ) );
    stream.skipVarData ( );                            // skip original script
    ret.putPrefixed ( i == n ? scr : QByteArray ( ) ); // !!! script replacement
    ret.putInt32 ( stream.readU32 ( ) );
  }
  ret.putVarInt ( stream.readVar ( ) );                // output count
  for ( int i ( 0 ); i < outputs; i++ )                // copy all outputs byte-by-byte
  {
    ret.putInt64 ( stream.readU64 ( ) );
    ret.putPrefixed ( stream.readVarData ( ) );
  }
  ret.putInt32 ( stream.readU32 ( ) );                 // lock
  ret.putInt32 ( SIGHASH_ALL );                        // !!! append hashcode
  return MyKey32 ( ret.constData ( ), ret.size ( ) );  // create hash256 of array
}

That helps me somewhat, but an example of an existing transaction would enable me (and others I'd assume) to understand it best.  Also, are you sure that that results in what is referred to as the "Z" value in the equation?

Yes, I am sure that this method works. This is a part of a program which looks for compromised private keys. The results (not recent) are here https://bitcointalk.org/index.php?topic=461351.msg6408633#msg6408633 () I can help you more but not for free.

Is there, by chance, a website I could simply paste something into and it'll give me this hash?  Too many steps to this process are currently beyond me.