Topic: Signed transactions for distribution - page 2. (Read 2299 times)

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?

Yeah you want it to be a little bit more decentralized. Problem is, this isn't something built into the protocol so clients would have to support it. And all you're doing is pushing a bit of data on the network. The client will need to know their specific tx history to make new transactions (which requires someone to keep the block chain), and you haven't even offered that.


And this is exactly how mining already works, so why wouldn't miners just perform this service for free? They're getting the tx fee, that's the whole part of the incentive.

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].

a) not sure what you mean by in advance. You will know the addresses when you receive the signed transaction... from there if your payment wasn't included you could refuse to send the tx.
b) I guess that was answered in a)
c) yes, but I'm not familiar with them.

Unfortunately you can't do it on a % of the tx model because it isn't just a tx from A to B, it's a tx from A to B with change to C. But you don't know and can't know whether B or C was the actual tx. So any fee would have to be based on data or something.

And you're trying to make a profit model out of something every node does anyway, so good luck with that. The one I saw that looked interesting had an entire secure web model where the server wouldn't have any private data but would update your accounts and your local software (or phone app) could do all the private work and send it to the server. It's a nice service, but don't expect people to pay much for it.

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?