Because lot of people underestimate Peercoin’s ability to serve as payment medium I decided to demonstrate possible solution.
Red dot: bank-like entities (local businessman, drug lord, bank, …)
Green dot: normal users
Black line: inter-‘bank’ long-term mutual micropayment channel (LTMMC)
Blue line: user-‘bank’ LTMMC
‘Banks’ establish business connections between each other by creation of LTMMCs. Users - banks’ customers - have LTMMCs with one or more ‘banks’.
Establishing MMC is simple:
customer creates TX1 w/ 10ppc spent to 2-of-2 multisig and asks ‘bank’ to sign return transaction(TX2 w/ 9.99ppc return to us) | reading
customer receives TX2 and broadcasts TX1
bank creates TX3(inputs unrelated to TX1 nor TX2) w/ 9.98ppc and asks customer to sign return transaction(TX4 w/ 9.97 return to bank)
bank receives TX4 and broadcasts TX3
When user x want to send 0.00523 to y he has two options:
let his bank choose best path to deliver his payment
query banks network topology and create onion route (tor-like) for his payment to obfuscate it
Each ~bank on our payment path charges micro-fee (let’s say 0.0001).
Entities have their funds tied to long-term contracts between them what results in better currency stability.
I’d like to create peer4commit for it.
Discussion welcome
To start some discussion: x has 9.99 ppc available at LTMMC with g.
He wants to send 0.005 ppc to y. He creates message with:
TX5 spending TX1 output, TX5 has two outputs: 0.0053 to g and 9.9847 back to x
destination in the form: c + encrypt( y_address, c_pubkey )
and sends it to g
That’s all
Magic happens underneath, g choose path to be g-f-c and through their LTMMCs money goes to y.
Second time x wants to pay 0.1 ppc to y he updates TX5 outputs to 0.1056 to g and 9,8844 back to x.
Where we benefit?
low tx cost
~instant(tx propagation) confirmation
better privacy(until g and c exchange clients info/path history) - there is no sign in the blockchain
We can even increase privacy by routing through entity who is known to not be in cooperative in spying with g(f.e. b, path g-h-b-f-c), then target would look like:
This off-chain solution sounds interesting. Blockchain was never made for high number of transactions per second. Having a lower fee for the microtransactions motivates people to use off chain transaction. Only thing I’m wondering about is what would be the role of the blockchain, only a ledger for infrequent large transactions. With your solution you could basically create a coin which will never have more than a few initial transaction to establish the LTMMCs
[quote=“Cybnate, post:4, topic:2515”]This off-chain solution sounds interesting. Blockchain was never made for high number of transactions per second. Having a lower fee for the microtransactions motivates people to use off chain transaction. Only thing I’m wondering about is what would be the role of the blockchain, only a ledger for infrequent large transactions. With your solution you could basically create a coin which will never have more than a few initial transaction to establish the LTMMCs
Or do I miss something?[/quote]
Blockchain for minting and bigger, fully trust-free transactions.
Design weak points:
user have to trust business relationships between ‘bank’ entities to execute tx along its path
it would be preffered to use rather small entities on the edges(first and last on path)[f.e. Mexican druglord - Ukrainian local co-op; to limit possibility of sharing customer’s info between them] but there is no DoS-free access to them currently
no return-on-failure currently
Ad 1.
a) user can probe path with tiny amount before main value payment, warmed-up path is expected to have smaller latencies
b) entities are expected to probe each other - failing path may eventually exclude themselves from payment paths
c) there should be a way to reveal path and prove bank’s failure/dishonesty
Ad 2.
I’m thinking about using stake as an access token.
Stake descriptor:
version | network | transaction_hash | output_number | scriptPubKey
Stake introduction (w/ PoW):
bank_id | stake descriptor | target | pow_nonce
Message envelope header:
hash(stake introduction) | time | scriptSig
Stake introduction is used in first stage to fill network devices’ caches and make them pre-verify stake descriptor validity. For later communication kind of proof-of-stake is used to prevent from DoS - network devices will blacklist stake descriptor and stake introduction of abusing user. Happily we have SHA-256 miners in our network so we can rent their resources (w/ micropayment channels?) to create PoW for stake introduction(stake introduction will have to be updated with decreasing hashing costs?).
Question for you: [size=12pt]does it have any sense?[/size] [size=14pt]AND/OR[/size]
Use existing infrastructure that already handles spam/DoS issues and creates some insulation, like e-mail(2.8 million e-mails per sec? wow).
Ad 3.
We can add return path to our tx but I would like to hear you: is it possible to make it work w/o any return policy - fee/punishment for wrong path choice?.
It would be wonderful if Peercoin could position itself as a first-mover in facilitating this sort of multisig hawala before Bitcoin and six dozen other cryptocurrencies start promoting variations of it under their own brands. The good news is that I think Peercoin may actually have some true advantages in this race:
Firstly, the community is large enough and distributed enough to actually begin forming stable LTMMCs while at the same time still united enough and agile enough to meld this functionality into the wallet as a core, user-friendly feature.
The second advantage is actually the name “Peercoin” itself. I think this title is an under-appreciated asset that has the potential to represent much more than “first POS altcoin.” Beyond simple Bits-, the concept of Peers- encompasses a larger vision of what cryptocurrency ultimately promsises to deliver. Making electronic payments that work like cash is an accomplishment, but creating populist alternatives to crony-banking is revolutionary, and there can only ever be one Peer-coin!
A third advantage is this community’s active planning for the next evolution the POS protocol. I am excited to consider how these LTMMCs could potentially address the issues of “hot” minting and of daily transactions hampering the opportunity to mint a coinstake. As I understand it, the “customer” and “bank” theoretically do not have to destroy coin-age until the expiration of the LTMMC. It seems that future POS might be able to leverage these arrangements in that potential stakes would essentially be “locked” by multisig and perhaps the reward could be split to both parties as incentive to maintain the relationship.
Finally, there’s peer4commit. I really wanted to post once on this thread to express my excitement and enthusiasm for this proposal, but I don’t want to get in the way of a technical discussion that exceeds my current level of comprehension. I’ll observe and study quietly from here on, but I definitely want to support the effort: set up the peer4commit project and take my money!
[quote=“learnmore, post:6, topic:2515”]It seems that future POS might be able to leverage these arrangements in that potential stakes would essentially be “locked” by multisig and perhaps the reward could be split to both parties as incentive to maintain the relationship.[/quote]lol killed me lol Thank you!
I don’t want to overheat that, let criticism and ideas flow for a week or so before sketching/coding start.
Peter Todd is the most interesting Bitcoin dev for me, he is aware of btc limitations(he created Viacoin), his works are really valuable. Thus, it’s huge pleasure for me to see that he named, defined and spread the above concept as hub-and-spoke model.
I hope that Peercoin will take a leading role in this model development and adoption.
Viacoin has OP_CHECKLOCKTIMEVERIFY on mainnet from few days, no problems so far.
I stuck on searching tools for more generic framework. I want something solid and… flexible
Core elements needed:
DoS protecting gateways- hubs(banks) cannot be exposed to public, hub should dial-in into gateway, so do clients
messaging engine- RabbitMQ, ActiveMQ,??
authentication/authorisation/filtering mechanism… cold minting keys would be nice
I’d appreciate any interesting idea how to piece together this Frankenstein.
[quote=“kac-, post:13, topic:2515”]Viacoin has OP_CHECKLOCKTIMEVERIFY on mainnet from few days, no problems so far.
I stuck on searching tools for more generic framework. I want something solid and… flexible
Core elements needed: * DoS protecting gateways- hubs(banks) cannot be exposed to public, hub should dial-in into gateway, so do clients
messaging engine- RabbitMQ, ActiveMQ,??
authentication/authorisation/filtering mechanism… cold minting keys would be nice
I’d appreciate any interesting idea how to piece together this Frankenstein.[/quote]
Although this is partly a cross post from here , I wanted to add this idea to this thread as well:
I wonder whether NBT can be used to fulfill the need for gateways being traded at exchanges that do well being DOS protected.
The hub would basically be a NuBits wallet, right?
Communication between ghub and gateway is only available in the form of the open source NuBot that can hook into exchanges via API.
before main value payment, warmed-up path is expected to have smaller latencies