Can speak a language other than English?

Are you looking to volunteer your linguistic skills to help a popular open source project?

The site at https://iancoleman.github.io/bip39/ is looking for translators.

If you're willing to help out, please request to become a translator for the project page at

https://www.transifex.com/iancoleman/bip39-website

or if you prefer to edit text files, submit a modified version of

https://github.com/iancoleman/bip39/blob/master/src/js/phrases_en.js

Currently BIP0021 - URI Scheme allows a merchant to request payment from a customer.

However, I'm looking for the opposite - a merchant to request an address from a customer, eg an exchange requesting a withdrawal address. As far as I understand, the only way for the customer to supply a withdrawal address is to copy and paste into a form supplied by the merchant.

I'm interested in the customer being able to click a button and being asked by their wallet to confirm 'do you want to receive X bitcoins into this wallet' and when they press 'yes' an address from that wallet is automatically supplied to the vendor (eliminating the need for the customer to copy/paste their address).

- Is there an existing scheme to request bitcoin addresses from wallets?

- If not, are there any existing documents exploring how such a scheme may work?

I've been interfacing with a lot of third-party blockchain APIs lately, and have found an inconsistency regarding the 'total received' value.

It's easiest to give an example:

Here's a list for totalReceived for the address 173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ

Blockchain.info: 462477517
https://blockchain.info/q/getreceivedbyaddress/173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ

BlockExplorer: 8.35757472
https://blockexplorer.com/q/getreceivedbyaddress/173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ

blockr.io: 4.62477517
https://blockr.io/address/info/173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ

live.bitcore.io: 8.35757472
http://live.bitcore.io/address/173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ

biteasy.com: 4.62477517
https://www.biteasy.com/blockchain/addresses/173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ

Helloblock: 835757472
https://mainnet.helloblock.io/v1/addresses/173MjkFkm1iCYTkW7fBZj5EoPHb5JWhyYJ
Although this seems to have recently changed and is no longer reporting totalReceived

Another address with the same issue is 1RckWiDzbdNEfRuTG1zStNpCYRUWaLJkr (0.9795 vs 1.929), but there are many cases. Mycelium sends change back to the same address so pretty-much every Mycelium transaction will be subject to this issue.

The value reported depends whether amounts sent from the address to itself are counted as received amounts or not. Some services count it, some don't.

Neither approach is necessarily 'right' or 'wrong'. My personal opinion is that amounts sent from the address to itself should not be counted in totalReceived, and in this case 462477517 would be the better value.

It would be good to see some discussion around which option should be chosen, so that some kind of standard can be reached and we don't have two different values for what should be the same value. Maybe there's a need to be more explicit and have both values reported, although I have no idea what naming convention you'd use to differentiate them.

Please post suggestions about which direction you think is most appropriate to take on this issue. Once a clear and logical decision has been reached regarding which value is most appropriate, any blockchain data providers with the conflicting value can be contacted and asked to update. This way the value will hopefully end up consistent across all data sources.

Also if you know of other sources of blockchain data please post them and I will add it to this list.

I've noticed the love that reddit tip bot is getting and wanted to see about extending this to the web in general.

The idea is simple - owners of the page add some metadata to the html elements containing the page content, and that data can be used by readers to send tips to the people who created that content.

The project is at the minimum viable product stage of development - see https://everywhereium.com - but beware, it looks pretty raw.

Things that are in the pipeworks (which you can contribute to!) are:

- graphics and css style for the project homepage
- extensions for other browsers
- a javascript library so people without extensions installed can still use it
- marketing / product people to look at the copy on the pages at everywhereium.com and improve it

and most importantly

- some discussion about how to implement an escrow system. This is critical because no sites currently have this metadata and if users can't send tips to any site they like (via escrow), the idea almost certainly won't grow. Site owners need motivation to add the data, and what better way than already having some tips waiting for them.

I can implement most of this myself (and in some cases already had) but want to get others involved in this idea, so if you can code or
'write words good' or create nice stylesheets or graphics, you should definitely put a little bit of time toward the project and contribute to that whole open-source thing. The project is at https://github.com/thedawnrider/everywhereium and there are several issues open for discussion.

Please have a look at the everywhereium.com site and give feedback. This is just an experiment and I am always open to ideas and contributors.

One thing I really wanted to make sure of was not to visually pollute the web with the tip info - the reddit tip bot (especially when verification is used) is so noisy.

Another thing which was important was allowing multiple people to receive tips per page, eg these forums have lots of individual content contributors per page, and I wanted it to work on these pages as well as single-owner pages.

I believe this idea has a lot of potential, I would love to hear what you think.

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?

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.

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

I've been reading quite a bit on bitcoin which is an incredibly fascinating digital currency and very different to the other digital currencies available. I'm trying to wrap my head around how the mining process works. Are you able to please explain it to me in a very dumbed down way?

Also, I've been reading nakamoto's paper on bitcoin and was wondering if you knew what the following meant:
- nodes
- hash
- zero bits
- proof-of-work

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.

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

[Bitcoin à la Future]

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 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)

Code:

#!/bin/bash
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002
bitcoind sendtoaddress mk563JtWmGCsEng4EpaTH2o6eZYZgCrSLR 0.001
bitcoind sendtoaddress mvTH5BorrGoFicGd9KMwAEiLnjscY55WJr 0.002

SENDER listtransactions

Code:

[
    {
        "amount" : -0.00100000,
        "txid" : "124caf3ca1e1f63a70dcd0253e44b33dec20444ff4c67e9c5715be0ab211e0c8",
        "time" : 1345863327
    },
    {
        "amount" : -0.00200000,
        "txid" : "26b37a2a38fc195e55fa2a395e4818bcb4c97e23b1c200677ab0d6b45f87beeb",
        "time" : 1345863327
    },
    {
        "amount" : -0.00100000,
        "txid" : "d992aecf3b0637e9eac118196c99eaeae1317c296e191246fecfb67c88afb17e",
        "time" : 1345863327
    },
    {
        "amount" : -0.00100000,
        "txid" : "1eebb55f17c2182942ad8599d21e67182d3ebcbd2f6b115ff2e7a94de7ac8a7b",
        "time" : 1345863328
    },
    {
        "amount" : -0.00100000,
        "txid" : "26233a249d6b2491400b4897d8d97478c8dbcb76a677c192edf3b26b9e8d5387",
        "time" : 1345863328
    },
    {
        "amount" : -0.00200000,
        "txid" : "5bb45618fcb27334698047f395018fe619651419870f052455eb9910d519a168",
        "time" : 1345863328
    },
    {
        "amount" : -0.00200000,
        "txid" : "c100372b6840203229556bf159adc84af7289d7acb3ce0413685d86c69b0252c",
        "time" : 1345863328
    },
    {
        "amount" : -0.00200000,
        "txid" : "d71734f47c652afd3306dfa350147801d0a934b8785aafce1153561edeb6e095",
        "time" : 1345863328
    }
]

RECEIVED listtransactions

Code:

[
    {
        "amount" : 0.00100000,
        "txid" : "1eebb55f17c2182942ad8599d21e67182d3ebcbd2f6b115ff2e7a94de7ac8a7b",
        "time" : 1345863331
    },
    {
        "amount" : 0.00100000,
        "txid" : "26233a249d6b2491400b4897d8d97478c8dbcb76a677c192edf3b26b9e8d5387",
        "time" : 1345863331
    },
    {
        "amount" : 0.00200000,
        "txid" : "26b37a2a38fc195e55fa2a395e4818bcb4c97e23b1c200677ab0d6b45f87beeb",
        "time" : 1345863331
    },
    {
        "amount" : 0.00100000,
        "txid" : "d992aecf3b0637e9eac118196c99eaeae1317c296e191246fecfb67c88afb17e",
        "time" : 1345863331
    },
    {
        "amount" : 0.00200000,
        "txid" : "5bb45618fcb27334698047f395018fe619651419870f052455eb9910d519a168",
        "time" : 1345863332
    },
    {
        "amount" : 0.00200000,
        "txid" : "c100372b6840203229556bf159adc84af7289d7acb3ce0413685d86c69b0252c",
        "time" : 1345863332
    },
    {
        "amount" : 0.00100000,
        "txid" : "124caf3ca1e1f63a70dcd0253e44b33dec20444ff4c67e9c5715be0ab211e0c8",
        "time" : 1345863333
    },
    {
        "amount" : 0.00200000,
        "txid" : "d71734f47c652afd3306dfa350147801d0a934b8785aafce1153561edeb6e095",
        "time" : 1345863333
    }
]

edit:

and this is the output from the bash script

Code:

124caf3ca1e1f63a70dcd0253e44b33dec20444ff4c67e9c5715be0ab211e0c8
26b37a2a38fc195e55fa2a395e4818bcb4c97e23b1c200677ab0d6b45f87beeb
d992aecf3b0637e9eac118196c99eaeae1317c296e191246fecfb67c88afb17e
5bb45618fcb27334698047f395018fe619651419870f052455eb9910d519a168
26233a249d6b2491400b4897d8d97478c8dbcb76a677c192edf3b26b9e8d5387
d71734f47c652afd3306dfa350147801d0a934b8785aafce1153561edeb6e095
1eebb55f17c2182942ad8599d21e67182d3ebcbd2f6b115ff2e7a94de7ac8a7b
c100372b6840203229556bf159adc84af7289d7acb3ce0413685d86c69b0252c

In the bitcoin client, calling settxfee doesn't require the wallet to be unlocked by the passphrase. It seems like this is something that should be strictly controlled. A malicious user could cause serious damage by setting your tx fees to a large value, and you wouldn't realise it until after the next transaction was made and your balance suddenly became surprisingly low.

Is there a reason why this call doesn't require the wallet to be unlocked?

[primary]

The result when fetching previous trades on Mt Gox api v1 has two unexplained parameters:
"primary" and "properties"

I'm using at this call:

https://mtgox.com/api/1/BTCUSD/trades

Can anyone explain these two properties in detail for me?

From the docs, I get this:

For multi currency,also returns the primary value,"Y" or "N", the primary currency is always the buyers currency

When primary is "N", what does this mean? For example, in the following data, what does "N" and "Y" mean? (some data removed for clarity)

{..."price":"9.69964","amount":"0.01","tid":"1345617420845024","price_currency":"USD",..."primary":"N","properties":"limit,mixed_currency"}
{..."price":"9.69967","amount":"0.01","tid":"1345617540156865","price_currency":"USD",..."primary":"Y","properties":"limit"}

A trade can appear in more than one currency, to ignore duplicates, use only the trades having primary =Y

What does that mean? Can a trade appear in the data which is not from USD? Does this mean a trade in EUR may appear in the data, even though via the url I specify to only give USD? What are duplicates? None of the data that has primary=N seems to be a duplicate of any of the surrounding data. All the trades have the 'price_currency' property as USD.

What are the possible values for "properties" and what do they mean? In particular, what does the following mean when they appear in properties:
- limit
- mixed_currency

I got my info from the documentation on this page:

https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1#Multi_currency_trades

I appreciate the clarification on what information this data is actually providing. A lot of questions I know but this is very unclear to me.

I'm using rpc to access remote wallets, and I want to ensure those wallets are encrypted before I store any details about how to access them.

Currently I'm calling getnewaddress and then dumpprivkey with that address, and if dumpprivkey returns an error I assume that the wallet is encrypted. If it gives me a private key, I assume the wallet is not encrypted.

This is a pretty terrible way of testing whether a wallet is encrypted.

Does anyone have a suggested 'best practice' way to achieve my goal?

I have been trying to establish an SSL connection to bitcoind

I followed exactly these instructions

https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon

I'm running

Code:

bitcoind -testnet

and then checking the ssl connection using

Code:

openssl s_client -connect 127.0.0.1:8332

which gives the response

Code:

CONNECTED(00000003)
140487709226656:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 226 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

This is all from my local machine, not over a network.

My bitcoin.conf is

Code:

rpcuser=bob
rpcpassword=bob

rpcallowip=192.168.*.*

rpcssl=1
#rpcsslciphers=DEFAULT:@STRENGTH

when I have the configuration line

Code:

rpcssl=1

in my bitcoin.conf I cannot use commands such as

Code:

$ bitcoind getinfo

, I get

Code:

error: no response from server

Can someone please help me diagnose why this isn't working? I'm using the latest version of bitcoin - "version" : 60300

Today I had a quick experiment with multisig on the testnet, a 'hello world' of sorts, and have some questions.

Assumed knowledge is from this thread about multisig.
https://bitcointalk.org/index.php?topic=82213.0

Some background:

I have two machines running bitcoind. The address I use from each of them is as below

address - n4n3p9eU2VsmjL7E2v2sYJUFEDybQ9KWJu
public key - 02b1ebcdbac723f7444fdfb8e83b13bd14fe679c59673a519df6a1038c07b719c6

address - mzdVDLcMRBzLBjhRzNNWcq9C8xSgdmEPe3
public key - 036e69a3e7c303935403d5b96c47b7c4fa8a80ca569735284a91d930f0f49afa86

I used these to create a multisig address:

bitcoind addmultisigaddress 1 '["036e69a3e7c303935403d5b96c47b7c4fa8a80ca569735284a91d930f0f49afa86", "02b1ebcdbac723f7444fdfb8e83b13bd14fe679c59673a519df6a1038c07b719c6"]'

This produces the address 2N5vbPQB7pMqyVa8JRcpZdCQLQCwDZCMyfo

The address validates.

Questions:

My understanding of multisig as it stands is that you can send to a multisig address, but you can't spend from it (see first link in post). Does this mean that funds received at 2N5vbPQB:- cannot be spent at all?

I sent 0.002 BTC to the address to see if it would receive, and thus so I could try to spend them using multisig, and so far (an hour after the send) it has not received the coins even for zero confirmations.

bitcoind getreceivedbyaddress 2N5vbPQB7pMqyVa8JRcpZdCQLQCwDZCMyfo 0
0.00000000

The blockexplorer link to the transaction in question is http://blockexplorer.com/testnet/tx/16e7756fb3ba1994d1f88043b3af0cd0d24e4eb6fb905a377b153668d3f7a043

Am I right in expecting that the address should have 0.002 coins in it?

Where can I find more information about how to spend these coins and when/how they will be spendable; or if I am wrong about this, an explanation to fill in my knowledge gap?

How am I able to better track / analyse this scenario beyond the commands and websites I have already stated?

Is there an estimate for when multisig will be usable? Is it already usable? If it's already usable, can someone point me to the info I require to be able to use it?

[Your webserver can run blissfully ignorant about what is actually going on with the wallet, it just gives out a new address on every request. You can sit at home on your computer with Armory running and the full wallet there, with full control. But someone who compromises the webserver will not get anything!]

Armory Daemon is now available on github:

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

More info on page 2 of this thread - https://bitcointalk.org/index.php?topic=92496.msg1197291#msg1197291

-------------------------

I thought I'd start this thread as a place to collate information about using Armory client on a webserver, since the only info I found so far was hidden on page 16 of the Armory Discussion topic.

The info below is about getting an Armory address on a webserver and it comes from https://bitcointalk.org/index.php?topic=56424.msg765880#msg765880

Anyone who has information or questions about using Armory on a webserver, please post it here so webdevs can make the most of Armory, which currently seems to be focusing on GUI interaction rather than API (understandably).




I put some thought into how Armory could be used for a webserver application, and I realized that with just a couple lines of python, you can generate addresses no problem on your webserver.  I added a couple convenience functions and committed them to the master branch of Armory. Here's what you do:

(1) Load Armory on your computer.  
(2) Create a regular wallet.  
(3) In Wallet Properties, "Create Watching-Only Copy"
(4) Upload watchonly wallet to webserver
(5) Setup webserver to load wallet and call wlt.getNextUnusedAddress() for each request
(6) Sit at home with the full wallet and watch/confirm/send transactions while the webserver does the work!

Demonstration code to see how to access/manipulate the wallet from a python script:

Code:

from armoryengine import *

wlt = PyBtcWallet().readWalletFile('/home/server/web_server.watchonly.wallet')
wlt.setAddrPoolSize(1000)

# Quick printing of addr info, and shows how to access various props of the addr
def pprint(addr):
   print 'The new address: '
   print '   Hash160:  ', binary_to_hex(addr.getAddr160(), BIGENDIAN)
   print '   Base58:   ', addr.getAddrStr()
   print '   Index:    ', addr.chainIndex
   print '   Have Pub: ', addr.hasPubKey()
   print '   Have Priv:', addr.hasPrivKey()
   
print 'Get the next unused address...'
addr = wlt.getNextUnusedAddress()
pprint(addr)

print 'Generating 10 more addresses:'
for i in range(10):
   addr = wlt.getNextUnusedAddress()
   print '\t', addr.chainIndex, '\t', addr.getAddrStr()

print 'Get addr #15'
a160 = wlt.getAddress160ByChainIndex(15)
print binary_to_hex(a160, BIGENDIAN)
addr = wlt.addrMap[a160]
pprint(addr)

print 'This wallet has %d addresses computed' % wlt.getHighestComputedIndex()
print 'Addresses used: %d ' % wlt.getHighestUsedIndex()

Here's the output on a watching-only wallet (this is actually the output of the second time I ran it):

Code:

Get the next unused address...
The new address: 
   Hash160:   728b0b8cc930cb4756328e743b7b2e7dde93a35f
   Base58:    mpEeSrEr3EiyCMRskT5VrELkY8X9ZwT3BV
   Index:     11
   Have Pub:  True
   Have Priv: False

Generating 10 more addresses:
	12 	mrhzBHQcn7jmhvpbcfW6ebiAFEm9qZF6AL
	13 	moPM3KPygygsWzvUHfeDsmPChL5xWycc5y
	14 	n4ZtG47TNMifGJ57msGAs8ZD1HeVqSqRyx
	15 	mw3cxXKCaKitV8w1wBRrpjQNWu4od5Nd5H
	16 	n1UGPkUgUXiwsotzfpAezpy6NkRg1fGMv5
	17 	muFPi3pAw7Rbb9aGc9UJPX9m6JT1VGHf9J
	18 	n3TRNc86Vmi2EygvjeMsAXXAYhPygR2sQK
	19 	mikSy5FjeSPVBSaXDs8ihMKrMgZsoohsjz
	20 	mwb8h2PJvGGGQTA7QBgvPVrWowQZi43ZD2
	21 	mpBFZ1H6AcRqHUZ7ETz1Xh1PqaPiMvdQDM

Get addr #15
c42ea65330263fd9c02fe5ca2e3a1c44dca356aa
The new address: 
   Hash160:   c42ea65330263fd9c02fe5ca2e3a1c44dca356aa
   Base58:    mw3cxXKCaKitV8w1wBRrpjQNWu4od5Nd5H
   Index:     15
   Have Pub:  True
   Have Priv: False

This wallet has 1021 addresses computed
Addresses used: 21 

Your webserver can run blissfully ignorant about what is actually going on with the wallet, it just gives out a new address on every request.  You can sit at home on your computer with Armory running and the full wallet there, with full control.  But someone who compromises the webserver will not get anything!

If you want the webserver to track incoming transactions, it will require loading the blockchain and checking for new blocks periodically.  It's not a lot of code, but I'll save it for later if you are interested.

One other thing:  Armory uses the crypto++ library, which is not particularly fast at ECDSA operations (and my key generation algorithm is kinda slow, which is why I'll be upgrading to a new one, soon).   My [decent] system can generate about 200 addr/sec.  So this script takes a few sec to run.  But all keys are stored in the wallet, so they don't have to be recomputed when you restart the script.

[Usage]

This project is an easy way for POS operators to have a useful interface to bitcoin other than fiddling around with the official client. Just press F2 and a qr code is displayed for your customer. It automatically detects payment and minimizes. No fiddling around, just a nicely integrated additional pos feature.

Bitcoin QR Popup

https://github.com/thedawnrider/bitcoin-qr-popup

Press F2 and see this:


Usage

Press F2
- a QR window appears
- the pos operator enters the amount of the sale in their local currency. This is automatically converted to BTC and the qr updates with this value.
- the customer scans the qr code and pays for their items.
- the application automatically detects payment and prompts the operator when the payment arrives.
- when the operator acknowledges the prompt saying payment has been received, the window disappears to resume regular pos operation.

Press F3
- a short history of transactions displays, making it easy to verify if the most recent payments were actually received. Probably not that useful, but if a customer 'claims' to have paid but hasn't, it's nice to be able to easily check.

Details
- Must have a local copy of bitcoin - remote support will take extra time to integrate.
- Must have internet access on the pos machine.
- Must be a windows machine. From my observations, most pos systems are windows-based.
- Bitcoin must be running in daemon mode (bitcoind.exe)
- This app won't run unless using an encrypted wallet. Forcing responsible practices on users? Better than the alternatives.
- Uses openexchangerates.org for hourly updated currency exchange rates. (164 different currencies available)
- Uses 24h weighted USD price from bitcoincharts.com for bitcoin exchange rate.
- Uses zero confirmations. There is no check for 6 confirmation, but adding this one hour after the transaction shouldn't be too hard to add.
- Only in English at this stage, I would love to translate this app to many languages. Google translate supports... something like 50 languages.
- Requires the .NET framework.

Roadmap
- Unit tests
- Better error handling, especially if bitcoin stops unexpectedly and the app is still running
- Translations to other languages.
- Remote bitcoin client access.
- Support mac and linux.

I imagine this will be mostly of use to small businesses who have a 'one computer fits all' type situation, such as my mechanic. It wouldn't take too much to extend it to remote access which makes it more attractive to stores with multiple pos terminals.

For the technically inclined who wish to review the code, please not that C# is not my native language, I'm a python web developer. Thus, I'd appreciate your input. If you would like to submit changes please send me a pm. Note that I had to modify bitnet to include a call for walletpassphrase as a way to check for an encrypted wallet, so the source code included in the bitcoin-qr-popup repository is slightly different to the official release for bitnet. This app has had a minimal manual test on Windows7 and XP.

If you use this app or want to see more like it, donations to 1FiVXpdBdcnv6GAVZDKRxeSJqZQrSx2s2Q are always welcome. I live in Melbourne so if you want some help getting it set up and you're in Melbourne I would be happy to help out.

As a final note, this is really just a new take on the official bitcoin client. I have a keen interest in UI and UX and this project is simply a different way to visualise and interact with the official bitcoin client. I hope it is of use to some people out there. Hopefully this project can inspire similar ideas and we can see some more pos acceptance of this fine currency.

I've noticed that various applications use various number of decimal places in their implementations.

The bitcoin-qt client uses eight, which is what I've been following in my development, however some use less. Also, some clients use rounding, some use floor. This lack of consistency makes it difficult to implement a correct check of the expected balance of an address, because sometimes amounts may be slightly off. If I'm requesting to be paid to eight decimal places and a client only pays accurate to two because that's what their client supports, and my value gets rounded down, the customer will be missing .00XXXXXX bitcoin so they technically 'haven't paid'. I know it's only by small amounts, but if I end up using the 'lowest common decimal place' then the rounding errors could get really pathetic.

Can the community please pick a standard and go with it? Have your say here.

I think we should be using eight decimal places, rounded...

I'm trying to get a list of all transactions using the 'from' keyword, regardless of what account they belong to

from the command bitcoind help I can see that listtransaction is specified as such:

Code:

listtransactions [account] [count=10] [from=0]

If I specify no arguments I get all transactions regardless of the account.

How do I use the 'from' parameter without the 'account' parameter?

ie I want to do something like this

Code:

bitcoind listtransactions from=X

which should show me a list of all the transactions after transaction number X regardless of the account they're in.

as an example of what I've tried but has not given what I want:

bitcoind listtransactions "" 9999999999999 32
only lists from transaction 32 onward for account "", I want any account

bitcoind listtransactions * 9999999999 32
* is not valid

bitcoind listtransactions --from=32
--from is not valid, returns an empty array

bitcoind listtransactions from=32
returns an empty array, presumably treats the first keyword as account

I am interested in placing a message into the blockchain for the purpose of timestamping the message (eg adding the hash of a document to the blockchain so that the document can be verified as existing sometime before the timestamp of the block)

I've looked at how btcmsg does it but the comment in this link suggests that btcmsg isn't the right way to do it.

http://bitcoin.stackexchange.com/questions/2616/how-to-decode-messages-embedded-with-btcmsg

Please don't encourage this abuse of Bitcoin. If someone would like to implement a message service correctly, there are many developers on IRC willing to help. – Luke-Jr

Can someone propose how I may best achieve placing a message in the blockchain? I've had some ideas but would like to hear how the pros think it should be done.

I expect flames that 'bitcoin isnt meant for that' - if so please explain the alternative you'd use instead.