Topic: The Affinity Protocol: trustless push transactions via a static device (Read 381 times)
February 05, 2016, 01:29:39 PM
this got moved to alternative clients / electrum? this requires core modification. blargh.
February 05, 2016, 12:30:13 AM
(warning. I wrote this with Monero terminology because thats the network I know best. Please look past that. Whats best for bitcoin is best for us all, so have at it.)
The Affinity Protocol:
A trustless means to create a push transaction with a static device
The problem:
Existing cryptocurrency payment networks rely on a device to create and sign a transaction. Common solutions for a point of sale situation involve the use of a smart phone to scan a QR code for a receiving address. The phone then creates the transaction and pushes it to the network. To perform this transaction push, the smart phone will either have to (1) be running a wallet and daemon instance, (2)have a wallet instance connected to a remote daemon, or (3) be connected to a web-wallet service. Firstly, all of these require a functioning smart phone with a trusted internet connection. Secondly, option 3 is the most probable, followed by 2, followed by 1, which is the inverse order for privacy and decentralization. Ultimately, none of these have the convenience, speed, and reliability of the current card payment systems. (a relatively dead device in your pocket that uses the merchants live infrastructure to move money around).
The solution:
Create a protocol that uses the point of sale as a trigger event to push a transaction from a remote daemon & wallet server.
How it works:
Point of Sale (POS) side:
At the POS terminal, the merchant displays the price amount. The customer inserts the smartcard into a smartcard reader attached to a node with a specialized wallet software. The smartcard signs a psuedo-transaction. This psuedo-transaction is inserted into the payment ID field (or any other available field) of a real transaction. The real transaction is from the merchant to themselves. The pseudo-transaction piggybacks onto the merchants self-transaction. This piggybacking prevents spamming and allows use of existing infrastructure. Mini-side chain implementation also possible, but potentially spammable. Below is discussed hybrid-sidechain using cleaved transactions.
The pseduo transaction / self-transaction hybrid enters mempool.
Server side:
The user of an Affinity card has to run a full node with a specialized wallet server, hereby referred to as server. This can also be outsourced to service providers (if desired. Obvi frowned upon).
The server scans the mempool and the blockchain. If a pseduo-transaction is identified by the wallet server as belonging to the owner of that particular wallet, then the wallet software uses the information in the pseudo-transaction to create a real transaction. The real transaction is created and pushed using standard process.
Things that need consideration:
A lot of information needs to be packed into the payment ID, and a lot of digital signatures and checks need to occur to ensure the transaction is only remotely created once. For instance, the server needs to be able to pull the following information from the psuedo-transaction:
1. Is this psuedo-transaction talking to me?
2. How to create the transaction
3. Be able to test whether this pseudo-transaction has been executed before
Alternative approaches could involve modifying the core protocol to permit transactions to have additional things added onto them that are cleaved off before entering the blockchain. This approach would require a secondary mini-blockchain (1000 block circle). So it would be (conventional transaction)-(psuedo-transaction). The daemon would check the conventional transaction component to ensure that its a valid member of the mempool, to relay the transaction and eventually add it to the blockchain. When added to the blockchain, however, the psuedo-transaction is separated, so that only the conventional transaction is added to the blockchain. The psuedo-transaction is then added to the miniblockchain.
Things that are cool:
This can all be done p2p, decentralized, hooray. You can buy your own chip cards and program them yourself. Merchants can make their own payment terminals. If a user has a card stolen, they can remotely disable their server, return home, remove permissions of that particular smart-card, and then program a new one.
Things that are not cool:
If using standard blockchain mechanisms, overall transaction can take 2 blocks. This time might be able to be decreased by implementing a miniblockchain. Perhaps the self-transaction can record something in the blockchain, such that anytime customer uses that particular smartcard, they build a reputation such that a merchant can immediately see "oh ok your a good Affinity user, I don't need to wait for n confirmations"
Of course this does nothing to address bitcoins current issues, and has flagrant friction with the whole settlement layer vs. coffee blockchain debate. But perhaps this could be worked into one of the various solutions being presented for this conundrum.
--------
I hope this was useful and/or made sense. I particular like the idea of creating transaction packets that can be cleaved. You can essentially use the primary network itself as an arbiter (with the fees and all) and relay network. So you can create a secondary daemon that connects to the primary bitcoin network and a secondary network. So a transaction would be broadcast with (primary transaction info)-(secondary network info). The primary transaction info is the standard bitcoin transaction that says "yeah, this thing can ride in the bitcoin network". The (secondary network info) packet gets cleaved before the transaction gets into the blockchain, but while its present it can perform various functions. In the above usage, the (secondary network info) included an affinity tag and transaction-creation instructions for a user of the affinity network. Similarly, this info packet could also trigger secondary routing.
So to participate in a secondary network, you would run a bitcoin node, and you would run a secondary-network node that scans the bitcoin mempool. The (secondary network info) packet would be detected by the secondary-network node, and then the secondary network node would relay the whole transaction+secondary thing to another member of the secondary network.
I'm probably describing something that already exists though. oh well.
Protease protocol
I think ultimately the Affinity Protocol would rely on the second part, which could be termed Motif protocol or Protease protocol. (can you tell I'm a biologist?) . The general idea is you have some larger thing (a package):
XXXXXXXX-YYYYYYYYYY*AAAAAAA
that can be cleaved into its separate parts as indicated by "-" and "*" above. So XXXXXXXX would be the primary network transaction (bitcoin in this case), and Y~ and A~ are separate parts. X~ allows the package to bounce around the bitcoin network (because its a valid transaction), and Y~ and A~ are along for the ride. Prior to inclusion in the blockchain, Y~ and A~ are cleaved off (and presumably have been added to a secondary blockchain and or have been used for secondary routing).
And all that would be necessary is a modification of the core protocol to allow anything with a valid transaction to be relayed through the network but then trimmed to only include the transaction upon addition to the blockchain.
The Affinity Protocol:
A trustless means to create a push transaction with a static device
The problem:
Existing cryptocurrency payment networks rely on a device to create and sign a transaction. Common solutions for a point of sale situation involve the use of a smart phone to scan a QR code for a receiving address. The phone then creates the transaction and pushes it to the network. To perform this transaction push, the smart phone will either have to (1) be running a wallet and daemon instance, (2)have a wallet instance connected to a remote daemon, or (3) be connected to a web-wallet service. Firstly, all of these require a functioning smart phone with a trusted internet connection. Secondly, option 3 is the most probable, followed by 2, followed by 1, which is the inverse order for privacy and decentralization. Ultimately, none of these have the convenience, speed, and reliability of the current card payment systems. (a relatively dead device in your pocket that uses the merchants live infrastructure to move money around).
The solution:
Create a protocol that uses the point of sale as a trigger event to push a transaction from a remote daemon & wallet server.
How it works:
Point of Sale (POS) side:
At the POS terminal, the merchant displays the price amount. The customer inserts the smartcard into a smartcard reader attached to a node with a specialized wallet software. The smartcard signs a psuedo-transaction. This psuedo-transaction is inserted into the payment ID field (or any other available field) of a real transaction. The real transaction is from the merchant to themselves. The pseudo-transaction piggybacks onto the merchants self-transaction. This piggybacking prevents spamming and allows use of existing infrastructure. Mini-side chain implementation also possible, but potentially spammable. Below is discussed hybrid-sidechain using cleaved transactions.
The pseduo transaction / self-transaction hybrid enters mempool.
Server side:
The user of an Affinity card has to run a full node with a specialized wallet server, hereby referred to as server. This can also be outsourced to service providers (if desired. Obvi frowned upon).
The server scans the mempool and the blockchain. If a pseduo-transaction is identified by the wallet server as belonging to the owner of that particular wallet, then the wallet software uses the information in the pseudo-transaction to create a real transaction. The real transaction is created and pushed using standard process.
Things that need consideration:
A lot of information needs to be packed into the payment ID, and a lot of digital signatures and checks need to occur to ensure the transaction is only remotely created once. For instance, the server needs to be able to pull the following information from the psuedo-transaction:
1. Is this psuedo-transaction talking to me?
2. How to create the transaction
3. Be able to test whether this pseudo-transaction has been executed before
Alternative approaches could involve modifying the core protocol to permit transactions to have additional things added onto them that are cleaved off before entering the blockchain. This approach would require a secondary mini-blockchain (1000 block circle). So it would be (conventional transaction)-(psuedo-transaction). The daemon would check the conventional transaction component to ensure that its a valid member of the mempool, to relay the transaction and eventually add it to the blockchain. When added to the blockchain, however, the psuedo-transaction is separated, so that only the conventional transaction is added to the blockchain. The psuedo-transaction is then added to the miniblockchain.
Things that are cool:
This can all be done p2p, decentralized, hooray. You can buy your own chip cards and program them yourself. Merchants can make their own payment terminals. If a user has a card stolen, they can remotely disable their server, return home, remove permissions of that particular smart-card, and then program a new one.
Things that are not cool:
If using standard blockchain mechanisms, overall transaction can take 2 blocks. This time might be able to be decreased by implementing a miniblockchain. Perhaps the self-transaction can record something in the blockchain, such that anytime customer uses that particular smartcard, they build a reputation such that a merchant can immediately see "oh ok your a good Affinity user, I don't need to wait for n confirmations"
Of course this does nothing to address bitcoins current issues, and has flagrant friction with the whole settlement layer vs. coffee blockchain debate. But perhaps this could be worked into one of the various solutions being presented for this conundrum.
--------
I hope this was useful and/or made sense. I particular like the idea of creating transaction packets that can be cleaved. You can essentially use the primary network itself as an arbiter (with the fees and all) and relay network. So you can create a secondary daemon that connects to the primary bitcoin network and a secondary network. So a transaction would be broadcast with (primary transaction info)-(secondary network info). The primary transaction info is the standard bitcoin transaction that says "yeah, this thing can ride in the bitcoin network". The (secondary network info) packet gets cleaved before the transaction gets into the blockchain, but while its present it can perform various functions. In the above usage, the (secondary network info) included an affinity tag and transaction-creation instructions for a user of the affinity network. Similarly, this info packet could also trigger secondary routing.
So to participate in a secondary network, you would run a bitcoin node, and you would run a secondary-network node that scans the bitcoin mempool. The (secondary network info) packet would be detected by the secondary-network node, and then the secondary network node would relay the whole transaction+secondary thing to another member of the secondary network.
I'm probably describing something that already exists though. oh well.
Protease protocol
I think ultimately the Affinity Protocol would rely on the second part, which could be termed Motif protocol or Protease protocol. (can you tell I'm a biologist?) . The general idea is you have some larger thing (a package):
XXXXXXXX-YYYYYYYYYY*AAAAAAA
that can be cleaved into its separate parts as indicated by "-" and "*" above. So XXXXXXXX would be the primary network transaction (bitcoin in this case), and Y~ and A~ are separate parts. X~ allows the package to bounce around the bitcoin network (because its a valid transaction), and Y~ and A~ are along for the ride. Prior to inclusion in the blockchain, Y~ and A~ are cleaved off (and presumably have been added to a secondary blockchain and or have been used for secondary routing).
And all that would be necessary is a modification of the core protocol to allow anything with a valid transaction to be relayed through the network but then trimmed to only include the transaction upon addition to the blockchain.
Jump to: