[quote=“lclc, post:80, topic:2002”]I’m not sure what will be easier for Peercoin to develop a voting-pools compatible wallet, implementing such a deterministic multi-signature wallet with the current, Bitcoin Core based source code or implement Proof Of Stake on top of btcd.
I would go with the second option. BTCD has a much nicer architecture and better code quality than Bitcoin Core, and it has at least two companies behind it who actively work on it.[/quote]
That’s when we realize there is a crucial lack of developer oriented documentation about Peercoin…
Hey guys, I just wanted to bring you in on some of the updates happening with this. Sunny and Sigmike are currently talking about what it would take to implement. lclc, in case you don’t know, Sigmike is Sunny’s first core developer for Peercoin that he’s brought on to help him. Maybe you could comment on the research he’s done on implementation. There seems to be a couple things he’s not completely sure of.
I would need to dive in a bit more to understand the scope of OT requirements. But generally speaking, if the required API support is fairly modular and not involving changes to core protocol, then it should have no problem getting accepted.
I did some researches and I think supporting OT would not involve changes in the core protocol except allowing OP_RETURN data (added in bitcoin 0.9) to support coin coloring. Sunny, what’s your position on this feature? It’s summarized here: https://bitcoinfoundation.org/2013/10/core-development-update-5/. It may bloat the blockchain a bit but it’s limited to 80 bytes and it’s prune-able. Maybe we should ask that on the forum. IMO we should implement that as it allows extra features (like colored coins) for a small cost and without other protocol changes.
Note that in OT the colored feature is not used in the core system. It’s just used so that members of a “voting pool” can easily agree on a single contract (list of members, schedule, etc). To do that they create a colored coin with the hash of the contract and send it to a multisignature address owned by the members. So m-of-n members must agree to modify the contract. There may be other ways to achieve that.
The other changes required by OT do not involve protocol changes:
[ul][li]add support for hierarchical deterministic wallets (BIP32)[/li]
[li]add a way to select inputs deterministically when sending coins[/li]
[li]implement some specific RPC commands (http://opentransactions.org/wiki/index.php?title=Voting_Pool_Wallet_API)[/li]
[li]add support for websocket to call the RPC API (although this can be done through a proxy as suggested on peercointalk)[/li]
[li]maybe add a way for remote multisig owners to sign a transaction (I haven’t found anything about that so I don’t know who is responsible for merging the signatures of all the multisig pool members)[/li]
[li]maybe add support for the Payment protocol (BIP70). I’m not sure who is responsible for that.[/li][/ul]
These changes look modular enough to be included in the official client. And even if they may not be directly useful to peercoin, their core can certainly be reused later (for example the BIP32 hierarchy used by OT is specific to OT, but the BIP32 support itself may be useful in the core wallet).
A good way to start could be to fork peercoin, implement these changes such that they can easily be merged in the official client, and when it’s done we decide whether they are modular enough to be merged.
Anyway, OT looks like a promising way to have off-blockchain transactions. It creates many useful financial tools that would be painful to add to peercoin. It’s more centralized but still secure enough for most transactions. I think it’s a good match for us: peercoin provides a very decentralized and secure currency while OT provides fast and cheap tools to manipulate and exchange peercoins in everyday life.
Thanks a lot for the research and detailed summary! I am generally fine with current bitcoin development so those new features/protocols introduced in bitcoin v0.9 should not be a problem except for the timeline merging with bitcoin v0.9. So it appears OT does not have showstopper issue getting support in the reference client.
So I guess the obvious question is, when will Peercoin be merged with Bitcoin v0.9? Is that something that could possibly happen in the v0.5 release, or are we going to have to wait until v0.6 to be able to implement OT?
We can import this feature prior to merging bitcoin v0.9. We did that in peershares.
So yes, we can add the OP_RETURN data support in peercoin v0.5 so that an OT compatible client can be implemented without requiring a new official peercoin version.
[quote=“Sentinelrv, post:82, topic:2002”]Hey guys, I just wanted to bring you in on some of the updates happening with this. Sunny and Sigmike are currently talking about what it would take to implement. lclc, in case you don’t know, Sigmike is Sunny’s first core developer for Peercoin that he’s brought on to help him. Maybe you could comment on the research he’s done on implementation. There seems to be a couple things he’s not completely sure of.
Thanks a lot for the research and detailed summary! I am generally fine with current bitcoin development so those new features/protocols introduced in bitcoin v0.9 should not be a problem except for the timeline merging with bitcoin v0.9. So it appears OT does not have showstopper issue getting support in the reference client.
We can import this feature prior to merging bitcoin v0.9. We did that in peershares.
So yes, we can add the OP_RETURN data support in peercoin v0.5 so that an OT compatible client can be implemented without requiring a new official peercoin version.
Very nice to see you are on top of this, Sigmike. I would love to see Peercoin compatible with OT. With trading over OT, rather than BTC-e, we would avoid situations like VeriCoin and Nxt suffered from.
Yes, we don’t need any protocol changes for Bitcoin.
But keep in mind, we have 4 people working full-time on btcd (actually btcwallet which is part of btcd) to add those things the wallet has to support for voting pools (multi-sig HD wallets etc.) and are missing in btcd. For Bitcoin Core (or a fork of it like the official Peercoin client) it’s even more work (websockets etc.).
That’s one reason I think Peercoin should port it’s POS to btcd.
The other one is that btcd is the far better code base than Bitcoin Core, has more active full-time developers, scales better, is more modular. It’s in Go, so that might be a problem in the beginning, but later coding with Go seems to be much faster and easier.
It’s nice to see that the Peercoin Core Developers are interested in OT
Is Peercoin still a cryptocurrency of store of value and a backbone currency after she is integrated with OT? I hope she is still yes. If not, how to introduce Peercoin?
Yes. Peercoin will be the same, and we get a semi decentralized system for trade which will be just as fast as the centralized exchanges we have today :)[/quote]
And you can still use the Peercoins as they are now, both systems exist next to each other. So it is the user choice which system they prefer for which type of transactions. This assumes that the merchants or receiver offers both options tough.
Sounds good, but what would be the charter/objective?. I understand that SK won’t take any funds. I don’t think it is useful to end up with another fund for Peercoin beside the existing ppcoin funds.
I think it might be useful to support the OT guys, but it would be great to hear their views about it.
Yes. The primary use-case for OT will first be crypto-secured exchanges. E.g. voting-pool-secured Peercoins with voting-pool-secured Bitcoins. Later, people might use it for P2P transactions, and take advantage of the additional financial instruments it provides.
Sounds good, but what would be the charter/objective?. I understand that SK won’t take any funds. I don’t think it is useful to end up with another fund for Peercoin beside the existing ppcoin funds.
I think it might be useful to support the OT guys, but it would be great to hear their views about it.[/quote]
The OT contributors are 85% Monetas AG employees atm, and we don’t have Peercoin on our list (from a business perspective it’s obvious that we have to implement Bitcoin first). The other 15% don’t work for money, just for fun, or use OT for them self.
Since we are agnostic to the currency, our point of view is that the Coins should add the needed features to their wallet if they want to have support for OT & voting pools. We’d like to do it for all the major coins, but we don’t have the money or manpower for this atm.
I still think Peercoin forked from btcd would be the best option for mid- and long-term, or you find some guys that implement all the needed features in the current Peercoin wallet (which is a lot of work, so I don’t think you can get it with a bounty).
lclc，how could open transaction handle BTC-fiat trade? Fiat can’t be multi-sig and those exchanges usually have bank accounts to receive and send fiat with users.
I’m not a big fan of bounties for bigger jobs, because usually you want somebody that doesn’t only do the job, but also keeps on working on it and updating it over time. I don’t know how much it would cost to implement Peercoin on top of btcd and how easy it is, but I’m sure it’s worth long-term.
Correct, no multi-sig for stone-age money, so no direct voting-pools security for that.
But what you can do, as an issuer (and there can be more than one fiat issuer on a server (if the server operator allows it), e.g. many USD issuers etc.), is putting voting-pool secured Bitcoins in a surety bond smart contracts (or just a multi-sig address hold by different entities). So if the fiat issuer fails to pay you your fiat back for your OT fiat tokens, the other entities of the multi-sig will pay you the Bitcoins they hold. That would be fiat backed by multi-sig Bitcoins (which is much better than what we have with the current exchanges).
“A surety bond is money that is placed in escrow as a form of collateral against failure to perform on a contract, or against damages that might be incurred.” http://otblog.net/2014/03/lex-cryptographia/
The btcd (Peercoind?) fork for Peercoin is the way to go in mid- and long-term, good job that you started this!
Some news from Justus Ranvier regarding the API that the wallets need to implement to support voting-pools (as an server operator):
[19:05] http://opentransactions.org/wiki/index.php?title=Category:Voting_Pool_Wallet_API
[19:19] lclc: Who was it that was interested in implementing voting pools for from Primecoin?
[19:19] You can give them the link I just posted
[19:20] thx! I will tell them
[19:20] That's what is needed for deposits
[19:21] Next batch will be withdrawals, but we probably won't have those worked out until 2 sprints from now
If you use Peercoind (btcd based), you’d not have to implement this since it will be already done for btcd!
