100 transactions per second per user

And this is only limited because of the client, the vaults can handle vastly more if needed.

Worth reading this explanation of SafeCoin tx rate which estimates about 40K tx / s / group: https://safenetforum.org/t/profiling-vault-performance/10331/47

Still early days for this, especially given the work currently underway to improve the client side (which is the current bottleneck for tx rate).

Currently looking for unpaid volunteers.

There's been hundreds of volunteer coding hours put into the project (and zero paid hours) so unfortunately translators are also needed to be volunteers at this point in time.

If anyone else considers paid translation work to be a valuable contribution they're welcome to put a financial contribution toward your translation efforts.

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

If I understand correctly, this library generates invoices (ie addresses + amounts), and also has a means of checking if an invoice is paid/unpaid.

I can see how the invoice properties could be used to create QR codes (or even use the method getQrWebpage if I don't want to generate the qr image myself), but I'm not 100% clear on the NFC side of things.

Can you tell me if I can use this library with NFC?

I had considered 'hacking' BIP70 as you describe to specify a return address. And it does conceptually fit with the abstract of BIP70: "a protocol for communication between a merchant and their customer".

The main barrier is wallets that implement BIP70 as currently specified will not work with this new scheme. Should BIP70 be revised/extended to include this new functionality the way BIP71-73 do?

edit: The extensibility section of BIP70 looks like it could be utilized for this purpose, but it really depends on whether wallet developers are willing to implement proposed changes.

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 just completed a buy on local trader - totally great and serves a very valuable purpose.

Some comments on user experience:

• It's not clear what the different alerts mean - there are two types of alert. 1) The dot on the localtrader button inside the app seems to come and go at random and has different colours and I wasn't sure what it indicated - presumably new activity but it didn't seem to correlate with new activity. It would turn up when there was no activity and it would not go away when I expected it should. 2) The status-bar notification at the top of the OS can only be cleared from the status bar, not from doing some action in the mycelium app. It wasn't clear what that icon was indicating, although I assume it was 'new activity' even though it didn't seem to correlate very well with that. In general I felt that the alerts for 'new activity' were not timely, had unclear meanings, and were consistent with my expectations.
• The 'final' screen after opening a new buy shows a chat window and accept/abort buttons. I felt that it was not clear what I should be doing next on this screen. I think the accept/abort buttons should be below the chat, since logically the user will chat first and only later press the buttons. Moving the buttons allows the user to clearly interact from the top first, then end interaction at the bottom. Chat first, then use the accept button. I initially wondered when to press the accept button and what I would be accepting (was I accepting the rate or was I accepting that the trade was complete or what?) Putting the buttons below the chat makes it clear to chat first, then once the chat is resolved (ie you are meeting with each other) the users should use the accept button.
• Response time to actions such as chat and accept was not very fast, in the order of tens of seconds. The UI just seemed a lot slower to respond than I would have expected from a normal internet-connected app

Overall the experience was fantastic and I would gladly recommend anyone to use local trader. With a bit of polish it will be more clear which actions the user should be performing (and in which order) to complete the process.

This is being discussed in bitpay/insight-api

https://github.com/bitpay/insight-api/issues/31

A minor bug in the pdf backup to do with the numbering 'Active X of Y' being incorrect.

• Have ten addresses in your wallet (none archived, not sure if this matters or not)
• Make a pdf backup
• Note in the pdf the order of X in the title 'Active X of Y' says [1, 1, 2, 3, 4, 5, 6, 7, 8, 9] when it should say [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

There are ten QR codes so the backup is still fully functional, but it is disconcerting to get to the end of the list and see '9 of 10' instead of '10 of 10'

Bug / Feature Request (not sure which!)

When sending without a network connection, the 'recipient address' page should not go away and the error message should stay until the user acknowledges it.

To Reproduce:

• Be connected to the internet on your mobile
• Click Send
• Obtain the details (scan qr)
• Activate flight mode (ie simulate network loss)
• Press send
• Enter pin

Actual result:

• Small message with low contrast to background is flashed as an alert, which goes away after a couple of seconds - very easy to miss
• Return to 'balance' page
• No record of failed transaction anywhere

Desired result:

• Return to 'Recipient Address' page with previously scanned details
• Show a message with strong colours that it failed, which does not go away until the user makes it go away
• Show a network connectivity indicator when this happens, so the user can know when they should retry the transaction

The reason I request this is because when at a shop, it's easy to get excited / distracted and 'just hit send' then not pay any further attention. The behavior between "tx worked" and "tx didn't work" is far too similar and can very easily lead to confusion.

I know that the 'Send' button cannot be clicked to initiate a qr scan unless the user is connected, but it's not too had to imagine an internet disconnection between the time between pressing that button and actually trying to broadcasting (which is a non-trivial amount of time, especially considering the time to scan a qr and enter a pin)

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'm loving mycelium wallet and am recommending it to people who ask me what to use.

I've got a question about broadcasting transactions from mycelium wallets.

Sometimes when I send a transaction it takes a while before it is broadcast to the bitcoin network.

I've noticed that whenever this delay happens, the delayed transaction is always announced just after a new block is found.

My questions are

- is it really a delayed broadcast or am I mistaken in my deduction from my observations?
- why is the delay happening?
- is it unique to mycelium or is it something that can happen on any wallet?

This has affected me in a contrived test environment when sending lots of transactions in a row (and is how I have been able to correlate a delayed broadcast with a new block being found).

I almost wrote it off as something that won't affect real-world use cases, but this did affect me today in real life when I bought something at a shop with mycelium, then ten minutes later I bought another thing at a different shop and the second transaction didn't broadcast. I loaded blockchain.info and saw the last block was about 20 minutes old. As soon as the new block was found, my second transaction was announced.

First transaction - https://blockchain.info/tx/2ce67ec3f2e5d63625d809bc0f513036273dce6fd68691590eb940ef02e79c6f
Second transaction - https://blockchain.info/tx/bfe8801f7779ca18dbb6f387784f2d898f00e0929e80b28d27c36780558f5c75

I should clarify when I say 'broadcast to the bitcoin network' I mean that I can see the transaction with zero confirmations on blockchain.info or in the destination coinjar.com wallet. When it is 'delayed' I cannot see the transaction on either of these services at all.

Any help in understanding this is much appreciated.

Code is at https://github.com/thedawnrider/bitcoinalafuture for anyone interested.

This site was stable and secure when set up correctly.

It never gained traction because it was
- not marketed at all
- had crap css style
- has questionable value to users

The problem with it is
- what incentive is there to make a prediction, rather than oppose someone else? Needs a way for creating information to be more valuable than consuming it.
- big players who can manipulate the market are better able to use this to strengthen their position, facilitating a concentration of wealth (my biggest issue personally with the idea).
- there are a lot more interesting things to do in the bitcoin economy than predicting the future price.
- the site needs some casino-style flashing lights to add to the entertainment value (which I consider to be the primary value).
- it has no charting (which would make the site potentially a useful sentiment indicator).
- it requires human input to move coins out to winners (something to bear in mind is this platform currently requires daily attention by the operator).

Updated the front page to look half-decent (standard bootstrap, but better than no style!)

Also there is now a javascript library which can be included easily on any page. It's demoed on the homepage. This lets userswithout an extension installed be able to send tips. The library will scan the page and put a 'tip' button on the top right of any element that contains the tip property. The tip button will expand when clicked to show a dialog containing that users info. See a demo of the js library in action at https://everywhereium.com

cybrbeast:
My aim is to make it easy to give tips. It seems too much effort to find a contact for the site and submit it to everywhereium etc.
The url idea is more along the right path, but there is still the problem of how to let the receiver know - having to find their email is still too much effort to place on the tipper in my opinion.

I think escrow with the option to search for your url / site is the best way, which allows users to also let the receive know they can just search the page and they should have a tip waiting.

But all this doesn't really solve the primary concern I have which is how to get escrow set up. I don't want to escrow it myself, because it puts too much trust in one person. Even if I could escrow via the most trustworthy bitcoiner on the forum it shouldn't come down to the trustworthiness of one single person.

Anyhow, I hope people enjoy the minor improvements thus far. Seen some other web-wide tipping services pop up on reddit lately, good to see this space being explored with other innovative ideas.

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 tried getting some info about bitcoind listtransactions behaviour so you had something to go off when emulating it. It was nothing to do with armory. Actually I haven't even got the latest version of armory to look at yet, been crackers busy lately, but will definitely try to do so on the weekend.

Offline transactions with bitcoind are actually quite interesting. I still prefer armory because of the deterministic and watch-only wallet features, that's really a remarkable feature to have.

Have a look at this gist for my idea about using Decimal values (or converting ints to decimals first) and then dumping in the json so it doesn't have floaty rounding display happening

https://gist.github.com/4536693

Will get back in a few hours with the other stuff I'm looking into.

edit: I am inclined to agree with you on the using integers and correct money handling rather than shitty floats or even decimals. At least in this case, when the value is received and loaded into a Decimal, it will be displayed and loaded completely accurately and not rely on the client correctly implementing rounding, which we cannot assume. As I have previously stated, I think following bitcoind api where possible is best since it makes for the least dicking around when migrating to use armory from bitcoind.

edit2: The option to set integer / decimal / string encoding is a great idea. Don't forget to allow users to set it back to the default for decimal if they desire.

edit3: I had a crack at getting the listtransactions data for the various scenarios you describe (and thus the 'way it works'), however I couldn't get any results. Frustratingly, I got raw transactions to sign (which is the second-last step of many) and then the last step is to broadcast the transaction, but my transactions were always getting rejected. I've got my progress thus far well documented and is definitely repeatable so I might try to work it out later in the week. It's worth asking on the development subform for clarification on the way the listtransactions call works, they will hopefully be able to answer it. Anyway I was creating raw transactions to match your scenarios based off this guide and testnet-in-a-box - https://people.xiph.org/~greg/signdemo.txt

I would have thought there's away to convert those floats to the correct decimal values, although maybe that was just a client... I'll look into it tonight cause those floats are horrid! Also I'll look at bitcoind listtransactions output if I get a chance.

Sounds like it's going well so far for the most part.

The changes to add auth are in the link below. Manually tested only. Returns the string "Unauthorized" if the user is unauthorized (no username or wrong password), otherwise returns the desired json. Credit must go to the author of txjsonrpc for including a nice wrapper for auth.

https://github.com/thedawnrider/BitcoinArmory-Daemon/commit/32cfd4697fed5546c57f5815b15a37f79988db74

inspired entirely by

https://github.com/bbqsrc/txjsonrpc/blob/master/examples/webAuth/server.tac

and if you want to do password storage differently than a text file (which I know you don't)

https://twistedmatrix.com/documents/8.1.0/api/twisted.cred.checkers.ICredentialsChecker.html

Hope this helps.

Great news, web-armory people! The daemon is being included with armory itself so will be up to date and more fully featured than I ever could have achieved.

see https://bitcointalk.org/index.php?topic=56424.msg1443054#msg1443054 for details.

I will keep this thread open to discuss the particulars of using armory on webservers, as the daemon is not strictly only for use on webservers (may be used for, say, running your uniquely common yet complex task easily, or remotely controlling your armory application).