I've read in the technical section of Chancecoin's site how payouts are handled. But I would appreciate a more in-depth technical explanation of the following topics. How is Chancecoin at all protected from an individual altering their client to award themselves extra Chancecoin? What is the method of consensus between peers to determine the proper random numbers to use? When a gambler loses how is the CHA verifiably destroyed, and when a gambler wins where does the b*(p*(1-e)-1)*c/(c-b*p*(1-e)) CHA come from? Has anyone read through and verified that the source code was secure? No where in this thread have I seen proper replies to these questions.

What exactly is a remittance and why does bitcoin stand to help the remittance market? I've heard remittances described as the act of immigrant workers sending money back to their homelands. Are these all remittances are, or is there a broader definition?

Just used Early Temple to make a contract and it succeeded! Some others and I are developing software that may end up needing any oracle to sign transactions, which is how I originally found Early Temple. Have you thought about making this in some way a distributed oracle? Early Temple is a single point of failure for any app that uses it, and that's why my team is holding back from using it.

I am writing a program that uses RPC to poll bitcoind for information about blocks, transactions, inputs and outputs and insert them into a database. After testing the output for the transactions within one block (specifically block #308799) I found that the number of outputs for some of the transactions in that block (according to bitcoind) were different from when I had originally inserted that transaction's data into the database. The transactions that threw these errors have the following transaction hashes

3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18
70ab887ea76c1c0fa3e4095f2696c7cb53231f9c8f16e2cbe9bd3c49a1f40dbd
3dff1e7732a45e4a0b568220cdad1aaeba1ba871bcc73767560bb6da6ff48273

if we look at the output data for the first transaction hash listed above, we found it looks like this


+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
| id        | txHash                                                           | type       | dstAddress                         | value     | offset | regSigs |
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
| 109811502 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig  | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC |  0.000078 |      0 |       1 |
| 109811503 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig   | 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E |  0.000078 |      0 |       1 |
| 109811504 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig   | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC |  0.000078 |      1 |       1 |
| 109811505 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig   |  1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E |  0.000078 |      1 |       1 |
| 109811506 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | pubkeyhash | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC | 0.0073245 |      2 |       1 |
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+


Note that they only different in the outputs with the same address only differ in their offset value. However, if we compare this to the info found on blockchain.info and on bitcoind for this transaction, located at

http://blockchain.info/tx/3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18

we find that there are only three transactions. There's still one regular pubkeyhash, but 2 of the multisig outputs have disappeared. The same pattern follows for the other two transactions; the same number of regular type outputs are listed on both my database, bitcoind, and on blockchain.info, but the number of multisig outputs is less on blockchain.info and bitcoind than on my database.


Now that I've given the background on my problem, my question is:

Can someone explain to me what is going on with these multisig outputs? Since I'm using bitcoind as a data source and then putting this data into my database, it seems correct to assume that at one point bitcoind really thought there were 5 outputs for that first transaction hash. My guess that bitcoind went back at a future point in time and updated that transaction's outputs, but I have no idea why or how because I don't understand the technical aspects of a multisig transaction. Any light shed on this would be great as I'll need to make the changes to my data-mining scripts as soon as possible if there is something harmful in keeping the transactions with a greater number of multisig outputs.

Just doing some pencil and paper math here. I was originally wondering if Bitcoin ever were to see the type of transaction volume that Visa sees, say, something like 300,000,000 transactions per day, would the lack of available bitcoin addresses ever be a problem. If a new address were to be used for every transaction, then it would still take roughly 2^40 days before we used all of the 2^160 addresses. I obtained this number by dividing the total number of bitcoin addresses (2^160) by the number of bitcoin addresses created per day (300 million), which comes out to roughly 2^40 addresses. So even without expanding the number of addresses, we won't have to worry for another trillion years.

Isn't mining inherently "inflationary" because of things like Moore's law and technological progress? I say inflationary because just like a dollar today is worth less than a dollar in a year because of monetary inflation, a brand spanking new butterfly labs ASIC with 600GH rate is going to be less valuable in a year when that ASIC becomes outdated. Since buying large amounts of these mining devices is a large upfront cost, why would anyone ever choose to go this route?

My friends and I pooled our money together to buy 2 Radeon 7950's a year and a half ago, when we could have made multiple litecoins a day mining. Due to the rig dying when we first got it working and then our hype wearing off after that, we never got it working until recently. Now it'll take several years to recoup the losses, and with FPGA's on the horizon it's a moot point. At least I have a nice gaming rig now 

I know this thread is old, but I came to it first, and then found an example of a transaction hash being in multiple non-forked blocks in the block chain. The blocks that contain the transaction with hash

d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.