Quote from: DeathAndTaxes on May 23, 2012, 01:22:52 PM

Quote from: Eli on May 23, 2012, 01:15:53 PM

Quote from: TangibleCryptography on May 23, 2012, 01:37:14 AM

Quote from: Eli on May 22, 2012, 05:04:09 PM

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