Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
Here's a slapped-together partial visual summary of my earlier post on why we don't need Extreme Consensus to maintain Bitcoin's sound money properties, and instead need fork futures trading in order to restore the original prediction market in forks that Satoshi mentioned in the whitepaper. [Click to enlarge]
it seems highly centralized, just like the RN. this also is a concern:
"We would like to build up a user base with which we can communicate, however, and to that end, we are enabling the high-speed mode of Falcon on an invite-only basis."
the "invite-only" status immediately classifies this as centralized. he also admits that he wants to "communicate" with it's participants, meaning that those participants will have to reveal themselves.
as well, i would be leery of anything associated with Emin Gun Sirer. he's been trying to carve a niche out for himself as an expert in Bitcoin for years now beginning with his SM paper and then parading that around via talks and presentations as if it is some kind of fact. it took me all of a second to understand that his conclusions were bunk b/c of the game theory involved with mining. he hates that i disagree with him, and that to date, no one has executed his SM attack.
as the maintainer of the Falcon network and as a Cornell researcher, it appears to me that he would want to extensively monitor traffic passing thru Falcon for his research purposes and perhaps ultimately sell that data for profit. i'm almost sure of the former and actually don't want to believe the latter, but i wouldn't put it past him and Cornell.
- Dec 16, 2015
- 2,806
- 6,088
@Tomothy : Soumya Basu of the Falcon team popped in to the BU slack a few days back. theZerg and I asked him a couple of questions on matters that were not yet reflected on their website at the time - I haven't checked since):
thezerg 10:39:
hi soumya, can you give us links and an overview of falcon?
is it related to https://switchless.com/falcon
soumya 11:23:
No- it's completely unrelated to that. Our landing page provides some background but we're still working on the design http://www.falcon-net.org
(Of the front end. We're pretty happy with the backend. XD)
The general overview is that we use cut through routing to parallelize the block transfers.
Instead of waiting to receive the full block before forwarding, we only wait for the header before we start broadcasting the blocks
Our main propagation overhead is the block size now, which compression will help out with quite a bit.
freetrader 11:31:
@soumya: from that page (which is quite interesting, thanks!)
> Only subscribed nodes get the benefits of our high-speed transport
So your project maintains this dedicated infrastructure, or other third parties?
or is it kept up jointly by a subscriber base?
soumya 11:33:
We maintain this entirely. Also, the benefit is for the source of the blocks not the recipients
So if you connect to our nodes, you'll still receive blocks quickly. You won't be able to send out blocks quickly unless you're trusted
We're moving away from this model to one where if you give us new, good blocks, you can cut through blocks as well
freetrader 11:39
i see. thanks for the info, it sounds interesting.
I suppose the infrastructure plays a very integral part in this.
I've had a glance at the website & slides but couldn't resolve this question:
Do you operate the infrastructure based on regular commercial service provider(s), or is it a kind of research project currently running on a fast academic WAN?
Since this seems to provide a valuable service to miners, I guess if it's not already a commercial entity there are plans to transition to one?
soumya 12:14:
Currently, we're deployed on Amazon EC2 instances (1 instance on each availability zone)
It's definitely not a commercial entity yet, but we might make it into one at some point. At this point, we're more concerned with building a robust dissemination network.
thezerg 10:39:
hi soumya, can you give us links and an overview of falcon?
is it related to https://switchless.com/falcon
soumya 11:23:
No- it's completely unrelated to that. Our landing page provides some background but we're still working on the design http://www.falcon-net.org
(Of the front end. We're pretty happy with the backend. XD)
The general overview is that we use cut through routing to parallelize the block transfers.
Instead of waiting to receive the full block before forwarding, we only wait for the header before we start broadcasting the blocks
Our main propagation overhead is the block size now, which compression will help out with quite a bit.
freetrader 11:31:
@soumya: from that page (which is quite interesting, thanks!)
> Only subscribed nodes get the benefits of our high-speed transport
So your project maintains this dedicated infrastructure, or other third parties?
or is it kept up jointly by a subscriber base?
soumya 11:33:
We maintain this entirely. Also, the benefit is for the source of the blocks not the recipients
So if you connect to our nodes, you'll still receive blocks quickly. You won't be able to send out blocks quickly unless you're trusted
We're moving away from this model to one where if you give us new, good blocks, you can cut through blocks as well
freetrader 11:39
i see. thanks for the info, it sounds interesting.
I suppose the infrastructure plays a very integral part in this.
I've had a glance at the website & slides but couldn't resolve this question:
Do you operate the infrastructure based on regular commercial service provider(s), or is it a kind of research project currently running on a fast academic WAN?
Since this seems to provide a valuable service to miners, I guess if it's not already a commercial entity there are plans to transition to one?
soumya 12:14:
Currently, we're deployed on Amazon EC2 instances (1 instance on each availability zone)
It's definitely not a commercial entity yet, but we might make it into one at some point. At this point, we're more concerned with building a robust dissemination network.
Here's a slapped-together partial visual summary of my earlier post on why we don't need Extreme Consensus to maintain Bitcoin's sound money properties, and instead need fork futures trading in order to restore the original prediction market in forks that Satoshi mentioned in the whitepaper. [Click to enlarge]
great table! i would add to column 1 row 2, "users and nodes might rebel".Here's a slapped-together partial visual summary of my earlier post on why we don't need Extreme Consensus to maintain Bitcoin's sound money properties, and instead need fork futures trading in order to restore the original prediction market in forks that Satoshi mentioned in the whitepaper. [Click to enlarge]
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
You can't do it that way as it correlates. If you have 300/1000 blocks for Classic, on the next block, it will either be 299 or 300 OR 300 or 301 depending on what type of block falls off the end.
This doesn't need any kind of monte carlo method in any case. It can be quite easily calculated.
(Edit, on further consideration, I think the last time I looked at these I decided they could be considered as independent events. But simulation not required anyway)
well, there you go. it took you all of 3 min to verify that my suspicions were correct. that sounds like Liquid centralization for exchanges.
here's another one:
yes, to sell information would be the commercialization i would be most worried about.
[doublepost=1465404158,1465403379][/doublepost]and for miners who can't afford to pay to access Falcon even if invited? tough luck. now that favors large miner centralization.
@Bloomie: Could we host the new Wiki that Tom Zander is trying to get going at wiki.bitco.in? He and I were just discussing the idea and I think it would be win-win.
(I've also sent you this same question by PM).
[doublepost=1465406396,1465405505][/doublepost]@Tomothy: In addition to what @sickpig said, Falcon also uses cut-through switching. I think these two diagrams explain quite well:
This is a lower-level change to the way the raw packets are processed. It is orthogonal to something like Xthin (e.g., Falcon could use Xthin).
I think this is interesting and important research.
(I've also sent you this same question by PM).
[doublepost=1465406396,1465405505][/doublepost]@Tomothy: In addition to what @sickpig said, Falcon also uses cut-through switching. I think these two diagrams explain quite well:
This is a lower-level change to the way the raw packets are processed. It is orthogonal to something like Xthin (e.g., Falcon could use Xthin).
I think this is interesting and important research.
jbreher
Active Member
- Dec 31, 2015
- 166
- 526
Absolute twaddle. At the time of activation, 25% of the miners have not publicly stated support for the move by means of running a suitable SW. This is not equivalent to opposition.
jbreher
Active Member
- Dec 31, 2015
- 166
- 526
Well, it's not 2x, it's 1.8x. And only if all nodes are SegWit nodes. And only if they decide to make all transactions SegWit. Does that sound like quibbling? I don't think so. Plus the little fact that an increase of 2x is seen by many (e.g., me) as the absolutely smallest increment acceptable 2Q13. Hell, 1Q13.
OK - those are goodness. Agreed.
It seems odd that anyone with an attitude of 'oh noes - 2MB is too big a change' would grant future developers such a blank check. No. This is a net negative.
Why would you spin a new class of non-validating node as 'flexibility'? It incentivizes nodes to not validate. That's counter to the ethos of node decentralization.
What!? The only way to operate in a trustless environment is to validate all transactions. In order to validate a transaction, one _requires_ not only the transactional part, but the witness part. And they must be correlated with each other. Separating them is _less_ logical. It provides some resource requirement reduction, but only for non-validating parties. And non-validating parties are worthless to network security.
Melbustus
Active Member
- Aug 28, 2015
- 237
- 884
What exactly are you proposing, then? Because the underlying mathematical nature of the system is *precisely* that a simple majority can change it. If one had to pick the *key* operational rule that enforces consensus, it's the "longest chain rule"; ie, the fact that miners *assume* everyone else is working off of the highest-PoW chain. This is what resolves forks (which happen several times a day with orphans), and enables the very idea of truly distributed consensus.
So are you proposing that Bitcoin's consensus algorithm be changed such that nodes do not follow the *longest* (>50% PoW) chain, but instead follow a chain using some other parameters? What parameters? Does humanity know how to do PoW consensus any other way?
I think you need to acknowledge that deep down, Bitcoin currently works in the way that you consider "totally useless". So either propose specific changes to the technical consensus alg (not various social norms, which is what you seem to mostly be discussing), or stop using a system you consider "totally useless".
jbreher
Active Member
- Dec 31, 2015
- 166
- 526
Your insistence in interminably invoking this ignorant incorrect inanity is causing me to lose all respect for the veracity and sincerity of your position.
it's worse than that; at least initially. b/c we know that initial implementations of SWSF require p2sh which, according to /u/johoe, gives us 1.57MB blocks, not 1.8MB. the reason that kore keeps touting 2MB, first Adam then Greg now jonny1000, is for appearances only. by saying 2MB, it gives the appearance of equivalency to those that don't know better. another favorite disingenuous tactic from kore gang that they persist on invoking despite being called out a zillion times by those in the know. maybe this emphasis on governance change is for good reason?
it can be thought of as being out of necessity b/c SW at it's kore (no pun intended) doesn't change the need for nodes and miners to transmit hefty additional loads of data across the network at a cost to them, not the policies they facilitate (think complex LN multisigs) nor the implementers of those policies (think kore dev). in the current flavor, anywhere up to 4MB.
[doublepost=1465413026][/doublepost]
thank you for highlighting this; i've been meaning to do this.
yes, the well known accepted example of how a fork is resolved in Bitcoin is instructive. namely, a 50:50 split in the network from blocks generated at opposite sides of the planet. these get resolved usually by the next block which normally will get generated by the at least 51% of hashrate out in the real world breaking the tie by working off one or the other chain. this is how Bitcoin works and certainly does NOT rely on extreme consensus.
basically we have a tie in the 2 camps of small vs large blockists in my mind despite the stats @jonny1000 cites. we need to resolve this fork. release an blocksize implementation that doesn't rely on signalling (to remove the cancer of politicking/bullying/censorship from the process) and let 51% of hashers choose. if we win, fine. if we lose, fine. the free market will have spoken.
[doublepost=1465413545,1465412588][/doublepost]to invoke a concept from @Zangelbert Bingledack separation of full nodes from mining pools as it applies to the signalling system we have today due to relative centralization; what we had in the past were individual miners who could immediately vote with their hashing power and choice of Bitcoin client implementation within the privacy of their home where they were insulated from an attacking, bullying, intimidating kore dev. which is what we have today as soon as a pool miner dares signal support for an alternate implementation within their blocks. this is typical of paranoid, threatened regimes that jump on even the slightest hint of opposition to their rule to squash out change.
[doublepost=1465414118][/doublepost]and let me repeat the obvious. the intimidation and character assasinations which emerge upon identification/signalling not only extend to mining pools; it extends to you, all of you who dare to express an alternative opinion on blocksize. i should know.
Last edited:
@cypherdoc @Melbustus
I believe this is why @jonny1000 is unhappy with this outcome. I think his Extreme Consensus solution is totally wrong, but the underlying concern is valid. Mining as "betting" no longer being available to most users as a tool during controversies, due to mining specialization, creates this situation where there is no working prediction market to let mining express market will in the manner Satoshi des. It must be reinstated or else controversy will cause havoc like we are witnessing as no real reliable information can be obtained.
@jonny1000's measures of Core support are highly flawed, but he is correct there is no sybil-resistant measures to look at; we need voting to cost something and offer big rewards for prescience. The mining/user gulf requires impeccably robust market data to remedy. If it isn't clear that this is the case with this blocksize debate, it will become clear in the future when the stakes are higher and much more complicated with far greater conflicts of interest and even more diabolical manipulation (if one can imagine that).
The 51% Nakamoto consensus is for converging on ledger state only, not block validity anymore since miners and users/nodes are no longer one and the same. Actually, 51% never was to be the sole deciding factor during controversy since forking away into separate chains is always possible. In the present day block validity is determined by both mining and noding, with miners forced to guess what nodes will relay, resulting in an uncomfortable "risk an orphan to see what happens," "no you go first" dynamic. At worst it could result in a needless split if miners guess completely wrong. Necessary splits enhance Bitcoin's value, but needless splits damage the value. I think any split that wouldn't have otherwise happened with accurate market information is a needless split.
In summary, 51% is used for ledger state, but if you try to use it for block validity as well you risk a split if miners are too out of sync with the market. Sometimes a split will be good, but not when it could have easily been avoided. 75% may be enough, but since miners don't have special knowledge of the market it is still quite conceivable they could get it totally wrong. Heck even with 95%. The solution isn't to increase the threshold to such high percentages, but to ensure miners have reliable market data and a merely reasonable threshold 66% or 75% then sounds good to me, but more likely just a flag day would work as the market price of the losing side of the fork should be zero before it ever has a chance to happen.
Much of @jonny1000's seemingly outlandish arguments are reactions to the same underlying problem I see, just with a solution I find completely unviable. However, I think we both agree that a prediction market would solve the problem.
The miners will have spoken - about something outside their field of knowledge. Only if they have reliable information about what the free market wants can they faithfully express it by proxy.
I believe this is why @jonny1000 is unhappy with this outcome. I think his Extreme Consensus solution is totally wrong, but the underlying concern is valid. Mining as "betting" no longer being available to most users as a tool during controversies, due to mining specialization, creates this situation where there is no working prediction market to let mining express market will in the manner Satoshi des. It must be reinstated or else controversy will cause havoc like we are witnessing as no real reliable information can be obtained.
@jonny1000's measures of Core support are highly flawed, but he is correct there is no sybil-resistant measures to look at; we need voting to cost something and offer big rewards for prescience. The mining/user gulf requires impeccably robust market data to remedy. If it isn't clear that this is the case with this blocksize debate, it will become clear in the future when the stakes are higher and much more complicated with far greater conflicts of interest and even more diabolical manipulation (if one can imagine that).
The 51% Nakamoto consensus is for converging on ledger state only, not block validity anymore since miners and users/nodes are no longer one and the same. Actually, 51% never was to be the sole deciding factor during controversy since forking away into separate chains is always possible. In the present day block validity is determined by both mining and noding, with miners forced to guess what nodes will relay, resulting in an uncomfortable "risk an orphan to see what happens," "no you go first" dynamic. At worst it could result in a needless split if miners guess completely wrong. Necessary splits enhance Bitcoin's value, but needless splits damage the value. I think any split that wouldn't have otherwise happened with accurate market information is a needless split.
In summary, 51% is used for ledger state, but if you try to use it for block validity as well you risk a split if miners are too out of sync with the market. Sometimes a split will be good, but not when it could have easily been avoided. 75% may be enough, but since miners don't have special knowledge of the market it is still quite conceivable they could get it totally wrong. Heck even with 95%. The solution isn't to increase the threshold to such high percentages, but to ensure miners have reliable market data and a merely reasonable threshold 66% or 75% then sounds good to me, but more likely just a flag day would work as the market price of the losing side of the fork should be zero before it ever has a chance to happen.
Much of @jonny1000's seemingly outlandish arguments are reactions to the same underlying problem I see, just with a solution I find completely unviable. However, I think we both agree that a prediction market would solve the problem.
Last edited:
@Zangelbert Bingledack
"The miners will have spoken - about something outside their field of knowledge. Only if they have reliable information about what the free market wants can they faithfully express it by proxy."
i'm not sure we have time to build a futures mkt. that doesn't mean it shouldn't be tried and built asap, as i agree with you that it would be very useful info. you also may be a little too pessimistic on miner's knowledge. or maybe not. but i think it would be useful to give them an opportunity to just go for 2MB blocks immediately w/o the pressure of having to go thru the signalling process. imo, signalling is broken as it allows all sorts of pre-emptive manipulative machinations to occur.
"The miners will have spoken - about something outside their field of knowledge. Only if they have reliable information about what the free market wants can they faithfully express it by proxy."
i'm not sure we have time to build a futures mkt. that doesn't mean it shouldn't be tried and built asap, as i agree with you that it would be very useful info. you also may be a little too pessimistic on miner's knowledge. or maybe not. but i think it would be useful to give them an opportunity to just go for 2MB blocks immediately w/o the pressure of having to go thru the signalling process. imo, signalling is broken as it allows all sorts of pre-emptive manipulative machinations to occur.
@cypherdoc
If we don't have time, we'll have to muddle through. Per my analysis above, that means finding a makeshift way around the market data problem, or maybe just waiting for things to get bad enough that no one can wonder whether or not 2MB is better than 1MB anymore. Perhaps that is why things have already gotten as bad as they have. We are starved for good data, and all the data we have is heavily biased by laziness and other grossly asymmetric incentives.
One way around it is of course the "leap of faith" or the "try it and see if anyone forks away" approaches by the mining majority, which is sloppy but would likely be fine in the end if the increment is small like 2MB (certainly needlessly risky though).
The faster we can get a futures market up, the easier everything will be. But I imagine if the heads of Bitfinex, Bitstamp, Huobi, etc. were convinced they could offer futures contracts quite easily starting a few weeks from now, regulations permitting.
If we don't have time, we'll have to muddle through. Per my analysis above, that means finding a makeshift way around the market data problem, or maybe just waiting for things to get bad enough that no one can wonder whether or not 2MB is better than 1MB anymore. Perhaps that is why things have already gotten as bad as they have. We are starved for good data, and all the data we have is heavily biased by laziness and other grossly asymmetric incentives.
One way around it is of course the "leap of faith" or the "try it and see if anyone forks away" approaches by the mining majority, which is sloppy but would likely be fine in the end if the increment is small like 2MB (certainly needlessly risky though).
The faster we can get a futures market up, the easier everything will be. But I imagine if the heads of Bitfinex, Bitstamp, Huobi, etc. were convinced they could offer futures contracts quite easily starting a few weeks from now, regulations permitting.
Last edited:
@Zangelbert Bingledack
yeah, the CFTC's got their mitts in the fray: https://news.bitcoin.com/bitfinex-75k-us-fine/
yeah, the CFTC's got their mitts in the fray: https://news.bitcoin.com/bitfinex-75k-us-fine/
xhiggy
Active Member
- Mar 29, 2016
- 124
- 277
@jonny1000
The activation threshold is not a kind of 'vote' where miners indicate their preference, either for or against with their hashpower. It's set to activate IFF 75 of the last 100 blocks were mined by miners supporting classic. This means that it is NOT a guarantee that 25% of miners (by hashpower) are opposed to the changes of classic at the time of activation.
This could mean that 100% of the miners switched to classic, 75 blocks ago. In this case, at the time of activation everyone is on board, even though there is only "75% consensus" at the time of activation. Do you understand how this works?
This could also mean that 25% don't care either way and don't want to shoulder the cost of switching until they have to. This goes against your reasoning that 25% are AGAINST the switch at the time of activation. As there is a cost of switching, it's reasonable that some won't want to until they have to, unlike core's consensus where everyone has to switch, in advance, to a rule change that might not happen. It screws over small miners and increases centralization.
You are also assuming the choices are Core V Classic, what if the 25% who aren't running classic are running alternative versions that would support classic as a reasonable second choice behind their preference, say BU or something.
Now we get to your situation, where the 25% are actually OPPOSED to the switch, not just airing on the side of caution and cost savings, not caring either way, or running a non core competitor to classic. If 25% of miners WILL NOT ever run classic, line in the sand, then they should fork away and start their own chain that can never fork, 100% consensus only. 25% is a significant amount of hash power and it's unlikely the classic side would divert their hashing to disrupt that chain. If this is evident as the 28 grace period counts down, plans can be made for a safe hard fork that allows each miner to operate the cryptocurrency they want.
Your argument, your bolded, underlined FACT, is just one of three interpretations. In my opinion, it's the least likely to take place. The only reason you interpret it this way is because it allows bitcoin to hard fork, something that erodes the value of lightning network.
For the sake of all that is good, share what you are smoking with me.
[doublepost=1465421347][/doublepost]
Given you have no evidence, I can state with equal validity that I see voluntary decision to use 75% as a sign of respect to the users and indication of respecting the network and desire to keep everything robust. Are you convinced that 75% is good now? No? Now you know how I feel.
This is not true, friend, let me try to explain why this is not a fact, but your self serving interpretation only.
The activation threshold is not a kind of 'vote' where miners indicate their preference, either for or against with their hashpower. It's set to activate IFF 75 of the last 100 blocks were mined by miners supporting classic. This means that it is NOT a guarantee that 25% of miners (by hashpower) are opposed to the changes of classic at the time of activation.
This could mean that 100% of the miners switched to classic, 75 blocks ago. In this case, at the time of activation everyone is on board, even though there is only "75% consensus" at the time of activation. Do you understand how this works?
This could also mean that 25% don't care either way and don't want to shoulder the cost of switching until they have to. This goes against your reasoning that 25% are AGAINST the switch at the time of activation. As there is a cost of switching, it's reasonable that some won't want to until they have to, unlike core's consensus where everyone has to switch, in advance, to a rule change that might not happen. It screws over small miners and increases centralization.
You are also assuming the choices are Core V Classic, what if the 25% who aren't running classic are running alternative versions that would support classic as a reasonable second choice behind their preference, say BU or something.
Now we get to your situation, where the 25% are actually OPPOSED to the switch, not just airing on the side of caution and cost savings, not caring either way, or running a non core competitor to classic. If 25% of miners WILL NOT ever run classic, line in the sand, then they should fork away and start their own chain that can never fork, 100% consensus only. 25% is a significant amount of hash power and it's unlikely the classic side would divert their hashing to disrupt that chain. If this is evident as the 28 grace period counts down, plans can be made for a safe hard fork that allows each miner to operate the cryptocurrency they want.
Your argument, your bolded, underlined FACT, is just one of three interpretations. In my opinion, it's the least likely to take place. The only reason you interpret it this way is because it allows bitcoin to hard fork, something that erodes the value of lightning network.
For the sake of all that is good, share what you are smoking with me.
[doublepost=1465421347][/doublepost]
This is BS not rooted to anything tangible in anyway. Respect? Robust? WTF do these things mean? They seem like personal sentiments.
Given you have no evidence, I can state with equal validity that I see voluntary decision to use 75% as a sign of respect to the users and indication of respecting the network and desire to keep everything robust. Are you convinced that 75% is good now? No? Now you know how I feel.
