Bitcoin Forum
October 18, 2018, 08:52:26 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 »
1  Bitcoin / Development & Technical Discussion / Re: where can i get testnet coins since faucets are down? on: September 06, 2018, 02:12:50 PM
Just mine them - they're easy to mine
2  Bitcoin / Development & Technical Discussion / Re: Is colored coins still in use? on: September 05, 2018, 09:18:21 AM
There is a good deal of work that will need to be done to make colored coins a viable alternative for storing physical assets on the blockchain.

Tether has over $1B stored as coloured coins on BTC network.
3  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: September 05, 2018, 08:12:47 AM
monsterer lack of understanding of what is required is mind blowing.
Long range attacks are more complicated that what has been mentioned.

Have you even read the OP? This attack is not long range, its short range - below your precious reorg depth limit.

Even the most pessimistic cost assessment puts this attack at 3% stake.
4  Bitcoin / Development & Technical Discussion / Re: Is colored coins still in use? on: September 04, 2018, 03:32:21 PM
Look into omnilayer. That's probably the biggest coloured coin provider on BTC - tether is an omni asset.
5  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: September 02, 2018, 11:24:33 AM
In this case, if the checkpoint is included before the attacker "liberates" his attack chain, it's still not a hard fork. It's simply a typical "weak subjectivity" scenario.

But if he was successful and the reorganization to the attacker's chain would have taken place, then it is. This would be similar to Ethereum's ETH/ETC fork.

I agree with everything you've written, apart from the fact that it gives validation to the idea that having the community vote to create a hard fork is in any way acceptable for a currency that's supposed to be decentralised.
6  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: September 01, 2018, 06:38:42 PM
PoS user informs the PoS Dev of sold keys, before the attacker can launch his attack ,

PoS Dev updates checkpoint thru program update, making the attacker purchase of old keys useless.

Now the attacker has the useless keys and lost his payment  , and the PoS User & Dev are Laughing at the attacker's attempt.
 
*What is funny is the attacker whom is attempting to do harm with a dishonest heart, thinks the PoS User will be honest with him.*  Cheesy Cheesy Cheesy

This might be the primary reason , no one ever tries to buy old keys.   Smiley
Because it is so easy to turn the attacker into the Chump.

What is funny is trusting any form of money where you have to rely on a hard fork in order to retain any sense of security.
7  Bitcoin / Development & Technical Discussion / Re: A new consensus that promises high levels of security (PoH) on: August 29, 2018, 08:57:06 AM
Looks like there are a lot of shills in this thread.
8  Bitcoin / Development & Technical Discussion / Re: A new consensus that promises high levels of security (PoH) on: August 29, 2018, 08:30:50 AM
Any distributed p2p, digital currency which relies on trust to make it work is nothing more than a horrible mistake a best, and at worst it's a scam.

As soon as you make that trust sacrifice, you might as well throw it all in the bin and use VISA, which has none of the drawbacks associated with crypto, and is already accepted everywhere.
9  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: August 28, 2018, 07:36:07 AM
No, that estimation includes the threats by long range attacks (like the attack you described - the typical "old keys attack"), bribe attacks, short-range attacks and other known N@S-related scenarios. No one of these attacks is free, most of them are highly impractical (try to find people that sell you 50% of the staking amount in some moment of time) and, thus, expensive

Not sure I'd completely agree with that. More like between 0% and 3% would be a more accurate estimate.
10  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: August 27, 2018, 08:42:28 PM
However, I believe a PoS attack to be in the same order of magnitude (~3-5% of market cap).

...ignoring the threat outlined in the OP of the thread?
11  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: August 26, 2018, 10:11:31 AM
Sybil attacks can place a fake chain with a lower PoW difficulty rating until a node sees the other chain with the higher difficulty and reorgs.

That is an objective decision.

You have to buy or steal the PoS coins to stake them?
Their is a cost involved.

Buying empty private keys will be very, very cheap compared to renting hash power.

Also your pretense at how easy it would be is over exaggerated.
Feel free to 51% attack zeitcoin to prove how easy it is for you.  Cheesy
(According to you it is a zero cost attack so nothing is stopping you.)

I have no motivation, nor desire to attack your shitcoin, I have better things to do with my time.

What I am saying is if their is a sybil attack involved and your node is being blocked from seeing the true chain,
you can use a block explorer to verify the true chain for PoS or PoW.

That is not only subjective, but is also human intervention. Double systematic failure.
12  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: August 25, 2018, 11:59:12 AM
True chain can be determined by comparing block height with the block explorer for PoS or PoW.
As a Sybil attack can fake a chain on either PoS or PoW and only comparing to a Block Explorer can verify the true chain for a syncing node.

Have you listened to a single thing anyone had said in this thread?

Producing blocks under PoS has zero cost, therefore any desired chain height can be reached by the fake chain, making it impossible to objectively differentiate between fake and canon chains.
13  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: August 25, 2018, 11:07:42 AM
It's a difficult attack to be sure because owning that much stake in a network is unlikely - but it is absolutely not impossible because many PoS systems especially have very lopsided distributions. Losing the ability for new nodes to know what is the "one, true chain" without needing outside information is a problem. How big of a problem is a matter for debate, but it can't just be brushed off as so unlikely as to be impossible.

...and, indeed in the scope of the topic of this thread, it becomes much more problematic than just a contemporary majority stake holder turning bad, even recently emptied private keys can be used to carry off this attack as long as there is no objective way for the network to determine the true chain.
14  Bitcoin / Development & Technical Discussion / Re: Low-Latency Restricted DAG on: August 21, 2018, 05:39:55 PM

I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.

You need an objective way to sort this out.
I guess OP would say B should never witness both A2 and A2+, users are supposed to get enough witness for A chain before considering a transaction confirmed.

That might work for an individual user, but if different users see a different state due to latency, you're back at square 1. There has to be some objective way of resolving this; either you have to adopt the synchronous swilrds hashgrid consensus(1), or you need to adopt something with a probabilistic finality like the tangle(2), or T.E.T.O(3).


1) https://swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf
2) https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf
3) https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf
15  Bitcoin / Development & Technical Discussion / Re: Low-Latency Restricted DAG on: August 21, 2018, 03:34:44 PM


In Figure 6, user A attempts to publish alternate blocks A2 and A3. Since user B3 has already wit-nessed blocks A2, A2 would be rejected by all participants. Furthermore, A can be flagged as a malicious or compromised user for presenting two different solutions for A1

I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.

You need an objective way to sort this out.
16  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: July 28, 2018, 10:45:22 AM
What I am telling you is , you are wrong.

If you modify the wallet client to place false time date in the blocks , all you are doing is making a hard fork that the other nodes will ignore.

That's called 'weak subjectivity'. You really need to do some more research.
17  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: July 27, 2018, 09:45:59 AM
Cost is not the issue, Each Block has a defined target of say 1 minute between blocks.

Your chain is 3 months behind, and still has a target time of 1 minute,  your block height will always be ~ the same 3 months behind and as such never a threat to causing a reorg, because a reorg can only happen if your block height # exceeds the main chain.

So how do you make up the 3 months time difference?

FYI:
Any change to the code to modify the time target between blocks could allow faster blocks, would lower the target difficulty making it a weaker chain and also break consensus with the other nodes, therefore making sure it would never be accepted over the main chain.

FYI2:
The phrase (block production has zero cost) , is incorrect.
There actually is a cost , it is time.  
Your block has to wait the coded time before block generation can occur, and those coins go dormant for a coded period, another time factor.
The Time between blocks is hard coded which affects the difficulty # in proof of stake coins, thus defining the strength or weakness of a chain.

I really hope you're not the developer of that coin in your sig, because you seem to have some fundamental misconceptions about consensus design.

1) I have already said this above, but I'm going to restate it in plain terms: any concept of time elapsed in a trustless system is utterly unverifiable without an objective measure such as PoW, which is an unforgable proxy for elapsed time

2) In PoS block production has zero cost, see 1)
18  Bitcoin / Development & Technical Discussion / Re: Proof that Proof of Stake is either extremely vulnerable or totally centralised on: July 26, 2018, 01:22:38 PM
My question is this:
Let's say their are no checkpoints , rolling or coded.

Someone buy the old private keys or at some point just actually owned over 51% of a coin total.

Say they try your attempt , but it was 3 months earlier when they owned coins.

The Blockchain has 3 months of confirmations ahead of them at a rated say 1 minute interval.

How do they ever catch up , with the block height of the main chain, won't they always be ~3 months behind?

* Now if you say it is possible to trick the time setting and somehow condense those 3 months into a day, please provide details or proof on how that is done.*

Because block production has zero cost, and there is no way to objectively verify any given block as being created at time T.
19  Bitcoin / Development & Technical Discussion / Re: Is POW systematically doomed to get a huge monster in its midst? on: July 12, 2018, 07:29:15 AM
This would be a perpetual subsidy - not one that runs out ?

Is there no competition to mine the most max POW transactions, and accrue the most mining subsidy ? A professional miner as you say in your paper.

The subsidy is perpetual, yes. There is no competition to mine a particular block; all miners can mine their own max difficulty blocks - they just have to be careful not to do so outside the path of most cumulative difficulty. Doing it like this maximises PoW efficiency, since no PoW is 'wasted' in orphans, it all adds to the security of the DAG.
20  Bitcoin / Development & Technical Discussion / Re: Is POW systematically doomed to get a huge monster in its midst? on: July 11, 2018, 06:27:59 PM
Smiley.. there you go!..  

The Mining Subsidy.. It's not clear to me quite how that works..  What Stops people fighting over it  - or do they just compete as normal ?

Everyone on the path of greatest cumulative difficulty gets a mining reward proportional to their chosen difficulty. The big departure from bitcoin is there is no competition to mine the best block, since only the sender of the single transaction within the block can 'mine' it.

Quote
How long does it take for a branch to become heavy enough to be considered final ? How do you remove the need for the coordinator that IOTA uses ?

Are you knocking this up and launching ? ..

How long in real time is hard to quantify, but its very easy to quantify finality - it's simply when enough PoW gets built on top of the transaction in question to make any attack B/E, where 'enough' is equal to the sum of all the block rewards above the transaction.

This doesn't need coordinators because it has a mining incentive.

I'm not planing on taking this any further as a cryptocurrency - simply because it doesn't support lite nodes. No DAG design can support lite nodes without extra centralisation. As @anunymint noted previous, satoshi didn't make any mistakes - blocks are essential for adoption.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!