Bitcoin Forum
May 13, 2024, 12:17:27 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 »
  Print  
Author Topic: DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)  (Read 91075 times)
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 08:26:13 AM
 #561

One of the key differences from what I argued upthread to monsterer, is that "providers" aggregate transactions and thus users can reason about malfeasance on less granular basis than every transactions for itself. This enables users to organize around "providers" which are behaving correctly.

I'm building a clearer picture of your design now. Providers aggregate transactions because users are not suited to the task of building blocks due to their ephemeral online presence. All PoW comes from users in this design, not providers. Users pick transactions from providers to place in their block when they send a transaction. In order to try and prevent a majority PoW from censoring transactions, users can look to these providers in order to tell if a particular fork is censoring transactions.

However, I see a problem: why can't the majority PoW simply create a majority of providers as well, and therefore gain a greater than 50% chance that users will miss information about censorship?
1715602647
Hero Member
*
Offline Offline

Posts: 1715602647

View Profile Personal Message (Offline)

Ignore
1715602647
Reply with quote  #2

1715602647
Report to moderator
In order to achieve higher forum ranks, you need both activity points and merit points.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715602647
Hero Member
*
Offline Offline

Posts: 1715602647

View Profile Personal Message (Offline)

Ignore
1715602647
Reply with quote  #2

1715602647
Report to moderator
1715602647
Hero Member
*
Offline Offline

Posts: 1715602647

View Profile Personal Message (Offline)

Ignore
1715602647
Reply with quote  #2

1715602647
Report to moderator
1715602647
Hero Member
*
Offline Offline

Posts: 1715602647

View Profile Personal Message (Offline)

Ignore
1715602647
Reply with quote  #2

1715602647
Report to moderator
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 09:03:00 AM
Last edit: January 21, 2016, 09:25:48 AM by TPTB_need_war
 #562

However, I see a problem: why can't the majority PoW simply create a majority of providers as well, and therefore gain a greater than 50% chance that users will miss information about censorship?

I would need to explain the last remaining secret about my design in order for the following to make complete sense, which then I might as well just quit implementing it because I would potentially lose the lead on being first to implement it.

I attempted to explain in my prior post on this topic in reply to enet, that users can't be objective about censorship of other user's transactions (per the discussion you and I had upthread), but each user (payer) can be objective about the provider which is censoring their own transaction. And since they all move away from that provider to avoid the censorship, then it has the net effect of taking PoW hashrate away from that provider. Sounds almost like a pool but as I said there are some important differences which I will hold secret for the time being. Also if that provider is refusing to interopt with other providers, this can be objectively observe and users might en mass move away from that provider based on a community alert (e.g. in a forum).

You are correct that the users with their PoW elect the providers, which in that respect is similar to a pool. But there are very significant differences and one of which is that users aren't being paid for their PoW shares and the providers aren't being paid by the PoW. That statement doesn't reveal the other secrets.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 09:09:58 AM
 #563

but each user (payer) can be objective about the provider which is censoring their own transaction. And since they all move away from that provider to avoid the censorship, then it has the net effect of taking PoW hashrate away from that provider

This objectivity is fine, except for the fact that the attacker is free to create an overwhelming majority of providers, such that moving away from one to another has no effect at all. There is a sybil problem here. You can attempt to mitigate this by making it expensive to become a provider, but then we regress back to the PoS security model, which no one wants in a new coin.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 09:21:42 AM
 #564

but each user (payer) can be objective about the provider which is censoring their own transaction. And since they all move away from that provider to avoid the censorship, then it has the net effect of taking PoW hashrate away from that provider

This objectivity is fine, except for the fact that the attacker is free to create an overwhelming majority of providers, such that moving away from one to another has no effect at all. There is a sybil problem here. You can attempt to mitigate this by making it expensive to become a provider, but then we regress back to the PoS security model, which no one wants in a new coin.

Sorry no. The users would have to be the attackers (assuming the users' cumulative hashrate far exceeds any attacker and remember I am targeting instant microtransactions so users' cumulative hashrate will be very astronomical with say 100,000 tx/sec). They decide the set of providers simply by choosing where they send their transactions.

Please also see my reply to enet, wherein I explained what happens if 51% of the users are apathetic and willing to support abusive providers.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 09:38:32 AM
 #565

Please don't make me explain this again. Every since we started discussing Iota, you have continued to repeat this same myopia over and over and over and over and over and over again. It is very redundant and it is cluttering the thread with noise. Whoever can't understand this very simple concept by now, isn't likely to ever understand it.

Partial ordering is a weaker requirement than total ordering, making the statement true. It doesn't matter if it is impossible to achieve in practice; I was making a gross simplification to prove a point, but that appears lost on you.

How many times have I told you that you can not analyze consensus designs piecemeal. It leads to nonsense posts.

Incorrect. You completely failed to comprehend the explanation I made in my prior post. Try reading it again and again and again until you can comprehend.

Nothing in that post addresses the problem. I'll say it again: If you remove the block reward, you remove the honest miners incentive, along with part of the game theory which makes bitcoin work. What incentive is there in your system to play by the rules for an attacker?

I already had explained this and I don't understand why it is so difficult for you to comprehend that the payers must send a PoW with their transactions. The majority of the PoW comes from payers, and the payers have every incentive to approve the longest chain, so their transactions are included on the block chain. If an individual payer wants to attempt a double-spend, he doesn't have enough PoW by himself to accomplish it.

Profitability of mining has nothing to do with the incentives in my design. I hope I don't have to explain this again.

You have shown no such weakness in my current design. Yeah I found flaws in my prior designs. So what. I made it very clear in the past that those designs were still under study and that I was not announcing the details until I was satisfied with my internal review.

Tell me this: how can a recipient know when it is safe to accept a transaction in your design?

Same as in Satoshi's design. When the acceptable number of blocks have been confirmed since the block that included the transaction.

Note that there is another mechanism for instant confirmations as well, but it is optional.

I've already shown you why this statement is incorrect. If you'd like me to go into more detail, I will.

No you have not! Damn it, you make me repeat the same explanations over and over and over and over again.

You continue to make the same mistake over and over: rushing to conclusions. There is no concept of time or clocks whatsoever involved in the tree of work idea, only longest chain of work.

You can't have branches which don't conflict on double-spends without a total ordering. You can't get total ordering without LCR unless you use a clock to timestamp each node of the tree. Period.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 10:06:35 AM
Last edit: January 21, 2016, 10:32:16 AM by TPTB_need_war
 #566

The word mining in Bitcoin mixes to issues: validation of transactions and creation of money.

Transaction validation has a very low cost associated with it compared to finding a hash; regular nodes also do transaction and block validation, and this is designed to be trivial, so I'm still not sure what you mean by making transaction validation profitable?

The bolded phrase can be incorrect if there are unbounded number of verification nodes. Refer to my upthread post for the reasoning and I quoted only the conclusion as follows:

To solve this problem we need to make the cost of what is burned when submitting a transaction greater than the cost of cumulative network verification costs.

I mentioned earlier today upthread that I would elaborate on the weaknesses in my design.

First let me explain the meaning of the above quote. So each provider is also (potentially) a verification node in my design. I say potentially because it is also plausible that providers would pool their verification and do it only once instead each duplicating the cost of verification.

So the first point is that system wide verification costs increase as the number of providers increase (assuming they aren't all pooling their verification). And remember upthread I pointed out that the Tragedy of the Commons of mining (where those providers processing more transaction volume and thus earning more fees, but all providers required to verify all transactions from all providers, would cause a centralization of or oligarchy of providers to control transaction fees as is the case for full nodes in Bitcoin and Ethereum per my upthread explanations) would be avoided only if transaction verification costs (and thus fees) were insignificant compared to typical transaction values. So since we can't limit minimum transaction values (because for one reason is that it would need an ongoing centralized monitor of exchange prices), the next best proxy is to make sure the cost of the PoW submitted with each transaction is much greater than the transaction fees (or more accurately stated in the red text quoted above). So we should set the PoW share difficulty as high as can be tolerated by the computers of payers (users) which will signing transactions (and the delay they can tolerate to compute the PoW share). This also has the benefit of making the total PoW hashrate from payers larger, thus making it more difficult to 51% attack the coin.

If users elect too many providers (in the scenario wherein all do their own independent verification) then if the distribution of users on providers becomes too concentrated into a few of those too many providers, then it is possible for the transaction fees on the seldom used providers to become significant, which would further incentivize users to concentrate into a few providers. Nevertheless this seems to be self-regulating in that since users (payers) have no financial incentive to concentrate in a few providers to begin with (since mining is unprofitable so the variance on block rewards is mostly irrelevant), then the community can (even the default wallet client) can work to distribute transactions across the available providers that have been elected by other payers when the concentration in any one provider exceeds some threshold (say 5% of the network hashrate and other than that leave the number of providers elected a free market function).

Note also that block chain storage costs (given the only regulation of spam are the PoW shares and any free market transaction fees but these should be insignificant relative to PoW per the above) could also be centralizing, i.e. providers might be economically incentivized to pool the storage and verification function. Nevertheless the decentralized, permissionless defense remains that users control the PoW and they can move their PoW at-will away from providers that are censoring or any other malfeasance.

So that is why I wrote upthread that my epiphany was that some centralization of mining is unavoidable but that the decentralized control can remain with the users, so in effect the system remains decentralized. The number of providers and the extent of pooling their verification and storage functions can anneal to the resilency requirements of the network (because for example if providers are DDoSed and unresponsive then users will switch to another provider).

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 21, 2016, 10:33:39 AM
 #567

You refer to game theory implicitly in almost every post but haven't analyzed Nash equilibria yet, have you?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 10:40:53 AM
 #568

You refer to game theory implicitly in almost every post but haven't analyzed Nash equilibria yet, have you?

I have thought extensively about other strategies that the various participants in my design could employ and my analysis is the Nash equilibrium is that that payers all have an incentive to approve each other's transactions, for a similar reasons that in Bitcoin miners don't have any incentive to create multiple chains and ignore the LCR. If payers deviate from this equilibrium then they get chaos and none of their coins and transactions are worth anything.

One of the key points of analysis is that it must not be possible for insoluble double-spend conflicts to accumulate and metastasise into downstream transactions in which many otherwise honest payers would have some financial incentive to fight each other instead of honoring the LCR. But double-spends never make it into a block, same as for Bitcoin, so they can't accumulate (except by the withheld 51% attack same as for Bitcoin and in this case the attacker wins any way so Nash equilibrium doesn't apply).

As for the providers, they are at the mercy of the payers;  that is unless they can somehow manipulate apathetic payers and get 51% of the payers to stick with a provider that is doing malfeasance or hide their malfeasance but I haven't found any such mechanism in my design yet.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 21, 2016, 10:49:59 AM
 #569

I have thought extensively about other strategies that the various participants in my design could employ and my analysis is the Nash equilibrium is that that payers all have an incentive to approve each other's transactions, for a similar reasons that in Bitcoin miners don't have any incentive to create multiple chains and ignore the LCR. If payers deviate from this equilibrium then they get chaos and none of their coins and transactions are worth anything.

One of the key points of analysis is that it must not be possible for insoluble double-spend conflicts to accumulate and metastasise into downstream transactions in which many otherwise honest payers would have some financial incentive to fight each other instead of honoring the LCR. But double-spends never make it into a block, same as for Bitcoin, so they can't accumulate (except by 51% attack same as for Bitcoin).

As for the providers, they are at the mercy of the payers;  that is unless they can somehow manipulate apathetic payers and get 51% of the payers to stick with a provider that is doing malfeasance or hide their malfeasance but I haven't found any such mechanism in my design yet.

So this - http://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf
Quote
Our results show that Bitcoin’s mining protocol is not
incentive-compatible. We presented Selfish-Mine, a mining strategy that enables
pools of colluding miners that adopt it to earn revenues in excess of their mining
power. Higher revenues can lead new miners to join a selfish miner pool,
a dangerous dynamic that enables the selfish mining pool to grow towards a
majority.
The Bitcoin system would be much more robust if it were to adopt
an automated mechanism that can thwart selfish miners. We offer a backwardscompatible
modification to Bitcoin that ensures that pools smaller than 1/4 of
the total mining power cannot profitably engage selfish mining. We also show
that at least 2/3 of the network needs to be honest to thwart selfish mining; a
simple majority is not enough.

- is not applicable? Ok.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 10:51:18 AM
Last edit: January 21, 2016, 11:03:26 AM by TPTB_need_war
 #570

I have thought extensively about other strategies that the various participants in my design could employ and my analysis is the Nash equilibrium is that that payers all have an incentive to approve each other's transactions, for a similar reasons that in Bitcoin miners don't have any incentive to create multiple chains and ignore the LCR. If payers deviate from this equilibrium then they get chaos and none of their coins and transactions are worth anything.

One of the key points of analysis is that it must not be possible for insoluble double-spend conflicts to accumulate and metastasise into downstream transactions in which many otherwise honest payers would have some financial incentive to fight each other instead of honoring the LCR. But double-spends never make it into a block, same as for Bitcoin, so they can't accumulate (except by 51% attack same as for Bitcoin).

As for the providers, they are at the mercy of the payers;  that is unless they can somehow manipulate apathetic payers and get 51% of the payers to stick with a provider that is doing malfeasance or hide their malfeasance but I haven't found any such mechanism in my design yet.

So this - http://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf
Quote
Our results show that Bitcoin’s mining protocol is not
incentive-compatible. We presented Selfish-Mine, a mining strategy that enables
pools of colluding miners that adopt it to earn revenues in excess of their mining
power. Higher revenues can lead new miners to join a selfish miner pool,
a dangerous dynamic that enables the selfish mining pool to grow towards a
majority. The Bitcoin system would be much more robust if it were to adopt
an automated mechanism that can thwart selfish miners. We offer a backwardscompatible
modification to Bitcoin that ensures that pools smaller than 1/4 of
the total mining power cannot profitably engage selfish mining. We also show
that at least 2/3 of the network needs to be honest to thwart selfish mining; a
simple majority is not enough.
- is not applicable? Ok.

Correct my design eliminates the selfish-mining attack, because there are no pools controlling 25 - 33% of the hashrate, which is the minimum required to execute that attack. Each payer only controls a minute amount of PoW, and besides the payer isn't doing the propagation. And moreover, the propagation of the transactions is occurring constantly, not just at the time a block solution is found!

Edit: most saliently, selfish-mining only applies when mining is profitable. The selfish-mining attack is one that is more profitable than not selfish-mining.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 11:31:08 AM
 #571

Sorry no. The users would have to be the attackers (assuming the users' cumulative hashrate far exceeds any attacker and remember I am targeting instant microtransactions so users' cumulative hashrate will be very astronomical with say 100,000 tx/sec). They decide the set of providers simply by choosing where they send their transactions.

The attackers can be both users and providers (you must have considered this?). A user with a majority PoW can also set up a majority of provider nodes, such that he can use his majority control to censor transactions with a greater than 50% chance of success, assuming the minority moves away from the attackers provider node randomly. If you require users to query ALL provider nodes for transactions, this becomes a DOS attack.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 11:39:35 AM
 #572

I already had explained this and I don't understand why it is so difficult for you to comprehend that the payers must send a PoW with their transactions. The majority of the PoW comes from payers, and the payers have every incentive to approve the longest chain, so their transactions are included on the block chain. If an individual payer wants to attempt a double-spend, he doesn't have enough PoW by himself to accomplish it.

Profitability of mining has nothing to do with the incentives in my design. I hope I don't have to explain this again.

Again you miss the point entirely. An individual payer CAN have a majority of PoW in exactly the same way as it can happen in bitcoin, except you've totally removed the incentive to use this power for good instead of evil.

Tell me this: how can a recipient know when it is safe to accept a transaction in your design?

Same as in Satoshi's design. When the acceptable number of blocks have been confirmed since the block that included the transaction.

Define 'acceptable' - you will find it impossible because there is nothing to value the PoW being expended.

You can't have branches which don't conflict on double-spends without a total ordering. You can't get total ordering without LCR unless you use a clock to timestamp each node of the tree. Period.

What does it mean to have a conflicting double spend? (a double spend is itself obviously a conflict, so you mean a conflict of conflicts?)
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 11:59:26 AM
Last edit: January 26, 2016, 02:50:01 AM by TPTB_need_war
 #573

I already had explained this and I don't understand why it is so difficult for you to comprehend that the payers must send a PoW with their transactions. The majority of the PoW comes from payers, and the payers have every incentive to approve the longest chain, so their transactions are included on the block chain. If an individual payer wants to attempt a double-spend, he doesn't have enough PoW by himself to accomplish it.

Profitability of mining has nothing to do with the incentives in my design. I hope I don't have to explain this again.

Again you miss the point entirely. An individual payer CAN have a majority of PoW in exactly the same way as it can happen in bitcoin, except you've totally removed the incentive to use this power for good instead of evil.

An attacker is up against the entire world's CPUs (and remember I designed a very efficient CPU hash in 2014). And who is going to finance that mining farm, when mining is unprofitable?

Remember your point (seems you forget your own points, haha) was that in PoW an attacker must sustain his attack at ongoing cost. But how does the attacker finance this cost when none of his costs are being recouped. I think you fail to consider many factors including for example that mining farms near hydropower generation plants have Bitcoin costs in the range of $50 per BTC. Thus mining centralizes and hashrate centralizes because of the economic profitability of mining.

What evil can the attacker do to recover his costs of mounting the attack? What is the incentive to do evil and how does the attacker finance the attack? And what can he accomplish with an attack? Of course a miner can short the coin, but can he recover enough profit from a short to pay for a 51% attack sustained long enough to do a double-spend that any large sector of the ecosystem cares about? If payees are following the correct probabilities (per Bitcoin 101 below), then the 51% attacker needs win at least 6 blocks to execute a double-spend of any significant value (unless he can spread out his spends in many smaller transactions). But this is the same for Bitcoin's design as well. There is no difference due to the mining being profitable or unprofitable. Bitcoin miners who are renting aren't incentivized to short the coin, otherwise the owners of mining equipment with their sunk capital costs wouldn't rent out mining hardware.

You are completely out-of-touch with the reality of the economics of mining. The reason Bitcoin is so vulnerable is because mining is profitable and thus finances the creation of ASICs and mining farms.

Also you make the assumption that the professional mining farms in profitable PoW of Bitcoin (i.e. Satoshi's design) don't have an incentive to do evil. I explained upthread that they will roll over when the government regulates them, because it is entirely in their interest to do so. Please don't ask me to repeat those points I made upthread since you didn't disagree with them at the time.

Tell me this: how can a recipient know when it is safe to accept a transaction in your design?

Same as in Satoshi's design. When the acceptable number of blocks have been confirmed since the block that included the transaction.

Define 'acceptable' - you will find it impossible because there is nothing to value the PoW being expended.

Did you not learn Bitcoin 101?

https://bitcoin.org/bitcoin.pdf#page=6
http://arxiv.org/abs/1402.2009

You can't have branches which don't conflict on double-spends without a total ordering. You can't get total ordering without LCR unless you use a clock to timestamp each node of the tree. Period.

What does it mean to have a conflicting double spend? (a double spend is itself obviously a conflict, so you mean a conflict of conflicts?)

I mean that without a total ordering you can't decide which double-spend to discard when those double-spends appear in separate branches of the tree.

The fact that you can't seem to comprehend what is being written is indicative of that you are not qualified as you seem to think you are on the analysis of consensus systems.

enet
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
January 21, 2016, 12:11:20 PM
 #574

Quote
As I explained to monsterer upthread, it is not possible to objectively prove (with cryptography and math) which chain is the honest one and which one is the dishonest one when there are censored transactions. But it is possible to determine which "providers" (in my design) are denying certain transactions and/or denying to interact properly with other "providers" which are not denying certain transactions.

Yes, that's a good point. PoW and PoS rely on an algorithm, not explicit actions of individual nodes. But to solve that problem you need some mechanism to securely count and distinguish nodes. And the Internet doesn't allow that. That's the whole reason for the extremely complicated construction via CPU. The Bitcoin whitepaper discussed an alternative to 1 CPU = 1 vote.

"The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. "

In a system with one-IP-one-vote, it would be possible to sanction individual actions - which is impossible in PoW/PoS.

Quote
You are completely out-of-touch with the reality of the economics of mining. The reason Bitcoin is so vulnerable is because mining is profitable and thus finances the creation of ASICs and mining farms.

Almost everything in Bitcoin is designed for it to work at the beginning. Its better to accept its not a perfect system and think what it was designed to do  - a quorum system via CPU, with incentives and currency. New designs can learn from many things and discard most aspects. Verification and storage of data needs to be profitable in the longterm. That's basic the most basic principle of Bitcoin. Users solve the tragedy of the commons together with the P2P ledger. The problem is not profitability, but economies of scale.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 12:35:21 PM
 #575

An attacker is up against the entire world's CPUs (and remember I designed a very efficient CPU hash in 2014). And who is going to finance that mining farm, when mining is unprofitable?

This is the same as in any PoW chain, nothing different there.

What evil can the attacker do to recover his costs of mounting the attack? What is the incentive to do evil and how does the attacker finance the attack?

You are completely out-of-touch with the reality of the economics of mining.

Hilarious. Ok, so the attackers only motivation is to double spend. Simple as that. Why do I need to explain this to you?

Also you make the assumption that the professional mining farms in profitable PoW of Bitcoin (i.e. Satoshi's design) don't have an incentive to do evil.

They have the incentive to do GOOD as well as evil in bitcoin. By removing this angle, you have thrown away a totally critical part of the game theory.



I'll accept that you can compute a probability of a double spend succeeding in the absence of a block reward in the face of an attacker who is arbitrarily attacking. However, you must have missed this from the 2nd paper you linked about the motivation of the attacker, which adds critical detail to the analysis:

https://bitcoil.co.il/Doublespend.pdf#page=12

v=value of double spend
r=probability of double spend success
k=number of merchants attacked per block
alpha=liquidity of purchase
B=block reward

"This means that discouraging an attack requires that:"

v <= (20*(1-r)*B) / (k*(alpha + r - 1))

Set B = 0, then

v <= 0

So to discourage an attack in the absence of a block reward, the value of the double spend must be 0.

I.e. it's impossible to discourage without a block reward.

I mean that without a total ordering you can't decide which double-spend to discard when those double-spends appear in separate branches of the tree.

Prepare to be surprised.

In addition, I just want to say that I am not attempting to attack you, or your idea here, I am just trying to help you succeed; it is better for a idea to receive the harshest critical analysis *before* you go to all the pains of implementing it, wherein it would be too late to fix the problems. I would like to offer suggestions in how to fix these flaws, if I can.
duplan
Sr. Member
****
Offline Offline

Activity: 269
Merit: 252


View Profile
January 21, 2016, 02:45:20 PM
 #576

Maybe you can find useful answers and working mechanisms here:
http://blog.maidsafe.net/2015/01/29/consensus-without-a-blockchain/
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 02:56:35 PM
 #577

Maybe you can find useful answers and working mechanisms here:
http://blog.maidsafe.net/2015/01/29/consensus-without-a-blockchain/

'The Transaction Managers' represent a centralised solution to double spending, and even then it appears a tenuous solution because there might be disagreement between transaction managers, which would then require consensus to resolve, opening the system up to all the problems of a blockchain.

enet
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
January 21, 2016, 05:32:15 PM
 #578

So to discourage an attack in the absence of a block reward, the value of the double spend must be 0.

Right, if assumes reward are directly tied to blocks (the atomic unit in Bitcoin). All that one observes of others nodes is very short term behaviour, and there is no way to sanction bad behaviour - all attacks have to be prevented in an ex-ante fashion. There are however potentially other ways to reward/punish behaviours, which are not tied to a single block.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 21, 2016, 07:55:34 PM
 #579

Right, if assumes reward are directly tied to blocks (the atomic unit in Bitcoin). All that one observes of others nodes is very short term behaviour, and there is no way to sanction bad behaviour - all attacks have to be prevented in an ex-ante fashion. There are however potentially other ways to reward/punish behaviours, which are not tied to a single block.

I'd like to hear your thoughts on rewards not tied to a block?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 21, 2016, 08:05:02 PM
Last edit: January 26, 2016, 02:29:39 AM by TPTB_need_war
 #580

An attacker is up against the entire world's CPUs (and remember I designed a very efficient CPU hash in 2014). And who is going to finance that mining farm, when mining is unprofitable?

This is the same as in any PoW chain, nothing different there.

I explained what is different but you've decided to ignore the education:

I already had explained this and I don't understand why it is so difficult for you to comprehend that the payers must send a PoW with their transactions. The majority of the PoW comes from payers, and the payers have every incentive to approve the longest chain, so their transactions are included on the block chain. If an individual payer wants to attempt a double-spend, he doesn't have enough PoW by himself to accomplish it.

Profitability of mining has nothing to do with the incentives in my design. I hope I don't have to explain this again.

Remember your point (seems you forget your own points, haha) was that in PoW an attacker must sustain his attack at ongoing cost. But how does the attacker finance this cost when none of his costs are being recouped. I think you fail to consider many factors including for example that mining farms near hydropower generation plants have Bitcoin costs in the range of $50 per BTC. Thus mining centralizes and hashrate centralizes because of the economic profitability of mining.

What evil can the attacker do to recover his costs of mounting the attack? What is the incentive to do evil and how does the attacker finance the attack? And what can he accomplish with an attack? Of course a miner can short the coin, but can he recover enough profit from a short to pay for a 51% attack sustained long enough to do a double-spend that any large sector of the ecosystem cares about? If payees are following the correct probabilities (per Bitcoin 101 below), then the 51% attacker needs win at least 6 blocks to execute a double-spend of any significant value (unless he can spread out his spends in many smaller transactions). But this is the same for Bitcoin's design as well. There is no difference due to the mining being profitable or unprofitable. Miners in Bitcoin aren't incentivized to not short the coin, otherwise they wouldn't rent out mining hardware.

You are completely out-of-touch with the reality of the economics of mining. The reason Bitcoin is so vulnerable is because mining is profitable and thus finances the creation of ASICs and mining farms.

Also you make the assumption that the professional mining farms in profitable PoW of Bitcoin (i.e. Satoshi's design) don't have an incentive to do evil. I explained upthread that they will roll over when the government regulates them, because it is entirely in their interest to do so. Please don't ask me to repeat those points I made upthread since you didn't disagree with them at the time.

What the fuck can't you comprehend from above?

You have an inability to think about anything in paradigm-shift terms. You tried to analyze a DAG as if all the branches obey a deterministic relative ordering, totally failing to comprehend that such an ordering is impossible without a global clock (since the LCR is impossible given multiple branches). Now you are demonstrating your intellectual handicap again.

I will reply to your myopic math delusion after I complete some tasks this morning. Don't forget how I taught the Monero developers some math recently (and make you sure scroll 2 pages up that thread and see how they were so sure of themselves and boastful just the same as you are now). Hint: unbounded entropy of the universe.

I mean that without a total ordering you can't decide which double-spend to discard when those double-spends appear in separate branches of the tree.

Prepare to be surprised.

In addition, I just want to say that I am not attempting to attack you, or your idea here, I am just trying to help you succeed; it is better for a idea to receive the harshest critical analysis *before* you go to all the pains of implementing it, wherein it would be too late to fix the problems. I would like to offer suggestions in how to fix these flaws, if I can.

You are wasting my time and I won't be surprised. I will be forced to point out more of your myopia.

It was already explained to you upthread that due to the fact that the speed-of-life can't be infinite, then it is impossible to have decentralized, trustless Consistency in the face of multiple perspectives (i.e. branches a.k.a. Partitions) without consuming some resource in a LCR. Any idea you are contemplating will be flawed because it violates the fundamental nature of our universe.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!