[We're pleased to announce, that Hive is now also available for Android in a beta version.]

We're pleased to announce, that Hive is now also available for Android in a beta version.

Hive Android is a standalone Bitcoin wallet. No external server or cloud service needed - the keys to your bitcoins are stored on your device.

      

Features

- Initiate transactions in various ways:
  * Scan a QR code
  * Click Bitcoin links
  * Touch-to-pay via NFC
- Support for payment protocol (BIP70) for increased security, reliability and speed in making payments
- Hive app store offers close integration with the rest of the Bitcoin ecosystem. Apps available for LocalBitcoins.com, Bitstamp, piiko and others.
- Works offline: Stores transactions for later sending or transmits them via Bluetooth
- Amounts displayed in BTC, mBTC or µBTC with exchange rate info alongside
- Add contacts based on your address book (information from your address book is solely used for the autocomplete feature - no address book data ever leaves your device)
- Notifications for incoming payments
- Encrypted backups

Technical details: Under the hood, this wallet is a fork of the "Bitcoin wallet for Android" by Andreas Schildbach. This means it's also a SPV wallet based on bitcoinj. The software is licensed as GPLv3 and the source code is available at https://github.com/hivewallet/hive-android/ .

This software is beta! That said, the beta tag applies mainly to the look and feel of the app, which will be overhauled before the first official release to better fit the overall Hive brand. We are building on top of a very mature codebase, so while bugs can never be ruled out, we feel that security-wise this app is in very good shape and will protect your coins adequately.

Frequently asked questions

Q: Is Hive Android open source?
A: Yes! The GPL-licensed code is available on GitHub.

Q: Is Hive Android available in languages other than English?
A: Not yet, but we are working on localization support. Translators will be able to help us via Transifex once that is ready. Your help in translating Hive is much appreciated!

Q: Is it really safe for novices to use, right now?
A: We think so, and we are using it on a day-to-day basis with real Bitcoin ourselves.

Q: How can I build an app for Hive?
A: Please see this forum post.

Q: Will you support Windows or Linux?
A: Not unless an exceptional developer steps up. Please contact us if you have the skills and would like to be involved!

Q: Will you support iOS?
A: Native iOS support is probably off the table due to Apple's general despotism. Try hive-js for an alternative.

Q: How do you make money?
A: Our plan is to take very small fees for transactions that happen within non-charity apps in the App Platform. At present this is not implemented.

Check it out on Google Play: https://play.google.com/store/apps/details?id=com.hivewallet.androidclient.wallet !

Hey there! Over the last couple of days I have put together a technology demo of how a point of sale solution using Bitcoin + NFC might look like. Here is the video:

https://www.youtube.com/watch?v=mguRpvf3aMc

And this blog post has some more details: https://www.bridgewalkerapp.com/blog/2014/01/01/bitcoin-nfc-point-of-sale/ . An excerpt:

The [...] video is a technology demo of how Bitcoin might be used [...] in a point of sale setting, where a customer wants to pay contactless with his smartphone. To set the stage: In this example the merchant is using a laptop to initiate the process. She enters the price of the product - let's say 2 euros - and the software uses the current Bitcoin exchange rate to calculate a Bitcoin amount, which is then shown to the customer on an external screen together with payment instructions. The customer holds his phone close to the NFC pad and receives the payment details. In this case he uses the Bridgewalker app, where he maintains a euro balance, which can be converted to bitcoins for the purpose of transfer at a moment's notice. The app picks up the payment request and - after final confirmation by the user - sends out a Bitcoin transaction. To increase speed and especially reliability a copy of the Bitcoin transaction is also sent back to the merchant via Bluetooth. The payment is now complete (caveat: the risk of double spending - see discussion below). In the video the merchant simply receives the bitcoins via Bitcoin-Qt. But one could imagine to plug in a merchant solution like BitPay or Coinbase here, which would then convert back to euros to complete the cycle.

Feedback much appreciated! :-)

[Edit:]

Bridgewalker's website and app got an update and a new strategy in how the idea behind Bridgewalker is presented. Basically it's the counterpart to services like BitPay and Coinbase, which protect merchants from exchange rate risk. Bridgewalker does the same thing for customers. From the website:

Your balance will automatically be adjusted upwards, if Bitcoin's exchange rate drops. Conversely, your balance is reduced if the exchange rate rises. The effect is, that your balance stays stable in respect to the counter currency - currently USD. If you deposit $20 worth of bitcoins, Bridgewalker will ensure that you continue to have $20 worth of bitcoins, regardless of how the exchange rate develops. Use Bitcoin as a digital payment mechanism, without worrying about its exchange rate!

  Get the app at: https://www.bridgewalkerapp.com/ !

As always: Feedback and comments much appreciated! :-)

Edit: This topic is locked. The main discussion can be found over here: https://bitcointalk.org/index.php?topic=156943 (11/2013).

Assume a trading bot has the following behavior: You can force it - at a time of your choosing - to buy BTC at spot price. There is a limit on how much it will buy (but within this limit you can specify the amount) and how frequently you can make it buy, as it sort of needs to "recover" first. It does that by selling at spot price sometime later - you cannot influence that part.

Any reliable way of completely eroding this bot's trading funds, given this knowledge?

[Edit:]

I am excited to announce the launch of "Bridgewalker". After giving Instawallet into the capable hands of Paymium, I had some time to focus on this new project, which I believe is an important stepping stone in making Bitcoin more useful while it is still under the influence of the volatility of its small market.

The basic idea is simple: Bridgewalker is a (hosted) Bitcoin wallet for Android smartphones, which allows you to receive and send bitcoins. So far, pretty standard. The difference is, that you will never hold bitcoins for more than a few seconds, as Bridgewalker will automatically exchange them for Euros as soon as you receive them (and they confirm) and will only buy bitcoins just that moment when you are about to send them. You can therefore use Bitcoin solely as a payment network, while being protected from market swings.



  Get the app at: https://www.bridgewalkerapp.com/ !

A word about fees: You might assume that all that exchanging back and forth is prohibitively expensive. But it is actually not too bad (in my opinion), although there is certainly room for improvement. The fee for a "round trip" currently works out to around 1.5 %. Which means, if you send 1 BTC to Bridgewalker and then back right away, you are left with 0.985 BTC. This includes both exchange fees and losses through market spread (Bridgewalker currently uses Mt.Gox for currency exchange). The fees should go down though, as Bridgewalker's volume increases.

One additional feature: Green addresses (https://en.bitcoin.it/wiki/Green_address) make a comeback here. Bridgewalker accepts transactions from certain green addresses (at the moment only Mt.Gox) instantaneously and in turn sends out transactions that can be identified by the green address 1MAxx46Dp3tFw933PxPwEYYGCpxYda2pyH .

Feedback and comments much appreciated! :-)

Edit: Updated description to account for change of counter currency from USD to EUR (11/2013).

Edit: Bridgewalker has been acquired by Hive! (11/2013).

Edit: Bridgewalker is shutting down (03/2014).

[Paper]

Paper

I have summarized the ideas around green addresses (I decided to call them marker addresses going forward) in a paper which got accepted and will be presented at a Bitcoin workshop & tutorial organized by Professor Clemens Cap of the University of Rostock. The workshop will take place on September 20th.

  Paper: http://www.bitcoinmonitor.com/static/paper/marker-addresses.pdf
  Workshop website: http://bitcoin.uni-rostock.de/index.php?site=callforpapers_en

Marker/Green addresses are a proposal for a simple method of allowing a Bitcoin sender to identify herself to a recipient, to be used in cases where two parties have a trust relationship and want to recognize each other's transactions for special treatment (usually instant confirmation). They have been discussed before on this forum primarily in these two threads:

  https://bitcointalk.org/index.php?topic=32818.0
  https://bitcointalk.org/index.php?topic=48170

Implementation: Receiving

Since finishing the paper, I have been working some more on the implementation side of things (based on bitcoind git tag v0.6.3). For the receiving side (recognizing marker addresses on incoming transactions) I have implemented an "getorigins" RPC call:

  https://github.com/javgh/bitcoin/tree/bw-getorigins
  ( diff to v0.6.3: https://github.com/javgh/bitcoin/compare/bw-master...bw-getorigins )

If you give getorigins a txid, it will (if the transaction has a suitable structure) display the addresses from where the coins came. For example for this transaction from Mt.Gox, where the green address feature was enabled, it returns this:

Code:

./bitcoind getorigins 162d25037687be593e1be27bf79583afa5141c7fcd168e068501f162d2016c9a

{
    "confirmations" : 39,
    "blockhash" : "00000000000003cb80e379d5fae8e19c2594d35881ec21ff54847d99e6894671",
    "blockindex" : 110,
    "txid" : "162d25037687be593e1be27bf79583afa5141c7fcd168e068501f162d2016c9a",
    "time" : 1344887758,
    "origins" : [
        "1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q"
    ]
}

You would then check if a known green/marker address appears somewhere in the list. Here we see 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q, which is the green address currently used by Mt.Gox. In the case of Mt.Gox the whole transaction is funded from that address, but the way the paper describes the technique it might just be one of the addresses appearing in the list.

Implementation: Sending

The sending part is still a little bit hacky. My code has a marker address hardcoded and expects that the local wallet has the necessary keys for it. It will then

• Always try to add a single 0.01 BTC from that address to any outgoing transaction and an additional output sending it back. If this is not possible, the transaction creation will fail. It will resort to using marker coins with zero confirmations, if no others are available.
• Mark those incoming transactions to the marker address as change, so that they do not appear in "listtransactions".
• Prevent marker coins (coins at the marker address) from being used in any other way for a transaction, so that the marker address does not get depleted.  
• Add an extra option to "getbalance", which shows the actual available balance after subtracting marker coins.

  https://github.com/javgh/bitcoin/tree/bw-markeraddress
  (diff to v0.6.3: https://github.com/javgh/bitcoin/compare/bw-master...bw-markeraddress

The transaction http://blockchain.info/tx-index/15610835/5fcc25b576547aafddc1fed22d27259478d6c000540cb458df44c629eb10bd0b?show_adv=true is an example for a marker transaction created in this way. In this case the marker address is 1MAbwuYp8CPChJ1ua25tnEKXkfXTVqEoyg.

Future work

I am working on a new Bitcoin project which will also make use of marker addresses. I hope some nice demonstrations will come out of that, but that's still a couple of months off.

Comments, questions and other feedback is appreciated! :-)

I'm happy to announce that the team at bitcoin-central.net (the first open source bitcoin forex) is going to take over instawallet.org as of Monday next week!

Davout and his colleagues are highly motivated to maintain the free service available at instawallet.org  since they believe it’s a great way to demonstrate the usability of the technology. I am happy that Instawallet has found a new home and that I can entrust it into the hands of such a capable team.

I understand that, following this acquisition, they will be announcing soon some new exciting bitcoin developments they have been working on for the past few months.

Meanwhile you can use the service, deposit or withdraw, as you see fit. Please note though, that the site's performance might be a little spotty with occasional downtime over the next couple of days as we are performing the transfer. After that it should perform much better again.

For those who may not be familiar yet with Instawallet (launched in April 2011), here is a reminder of the original announcement:

https://www.instawallet.org is an online wallet service which requires no signup. When you browse to the website, a secret link is created for you, which is the only way to access your wallet.

This service is mostly targeted towards people who are curious about Bitcoin and want to give it a try. These people often don't want to download software (the Bitcoin client) or even sign up for a new website. Here they can try out Bitcoin without having to jump through any of these hoops.

To that end I have tried to keep everything very speedy. The balance auto-updates as soon as you receive a transaction. You can get your first  0.05 BTC from a friend  and donate it to the EFF in a matter of seconds.

I have decided to shut down Instawallet for the time being. More details at www.instawallet.org . It was a great experience creating and running Instawallet, but at the moment I don't have the time and resources to continue to support the site. Thanks everyone for your support throughout the history of the project!

Full quote from the site:

Instawallet is shutting down. Please withdraw all your funds over the next days. The site will remain active until most funds have been withdrawn. Any remaining claims will then be dealt with manually.

Please note: Some of Instawallet's funds are in cold storage. Depending on how quickly users are withdrawing, the site might occasionally run out of funds until I move more coins out of storage. Please do not panic in that case and just try again a few hours or a day later. All funds are completely accounted for and can be returned in full.

A number of factors have come together for me to decide to shut down the site. The main reason though is that I currently do not have the time necessary to continue running the site and deal with issues properly. I have had people interested in buying the site in the past, so it might continue in a different form. (If you are interested in acquiring Instawallet feel free to get in touch with me.) I have not decided on that yet though.

It was a great experience for me to provide this tool to the Bitcoin community over the past months and I have definitely learned a lot. It was a tough decision for me to make, but it will also allow me to focus on new projects. I'm looking forward to see how the Bitcoin ecosystem develops further.

Thanks for all your support!
Jan

I just got alerted by a user, that there is a tor hidden service at the address http://zgnbvbgfmoew7uz3.onion/ which claims to be Instawallet. From what I can tell, it always displays the same Bitcoin address: 1Pk9J8gbfvrLt27shdAMxBn21gdJsXGxCK .

This is _not_ the real Instawallet server! Instawallet does not run a tor hidden service and the only way to access the real service is through https://www.instawallet.org .

[Update:]

Hi there! Today I'm releasing the first version of a simple Bitcoin point of sale application. It was mainly written to demonstrate the use of the green address feature, but can also be used independently of that. It is written in Python and works in combination with a standard Bitcoin client. It is targeted at standard PC hardware, e.g. laptop (used by merchant) + external monitor (facing the customer).

Here is a video of the system in action: http://www.youtube.com/watch?v=o84SfChQ-S8 . (Update: Here is another, shorter video of just the payment being performed: http://www.youtube.com/watch?v=DNpcf9rSBIk .)

More details and explanations, the code and a number of screenshots can be found on the project's page on GitHub: https://github.com/javgh/greenaddress-pos-tools .

Looking forward to your feedback! :-)

Update (Jan 2014): The system has been extended to use NFC and Bluetooth. See this thread for details: https://bitcointalk.org/index.php?topic=395469.0 .

I already posted this on Reddit a little while ago ( http://www.reddit.com/r/Bitcoin/comments/j0bva/help_me_build_a_point_of_sale_application_design/ ), but not much came out of it. So I want to give it a shot here again:

I'm working on a Point of Sale system written in Python and targeting standard PC hardware. Think laptop + external monitor. The laptop is used by the merchant to set up a new transaction and the external monitor shows the necessary details to the customer (amount, QR code, etc.).

I have most of it written and I will be releasing this as open source soon. Among other things, it will be a demonstration of the green address approach I described here: http://bitcointalk.org/index.php?topic=32818.0 . I wanted to ask the community if someone would be interested in designing the payment screens. They are just HTML pages.

Three screens are needed (the plan is to show them in a browser set to fullscreen mode):

• Payment info: Shows amount, Bitcoin address, in some cases conversion details (if the merchant entered a USD price which was converted to BTC, the course that was used will be displayed) and finally a QR code. Here is a simple page that has these components: http://pastebin.com/8Xby7nNs . You are free to modify and style the page as you see fit (also adding phrases like "Please pay to this address..." and whatever you find necessary.)
• Payment received: A page that states that a payment has been received.
• Idle: A page that will be shown when the system is idle. Maybe just a big Bitcoin logo or some kind of welcome screen. It's up to you.

If you decide to contribute, you should be willing to license your design under an open license, since this project will be open source. You can also check out the comments on the Reddit thread I linked, which has a few more details.

I hope there are a few people out there who would enjoy contributing to something like this. Looking forward to working with you!

[Green address technique]

I'm happy to announce that the "green address feature" just went live on Instawallet.org.

Green address technique

The idea is simple: When you send money using Instawallet and activate this option, your transaction will be created in such a way that it only uses coins from a specific Instawallet address: 1CDysWzQ5Z4hMLhsj4AKAEFwrgXRC8DqRN. By looking for this "green address", others can verify that this transaction was created by Instawallet.

This allows Instawallet to act as a trusted third party for instant payments. If you trust that Instawallet will not perform double-spends, you can accept transactions from this green address without having to wait for confirmations. This mechanism has the advantage, that it is "in-band": As long as you are receiving Bitcoin transactions, you can implement this check. Furthermore, the technique can be easily implemented by other third parties (Mybitcoin.com, Mt.Gox, Tradehill, etc.). It is up to the recipient to decide from which green addresses they allow zero-confirmation transactions.

In summary: This mechanism allows to implement secure, zero-confirmation transactions with the help of a trusted third party while staying completely within the Bitcoin protocol.

Possible uses:

• instant payment at a vending machine
• instant payment at a store
• instant deposit at a gambling website
• lots of other possibilities!

Implementation notes

In theory, checking for a specific green address is very easy. In practice, unfortunately, the Bitcoin daemon currently provides no way of accessing this information using the RPC interface. A patch will have to be written and used. But this is a temporary problem, which should be easy to fix. Of course Blockexplorer or Bitcoincharts also provide a way of checking the input addresses used by a transaction.

Vision

I hope this technique gains some traction and will be implement by a number of online wallets. It could then - for now, until a more sophisticated solution emerges - provide a way to do secure instant payments. By having this implemented by multiple parties, it should help to keep everyone honest and fees low (Instawallet currently provides this feature free of charge).

Merchants will have to decide which green addresses they accept and it might be necessary to standardize on a protocol that would communicate this automatically. I propose the following convention for the moment: When using a bitcoin URI (bitcoin:14Z1mazY4HfysZyMaKudFr63EwHqQT2njz?amount=5) the additional parameter (green_address=r) should indicate, that the recipient _requires_ the use of a green address. This allows clients which recognize this parameter to prevent a "standard" transaction from being used, where it might end up not being accepted - let's say at a vending machine, where instant payments are the only option. Of course you can not prevent people from sending you money ;-) , but this would at least provide an automatic way of warning them about the fact, that you might not accept just any transaction.

Going further, it might become necessary at some point for a merchant to communicate which green addresses they accept. For this I propose the additional parameter "green_address_details=URI", where URI points to a JSON document describing acceptable green addresses. The format for this document should be extensible, as to allow both static addresses as well as pointing to yet other places (maybe some from of global green address directory?).

To keep Bitcoin URIs short (as they have to fit into QR codes), I also propose that for each of the possible arguments a short version is defined that can be used instead:

• a for amount
• l for label
• ga for green_address
• gad for green_address_details

Turning an URI like "bitcoin:...?amount=5&green_address=r" into "bitcoin:...?a=5&ga=r". While on the topic of Bitcoin URIs: I would have preferred for the amount value to be in Satoshis, but it seems that specifying it in BTC has already become common practice, so I guess I won't go against the grain on that issue then.

Short term

The above suggestions are of course still a long way off and might not materialize. For the moment it should be fine to assume the acceptable green address implicitly (as, of course, only Instawallet is implementing it right now anyway) and thus only support the additional parameter "green_address=r" or "ga=r". I will be putting together a small point-of-sale demo shortly, to demonstrate the use of this technique. (Merchant shows QR code, customer scans code and uses Instawallet to pay, merchant checks for green address and the sale is complete).

Looking forward to your comments!

Update: Those looking to create green-address-style transactions themselves, might want to have a look at this Github branch https://github.com/javgh/bitcoin/tree/greenaddress and my comments about it further down ( https://bitcointalk.org/index.php?topic=32818.msg418326#msg418326 ). Although in the long run it might be better to implement this as a standalone solution, possible based on bitcoinj, which would only manage a single green address. This would keep it from interfering with other activities.

Update: There is now a point of sale implementation based on this approach. See this thread: https://bitcointalk.org/index.php?topic=38893.msg475829#msg475829 .

I'm happy to announce that there is now an API available for Instawallet. This API can be used to write mobile clients, desktop clients, browser plugins or any other cool stuff you can come up with. There already exists one Android client that uses Instawallet (BitPay), which currently screen-scrapes the Instawallet site, but plans to switch to this API soon.

I will put up the complete documentation on the Instawallet site soon. To see the API in action, I wrote a simple console client for Linux that can be found on GitHub: https://github.com/javgh/iw-console/blob/master/iw-console.py . Screenshot:



Here is a quick overview of the API. All calls return JSON-encoded data:

HTTP POST https://www.instawallet.org/api/v1/new_wallet
    Creates a new Instawallet.
    Example response: {"successful": true, "wallet_id": "1CKAK7zU5NGUlY1n3PK0aw"}
    Note: You can also use HTTP GET, but this is deprecated.

HTTP GET https://www.instawallet.org/api/v1/w/<wallet_id>/address
    Returns the Bitcoin address associated with this Instawallet.
    Example response: {"successful": true, "address": "1PmggT9YKj4HL2iaUs8ukUSvvk3Q1xMv5G"}

HTTP GET https://www.instawallet.org/api/v1/w/<wallet_id>/balance
    Returns the current balance in Bitcoin base units (Satoshis). This means 0.01 BTC will be returned as 1000000.
    Example response: {"successful": true, "balance": 1000000}

HTTP POST https://www.instawallet.org/api/v1/w/<wallet_id>/payment
    Your request needs to include the parameters "address" and "amount". Amount should be in Bitcoin base units (Satoshis). Example response: {"successful": true, "message": "Sent 0.01 BTC to 14Z1mazY4HfysZyMaKudFr63EwHqQT2njz", "message_code": 0}

If an error occurred or the API is not available for some reason, the parameter "succesful" will be false and a "message" as well as a "message_code" will be returned alongside. See the following table for possible messages and codes:
1   The API is currently unavailable.
2   Please provide a Bitcoin address.
3   Please specify the amount you would like to send.
4   Sorry, this does not look like a valid Bitcoin address.
5   Sorry, I was not able to parse the amount field.
6   Sorry, currently only amounts of 0.01 BTC and more are supported.
-4   Sorry, this does not seem to be a valid Bitcoin address
-6   Account has insufficient funds (or not enough confirmations) to complete this action
0   Sent <amount> BTC to <address>

The API also provides a way to get push-notifications on balance change. To use this feature, you first need to get a subscription ID:

HTTP POST https://www.instawallet.org/api/v1/w/<wallet_id>/subscription
    Returns a subscription ID to be used with the push-notification service.
    Example response: {"successful": true, "subscription_id": 1563757213}

The next step is to open a standard socket connection to www.instawallet.org:8202 and to send a JSON object encoding the subscription ID on a single line (terminated by either "\n" or "\r\n") like this: {"subscription_id": 1563757213} . Only the first such object will be accepted, further lines will be ignored. The server should respond with a "ping" (regardless of whether the subscription ID is valid or not). You now simply keep the connection open and the server will send another "ping" each time the balance on the server changes. Note: Because of the subscription mechanism the socket connection can be unencrypted.

Feedback and comments welcome!

I am currently trying to upgrade Instawallet to allow for transactions that a smaller than 0.01 BTC. I'm running into a couple of problems which I'm sure many other webmasters of Bitcoin-related sites will share. So I would like to try again to start a discussion on a more flexible transaction fee structure.

There are two problems:
1) The current RPC interface doesn't provide a very good way of dealing with fees. I want to be able to know in advance what fees I have to pay and be able to provide a maximum on a per-transaction basis. BlueMatt has worked on an improved interface (see this pull request: https://github.com/bitcoin/bitcoin/pull/289), which I think is very promising and I hope it can get the attention it deserves and this or a similar improvement can be merged into mainline soon.

2) The fee structure for getting a transaction relayed is too rigid. I'm not talking about what ends up in a block here. The miners are free to come up with good fee structure and I'm sure they will. I'm talking about the step before that, when transactions are getting relayed by the Bitcoin network. My users/customers will be using a standard Bitcoin client and will hook into the Bitcoin network at a random position. I want to receive from or send transactions to them and as such am bound by what the network in between will relay. The rules for this are not flexible enough.

What's the issue exactly? We have two shared resources:
a) network bandwidth of nodes
b) space in blocks

Again, I think that "b" will be taken care of by the miners. But access to "a" is governed by what the majority of Bitcoin nodes will do and the majority of Bitcoin nodes will run the standard Bitcoin client software. Currently this means that a transaction smaller than 0.01 BTC and which does not include a fee will not be forwarded by the network - and as such never has a chance to get to a low-fee miner unless you get out of the way to directly connect to the miner, which again your users/customers will probably not do.

I believe that free and as-cheap-as-possible transactions are a killer feature of Bitcoin at it's current stage. We need to make sure that free market effects can work not only on what miners will include in a block, but also on what nodes will forward in the network.

That's why I think we need some form of auto-adapting mechanism when it comes to forwarding transactions. We will never come up with a reliable set of fixed rules of what differentiates a spam transaction from a legit transaction. Instead, I think nodes should simply forward as much as they are able to, but focus on high-priority transactions when they are starting to get overwhelmed.

To describe the algorithm, lets assume a node can wait a while before it forwards a transaction: So it would collect transactions for some time, then sort all the transactions by priority and then forward as many as it is able to, starting from the top of the list. Obviously transactions should be forward as soon as possible, so this algorithm needs to be adapted to work in real-time: It would probably need to look at past transactions and dynamically determine the threshold it needs to apply to stay within the rate limits in needs to obey with regard to network bandwidth.

If such an adaptive algorithm were in place at the majority of nodes, the network bandwidth would be available at a price that corresponds to the current level of traffic. On "good days" you would probably get away without a transaction fee for the time being. On days where the network is spammed by some person, you still only need to pay a little more than the spammer to still get through.

Your thoughts?

Bitcoin is, as far as I know, unique among digital currencies because of its decentralized nature, where you don't need to trust anyone in particular, but just need to trust that 51% of the hashing power is honest. It does have however serious scaling challenges and the ever-present problem of delays before transactions are confirmed.

Many other solutions instead require a trusted mint to issue coins, which then allows to do very fast transactions. Lots of thinking and cryptography has gone into these systems to give them additional nice properties. Especially "Chaumian blinding" is a key technique here, as far as I can tell, which prevents the central mint from knowing too much about the people that it issues coins to: If Bob gets some coins from the mint, then buys something at a sex toy shop and the shop then redeems the coins with the central mint, then Chaumian blinding prevents the mint from concluding that Bob was shopping at the sex toy shop.

The Ripple project is yet another approach to the trust problem: Here a trust chain between people needs to exist. (I trust a friend who trusts the person I want to pay.)

I think Bitcoin will pretty quickly face serious scaling issues and it seems to me, that some of these technologies could be a great complementary solution. Imagine having a (more-or-less) trusted central mint, where you could exchange Bitcoins for Fast-Transaction-Coins. With those coins you can now do fast mobile payments and extrem micropayments and whatnot, and at the end of the day (quite literally) exchange them back to Bitcoins. If you only keep a small amount of Fast-Transaction-Coins at any given time (like petty cash), you don't even need to have that much trust in the central mint, because you would have limited losses should the mint disappear or abuse its position.

So my question is: Which project would you consider the best fit to interface with Bitcoin in such a way? I guess it would make sense to leverage existing open source code in building something like that. Here is a nice overview of various digital currency projects: http://disattention.com/78/digital-currencies-crypto-finance-and-open-source/

My personal thoughts on this:

I think Ripple is very interesting, but I am not convinced that the "trust chain" works well enough for arbitrary situations. I just want to buy something from some random online shop without needing to figure out a trust path to them.

Open Transactions seems like a very interesting project, but suffers a little bit from too much complexity. Because of that, I haven't fully understood it and have the feeling, it tries to do too many things at the same time. But maybe a simple subset of Open Transaction would be a good start. And I believe the author has started on some "Bitcoin to Open Transaction" solutions already: see https://github.com/FellowTraveler/Moneychanger/wiki

Links to the options mentioned in the poll:
Open Transactions: https://github.com/FellowTraveler/Open-Transactions/wiki
Ripple: http://ripple-project.org/
Lucre: http://anoncvs.aldigital.co.uk/lucre/
OpenCoin: http://opencoin.org/
Loom: http://loom.cc/

What are your thoughts on this? Do you think making Bitcoin the backbone system too a low-latency, high-volume counterpart is a worthwhile goal, even if it introduces one or several centralized exchange points?

I'm happy to report that I found some time to give http://www.bitcoinmonitor.com a new look! I also updated a few other things. The website now uses the trade data from bitcoincharts.com (great service, thx tcatm!). Some of you also requested the feature of being able to zoom into the data, and I implemented a simple variation of that, hope you like it. Donations always appreciated! :-)

I'm happy to announce that https://www.instawallet.org is now live. It is an online wallet service which requires no signup. When you browse to
the website, a secret link is created for you, which is the only way to access your wallet.

This service is mostly targeted towards people who are curious about Bitcoin and want to give it a try. These people often don't want to download software (the Bitcoin client) or even sign up for some random website (e.g. MyBitcoin). Here they can try out Bitcoin without having to jump through any of these hoops.

To that end I have tried to keep everything very speedy. The balance auto-updates as soon as you receive a transaction. You can get your 0.05 BTC from the faucet and donate it to the EFF in a matter of seconds.

Feedback is much appreciated! :-)

Reading the current Bitcoin source on github, I can identify theses rules for getting a transaction relayed by a node:

- if a transaction is fairly large, 0.01 BTC per kb is required
- if I want to send less than 0.01 BTC, a fee of 0.01 BTC is required
- if I want to avoid the rate-limiter, a fee of 0.01 BTC is required
- something about raising fees when a block is almost full (not sure I understand that completely)

Any other rules I have forgotten?

To be honest, I don't really like where this is going. Especially this arbitrary value of 0.01 BTC, which is hardcoded in the source. Sure, it can be changed at some point, but it just doesn't seem very flexible.

Can't we come up with something that auto-adjusts in some way? For example: A node could commit to a certain maximum number of transactions relayed per minute. If it sees that the rate is exceeded, it gradually increases the fee it requires, until the rate is within limits again. If someone starts penny-flooding again, you only have to pay a little more than the attacker, instead of having to jump to the arbitrary value of 0.01 BTC right away. (Just to clarify: I know that the node isn't getting any fees for relaying transactions. When I say it "requires a fee", I mean it in the sense that it wants to see that fee on the transaction to consider it for relaying.).

Also: In the discussion about fees, you often hear: "the miners will sort it out". I think it's important to be clear that there are two different issues:
1) What transactions to include in a block. If this gets crowded, miners can figure out whatever fee structure they think will work best. This is very flexible and nice
2) What transactions to relay. Because bandwidth is a limited resource as well. And that's not flexible at all right now, with an increasing number of fixed rules in the source code. This is where I would like to see some auto-adjusting mechanism.

Once Bitcoin trickles into more Linux distributions, I think one great advantage will be the fact, that a payment system is just one "apt-get install" away. Just install some software packages and you are ready to receive and send Bitcoins. Think LAMPB: Linux, Apache, MySql, PHP and Bitcoin. :-)

I'm wondering what a good standard setup for this would be. Linux distributions could integrate the necessary daemon scripts to run bitcoind as a system service to which you then connect using the JSON-RPC interface. But maybe bitcoind should support some kind of user schema for that? In the same way that you only run one instance of mysqld, but can have different user accounts using databases that are isolated from each other. There would be only one bitcoind running and only one copy of the block chain be managed, but several different wallets that can be accessed by supplying different user credentials using the JSON-RPC interface.

Do you feel that this is something that should be added to bitcoind at some point? or would you prefer this to be an external component that provides the user management on top of a single wallet?

I'm trying to get a better grip on the correct math to use on block distribution: If the average time between blocks is 10 minutes, does that mean that the average time - from a random point in time - until the next block is 5 minutes? Or is that reasoning flawed for this kind of distribution?

Also: Can you fill in the correct values for A and B in this statement: "The average waiting time until the next confirmation block is between A and B minutes in 95% of all cases". It would be nice if you could explain how you go about calculating that. :-)