I can't access bitmit. I get no response in my browser or from a ping.

Can anyone confirm the status of http://www.bitmit.net?

Aaaaack been a long time since I looked at this and forgot to copy the new _CppBlockUtils.so to the repo. I have not changed any c++ code, this is just a wrapper. I am going to put this on hold until the changes are made. Then I will properly re-assess the situation and put this in a fork of BitcoinArmory rather than as a standalone daemon with the .so binary included.

I have recently pushed changes to the daemon to bring it up to date with the latest armoryengine.py

Unfortunately I am unable to load the blockchain, and am getting these errors.


Any ideas why these errors are being thrown? This is happening in TheBDM.run()

The daemon still runs and correctly responds to getnewaddress however I haven't got a suitable wallet to test the other calls, namely:
getbalance
getreceivedbyaddress
listtransactions
sendtoaddress

Please see https://github.com/thedawnrider/BitcoinArmory-Daemon/blob/master/armory-daemon.py for the source

Sorry for neglecting this for so long. The site is going to be shut down due to lack of interest.

The site has served the purpose of me learning a few things about hosting a bitcoin related site, so rather than maintain a non-used site I will shut it down.

Anyone interested in the code, I will be open-sourcing it after the site is shut down.

I am unable to find any services that allow me (as a non-American person) to order something which is only shipped to American addresses, and have the package forwarded to me in my non-American country.

eg what http://www.ship2me.com/ does

Does anyone know if such a service exists? Seems like bitcoin is a natural fit for this kind of thing.

This is an interesting point you make. On one hand it seems fairly certain you are right about this, but maybe etotheipi can confirm whether the wallet can handle the creation of multiple unsigned transactions at a time? It seems like a fairly likely situation to happen under most normal use cases, even with the gui client. If the daemon software can avoid having to implement a strict 'sequential' series of transaction where the server must create-a-tx-then-announce-before-creating-the-next-tx, it would make life much much easier.

TBH I always assumed transactions could be grouped and processed offline as a batch. If armory does require one-at-a-time, that would become a very limiting factor for even a moderately popular web-based service.

Massive kudos for making this happen unclescrooge. Armory takes a fair bit of poking around, so it seems you've done well with this.

I added the code and have written some basic tests, unfortunately time is unexpectedly short for me this weekend so later in the week I will try adding the missing fields from listtransactions (and properly confirm that the existing fields are correct).

See the latest on github for the changes. I appreciate the efforts you have put in unclescrooge. It's nice to know people are looking at this, gives me motivation to continue on it. I was planning to use this in a project I was working on, but that has been put on the backburner and as such armory-daemon has languished.

If you think you can improve or add to this please do.


Here is some brief background to help with the understanding.

The bitcoin network is essentially a shared log of all the transactions ever made (this log is known as the blockchain, but I will refer to it as the log, since I found lingo to be a serious hindrance to my own initial understanding). By adding up all the cumulative transactions since the beginning of time, the current balance of each person can be determined (much like how your regular bank account works). If you can easily change previous entries in this log, you can easily change your balance, so the purpose of mining is to make it infeasible for any individual to artificially alter this log.

There are really two challenges that mining solves - making the log unchangeable, and allowing a group of potentially untrusted computers to arrive at an agreement about what the current state of the log should be.

1) Mining to make the log unchangeable - ie making the log secure

For your google, 'proof of work' is the key to how this works (explained later in this email).

Miners all have an agreed-upon version of the log on their computer which they have downloaded via the p2p network. When a new transaction is broadcast on the network, it needs to be added to the log. The idea of mining is to make adding the new transaction simple but to make changing old transactions difficult. To achieve this, miners perform a specific calculation on 'the soon-to-be future version the log'.

The miner is seeking a specific piece of random data (aka a nonce). They add this random piece of data to the existing log, plus any new transactions, and do a calculation on that data (the calculation is known as a 'hash'). The aim is for the calculation to give an answer which is less than a specific value (know as a 'target') set by the network. When the miner finds the random piece of data that leads to the answer being suitable, they announce their finding to the network and the network verifies that indeed that piece of information gives the result desired, and those transactions are added to everyone's log. This requires some deeper explanation, and a tangent.

Hashing is the process of taking a piece of data and creating a 'fingerprint' for this data. The fingerprint is known as a 'hash'. You can pretty-much substitute 'hash' with 'fingerprint' throughout this document. You can hash a piece of text, a file, a number, a database - any piece of data. The main thing about a hash is that the content of the hash will be different for different pieces of data, but every hash is the same size. For example, the hash of 'test' is 098f6bcd4621d373cade4e832627b4f6 and the hash of 'Test' (capital t) is 0cbc6611f5540bd0809a388dc95a615b - completely different despite only a small change in the input, but both the same length. (Although these hashes have letters, they are actually numbers in base16, aka hex format. a=10, b=11, c=12 ... - hex numbers can be converted to regular base10 decimal numbers trivially, but base16 is friendlier to computers... I badly want to geek out about hashes here but it's a bit tangential so you'll have to ask me if you want that kinda info). Another thing about hashes is if someone gives you a hash, you can't easily say what original data resulted in that hash, but if you have the original data, calculating the hash is very easy. This property leads to the hash being known as a 'one-way function'. This 'one-way'-ness is very important for mining. Note that in this example I hashed 'test', which is a tiny piece of data, but bitcoin miners are hashing the entire bitcoin history, which is several gigabytes of data.

Back to the topic - what miners do is calculate the hash of the old transactions (the log), plus the new ones, plus some random data. They look at the number which results from the hash (it's completely unpredictable what that value will be) and see if it's less than a certain value set by the network. If it is, it means that (statistically speaking) there has been a certain minimum amount of calculation that has been undertaken to reach that result. This is the 'proof' of work. An example:

I am a miner. I perform one of these hashes on the old log + new transactions + a random piece of data and it gives me the number 1000. The network says I need to find a result which is less than 200. It won't accept my result, so these new transactions cannot be added to the network yet. I do another hash with a new random piece of data. The result is 777. Still not low enough. I try a hashing a third, fourth, fifth random piece of data, with no luck, but my sixth piece of random data I get the value 160. The random value I used to get 160 is announced to the network, and after others on the network confirm the result, the network accepts my solution and the new transactions are added to the old log. The fact I am able to provide this random number is 'proof' that at least a minimum number of calculations has been performed. The network knows this because for a hash to give a result less than 200 will take, on average, a certain number of calculations. Of course the numbers in mining are ridiculously large, but this example highlights the principle. Sometimes the next result will be found very quickly, sometimes it takes a long time to find. But in the long run, it all averages out. On the bitcoin network these random values are found approximately every ten minutes.

This is where the 'one-way function' property of the hash comes in. Miners know what they want the result of the hash to be; the network has told them - in the example above the result must be less than 200 - but they can't easily work out what the random portion of the data should be by 'reversing' the hash. They just have to guess the random part over and over until they find a suitable random portion that hashes to the less than the value required by the network.

The problem now is, if more people start hashing, successful hashes will be found much more quickly. (Why this is a problem is something I can answer later if you want). To account for this the network adjusts the minimum value required so that solutions are found by miners roughly every ten minutes, regardless if it's a few guys mining on their pcs or if it's governments using their crazy supercomputers. Another example:

The hash that the network in this example uses leads to results between 0 to 9999. The minimum value required by the network to accept a 'proof' is 9000. It's pretty easy to find a hash that is less than 9000. On my own, I could find the random piece of information to give me the right hash every ten minutes. But then fifty more people start calculating hashes on the network, and new solutions can be found every fifteen seconds. The network notices this speed up and adjusts the target value to be less than 6000. Now it takes me a lot longer as an individual to find the value, but because there are more people performing the computation, it still takes on average ten minutes to find the value. The bitcoin network does this adjustment (known as a 'retarget') after 2016 hashes have been solved ('solving a hash' is known as 'finding a block'), which is about every two weeks. This is one of the mechanisms which allows anyone to take part in securing the network, or to stop taking part without compromising the security.

So apparently this hash / proof of work thing is a way to ensure transactions are only added to the network at a certain rate. But it does much more than that. Because the result of the hash changes depending on what the inputs are, if someone uses an altered history from what everyone else is using, their history + new transactions + random value hash won't be the same as everyone else's, and their random value will be rejected even if they think it's a good value (ie there is no purpose to them mining). Because the log is cumulative, and a certain minimum amount of computation has gone into building that log up, to change it would require more computation power than what the miners are putting into it, which is a lot (far more than any individual would realistically have - this concept has been horribly simplified but it gets the idea across).

We have arrived at one of the purposes of mining - the log cannot be easily changed.

2) Allow untrusted computers to share a common log

The point above showed that malicious miners cannot use an altered history because it would affect their hash. This requires some more explaining.

Users of bitcoin would only ever aim to potentially alter their own transactions from the log, eg to say that the transaction they made five days ago never happened. Mining prevents this from happening (known as a 'double-spend').

Say I have a transaction in the log which is one day old, where I sent someone 100 bitcoins. I want to change that transaction from having sent 100 bitcoin to having sent 0.1 bitcoin (or even completely remove the transaction). If I can do this, the person I sent 100 btc to yesterday would now have only 0.1, and I would have regained 99.9 bitcoin. To understand how to do this and why it's hard, a tangent must be taken, regarding how the 'correct' version of the history is determined.

The network decides which history is valid by a very simple rule - it takes the longest history and uses that. And by longest I mean the one with the most transactions (even that is simplified, but essentially good enough). So for me to change a transaction from one day ago, I can't just cut the last days transactions because the network would reject my history for being too short. I must provide the network with a modified history that is at least as long as the current history. To do that, I would have to have had enough computation to recalculate any transactions after the modified one up to the present moment, thus making my history longer than the currently accepted one, despite containing a fraudulent transaction from a day ago. To achieve this is computationally and economically infeasible. The older the transaction, the harder it becomes to change. Hopefully you can begin to see that the 'cutting edge' of the log is a fairly tumultuous place, and that the explanation given here is indeed fairly simple.

This demonstrates how mining prevents malicious users from altering the history and allows untrusted people to maintain and agree on a common piece of data that is continually changing. You can see that if miners stopped performing their computation then it becomes easier for a malicious user to be able to alter the log.

3) A bonus purpose of mining is as a way to distribute the currency. When a miner finds that random piece of information and contributes to the log, they're given brand new coins by the network. This is their reward for securing the log. And it solves that simple yet necessary problem of who to give the coins to and how to initially distribute it. It made me stop for a moment when I learned this and ask how do current printers of money deal with the initial distribution... something I had not previously considered.


Now, for the words you wanted clarified -

Nodes:

A node is a computer running the bitcoin software. Some (most) nodes simply store the log and don't do any work on it. They receive new transactions and pass them on to other computers on the network (known as 'relaying a transaction'). You might say this is one of the significant parts of the p2p portion of the network, along with p2p sharing of the log itself. Some nodes perform the computation I talked about, known as mining. Any node can mine for bitcoin, ie add transactions to the log, the person just has to tell the software to start mining. But most nodes do not mine. Any time you are running the bitcoin software, you are a node on the bitcoin network.

- hash

Explained above - essentially a digital fingerprint for a piece of data.

- zero bits

Not sure your level of understanding of computers so I will explain it in full. A number on a computer is a binary value, a series of 0s and 1s. For example, the number 5 in binary is 101. 5 is a 'three bit' binary number. Another example, 128 is an eight bit binary number - 10000000. You can open your calculator and change it to programming mode, and go from binary to decimal if you want to better grasp this. But I'm pretty sure you know binary! The point here is that 'bits' is the length of a number in binary format.

A zero bit is any bit that has zero in it. For the purpose of bitcoin, leading zero-bits are of interest. Consider the number 0001 in binary. This is simply the number 1, but with three leading zero bits.

Remember how a hash is 'fixed-length' number? This means it's possible to have a hash which has the first part of it as zero. In normal decimal maths, the leading zero is ignored, but because hashes are a fixed length, the leading zero is included in the number.

Also remember the network requires the output of a hash to be less than a certain value for it to be considered valid? You can see how miners would be interested in how many leading zero bits are in the result of their hash, because that determines how small the value is. eg a hash that results in 1000 is quite large, but a hash that results in 0001 is quite small.

In other words, the number of leading zero bits determines how small a number is.

- proof-of-work

Outlined above, proof of work is a system that proves, statistically speaking, that a certain amount of computation has been performed.

Sorry for the slow response, I am subscribed to this thread but very rarely come on this forum any more so have not been updated on the new posts. I recently started at a new job which has sadly diverted my attention away from bitcoin dev.

I will be looking at this code on the weekend. I made some changes a while ago but never pushed them to git. By the end of the weekend check back on this thread, there should be updates. It's been a while since I've looked at this daemon, and certainly have not been using it in production on any of my systems. But from memory I also could only get getNextUnusedAddress to work properly, although the other calls did something slightly related to the required task, just not something completely useful yet.

The end of the weekend - I am sure some updates will be ready.

https://github.com/bitcoin/bitcoin/pull/1862

Yes the rpc port is still on port 8332, lsof confirmed this.

The other problem was using 127.0.0.1:8332 which didn't work, but localhost:8332 did work

Thanks for the clarification Diapolo.

I'm trying to make a connection to bitcoind testnet but it fails with 'curl: (7) couldn't connect to host'

It used to work, but now it does not. I can connect to non-testnet without issues.

I noticed that I have a new folder in my .bitcoin directory called 'testnet3' - I put my old certificate and key files in that new directory for ssl (although both ssl and non-ssl rpc is broken for me on testnet). The certificate and key file is in .bitcoin and .bitcoin/testnet and .bitcoin/testnet3 so I am sure the file is not the problem.

When I try to connect with or without ssl to testnet via curl I get the response in the first line of this post.

Here is my command to testnet which does not work: (change port to 8332 and the commands work for me with non-testnet)

non-ssl
curl --user bob --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.7:18332/

ssl
curl --user bob --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' https://127.0.0.7:18332/ -k

Any ideas why this is no longer working? Can anyone else confirm rpc is not working for testnet? Am I missing something obvious here and just need a sanity check?

Bitcoin version from getinfo is 70003

The api for everything except getnewaddress depends on loading the blockchain. If you stripped it right down to just that one call, then yes it would be great when combined with bitcoinmonitor.net, and as you say, it's not even required to have bitcoin running. But for any functionality beyond getting new addresses from the wallet, you will still need to have bitcoin running so there's access to the blockchain.

The simple Armory Daemon is now on github. It aims to be as close to a direct replacement for the Satoshi interface as possible.

https://github.com/thedawnrider/BitcoinArmory-Daemon

Available json-rpc calls are based on the Satoshi rpc interface and are as follows:

getbalance
getnewaddress
getreceivedbyaddress
sendtoaddress

getbalance:
Returns a decimal value in BTC for the total remaining balance in the wallet.

getnewaddress:
Returns the next address in the wallet as a string.

getreceivedbyaddress:
Returns a decimal value in BTC for the amount received by the address.

sendtoaddress:
Returns an unsigned transaction as a string. Implementation of signing and broadcasting is left to the client.



Features that may be included in the future:
User authentication
SSL
More API methods as required (the current set fills my needs). listtransactions is one method I am looking to include in the future.
Please suggest anything else you personally may find useful, as I have designed this only to fill my specific needs.



Clarifications required:

- Are incoming transactions which eventually do not become part of the blockchain dealt with correctly? I am unsure how / unable to test this.

- What happens if multiple transactions are made which would result in the balance being less than zero? Presumably when it comes to broadcasting the last of the signed transactions there will be an error from the Armory client which is performing the signing/broadcasting. Should tracking of the likely future balance in the daemon be enforced even though the transactions have not yet been broadcast and maybe never will be? How should this be managed, if at all?

Just to clarify, do you want a C# version of the 'calculator' part of this page (between the graph and the table)?

http://www.bitcoincharts.com/markets/mtgoxGBP_depth.html

API documentation is now available

https://www.bitcoinalafuture.com/api/

Another tip:

 you can post your prediction (or the opposing prediction) easily by clicking the + button next to a prediction in the table on the homepage.

It will look something like this https://www.bitcoinalafuture.com/#price=13&lt=1&time=1347580800000

The link will take you to the homepage with pre-populated fields on the page so you need to do is enter the return address.

I have made a platform for exactly this

https://www.bitcoinalafuture.com/

The aim was to have a data-friendly representation of future predictions. Bets-of-bitcoin has been seeing a few of these style of bets lately but it's not friendly as a data source.

This is a new service only about a week old, hopefully it picks up some traction.

It has a convenient link system so you can easily tell people how to predict against you - https://www.bitcoinalafuture.com/#price=13&lt=1&time=1347580800000

There's some more detail in the service announcements forum

https://bitcointalk.org/index.php?topic=105121.0

I plan to make predictions 'trade-able' by paying the owner of a receive address to change it to your own address.

No longer active

https://bitcoinalafuture.com/

https://github.com/thedawnrider/bitcoinalafuture


Bitcoin à la Future

A place to speculate on the future price of bitcoin.

Summary

Users fill in a statement declaring whether they think the price of bitcoin will be above or below a certain value at a certain point in the future. The user submits their prediction and backs it with the amount of bitcoin they would like to win if the prediction is right. Others may disagree with this statement and make their own prediction against it, and also submit the amount of bitcoin they would like to win if they are right.

When the prediction can be evaluated, the winners receive their initial deposits back. The losers deposits are given to the winners. Winners can win up to the value of their original deposit, minus ten percent for fees. The distribution is on a first come first served basis. Any leftover losing amounts after all the winnings are issued will be returned to their respective losers.

Predictions remain open for activity until two hours before the prediction is due for evaluation. After this time, any deposits received will be returned and not evaluated as a winner or loser.

Uses

Hedging

If a person wishes to be more certain about the value of their bitcoin, they can hedge against a rise or a fall. For example, to hedge against the price going down, a user may predict that the price will be less than a certain value in the future. If it is less than that value, their winnings help keep their overall bitcoin value consistent, and if the amount is more than the predicted value, they lose some coins but the higher exchange rate means their overall bitcoin value remains consistent.

Speculating

If a person would like to obtain more bitcoin, they can predict the price movement and hope that they win. If they do win they receive more bitcoin and increase their overall bitcoin value, and the risk has paid off. If they lose, they have less overall bitcoins and the risk has caused them a loss.

Gambling / Entertainment

See Speculating

Price Discovery

The data is all publicly available and can be used to create an idea of market sentiment.

Future Development

Future development will look to include:
- a chart with interpretation of the data
- documentation for the api
- a websocket to announce new predictions
- the option to replace someone else's return address with your own for a cost (ie buy and sell contracts)

Please let me know if there are any specific features that are desirable or if any of the above future developments are particularly undesirable.

Trust

How can you trust this site? The entire history of the site is available, you can confirm exactly what has happened in the past. Deposit a small amount and confirm that it works how you expect. Never risk more than you can afford to lose. If you still don't trust it, simply don't use it.

Translators

The site has been translated using an automated tool, if you want to provide human translations please let me know and we'll arrange something.

I was thinking for the cotd style site that one address would be published which would be associated with an item, and whoever deposited to the address first would be the winner and get the item, the rest of the payments would be returned. To have everyone get an address and then deposit to it doubles the 'race' for competitors. To prove the comp wasn't rigged I would upload the wallet so the order in which transactions was received could be verified. However, I see that there is no way even with uploading the wallet file to prove that the wallet file wasn't tampered with to make the order specific. For ordered transactions, it's best to use some means other than the wallet tx timestamp to verify it.

Thanks d&t and error, you have helped me realise that bitcoin tx timestamp being more accurate isn't actually a solution to the problem I am trying to solve.

Say I run a site like 'catch of the day' where users deposit bitcoins to a specific address which relates to a specific item. I have 100 of those items. Everyone wants one. As soon as the address is announced, I get 500 people deposit, all received within 1s of each other and thus with the same timestamp. I have to refund 400 of those and send products to 100 of them. Which deposits do I send the product to and which ones do I return? There are many instances where the order of receiving money matters. And many instances where the automation of sending money is possible resulting in floods of transactions. Even without providing a 'real world' example, the question of 'why was the arbitrary accuracy of X microseconds chosen for transaction receive time' is still valid (in this case X is 1e6).

I suspect you will say 'applications like that aren't suited to bitcoin' - but that doesn't answer the question of why the accuracy is low when it could be high, and thus possibly facilitate these styles of applications.


Yes I thought this would be the case. Thanks for clarifying.

I have some questions about the time that transactions are received as recorded by the official satoshi client.

1) Why is the time recorded for a received transaction only stored to an accuracy of one second instead of a greater accuracy such as one millisecond or microsecond? It would seem that for automated services which need to know the order in which transactions have arrived, this would not provide enough accuracy.

I ran a quick test using the following script to send alternating amounts rapidly in a row, which produced the following sent and received transaction list from calling listtransactions (see end of post, trimmed for clarity)

It may be expected that transactions announced in the order 0.1, 0.2, 0.3, 0.4 etc should arrive in the order 0.1, 0.2, 0.3, 0.4 etc however if the time between announcing them is small enough, they do not.

I have justified this discrepancy by telling myself 'the network is complex and transaction propagation is complex', however my second question is

2) If two received transactions have the same timestamp (accurate to one second), how can I be certain which transaction was received first? Is it fair to assume that the transaction list from calling bitcoind listtransactions is in the same order as the client received them? It seems like a fair assumption, but I just want to be sure. From the transaction list I have on the 'send' client it seems this is not the case, and the order for transactions with the same timestamp is arbitrary. For example, when querying a normal sql database for several rows without any 'order by' clause, there should be no expectation about the order of those rows - does this also apply here?

Also

3)  What sort of error should I expect on this? For example, how much time between transactions should I leave to be 99% certain that they will appear in the receive client in the correct order? Can this question even be reasonably answered or does it depend too much on unknown factors?

4) Does the bash script below definitely send the coins in the order described or am I experiencing some kind of threading complexity which means that the transactions are actually being sent in a different order to what I would expect? (Just a sanity check here)


SENDER listtransactions

RECEIVED listtransactions


edit:

and this is the output from the bash script