Bitcoin Forum
July 06, 2022, 06:42:43 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 »
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] IPO of MaidSafe: Entering the Future of the Decentralized Internet on: December 14, 2016, 11:18:47 PM
100 transactions per sec !!!are we living in still in Stone age Huh
1000 transactions per sec can be done easily ,,,can prove it

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:

Still early days for this, especially given the work currently underway to improve the client side (which is the current bottleneck for tx rate).
2  Bitcoin / Project Development / Re: Translation help for BIP39 website on: November 30, 2016, 01:02:56 AM
How much do you pay?

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.
3  Bitcoin / Project Development / Translation help for BIP39 website on: November 29, 2016, 10:42:43 PM
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 is looking for translators.

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

or if you prefer to edit text files, submit a modified version of
4  Bitcoin / Project Development / Re: [ANN] Easily accept bitcoin on android devices for in-app/in-game purchases. on: March 07, 2015, 09:45:23 AM
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?
5  Bitcoin / Wallet software / Re: Requesting address on: January 31, 2015, 05:34:04 AM

BIP70 supports the wallet returning a "refund address" along with the signed transaction to the vendor.

I would assume it would be possible for the flow to work like this:

1. User clicks BIP70 enabled link.
2. Site sends signed request to a null output. "00" or something arbitrary.
3. This value should indicate that the wallet client just return an empty reply (no transaction) with just a return address.

It's primitive, but rather than try to create a new BIP, using existing BIPs that can provide the functionality would be easier.

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.
6  Bitcoin / Wallet software / Requesting address on: January 30, 2015, 06:44:31 AM
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?
7  Bitcoin / Mycelium / Re: Mycelium Bitcoin Wallet on: April 30, 2014, 07:07:04 AM
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.
8  Bitcoin / Wallet software / Re: totalReceived is inconsistent - help improve it on: March 27, 2014, 11:08:29 PM
This is being discussed in bitpay/insight-api
9  Bitcoin / Mycelium / Re: Mycelium Bitcoin Wallet on: March 27, 2014, 09:44:07 PM
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'
10  Bitcoin / Mycelium / Re: Mycelium Bitcoin Wallet on: March 21, 2014, 12:20:17 AM
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)
11  Bitcoin / Wallet software / totalReceived is inconsistent - help improve it on: March 20, 2014, 10:00:48 AM
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 462477517

BlockExplorer: 8.35757472 4.62477517 8.35757472 4.62477517

Helloblock: 835757472
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.
12  Bitcoin / Mycelium / Re: Mycelium Bitcoin Wallet on: January 18, 2014, 10:48:08 AM
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 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 -
Second transaction -

I should clarify when I say 'broadcast to the bitcoin network' I mean that I can see the transaction with zero confirmations on or in the destination 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.
13  Economy / Service Announcements / Re: [ANN] Bitcoin la Future on: May 26, 2013, 12:32:33 AM
Code is at 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).
14  Bitcoin / Project Development / Re: Tip any website with everywhereium on: May 19, 2013, 10:01:22 AM
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

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.
15  Bitcoin / Project Development / Tip any website with everywhereium on: May 02, 2013, 03:40:14 AM
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 - 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 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 and there are several issues open for discussion.

Please have a look at the 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.
16  Bitcoin / Armory / Re: Armory - Discussion Thread on: January 17, 2013, 06:25:31 AM
edit3: I had a crack at getting the listtransactions data for the various scenarios you describe...[/url]

I'm not sure I understand what you tried.  Were you trying to test creating unsigned transactions and then sign and broadcast with Armory?...

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.
17  Bitcoin / Armory / Re: Armory - Discussion Thread on: January 15, 2013, 06:45:22 AM
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

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 -
18  Bitcoin / Armory / Re: Armory - Discussion Thread on: January 15, 2013, 03:15:25 AM
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.
19  Bitcoin / Armory / Re: Armory - Discussion Thread on: January 11, 2013, 09:51:24 AM
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.

inspired entirely by

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

Hope this helps.
20  Bitcoin / Armory / Re: [ANN] BitcoinArmory-Daemon - armory on web servers on: January 09, 2013, 10:33:33 AM
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 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).
Pages: [1] 2 3 4 5 6 7 8 9 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!