Bitcoin Forum
May 13, 2024, 05:05:36 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
1  Economy / Digital goods / Re: Buying automated trading strategies - 100k USD budget on: October 27, 2020, 10:04:15 AM
But as far as I know, every black box bot gets rekt at some point without the involvement of human, I would be glad to see if you find such a bot and seeing it working.

That's why I look at the equity chart for months of forward testing, because I can tell if it will rekt itself. Rest assured, there are indeed strategies which are viable for months/years and they never rekt. Worst case they stop producing profit and then search for a new strategy.
2  Economy / Digital goods / Re: Buying automated trading strategies - 100k USD budget on: October 27, 2020, 08:41:08 AM
I wish this thread wasn't moved to somewhere traders do not read.

Automated trading strategy is any trading strategy which is automated. Not sure why this was confusing.

I am completely able to tell the viability and value of any given strategy simply by looking at the P/L or equity chart. I have been doing this for a long time.
3  Economy / Digital goods / Buying automated trading strategies - 100k USD budget on: October 26, 2020, 12:01:10 PM
I'm looking to add to my library of automated trading strategies and I have a 100k USD budget for the right ones.

The right ones will have:

* Complete automation, no human influence
* Profit + equity graph for at least four months
* Low drawdown
* Enough trades to confirm strategy confidence

PM me, or post here with questions.
4  Bitcoin / Development & Technical Discussion / Re: The Finality Design of Blockchain Consensus Mechanism on: June 17, 2019, 08:32:16 AM
For example, PoW does not have absolute finality, only probabilistic finality; BFT has absolute finality, so does Casper FFG. YeeCo’s Tetris consensus also has absolute finality.

Use of 'absolute' is horribly misleading. There is no 'absolute' in any system which is not fully objective. Casper and all BFT-type consensus designs are subjective by nature.

You are correct that PoW only has probabilistic finality, but nothing else has 'absolute' finality, at best they have finality within the set of tolerances set out by the design, which usually include such things as an honest majority of bootstrapping nodes etc.
5  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof of Capacity as a replacement for Proof of Work. on: May 08, 2019, 08:28:18 AM
There is less at risk than in traditional PoW, but not nothing; the point is that if PoC was carried out in an "industrial" fashion like Bitcoin mining then the loss of failed hard drives would become a major factor.

That is not value-at-risk in the same way as electricity cost of mining; what you are referring to is the marginal cost of maintenance, which of course all hardware has especially regular bitcoin mining hardware.
6  Bitcoin / Development & Technical Discussion / Re: [question] Is it possible to use Lighting Network to transfer USDT on: March 27, 2019, 10:09:10 AM
Since USDT also use Bitcoin network , i am wondering if this is possible. If it is possible , is it a same lighting network or a totally different with bitcoin lighting network.

You'd need omnicore (the backbone supporting USDT) to support LN internally for this to work, because the way omni tokens are identified as BTC UTXO's is not trivial. This would also need LN operators to run omnicore as well as bitcoin core.
7  Bitcoin / Development & Technical Discussion / Re: What is sharding, and will sharding scale Bitcoin? on: February 22, 2019, 10:16:27 AM
The problem with sharding is that if you want miners to work separately in each shard (as you must), then the hashrate of the network is divided up by N shards, meaning a double spend attack just got N times easier within each shard.
8  Bitcoin / Development & Technical Discussion / Re: (Brief introduction): A Stake-Based Blockchain Voting Consensus Protocol on: January 31, 2019, 09:26:26 AM
The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

And what is the chain selection rule for non-bootstrapping nodes? Same? Different?
Different. With finalization, without the check above.

What about the cumulative stake rule, how does that combine?
9  Bitcoin / Development & Technical Discussion / Re: (Brief introduction): A Stake-Based Blockchain Voting Consensus Protocol on: January 30, 2019, 02:34:54 PM
The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

And what is the chain selection rule for non-bootstrapping nodes? Same? Different?
10  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 29, 2019, 07:36:31 PM
Or, your attacker can pay large portions of previously active stake to go quiet, then wait some amount of time and launch his attack when he knows your selection rule will favour his fork.
How does that work? Bribling?

Yes.

Quote
How long does the quiet periods usually last? If I find out that the chain I accepted have some proportion of stakes suddenly disapear for two days, I'll check it again. Late, but still objective.

More importantly, in PoAS, miners are working fulltime with accumulated stakes. If you don't want the real miners suddenly stop working , which is too obvious, you have to buy the accounts of those working miners. I can't figure out how to purchase that yet.

It cannot work. Whatever rule you come up with related to inactive stake, you can easily replicate either through bribing, or just might happen by accident.

In addition, the attackers could easily be miners as well.

You cannot cobble together a chain selection rule + some other bizarre ad-hoc rule for detecting history attacks; they have to be one and the same rule, otherwise this will just be to easy to exploit due to complexity.
11  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 29, 2019, 05:23:15 PM
"A certain proportion of active stakes suddenly become never active for a certain period of time." as I said. Isn't that objective?

Yes, but it doesn't work. That could easily happen on the canon chain during quiet periods. Or, your attacker can pay large portions of previously active stake to go quiet, then wait some amount of time and launch his attack when he knows your selection rule will favour his fork.
12  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 29, 2019, 05:11:07 PM
That was an example, what I want to say is : you can't easily fake a perfect chain that can't be recognized when we compare it with the real one.

I'm saying the opposite - you can easily fake a chain by doing this. Give me one objective way of distinguishing between a history attacked chain and the real one.
13  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 29, 2019, 04:39:18 PM
I mean the 20% active accounts he didn't buy. He can't fake them as active.

You can't build a selection rule based on inactive stake. The canon chain may have a whole load of inactive stake during genuine quiet periods, you don't want to select against it during these times, because that's another attack angle.
14  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 29, 2019, 03:54:51 PM
True, I was wrong about that. But there exist many objective methods that can tell the differences between the original chain and the fake one. Such as "the inactive account with 20% stakes never active anymore since..." or something like that.

I don't think so. 'Active since' doesn't make sense because when the attacker buys the private keys, he forks from the point where they were active and produces a fake chain with this now active stake participating. The only thing preventing this attack from succeeding is online nodes being relied upon to keep their existing fork and reject the attackers fork. But this is subjective, not objective.
15  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 29, 2019, 08:30:57 AM
Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.
Bootsrap attack may be a common problem of all chains with finalization. Let's talk about the difficulty and the impact of launching a successful history bootsrap-poinsoning attack in our system.

First, you have to find a history point where there are enough empty accounts that had more stakes than the average total online stakes after that history point.

That isn't true for bootstrap poisoning - as far as any bootstrapping node knows, there is no history available *after* their currently syncing block. A bootstrapping node will accept any valid data as canon, whereas an online node would be able to discard old forks because it has a memory of the real chain.

Moreover, I would say bootstrap poisoning is a problem for all coins which have the NaS problem. 'Finalization' is not a well defined term.

Quote
As the example I gave, the users who sold their empty accounts to the attacker are actually risking their assets (if the attacker succeeds ,their current assets A' and B' will become useless.) for a short-term profit which is the cost of the attack. And that risk cost should not be low enough for one to bear.  At least he can't attack constantly, that makes the influence  of the bootstrap poisoning attack limited (maybe a fork with a few victims, which won't last long).

The users who sold their now empty private keys to the attacker risk nothing. They have long since profited by cashing out.
16  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 28, 2019, 07:42:59 PM
Under the circumstance you described, the history attack could be succeed. But if you can't control the time of your attack, what's the point of the attack?
Besides, if there is a chain with the ability of finalization, I will not confirm my transactions untill the final state is established when I am going to make an important deal.

Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.
17  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 28, 2019, 05:18:08 PM
The other one is the branch priority decision strategy:The branches with higher online stakes will definitely be heavier. Therefore, unless the historical stakes that an attacker possesses exceed all the online stakes of the current main branch, it will not succeed.  For example: the total stakes are made up of three equal part A,B and C. If you collect the private keys of part A and B at a history point, that's 2/3 of the total and you plan to build a new fork from the history point and replace the original one. But the owner of stake A and B must have moved their stakes to other accounts, like A', B', before they give the old private keys to you. So the original branch will have the active stakes of A'+B'+C and your branch will have the stakes of A+B. Your branch will never heavier than the original one under my strategy. Besides, your account A and B will become invalid when a new save point is established.

But what if that is easy?

What if I own old (now empty) private keys containing more stake than the current online stake in the main branch and that is within your re-org limit? Surely I can just construct a new branch from there which will become selected as the best branch?

If the amount of current online stake dwindles due to a network outage, or other force majeure, this doesn't seem to far fetched.
18  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 28, 2019, 02:37:45 PM
Stake weighting, not with network dispersity but with accumulated stakes. Sybil attacks are also not so easy and not even valuable for attackers to apply, and it is no big deal if it really happens.
Please at least read the answer I just replied, I don't want to explain the same stuff repeatedly.
The main idea of the paper was introduced here https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375.

First of all, thank you for your concern. But you don't have to be offensive because I am not your enemy but a guy who wants to share something and discuss them with someone interested. Maybe I have offended you with some unappropriate words that I didn't noticed, I appologize for that.  Anyway, all questions are welcome.

Cumulative stake weighting for branch selection is a good idea, but only when you cannot move a critical amount of stake around on a block by block basis, otherwise history attacks are still possible. This means you need a limit on the amount of stake you can move over a certain number of blocks*.

The 'network dispersity' thing is just nonsense, though.


*) See our discussion with @shunsaitakahashi on PoA - https://bitcointalk.org/index.php?topic=3913439.0
19  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 27, 2019, 07:07:25 PM
If the key issue you mentioned means the "VPS" problem, maybe you have missed the main idea of the paper or maybe I missguided you by my previous posts, I am sorry for that. Although I have a preference for it because it's objective and seems "elegant" to me, "Network Dispersity" is just one of the abilities to "accumulate stakes". If it fails, the security and fairness will not be affected because:
1.
Quote
If countermeasures are not taken, and in the end, if the miners want to win more votes, they will need to arrange more super gatherer nodes globally

And the competition of accumulate stakes is still fair and objective.
Even if the accumulating process is subjective, you could consider it as a sort of "public" DPoS protocol in this respect.
2.
Quote
most of the stakes are owned by the richest users who will tend to accumulate their stakes by themselves and work alone.

It means that the chains will remain strong whether the "network dispersity" works or not, and the motivation of breaking the rules of network dispersity is low because of the negative ROIs.

Please enlighten me, what is the main idea of the paper, because as far as I can tell, the main idea is stake weighting with "Network Dispersity" added on top, which has horrible sybil attack problems?
20  Bitcoin / Development & Technical Discussion / Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol on: January 27, 2019, 11:20:29 AM
This problem was discussed in section 6(2).

You briefly mention the problem and that 'countermeasures' might need to be deployed, but the key issue is not addressed.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!