Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bitmarley

Pages: [1] 2 3 4 5 6 7 8 9
Thanks a lot for the responses. Seems like BitFury already admits that BitShares is not vulnerable to most of the attacks they listed. So the BitFury report is very positive for the BitShares community from my perspective.

They say this about the Long Range Attack.
"In delegated PoS, an attack typically re-quires collusion by 2/3 of delegates"

Is this a risk for BitShares when 2/3 of witnesses collude then?
Can you provide more detail about TAPOS and how it prevents collusion? 

Any comments/links relevant to the DOS and Sybil attacks?

General Discussion / Re: How to bootstrap bitUSD liquidity?
« on: October 22, 2015, 04:01:03 pm »
What's stopping me is that I cannot buy bitUSD via a BTC:USD based limit order in a single trade. Most liquidity is at BTS:USD but I am concerned with having my position filled at the right BTC:USD price. I don't want to worry about the BTS:USD price limits! All I want to do is BTC:USD analysis and trading.

But in BitShares I first need to move my BTC to BTS then back to BTC then place a BTC:USD order. But if I do these trades how much will I lose with exchange rate slipping especially when the markets already have low liquidity? Some decentralized alternatives to this at the moment are Mycelium>Coinapult or Coinomi>NuBits. Seems a lot easier not using BitShares just yet. Don't know the exact cost differences but the alternatives are much simpler. 

If only I could go direct from BTC into bitUSD in a single transaction based on a BTC:USD price limit order.


I noticed this table on page 16:

Table 2: Vulnerability of proof of work and proof of stake consensus mechanisms to attack vectors

Attack type                                               PoW              PoS               Delegated PoS
Short range attack (e.g., bribe)                       −                  +                            −
Long range attack                                         −                  +                            + 3*
Coin age accumulation attack                        −                  −                             −
Precomputing attack                                     −                  +                             −
Denial of service                                          +                   +                            +
Sybil attack                                                 +                   +                            +
− −
Selfish mining                                          maybe               −                            −

So I think this means BitShares has vulnerabilities for Long range attack, Denial of service & Sybil attack only according to BitFury. And the point 3* says Long range attack can be prevented by using social-driven security in addition to protocol rules. 

3.8.3 Long Range Attack
Short range attacks described earlier in this section are made expensive in the case of delegated proof
of stake, so we need to consider the cost of long range attacks as well. For proof of work systems, the
cost of a long range attack is prohibitively high. For example, an attack on Bitcoin lasting for 1,000
blocks would require $4 million at very least (and, unlike a short range attack, it would be highly
visible as observed network hash rate would drop in half for an extended time).
In earlier versions of proof of stake, the cost of a long range attack would be much lower; as we
showed in the previous section, a one day long attack may cost about $5,000 in a system where a valid
blockchain is determined based on total destroyed coin age. In delegated PoS, an attack typically re-
quires collusion by 2/3 of delegates; its cost is difficult to assess, as delegated PoS protocols use differing methods to select, reward and punish delegates.

5 Conclusion

A recent development in proof of stake are delegated systems. While these systems solve several
major problems with the straightforward PoS implementations, they are not yet widespread, making
it difficult to evaluate their security. Nevertheless, delegated PoS solves the “nothing at stake” problem
and prevents short range attacks on the system.

So are any of the attacks listed in the document applicable to BitShares?
No point digging our heads in the sand. Here is the list of attacks:

3.1 NothingatStakeProblem
3.2 InitialDistributionProblem
3.3 LongRangeAttack
3.4 BribeAttack
3.5 CoinAgeAccumulationAttack
3.6 PrecomputingAttack

Can anyone provide analysis or links relevant to these and BitShares?

Technical Support / Re: Privacy warning
« on: October 21, 2015, 09:24:20 pm »
Neat. :)
Thanks again.

Technical Support / Re: Privacy warning
« on: October 21, 2015, 06:44:12 pm »
Thanks for your answers.

1) wss indicates web socket over SSL, so: yes


2) no

But aren't the first part of secure URLS i.e. wss:// sent to the ISP in plaintext to establish the connection?

3) of course! of account information including transsactions and balances are
   publicly readble from the blockchain. To prevent that you can use stealth
   transfers (see @cass's link above)

But could anyone log my IP address against the account balances I request and the transactions I send?

4) even if the connection was unencrypted .. all that is send is either public
   knowledge from the blockchain, or simply a already signed transaction.
   Nothing else

But for privacy one doesn't want their IP address connected to those public entries.....right?

Stakeholder Proposals / Mergin liquidity
« on: October 21, 2015, 05:30:52 pm »
I want to trade BTC:USD.
There is not enough liquidity in BTC:USD.

Can't the network also utilize the BTS:BTC & USD:BTS liquidity?
So the BTC:USD market is actually a merge of BTC:USD + (BTC:BTS * USD:BTS)?

Technical Support / Re: Privacy warning
« on: October 21, 2015, 03:34:23 pm »
Also important privacy questions about new Graphene client:

1) Is any part of the connection encrypted?
2) Does my ISP know I am using the light client?
3) Is the account identity exposed to recover balances? send transactions?
4) What is sent in plain text over the connection?


General Discussion / Re: Too many 100% delegates are bad!
« on: July 18, 2015, 04:01:58 pm »
That is not true . I fact , Bitcoin dilution grew a whole industry ---- mining that is on the front line of promoting bitcoin .

I agree. But the main point of my post was that bitcoin miners do not compete on that basis. They compete on the basis of mining power. Whereas BitShares delegates compete on more levels.

Also just thinking out loud.......the interesting thing I liked about the protocol described in the paper was that since the voting boards are adhoc and changing randomly only a few stakeholders need to contribute at any time. The existing voting requires all stakeholders to be interested all the time in order to deliver voting that produces the best results. This is unrealistic as all stake holders can't always pay attention to who are the best delegates. But instead if I can commit to occasionally sharing the effort along with others who have a significant BTS stake to vote, then analysis behind voting will be much higher quality. In this way good delegates/projects/expenses should quickly be funded. And bad ones should always be quickly rejected.

For example, you need to get your bunker mining delegates voted up. But probably a lot of stake holders are out of reach or don't have time to prioritize to analyzing your offer and voting for your delegates even though its in their best interest. With the randomized boards described in the paper a group of stake holders could could have a random group of 10 or so (it says board sizes are customized) to control their votes. So these 10 board members who temporarily represent a large block of BTS stake holders and have immediate authority for a large voting block.

So as a delegate you can now directly communicate with a small group of decision makers to present your offer for faster access to funds. You wouldn't need to spend so much effort to "get the word out". The stake holders benefit too because good opportunities are not missed due to the analysis work load of voting.

I read the paper posted at

There was a section therein which described crowd funders maintaining control of funds using a protocol of randomized juries. This sounds excellent especially since control is weighted by Stake. I'd be willing to contribute to such a fund for BitShares development if it existed. Basically it sounds like funders could maintain control over expenses through a system of rolling randomized juries that act as a temporary board for authorizing fund transactions. The end of the paper mentions an idea to extend bitcoin multi-signature accounts to be controlled by rolling juries/boards. Will someone do this with bitcoin and beat us to the punch? Is there anyone else that thinks BitShares could benefit by implementing such a protocol?

General Discussion / Re: Too many 100% delegates are bad!
« on: July 18, 2015, 01:18:16 pm »
The problem is the low market cap. If delegate pay (dilution) was increased then it would/could only serve to crash the price lower in a vicious cycle.

In the case of BitShares development investment should be a function of dilution. Unlike bitcoin BitShares dilution feeds directly back into delegate pool which are selected by Stakeholders. With bitcoin dilution goes to mining power only so miners have no incentive to compete based upon development, marketing and other community contributions. That was the brilliance of the original delegate model. Is the community forgetting this????

Perhaps the issue stems from binary voting and stakeholders need more fine tuning to control delegate funding. To fix this perhaps delegates specify how much they need in bitUSD and then stake holders respond by specifying the same. For example, a delegate may request 4000 bitUSD per month and stake holders may authorize 3000 bitUSD per month.

Additionally perhaps there could be a special kind of BTS which cannot be sold within 6 months as an extra incentive on top of what is already offered. Like a long term stock option. Delegates and stakeholders could negotiate custom amounts of each through a finer tune voting mechanism.

The reality is we as a community need to fund development. We cannot wait 6 months since the network effect principle means we are in a race. If we wait and lose then our whole investment will fail. We must build mechanisms that result in the fastest development. And we should align incentives so that funding works via the voting mechanism.

General Discussion / Re: Too many 100% delegates are bad!
« on: June 26, 2015, 11:00:43 am »
Yes but I figured the same problem would still apply, if workers are setting "a pay rate" as a % and they are all maxing it out at 100%. I read the link but there are ambiguities on how this could be implemented. Can you give a brief summarize from your perspective?

General Discussion / Too many 100% delegates are bad!
« on: June 26, 2015, 10:41:55 am »
This is not against any delegates in fact the point is that too many 100% delegates indicates  delegate pay is obviously not enough. How could it be that across the broad range of services that delegates provide they all require the same pay? Of course not. The problem is the pay rates are too low so they are all maxing out at the same 100% rate.

If the pay outs were higher then delegates could reduce their pay rates below 100% and then they would all have different levels and we could compare them against each other. As it is now, the pay outs are so low it seems that they all need 100% settings.

Is there a way to increase the pay outs so that delegates can function at pay rates below 100%?

Is it possible to fix the pay rates to a bitUSD price feed to stabilize delegate pay?

General Discussion / Re: New kind of order: Limit At Feed
« on: June 26, 2015, 10:27:06 am »
Really really important feature I hope the next version has this.

Pages: [1] 2 3 4 5 6 7 8 9