Ok, so that is reasonable. As a node operator I could simply give all of these micro-transaction fees low priority, and wait them out - I don't really need them right away, and once the flow of transactions starts, it wouldn't be noticeable (getting 5btc tomorrow for the work done today, is not a big deal if you get 5 btc every day...).

You've got a point. What about a flat rate of about 10c for every transaction above $10? Would that seem more "new world thinking"? what about 1c?

I'm not trying to make money out of this - my thinking is how to get these nodes operational as soon as possible, and to get them operational you need to provide an incentive to node operators to hassle for the installation and maintenance of these node. Without a solid monetary compensation these nodes will not exist, and there willb e only nodes that are donated to the community that will not be able to support massive amounts of users.

I want to create Safebit with an option to have a slim wallet, meaning it doesn't need to connect to the bitcoin network in order to operate - for this to be viable I can either create my own servers/nodes that would accept TXs from Safebit users and would process them (free or otherwise), but then I hit a wall of becoming a "centralized" banking service with a new take on it, or I can create a way for other people to have incentive to create these nodes/servers by paying them - I can pay them directly but than again - I have the control over these server, or I can create a node that would operate at a cost to the user, but would provide valuable service in return that the users would feel that it's a fair deal.

If these nodes are following a certain guideline, and have basically the same features across many different nodes/server, and from the user point of view he simply wants to find the node that will process his transaction quicker, and these node operators would earn money based on the amount of incoming transactions that they push to the network.

If I'm reading this correctly - what you're saying is that when I take the small fee from my customers, I basically generate a huge list of tiny transactions that I need to merge latter on (to actually use them), correct?

Well, is there a way to handle that? I mean how does a business that would want to work on micro transactions would work if what you describe is a genuine pain and could cost a lot of money? Is there a way around it?

I'm building an image hosting site right now that would support micro bitcoin transactions for the image uploaders/owners, so you're saying that I will hit some kind of wall with these micro-transactions?

No, you see, that's where you get it wrong - I don't care about small transaction - nobody does.

It's true that they can make a ton of money if we did have a sane way to tax them, but because of the way bitcoin is built it's just not worth the effort at this point.

The way I see it there is no "need" to tax small transactions - these will go through the nodes/servers and won't require an additional tax - the ones that will be taxed will be those that have substantial value in them - for example every tx above $10 USD.

From $10 taking out $0.001 for the bitcoin network fee, and adding to that a 0.1% (or less, much less, say 0.001%) of the transaction value would only add additional $0.001 to the fee - nothing that I AS A CONSUMER would rage about or even care about.

Looking from a consumer point of view (which I'm doing right now) a tiny transaction of 0.1% of my whole transaction value above $10 is worth the features I'm getting for the money I'm spending.

I strongly disagree. I need this right now, and yet it doesn't exist.

While this is true:


But my "business" model doesn't apply to micro-transactions. All transaction are already taxed as is, adding another tax on txs that are too small to even cover the tx fee would be plain stupid, and like you say no one will find it useful. On the other hand taxation of large txs (say above the value of $10 USD) the customer won't really feel the little tx fee added, and operators will obviously operate on a profit even with the cost of tx fee on the tax that they take, not optimal for them but necessary for the miners.

Also - some blockchain consumers/providers won't always want to be miners, right? They will need to allocate hefty resources for that job, and I'm referring to a "drop in" script that site operators could upload to their servers, run and have bitcoin network interaction service offered to their users, and subsequently make money by simply provide blockchain info and pushinh random transactions into the blockchain.

Getting transaction history - clients could either store in internally somehow [doesn't really matter how at this point] and you have a few places that provide this kind of service already, like blockexplorer and blockchain.info, right?

In the best case scenario these nodes will also allow users to poll for transaction history to generate and sign new transaction, exactly like Stefan envisioned and implemented it an in BitcoinJS - they will have the incentive to provide the information because they know that clients will then use them to send through transactions [and they will get the fee...].


Great! Give me a list of miners that accept some kind of async way to push transaction through them - preferably a simple to use API over HTTP(S), and indeed some clients will chose to work with miners instead of independent services that aim only to provide transaction push and/or blockchain info. The thing is that if this exists already - I haven't heard about it, and it would be great because I could use it right now, but do they exist?

What do you mean "every node does anyway"? You mean if I install BitcoinJS node? Obviously it does that by default for free, but there is little incentive for operators to setup a node because it gives them nothing except the satisfaction of "helping others", and we know that while it's nice and all, it doesn't pay the bills, and so in order to make Bitcoin node ubiquitous you need to provide incentives for the operators.


I'm not sure what are you referring to, but I'm generally referring to nodes without any affiliation to clients - i.e. at some point in the future you will have a giant list of domains (www.somename.com) that support bitcoin transactions, and clients will simply chose the most fitting one (or just randomly), and simply send their signed transactions to these nodes without actually caring about their security model (why would they need to? the transaction is signed already, impossible to tamper with, correct?) - all they care about is that their transaction is pushed into the network.

Better yet - clients will send out a transaction to 2-3 nodes at the same time, and the nodes will compete to push the transaction to the network - the first one to succeed gets the fee on that transaction [not entirely sure how to accomplish this just yet].

I'm adding 25BTC bounty if this is done inside Safebit.

Ok, so I'm thinking about how Safebit could work in the real world without having any client-side bitcoin network interaction (I know it's not the best method, bare with me).

It's easy enough to create bitcoin addresses and private keys on the client side, plenty of examples on this front (BitcoinJS and BrainWallet are just two), and there is a way to create and sign transactions only on the client-side, which at that point can be sent to a third party that only forwards the transaction and pushes it into the bitcoin network.

So far so good.

Now if I wanted to create a service that receives a signed transaction and pushes is to the network, I would want some kind of compensation for that work, especially if the service becomes popular (you know, managing servers and keeping everything up to date and flowing), I'm thinking about letting through only transactions that have a nominal fee assigned with them that will be forwarded to an account of my choice.

The flow looks something like this:

Client A needs to send 15 coins from address A to address B.
Client creates and signs a transactions with 15 coins going from address A to address B, and adds a transaction worth 0.1% (0.0015BTC) of the original transaction and sends it to address X.
Server receives signed transaction from Client A and checks to see if the transaction has a payment of 0.1% of the total transaction value (not including this tax/fee) going to address X, if it does, the server posts the transaction to the Bitcoin network, if it doesn't the transaction is ignored.

My question is - Can the server know in advance what are the addresses and the amounts in the transaction?

If not, how hard would it be to create a mock-network that won't be actually connected to the bitcoin network but would update the blockchain frequently, and then the server would use that network to "see" if the incoming transaction has a fee/tax in it?

In my view Bitcoin interaction with the end-users would be on this kind of level, where the clients don't actually have direct connection to the bitcoin network, but rather talk to a centralized server (wait, don't pull out the pitchforks just yet) that would receive these signed transactions and would only forward it to the network. Exactly like BitcoinJS nodes are supposed to operate.

The thing is - these server need to cover the operational costs, and if they aren't making any money on top of that, well, no one will be interested in operating them in the first place. So what I'm thinking about is these server could simply run on any domain, users would simply install a simple bitcoin service, and would "ping" the "clients" to notify them that they are accepting signed transactions.

When clients want to use that service, they will "ask" the server "what's the fee?" or "what's the rules to use your service?" - some servers will have no rules and no fees, other will have certain rules (for example - no transaction to known porn sites/business - just an example!), while other will have a fees but no rules [optimal], and if the conditions are accepted by the client it will forward the transaction to that server along with the required fees/rules.

Servers could compete with eachother on the fees that they require, and every web-host could easily support bitcoin transactions - hey - it's a great way to make extra money for any host/website - just allow users to push in transactions.

So, the answers I need:
a] Can I know in advance what addresses and amounts are in the signed transaction?
b] If [a] false how can I verify that these transaction actually follow my rules?
c] Any existing projects for this kind of concept (besides BitcoinJS which requires Node)? PHP/Python/Ruby?

I really don't mind at this point how this works or what language it is, as long as it's accepted into the main branch of Bitcoin-QT so that newbies can launch the server with ease.

I join this with a pledge of 5BTC generally, and add an extra 10BTC to the pledge if this is implemented for Safebit.

Safebit is currently a Chrome app, does this work for you, da2ce7?

Thanks!

We've just recently decided to reboot the development process after a long break, feel free to subscribe to the newsletter: http://safeb.it/

Why not simply support the Safebit project?

The idea of Safebit is to make Bitcoin accessible to non-techies, this is why I created the project in the first place.

Hey Guys,
As some of you might know already, I'm developing the Safebit bitcoin wallet, and one of the major problems that I see my users [including myself!] having issues with is launching the bitcoin client in server/daemon mode.

It seems that for some reason or another this is not a straight forward flow, and somehow the way parameters are passed is not very intuitive even for intermediate users [again, including myself].

I've decide to launch a simple bounty to create a simple, useful, and straight forward bitcoin client launcher. The idea is basically bundle the launcher with the default bitcoin-qt release so that developers and users alike will have an easy way of a) launching the bitcoin app with custom parameters, and b) easily creating shortcuts to those launch parameters so that users can fire up the previously defined configuration in a breeze.

I've designed a simple user interface to accommodate this new launcher tool - the idea of this launcher is to be super simple to understand and configure - these configurations are potentially very dangerous to the users bitcoins, so we need to be careful here and make sure that the users understand the configuration options and don't do something that might harm them.

Here's the design:


Right now as you can see it's pretty darn simple - two page, one of which is actually designed at the moment, and very minimal on the options - the other options could be added latter on.

Here's a basic specification for the launcher:

After clicking "Start Server" the button and all of the configuration fields will become disabled, and the stop server button will become enabled.
Optional: The area where the username/password fields are will disappear once the server is launched, and instead will appear a draggable element that will contain the username, password and port. This draggable element could for example be dragged into the Safebit application, which in it's turn will know what to do with the setting (i.e. configure the application to run with the provided information).

When clicking on the "Create Shortcut" tab a "Save" dialog will appear to save a shortcut to the bitcoin-qt app with the wanted parameters.

The launcher application should check the configuration during "start server" phase to make sure that the configuration actually setup correctly and working properly as expected.

The launcher should run on all 3 major platforms - Linux, Windows, and MacOS and should be identical on all three.

The launcher should follow the Bitcoin-QT coding guidelines [comments, clean code] and eventually should be merged into Bitcoin-QT.

The starting bounty for this project is from myself at 10BTC.

I wake up to a cup of coffee, cigarette, and reading The Marker, the largest and the most interests-free financial news paper in Israel.
And today was no exception, except that I was greeted with a huge-ass cover story about Bitcoin.



Link to the digital version of the article: http://www.themarker.com/wallstreet/1.1690268

Hey Guys,
I'm looking for a Javascript developer to work full-time on Safebit.

The payment will be $1,000 every month, paid via Bitcoin or your method of choice (not including PayPal).

For more details: https://bitcointalk.org/index.php?topic=77046.0

Hey Guys,
Haven't been here a long time, just dropping by to see whats new in the forums from time to time.

I've started Safebit Bitcoin almost a year ago, and for a while I was trying to raise some funds to develop it as a full-fledged product. I guess it was too soon to go to these kind of investment methods, and a lot of time was lost. But the product is still, and my passion towards Bitcoin is growing by the minute, and I still believe that bitcoin NEEDS a simple user interface that would cater to most of the general population.

I've decide to hire someone who can develop Javascript, HTML, CSS and perhaps Python to start working on Safebit.

This is what currently out there: https://chrome.google.com/webstore/detail/ablfbfgmgfoggdhhcnledndibdihggpb?hl=en-US
This is the main code repository: https://github.com/elis/Safebit
This is the wiki for the project: http://safebit.wikia.com/wiki/Safebit_Bitcoin_Wiki (Plus: search for "Safebit Bitcoin" for some more details)
None of these have been maintained in the last 6-7 months.

The payment will be $1,000 USD paid either with FIAT currency (not PayPal) or Bitcoin, your choice.

Stock options plan will be included.

The request is that you work full time on this project (i.e. no other paid projects), and have experience and feel comfortable with Javascript, HTML, CSS and PHP or Python, and delivered at least one former project (please provide link).

Send application to eli@safeb.it

[UPDATE]
The payment is for a monthly salary, not weekly or global project wide.
1 month of work = $1,000

Need devs?

I may have gone a little overboard with that: