Bitcoin Forum
September 22, 2019, 11:17:50 PM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: « 1 ... 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 [102] 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 »
  Print  
Author Topic: delete  (Read 165306 times)
smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:02:11 AM
 #2021

Btw, has anyone paid close enough attention to the selfish-mining paper to observe that as the attackers hashrate approaches 50% of the network, his portion of the blocks won goes to 100%.  Shocked

You don't need to pay close attention. It is well known even without selfish mining that with 50+% you can reject all other blocks. I think Satoshi mentioned it.

Quote
Bitcoin often has a single pool with 50% of the network hashrate.

There is a fundamental problem here.

Agree

Quote
All the anonymity tech in the world is sort of useless against the state under this current situation.

Disagree. It is entirely possible the state has nothing to do with mining, nor will, and even with concentrated pools anonymity can still work. For example, perhaps the mining pools, even if concentrated, will jurisdiction shop the way the pirate bay does, or go more underground and become stateless (this could serve to decentralize them, since smaller pools are easier to hide). There are many such possibilities, not just the one guaranteed future of the state taking control of pools. That is certainly possible though.

Quote
We need to fundamentally rethink the longest chain rule as it is currently formulated.

Not necessarily. Another solution would be radically reducing concentration.


1569194270
Hero Member
*
Offline Offline

Posts: 1569194270

View Profile Personal Message (Offline)

Ignore
1569194270
Reply with quote  #2

1569194270
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:17:34 AM
 #2022

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

It is only a risk against an attacker that has 50% of the network hashrate and thus can rewrite the chain, but in that case you have bigger problems any way.

Thus afaics, TT's concern is BS.
TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:23:38 AM
 #2023

Btw, has anyone paid close enough attention to the selfish-mining paper to observe that as the attackers hashrate approaches 50% of the network, his portion of the blocks won goes to 100%.  Shocked

You don't need to pay close attention. It is well known even without selfish mining that with 50+% you can reject all other blocks. I think Satoshi mentioned it.

Good point, but also note the selfish mining revenue equation shows that you get very close to 100% before you hit 50%.

Quote
All the anonymity tech in the world is sort of useless against the state under this current situation.

Disagree. It is entirely possible the state has nothing to do with mining, nor will, and even with concentrated pools anonymity can still work. For example, perhaps the mining pools, even if concentrated, will jurisdiction shop the way the pirate bay does, or go more underground and become stateless (this could serve to decentralize them, since smaller pools are easier to hide). There are many such possibilities, not just the one guaranteed future of the state taking control of pools. That is certainly possible though.

IMO very naive. But okay.

Quote
We need to fundamentally rethink the longest chain rule as it is currently formulated.

Not necessarily. Another solution would be radically reducing concentration.

Except that selfish mining starts at 25%, and creators of fiat can surely rent as much hashpower as they need when the time arises.

Your alternative would have to be very radical spread of mining. Wait, wasn't that what I've been suggesting...
smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:23:56 AM
 #2024

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Among the trust assumptions here are that there weren't bugs in the code in the past that allowed invalid ring sigs to be accepted. But there are actually quite a few subtle assumptions that sneak in when you can't verify the entire chain.


TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:28:58 AM
 #2025

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

(so who was spreading FUD again?)
crypto_zoidberg
Hero Member
*****
Offline Offline

Activity: 937
Merit: 559



View Profile WWW
October 05, 2014, 12:30:20 AM
Last edit: October 05, 2014, 01:07:22 AM by crypto_zoidberg
 #2026

.....
It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

It is possible but unreasonable because PoW prooves tx history anyway, with relation from current block till genesis.
Possible because i have  "not pruned" backup, so if i share it - it will be a natural prove. Isn't it ?


smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:31:13 AM
Last edit: October 05, 2014, 02:40:56 AM by smooth
 #2027

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

See edit above. You are trusting that the code that constructed that chain (i.e. accepted those inputs and outputs) worked correctly. That does not need to be the same code you are using today. You can't verify it.

Personally (and I'm pretty sure tacotime agrees) I believe that SPV-style approaches are far better, where it is possible to verify as much of the chain as you want, but not necessary to verify all of it to function, and fully verifying nodes still exist. Yes I am aware that an exact mapping of Bitcoin SPV does not apply, that's why I said SPV-style, not SPV.




TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:33:21 AM
 #2028

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

See edit above. You are trusting that the code that constructed that chain (i.e. accepted those inputs and outputs) worked correctly. That does not need to be the same code you are using today. You can't verify it.

http://pandodaily.files.wordpress.com/2012/01/backpedaling3.jpg
TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:36:54 AM
 #2029

Those ring proofs are still available (somebody is saving them) if we need to reconstruct from a discovered bug. In the meantime, no need to force everyone to download them every time we sync, which is a significant problem for XMR as I've read some users complain.

And if you think about how to radically decentralize mining as I have been doing for months, then you will realize a long download time for syncing is a significant issue.

(I repeat, "the jury is still out...")
smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:40:57 AM
 #2030

Again, see edit above.

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

Possibly it is discovered by someone who has an archived version of the chain, but even then, it can't even be independently verified that their claimed version of the chain is the correct one. Maybe someone else comes up with a different one. There are no hashes to refute this.

It is far better to retain the ability but not the requirement to independently verify the chain, and retain the chain somewhere in a trustless decentralized network.

Even committing a hash of the early chain (full hash including, not excluding, ring sigs) when you trim it would be somewhat better, but as far as I know is not being done.

The trust model of the BBR ring sig trimming -- within the chain itself and not relying on external sources -- is simply that everything is okay below the checkpoint because the developer said so and put a checkpoint there.

BTW, one last comment on this. I'm not even saying the BBR trimming is a bad idea. I see a lot of merit in it. I'm just saying that it involves changing the trust model, and is not unequivocally a good idea. It is a trade off. Nor do I agree that the only choice is between the current BBR implementation and the current Monero implementation.



smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:44:51 AM
 #2031

Again, see edit above.

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

Possibly it is discovered by someone who has an archived version of the chain, but even then, it can be independently verified that their claimed version of the chain is the correct one.

It is far better to retain the ability but not the requirement to independently verify the chain, and retain the chain somewhere in a trustless decentralized network.

Even committing a hash of the early chain (full has including not excluding ring sigs) when you trim it would be somewhat better, but as far as I know is not being done.

The trust model of the BBR ring sig trimming is simply that everything is okay below the checkpoint because the developer said so and put a checkpoint there.

BTW, one last comment on this. I'm not even saying the BBR trimming is a bad idea. I see a lot of merit in it. I'm just saying that it involves changing the trust model, and is not unequivocally a good idea. It is a trade off. Nor do I agree that the only choice is between the current BBR implementation and the current Monero implementation.





I completely agree with smooth here, the downsides of trimming the chain overshadowed the irrelevant time for syncing.

Sync time isn't irrelevant but it the choice between A and B is a false one.

Also the constant factor reduction might turn out to be relatively unimportant given other scaling factors.
TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:45:30 AM
 #2032

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

There are so many significant costs (if one realizes that without radically decentralized mining we are just wasting our time) that are paid for protecting that silly scenario.

You got sucked into defending a bad idea by the consensus of the XMR devs. It isn't your fault. You can't entirely speak your own mind.
smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:46:43 AM
 #2033

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

There are so many significant costs that are paid for protecting that silly scenario.

False. At best it is a constant factor reduction in the chain size.

TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:47:20 AM
 #2034

(if one realizes that without radically decentralized mining we are just wasting our time)

See my edit.

Then again, I am not sure if ring signatures are even congruent with radically decentralized mining...
xulescu
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250


View Profile
October 05, 2014, 12:47:42 AM
 #2035

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

It is only a risk against an attacker that has 50% of the network hashrate and thus can rewrite the chain, but in that case you have bigger problems any way.

Thus afaics, TT's concern is BS.

Everyone seems to assume that the difficulty is constant when it is actually an amazingly fast exponential. You don't need >50% of the hash rate to rewrite past blocks. On the contrary, most of the weight of a particular chain is in the newest blocks.

Those ring proofs are still available (somebody is saving them) if we need to reconstruct from a discovered bug. In the meantime, no need to force everyone to download them every time we sync, which is a significant problem for XMR as I've read some users complain.

And if you think about how to radically decentralize mining as I have been doing for months, then you will realize a long download time for syncing is a significant issue.

(I repeat, "the jury is still out...")

If everyone is not storing, then those who store will have an information advantage.

In XMR's present case, full nodes store everything.
In XMR's future case, full nodes store everything and SPV-style nodes store just a cache of what they need.

In BBR's present case, "somebody" stores everything and full nodes do not store rings.
In BBR's future case, "somebody" stores everything, full nodes do not store rings and SPV-style nodes are still required.

Do you see where I'm going with this?
smooth
Legendary
*
Offline Offline

Activity: 2254
Merit: 1136



View Profile
October 05, 2014, 12:49:21 AM
 #2036

(if one realizes that without radically decentralized mining we are just wasting our time)

See my edit.

Then again, I am not sure if ring signatures are even congruent with radically decentralized mining...

I disagree that a constant factor reduction in chain size will reliably give you radical decentralized mining. The constant factor gets overwhelmed by whatever super-linear scaling occurs, over a relatively small range.




TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:53:17 AM
 #2037

(if one realizes that without radically decentralized mining we are just wasting our time)

See my edit.

Then again, I am not sure if ring signatures are even congruent with radically decentralized mining...

I disagree that a constant factor reduction in chain size will reliably give you radical decentralized mining. The constant factor gets overwhelmed by whatever super-linear scaling occurs, over a relatively small range.

You seem to offer some support to my second sentence then...
TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:56:26 AM
 #2038

Do you see where I'm going with this?

No. Could you be more explicit?
robinwilliams
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
October 05, 2014, 12:56:52 AM
 #2039

Quote
There are so many significant costs (if one realizes that without radically decentralized mining we are just wasting our time) that are paid for protecting that silly scenario.

market caps seem to agree with leaving the ring signatures in ... and i actually would prefer it as well.

it seems odd that anonymint who is the MOST CONSERVATIVE on EVERYTHING to do with anoniminity is siding on the side of possibly not being able to prove anoniminity of prev transactions.
TheFascistMind
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 05, 2014, 12:57:59 AM
 #2040

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

There are so many significant costs that are paid for protecting that silly scenario.

False. At best it is a constant factor reduction in the chain size.

We have another protection against that silly worry. It is known as "open source".
Pages: « 1 ... 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 [102] 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 »
  Print  
 
Jump to:  

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!