Topic: A provisional simplified transaction system for Bitcoin (Read 1322 times)

look into bitcoinj which implements it.

SPV doesn't seem to contain the transaction information however, such as the vouts and txins for unspent transactions? Just the block headers to see if the transaction is in the POW... or am I missing something?

https://bitcoin.org/bitcoin.pdf paragraph 8
or look in libs like bitcoinj which implements it...

electrum and multibit are functional spv-clients.

edit: paragraph 8 instead of page 8

Honestly? I'm not up on SPV, if you can point me to a good decent write up on it then I'll happily read it.

If they can be used in the above way, so that the client merely needs to keep a copy of the private key only - for authorising the transaction, then great. It would make the whole online process of paying for things in bitcoin far far simpler.

but still: why not just use SPV proofs as DnD said?
your idea is a less secure solution where we already have a better on (SPV-Clients)

> How can you "confirm" the value with other full nodes?

Well, unless all of these other UXTO nodes are working to circumvent the same transaction outputs (ie they are all wrong, and all in the same way) - chances are that one of the nodes checked would show this as incorrect. Again, there is no incentive for a node to do wrong - as it would just quickly get banned for showing different values for the same txid as compared with other nodes.

How can you "confirm" the value with other full nodes?  The only way is to verify that an output is correct without a complete copy of the blockchain is to verify that the transaction exists in a block sufficiently deep in the longest chain.  To accomplish that without a full copy of the blockchain you need:
1) the txn containing the unspent output
2) The merkle branch to the transaction to compute the merkle root hash and verify it is in a block
3) Copy of the block headers to verify that block is sufficiently deep and on the main chain.


So yes if you have all that you can verify the output is accurate.  If you have all that you are an SPV client and don't need a "UTXO server" as any full node on the network is a "UTXO server".

You mean because the unspent parts would go to fees in the blockchain? Valid point.

You could validate this by confirming the balance/transaction with any other nodes. You could also imagine the concept of trusted/untrusted nodes then, and a system whereby uxtos servers are incentivised to show the correct balances - because after all, losing 9BTC to the blockchain is just malicious, and doesn't benefit that particular UXTO node at all - with such verification it could be overcome.

The value of the outputs you are "spending".  What happens if an UTXO server lies and says your output worth 10 BTC is only worth 1 BTC.  Oops you just lost 9 BTC if you sign that without validating.  How are you going to validate that output X is unspent and worth 1 BTC without either SPV client or your own copy of the blockchain?

Unrelated to that how is your client going to now when you receive payments?  Just trust the UTXO? If the UTXO server says you have a new payment from a sender worth 1 BTC how do you know it isn't lying?   Just being able to sign outgoing txns is of limited use.  Most users will also want to know (preferably in a trustless manner) when they receive payments as well.

SPV clients already solve both of those problems in a trustless manner.  So what do you gain over an SPV client and is it worth the need for implicit unverifiable trust of the UTXO server?

What is there that needs to be verified? You as the client know how much you need to spend, also you can see  the value of the transaction that is passed to you to sign.

How will your "verify" the values are correct?  You are getting them from a third party and lack an independently verified blockchain to ensure the outputs provides are valid.

An SPV client doesn't just obtain the outputs necessary to create a new transaction it also obtains the "meta data" to validate them in a trustless manner.  This is done by validating the partial merkle path produces the merkle root hash in the blockheader.

Simply saying "verify" abstracts away the whole problem.  It is like saying I will prevent double spends by preventing them.  How will you verify.  If a UTXO sever gives you an output X says it is an unspent output to one of your public keys worth 1 BTC HOW do you verify that information is correct?

The transaction that you sign will contain all the values that you will be sending. It cannot lie about it, as you need to verify this before signing it.

You do realize your are proposing an insecure method of transaction creation and validation.  SPV clients can already do this securely.  What is the benefit over an SPV client?  How does the client ensure the UTXO server is not lying about the output value?

Current Method

Currently, payment processors either require centralised storage of the coins (such as coinbase), or manual control via your Wallet (Bitcoin Core etc). In these circumstances, the user either needs to rely on the centralised partner, or build the transaction themself either via a SPV or full node. In either case, they need to capabilities to receive, and transmit and manage their bitcoin wallet on the device that they wish to transact with.

New method (disclaimer)

This idea is presented as is, without any real application thus far, and can most definitely be improved and extended on. So, please post problems/critiques/issues/ideas - but lets see if this idea can be improved to something useful, and not just buried

Addresses

When we think of what we need to spend bitcoins, we need one thing. The unspent transaction inputs. From these, we can ascertain the balance of an Address - but further, we can construct transactions using this information to pay anyone - all that is missing is the signature.

From this we can imagine a setup as follows:

UXTO servers, all providing a current database of unspent transactions on the bitcoin blockchain, and utilising leveldb or such - in a design that can quickly bring back the balance of any bitcoin address (by iterating through the transactions associated with this address and totalling up the value). These gateways can also generate the transactions needed - say by an online shop.

Client machine - All this needs is the ability to securely sign the transaction. Ideally a hardware device with physical activation (such as a button) that can do three things: receive transactions, sign them, and provide a list of all the public keys for which it has private keys. The client machine can then send this list to the UXTO server, which can then fashion the transaction/ensure there are enough funds - and send to the client to sign. The client's machine can check the right amount is being requested - then send back the signed transaction, which cannot be tampered with.
Further, these UXTO servers can be used as decentralised live balance viewers. They could implement a fee inside the transaction for their usage - and take the place of bitpay/coinbase or other such parties.

These servers could become multisig, or use any additional technology as required.

Also, as they could become a halfnode, after syncing with full nodes, they could keep up to date with UXTOs, without requiring the full blockchain download - so could be far smaller.