Topic: Signed transactions for distribution (Read 2259 times)

Connecting to Bitcoin peers requires using the Bitcoin Protocol, which requires making a different type of connection. Using a dedicated HTTP server on the other hand requires only doing a regular ajax request to a remote server with the details of the transaction.

This tiny difference is what makes it easy for new developers to come in and create new tools - the simpler tools that you can provide to developers the more developers you'll have working on this. Remember, time = money, so business makers who ask devs "how long will X take you to do with Bitcoin?" and the dev answers "a lot" because it requires doing different complicated things, and if it's cheap you'll have more people putting money into Bitcoin related projects.

You don't connect to a protocol, you connect to a server. If someone wants to use your service he'll have to connect to your server, so I can't see any difference.

First of all, yes. These kind of service will offer better anonymity than what you get with the vanilla bitcoin experience.
Second — to broadcast the transaction to 3 peers you need to connect to a different protocol which can be problematic at certain situations, and it's not exactly a "fire and forget" solution, because you have to check that the transaction was broadcasted, and if not, you have to do the procedure again.

I can get on the Bitcoin network, find 3 peers and broadcast my transaction to all 3 then disconnect.  In less than one second.  There is no need for an external service, unless you are offering something extra, like anonymity.

Because broadcasting the message to the network [as I understand it] requires the user to be connected to at least one peer in the network, meaning a different kind of protocol to handle.

Having a service that will broadcast your transactions to the network for a small fee (if the transactions are not small ones) requires you to compile and sign a transaction, and send it to the broadcasting service via HTTP, very straight forward for client-side clients and thin clients.

Why would someone use this service instead of just broadcasting that 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

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

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?

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

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?


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.

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.

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.

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

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.

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

said the spider to the fly


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


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.

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.

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.