Signed transactions for distribution

[Eli]

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?

[1714026355]

1714026355

[1714026355]

1714026355

[1714026355]

1714026355

[1714026355]

1714026355

[1714026355]

1714026355

[Etlase2]

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.

[Eli]

And you're trying to make a profit model out of something every node does anyway

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.

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.

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

[Etlase2]

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.

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.

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

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.

[Eli]

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.

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

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.

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?

[Eli]

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.

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.

[Etlase2]

It doesn't exist yet because it isn't really needed yet. When it is needed, miners will always be able to undercut some intermediary (and it will be in their best interest to avoid having an extra 100 bytes or more per tx), so I doubt that this is a particularly interesting business model. Miners also don't have to combine tx fee inputs, you on the other hand will be paying out the ass for thousands of very, very micro transactions being combined.

[Eli]

It doesn't exist yet because it isn't really needed yet.

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

While this is true:

you on the other hand will be paying out the ass for thousands of very, very micro transactions being combined.

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.

[Etlase2]

"the customer won't really feel the little tx fee added"

said the spider to the fly

adding another tax on txs that are too small to even cover the tx fee would be plain stupid

Meaning: only send me your transactions if I stand to make money off of it

But my "business" model doesn't apply to micro-transactions.

I'm talking about your payment. If you are having your customers add in a payment to you in their transactions, this payment will be a new output in the chain. When you want to spend or move these coins, you will have to combine them all, each being 200 some odd bytes or something. Tx fees go up significantly when you start combining a lot of small transactions. And tx fees are excessively low atm because of the mining reward.

Perhaps in the distant future miners might start paying a small portion of tx fees to supernodes that give them transactions. I don't see anything like this being a paid-for service anytime remotely in the near future. And it should probably never be paid directly by the tx sender, it's a waste of bandwidth.

[Eli]

Meaning: only send me your transactions if I stand to make money off of it.

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.

[Eli]

I'm talking about your payment. If you are having your customers add in a payment to you in their transactions, this payment will be a new output in the chain. When you want to spend or move these coins, you will have to combine them all, each being 200 some odd bytes or something. Tx fees go up significantly when you start combining a lot of small transactions. And tx fees are excessively low atm because of the mining reward.

Perhaps in the distant future miners might start paying a small portion of tx fees to supernodes that give them transactions. I don't see anything like this being a paid-for service anytime remotely in the near future. And it should probably never be paid directly by the tx sender, it's a waste of bandwidth.

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?

[TangibleCryptography]

% based fees are not possible as the network doesn't know the size of the tx.

Also don't you think % base fees reek of old world thinking.  How much more does it cost to accept a 1,000,000 BTC tx than it does to accept a 100 BTC tx.

To answer your question the service you are looking to provide would be trivial.  I don't think anyone would use it but it simply requires you having a form and/or API where signed tx can be sent.  You need a modified bitcoind to verify the tx, and submit it to the network.  Checking for "delivery fee" is a little more work but not much.

[TangibleCryptography]

I'm talking about your payment. If you are having your customers add in a payment to you in their transactions, this payment will be a new output in the chain. When you want to spend or move these coins, you will have to combine them all, each being 200 some odd bytes or something. Tx fees go up significantly when you start combining a lot of small transactions. And tx fees are excessively low atm because of the mining reward.

Perhaps in the distant future miners might start paying a small portion of tx fees to supernodes that give them transactions. I don't see anything like this being a paid-for service anytime remotely in the near future. And it should probably never be paid directly by the tx sender, it's a waste of bandwidth.

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 will have pretty significant tx fees.  There is no "wall" but fees are based on tx size.

1 BTC made up from 1 input = ~500 bytes.
1 BTC made up from 200 inputs avg of 0.0005 = ~100 KB.

The network charges fees based on the tx size.  Having tons of small inputs means you have very large low priority tx.  You can either wait a very long time for the coins to age (~1 coin day) or you will be paying significant tx fees.

[Eli]

% based fees are not possible as the network doesn't know the size of the tx.

Also don't you think % base fees reek of old world thinking.  How much more does it cost to accept a 1,000,000 BTC tx than it does to accept a 100 BTC tx.

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.

[Eli]

I'm talking about your payment. If you are having your customers add in a payment to you in their transactions, this payment will be a new output in the chain. When you want to spend or move these coins, you will have to combine them all, each being 200 some odd bytes or something. Tx fees go up significantly when you start combining a lot of small transactions. And tx fees are excessively low atm because of the mining reward.

Perhaps in the distant future miners might start paying a small portion of tx fees to supernodes that give them transactions. I don't see anything like this being a paid-for service anytime remotely in the near future. And it should probably never be paid directly by the tx sender, it's a waste of bandwidth.

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 will have pretty significant tx fees.  There is no "wall" but fees are based on tx size.

1 BTC made up from 1 input = ~500 bytes.
1 BTC made up from 200 inputs avg of 0.0005 = ~100 KB.

The network charges fees based on the tx size.  Having tons of small inputs means you have very large low priority tx.  You can either wait a very long time for the coins to age (~1 coin day) or you will be paying significant tx fees.

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

[Etlase2]

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.

What is special about higher value transactions that they will need your service and will be willing to pay for it, but microtransactions won't? Is there going to be something that blocks them from going through nodes/servers? Will microtransactions not need the benefit of an online service that precludes the need for storing the block chain?

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.

Maybe the consumers won't care, but the miners who have a maximum amount of data per block will care. To a standard transaction, your extra pay out is going to add 33% more data to every transaction. This means the consumers will not only have to pay for your service, but also pay extra to the miners when data starts becoming an issue.

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.

Thing is, you're not really offering much in the way of features. I would not be surprised at all if many people provide this service for free. I think Electrum is already doing so, but I don't know exactly how electrum operates.

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

This *might* work now, although I'm not entirely sure how the age of coins vs. the tx size comes into play for the tx fee. But in the future, miners will be running out of space in blocks and may perpetually ignore your very large, very little fee tx.

When the TX fee becomes a bigger portion of the block payout (or even a significant chunk), I could see this service being free to users and then charging miners to get the "freshest and most transactions" delivered immediately. Maybe. But that's the only way I really see this working.

[TangibleCryptography]

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?

Better but
a) once again you have no idea the value of the tx.  Only the sum of the output (which includes the change)
b) the metric that determines cost if the size of tx in kb not the value of the tx.

x cents per kb (rounded up so all tx are considered at least 1 kb) would be more logical.  Still I doubt anyone would be willing to pay for it but at least your pricing metric is possible to enforce and matches the critical resources (the size of the tx).

[Eli]

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?

Better but
a) once again you have no idea the value of the tx.  Only the sum of the output (which includes the change)
b) the metric that determines cost if the size of tx in kb not the value of the tx.

x cents per kb (rounded up so all tx are considered at least 1 kb) would be more logical.  Still I doubt anyone would be willing to pay for it but at least your pricing metric is possible to enforce and matches the critical resources (the size of the tx).

So I guess now we're getting back on track as this is the exact reason I opened this thread in the first place;

My question is: How can I know in advance what amounts and/or addresses does a transaction have in it if the transaction is already signed?

What are my options to understand the incoming signed transaction and evaluate whether I want to push it to the network or not?

[DeathAndTaxes]

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?

Better but
a) once again you have no idea the value of the tx.  Only the sum of the output (which includes the change)
b) the metric that determines cost if the size of tx in kb not the value of the tx.

x cents per kb (rounded up so all tx are considered at least 1 kb) would be more logical.  Still I doubt anyone would be willing to pay for it but at least your pricing metric is possible to enforce and matches the critical resources (the size of the tx).

So I guess now we're getting back on track as this is the exact reason I opened this thread in the first place;

My question is: How can I know in advance what amounts and/or addresses does a transaction have in it if the transaction is already signed?

What are my options to understand the incoming signed transaction and evaluate whether I want to push it to the network or not?

Signing isn't encrypting.  If it was well no node would be able to parse the tx.

In psuedo code it works like this. Node creates a tx.  Node takes a hash of the tx.  Node signs the hash w/ private key = signature.  The signature it appended to the "plain text" tx.

Address A pays Address B 1 BTC from public key A1
Hash of tx:  fkljf8a8FSlp2WGfd29ED
Hash signed w/ private key a1 = signature c892njkn2kqhjkherqkjh

Processing node takes the signature and signs it the public key (this is why public key not just the public address is in the tx) and that will produce the hash.  Processing node hashes the original tx and compares it to the decoded hash.  If they match then processing node knows the tx was originally signed by the holder of the private key.

Hash of Tx -> Signed w/ private key -> Signature
Signature -> Signed w/ public key -> Hash of Tx

I would imagine it would work something like this
a) user submits signed tx by API or web form
b) parse the tx
c) verify the signature  (sign the signature w/ public key,  hash the original tx, both values should match)
d) verify the tx is valid (bitcoin protocol rules)
e) verify the tx meets your fee requirements (which should only be a flat fee or fee per kb)
f)  broadcast tx to the network

[Eli]

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?

Better but
a) once again you have no idea the value of the tx.  Only the sum of the output (which includes the change)
b) the metric that determines cost if the size of tx in kb not the value of the tx.

x cents per kb (rounded up so all tx are considered at least 1 kb) would be more logical.  Still I doubt anyone would be willing to pay for it but at least your pricing metric is possible to enforce and matches the critical resources (the size of the tx).

So I guess now we're getting back on track as this is the exact reason I opened this thread in the first place;

My question is: How can I know in advance what amounts and/or addresses does a transaction have in it if the transaction is already signed?

What are my options to understand the incoming signed transaction and evaluate whether I want to push it to the network or not?

Signing isn't encrypting.  If it was well no node would know what it is.

In psuedo code it works like this.

Node creates a tx.  Node takes a hash of the tx.  Node signs the hash w/ private key = signature.  The signature it appended to the "plain text" tx.

Signed or not every node can parse every tx.  The network wouldn't work otherwise.  You simply need a modified client (or deamon built from a bitcoin library) which validates the tx and act upon it based on whatever rules you devise.

I would imagine it would work something like this
a) user submits signed tx by API or web form
b) parse the tx
c) verify the signature
d) verify the tx is valid (bitcoin protocol rules)
e) verify the tx meets your fee requirements (which should only be a flat fee or fee per kb)
f)  broadcast tx to the network

Meaning I can know in advance whether the incoming transaction (API or form) is up to par with my requirements, at least based on what I've read so far. Ok, I'll start investigating the technicalities of this. Thanks to everyone commenting here