Signed transactions for distribution

[DeepBit]

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

Why would someone use this service instead of just broadcasting that TX to the network ?

[1714024816]

1714024816

[1714024816]

1714024816

[Eli]

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

Why would someone use this service instead of just broadcasting that TX to the network ?

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.

[etotheipi]

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

Why would someone use this service instead of just broadcasting that TX to the network ?

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.

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.

[Eli]

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

Why would someone use this service instead of just broadcasting that TX to the network ?

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.

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.

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.

[Berlu]

to broadcast the transaction to 3 peers you need to connect to a different protocol

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.

[Eli]

to broadcast the transaction to 3 peers you need to connect to a different protocol

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.

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.