Search content
Sort by
Showing 14 of 14 results by romanbrown
Re: Pebblecoin (XPB) - FIRST DPOS CRYPTONOTE COIN LIVE - Qt Wallet GUI
Very very interesting. Did you save all ring signatures features?
Yes, all ring signature features are preserved! Transactions continue to be anonymous and untraceable, including the vote transactions.Do you have a pure DPOS (POS) after PoW or a Hybrid PoS/PoW?
It's pure DPOS now.Thank you.
EDIT: we really like your experience, because XDN is still on PoW phase.
Thanks!EDIT: we really like your experience, because XDN is still on PoW phase.
Re: Pebblecoin (XPB) - FIRST DPOS CRYPTONOTE COIN LIVE - Qt Wallet GUI
Whats wrong with the hashrate?
I am not sure why it shows up like that, but there is no more hashing at all on the network so the number is invalid anyway. The "difficulty" is apparently 4294967295 but I'm not sure why. I will have to ask Roman. If it is 4294967295 though and the network gets one block every 15 seconds (default delegate staking time) then if it were hashing, it would need 68.27 MH/sec.
Re: Pebblecoin (XPB) - FIRST DPOS CRYPTONOTE COIN LIVE - Qt Wallet GUI
so is this coin pure POS now? No more boulderhash?
Yeah, there's no need for POW anymore. Boulderhash was designed to be botnet resistant, which was great, but DPOS solves that problem, and much more efficiently too. Re: Pebblecoin (XPB) - FIRST DPOS CRYPTONOTE COIN LIVE - Qt Wallet GUI
DPOS on cryptonote? Which coin it copy?
The coin itself is forked from bytecoin. I implemented DPOS on it from scratch, using Bitshares as the model. So the DPOS code isn't copied from anywhere else.Re: Pebblecoin (XPB) - Botnet Resistant - Cryptonote, Wallet GUI!
Im very excited to be working on implementing my ideas on xpb! After discussing my whitepaper with xpbcreator, weve decided to roll out the implementation in four major phases, one of which wasnt mentioned on the whitepaper. I recommend reading the whitepaper before this post if you want to follow along. The four phases are:
1) Delegated Proof of Stake
...
1) Delegated Proof of Stake
...
How many coins are going to be mined before DPoS is implemented and all mining rewards are stopped? It would be nice if there's an announcement 60 or 90 or 365 days before the switch is made. Also, the sooner the switch is made (with little to no time before announcement), the more this coin will be tainted as short PoW period with relatively few miners before switching to (D)PoS.
Any idea how many delegates are going to be used for DPoS? Follow bitshares model and have 101? Are there even 101 people mining this coin at the moment? I'm not a fan of bitshares because of the small number of delegates that control the entire network, but it seems like if the switch from PoW to DPoS is made soon for pebblecoin, then there will be a much smaller number of people than 101 validating each block and reaping all the rewards.
There'll be 100 delegate slots, similar to bitshares. XPB pointed out why theres good reason to believe there'll be enough interest. If there are fewer delegates then anybody can sign up to be a delegate and easily (with zero votes) get rewarded for securing the network, just like with proof of work when there isn't a lot of hashing power.Re: Trustless, Tradable, Reality-Based Contracts on cryptonote coins
Was it implemented? Is it in the working? It'd be interesting to see such a thing on cryptonote, basically monero.
I'm implementing it on Pebblecoin - see the coin thread here: https://bitcointalk.org/index.php?topic=909624.0 . Looking forward to see how it holds up!Re: Trustless, Tradable, Reality-Based Contracts on cryptonote coins
what it mean "trustless"? unsafe?
Nope, it just means "as little reliance on central authorities as possible". In the same sense that Bitcoin is trustless - you don't have to rely on Visa or Mastercard or a bank to take care of the ledgers. Re: Pebblecoin (XPB) - Botnet Resistant - Cryptonote, Wallet GUI!
Im very excited to be working on implementing my ideas on xpb! After discussing my whitepaper with xpbcreator, weve decided to roll out the implementation in four major phases, one of which wasnt mentioned on the whitepaper. I recommend reading the whitepaper before this post if you want to follow along. The four phases are:
1) Delegated Proof of Stake
2) Subcurrencies
3) Contracts Graded by Creator
4) Contracts Graded by Delegates
In the whitepaper, I clearly spelt out how #2-3 and most of #4 can be implemented. However, one shortcoming of the paper is that I didnt describe how the tradeable contracts can be scored in a trustless way. I put forth some ideas, some mention of miners as information gatherers, but no clear way on how to implement it. Evidently, this is an important part of the system.
There would be some problems with using the proof of work miners as information gatherers. First, it may be difficult to provide a clear incentive for them to actually gather the information. Second, dishonest miners may report the wrong information, with no clear repercussions. It enough dishonest miners provided the wrong information, the contract would be incorrectly graded, and with no recourse. The higher the value of the contract, the greater the incentive to score dishonestly, with no long-term repercussions as the miners are all anonymous. Theres also the potential for a hashing power attack: even if 90% of future blocks have to agree, and most miners are honest, someone would only have to temporarily ramp up hashing power to 9x that of the current networks power for 200 blocks to determine any outcome.
Implementing delegated proof of stake solves these issues. We can now require nearly all of the delegates (say 90%) to agree on the data points before a contract is graded. Each of the delegates can be required to post a bond in order to supply a data point, which they forfeit if the rest of the network disagrees. That bond could also be imposed on proof of work miners, but aside from losing that bond, delegates face the even greater penalty of being voted out of being a delegate if they constantly gather incorrect information. By default, clients can elect to stop voting for a delegate that provided false information. Finally, it would be nearly impossible and financially prohibitive for a dishonest actor to become 90+% of the delegates for the sole task of grading contracts inaccurately. In the case where an attacker gains 10%+ of the delegates and attempts to block consensus, well need to figure out a resolution mechanism (still in the works).
Delegated proof of stake also has the added benefits of securing the network more securely and at a fraction of the cost of proof of work. Some may argue that delegated proof of stake places control of the network in the hands of the few, but the rebuttal is that every single proof of work cryptocurrency already has this problem anyway, and in a worse way. On the coin with the largest market cap, just four mining pools together control 50% of the network. Since the consolidation of power on a network happens regardless, proper rules and incentives can much more effectively deter and prevent dishonest activity on the network. The cost of having a delegate process a block is very cheap, since no proof of work is required. In the case of Pebblecoin, this should also make network propagation times much faster given the slowness of the boulderhash algorithm.
Steps 1-3 are basically already planned out. As xpbcreator said, well roll out a testnet for #1 in two weeks time. There are still a few decisions to be made for #4. One is to fully plan out conflict resolution if delegates - be they honest or dishonest - disagree on data points, or if a malicious client creates a difficult-to-gather data point. Another is to fully flesh out the scraping language that will be required to turn data gathered from web-pages (usually HTML data, but maybe JSON and plain-text as well) into data points to be placed into the blockchain. They key is to be able to use well-known sites, such as Yahoo and ESPN, as data sources, so the scraping language must be flexible, but it must not be too complex so as not to be prohibitive to run.
Any comments on the approach and whitepaper would be very appreciated!
1) Delegated Proof of Stake
2) Subcurrencies
3) Contracts Graded by Creator
4) Contracts Graded by Delegates
In the whitepaper, I clearly spelt out how #2-3 and most of #4 can be implemented. However, one shortcoming of the paper is that I didnt describe how the tradeable contracts can be scored in a trustless way. I put forth some ideas, some mention of miners as information gatherers, but no clear way on how to implement it. Evidently, this is an important part of the system.
There would be some problems with using the proof of work miners as information gatherers. First, it may be difficult to provide a clear incentive for them to actually gather the information. Second, dishonest miners may report the wrong information, with no clear repercussions. It enough dishonest miners provided the wrong information, the contract would be incorrectly graded, and with no recourse. The higher the value of the contract, the greater the incentive to score dishonestly, with no long-term repercussions as the miners are all anonymous. Theres also the potential for a hashing power attack: even if 90% of future blocks have to agree, and most miners are honest, someone would only have to temporarily ramp up hashing power to 9x that of the current networks power for 200 blocks to determine any outcome.
Implementing delegated proof of stake solves these issues. We can now require nearly all of the delegates (say 90%) to agree on the data points before a contract is graded. Each of the delegates can be required to post a bond in order to supply a data point, which they forfeit if the rest of the network disagrees. That bond could also be imposed on proof of work miners, but aside from losing that bond, delegates face the even greater penalty of being voted out of being a delegate if they constantly gather incorrect information. By default, clients can elect to stop voting for a delegate that provided false information. Finally, it would be nearly impossible and financially prohibitive for a dishonest actor to become 90+% of the delegates for the sole task of grading contracts inaccurately. In the case where an attacker gains 10%+ of the delegates and attempts to block consensus, well need to figure out a resolution mechanism (still in the works).
Delegated proof of stake also has the added benefits of securing the network more securely and at a fraction of the cost of proof of work. Some may argue that delegated proof of stake places control of the network in the hands of the few, but the rebuttal is that every single proof of work cryptocurrency already has this problem anyway, and in a worse way. On the coin with the largest market cap, just four mining pools together control 50% of the network. Since the consolidation of power on a network happens regardless, proper rules and incentives can much more effectively deter and prevent dishonest activity on the network. The cost of having a delegate process a block is very cheap, since no proof of work is required. In the case of Pebblecoin, this should also make network propagation times much faster given the slowness of the boulderhash algorithm.
Steps 1-3 are basically already planned out. As xpbcreator said, well roll out a testnet for #1 in two weeks time. There are still a few decisions to be made for #4. One is to fully plan out conflict resolution if delegates - be they honest or dishonest - disagree on data points, or if a malicious client creates a difficult-to-gather data point. Another is to fully flesh out the scraping language that will be required to turn data gathered from web-pages (usually HTML data, but maybe JSON and plain-text as well) into data points to be placed into the blockchain. They key is to be able to use well-known sites, such as Yahoo and ESPN, as data sources, so the scraping language must be flexible, but it must not be too complex so as not to be prohibitive to run.
Any comments on the approach and whitepaper would be very appreciated!
Re: Trustless, Tradable, Reality-Based Contracts on cryptonote coins
As a general bit of advice, people tend to throw writeups in the trash when they begin with a number of strongly worded incorrect comparative claims.
The most visible (and seemingly most widely used) approach to binary external information contracts in Bitcoin is the reality keys approach: This has the oracles selectively reveal a private key based on an outcome. This is consistent ('reality based') and one can happily use multiple oracles in your thresholds, which meets your (IMO misleading) definition of trustless. The contracts are also tradable with the cooperation of all the parties (but not the oracles), which is indeed an area that could be improved. The key reveal approach also has other useful properties, like being private (used well, no one who isn't a party to the contract-- even the oracle-- can tell a contract happened).
In future writeups you should limit your comparison to a very specific implementation to avoid turning people off with "wtf, thats not right"; or better: focus on describing the positive qualities of your proposal rather than criticizing other things.
On a more technical note, ... are you really putting a URL fetch into a consensus rule in the system, what happens when a malicious site gives random results? WRT "trust" at least in Bitcoin the trust in miners is generally narrower than you think, and the consequences of violating that trust are more limited. (Also keep in mind you're still single threading your trust on that URL).
Cheers,
The most visible (and seemingly most widely used) approach to binary external information contracts in Bitcoin is the reality keys approach: This has the oracles selectively reveal a private key based on an outcome. This is consistent ('reality based') and one can happily use multiple oracles in your thresholds, which meets your (IMO misleading) definition of trustless. The contracts are also tradable with the cooperation of all the parties (but not the oracles), which is indeed an area that could be improved. The key reveal approach also has other useful properties, like being private (used well, no one who isn't a party to the contract-- even the oracle-- can tell a contract happened).
In future writeups you should limit your comparison to a very specific implementation to avoid turning people off with "wtf, thats not right"; or better: focus on describing the positive qualities of your proposal rather than criticizing other things.
On a more technical note, ... are you really putting a URL fetch into a consensus rule in the system, what happens when a malicious site gives random results? WRT "trust" at least in Bitcoin the trust in miners is generally narrower than you think, and the consequences of violating that trust are more limited. (Also keep in mind you're still single threading your trust on that URL).
Cheers,
On Bitcoin it is most certainly true you can have a multisig script with many signatures. The main issues/improvements to this approach are:
1) The script itself is not liquid and tradable in the same way as Bitcoin currency is liquid and tradable. By having a contract tradable as a currency it eliminates any friction and barriers to trading the value or liability of a contract. Currently, there is no way to trade all or part of a multisig script without cooperation from the other parties in the contract.
2) My use of the term "reality based" is a reference to the fact that each multisig script on Bitcoin is independent from any other script on the blockchain. There is no link between what should be two identical contracts, and so two identical contracts can potentially be scored differently if the oracle(s) mistakenly or purposefully decide to. When implemented the way I described, all contracts using the same data sources would be scored by the data instead of by oracles. It is true something has to gather that data, but the data itself scores the contract not the private key signatures.
Re: Trustless, Tradable, Reality-Based Contracts on cryptonote coins
I'm sure plenty of people within the XMR community would be willing to donate. I, for sure, would donate at least 100 xmr. I know someone is working on an openbazaar fork and managed to get some funding through the thread. I hope we'll be able to do the same thing with your project.
Basically would like developers of one of the coins to work with me, and get some compensation as it would certainly raise value of the coin.Active thread: https://bitcointalk.org/index.php?topic=947839.0
Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol.
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol.
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
Re: Trustless, Tradable, Reality-Based Contracts on cryptonote coins
Active thread: https://bitcointalk.org/index.php?topic=947839.0
Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol.
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol.
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
Trustless, Tradable, Reality-Based Contracts on cryptonote coins
Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol.
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
Trustless, Tradable, Reality-Based Contracts on cryptonote coins
Ive designed a very specific technical implementation to add trustless, tradable, contracts on the Cryptonote prototcol.
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com
The whitepaper can be downloaded from Google drive
https://drive.google.com/file/d/0B75gaqtEgDR8UHU2UVJ6TkYzMnRkdFFsbklBd3hVMDV1eDQw/view?usp=sharing
I am looking to implement this very soon on one of the existing Cryptonote coins.
Looking for suggestions, criticisms, anything that will facilitate this implementation. Unlike most other suggestions or whitepapers I have the full technical ability and experience to implement these changes. I don't want to deal with the prospect of launching a new coin, nor should I have to as these changes would only improve the features of an existing Cryptonote coin.
Roman Brown
romanbrown54@gmail.com