Gold collapsing. Bitcoin UP. [NooNooPol]

[TPTB_need_war]

There is a reason they didn't let the Silkroad sites establish a following. Because once knowledge age capitalists taste freedom to profit and innovate, they don't stop innovating new ways to achieve it.

Once you build an ecosystem around true anonymity, the bastards can never put the cat back in the bag.

[1713277329]

1713277329

[1713277329]

1713277329

[1713277329]

1713277329

[1713277329]

1713277329

[TPTB_need_war]

Notice the gradual effort to turn Bitcoin into NWOcoin. They can't be too overt. They will go overt against a supreme threat to hegemony such as anonymous drug markets on Tor hidden servers.

So any counter-effort must be sufficiently disguised as a lower-level threat initially. And there must be a plan to enable a "force-field" protection before going to the overt threat stage.

That "force field" can entirely nullify DDoS, Sybil attacks and even make it impossible to find the nodes involved. So then when the protocol is encrypted and the "force field" is on, the bastards are toast.

[Adrian-x]

It's not an Alt. And won't survive as one.

[tvbcof]

It's not an Alt. And won't survive as one.

Every incompatible protocol difference is an 'alternative'.  This includes the so-called 'core'.  If something doesn't survive it loses the 'alt' label.

[Adrian-x]

It's not an Alt. And won't survive as one.

Every incompatible protocol difference is an 'alternative'.  This includes the so-called 'core'.  If something doesn't survive it loses the 'alt' label.

I like the origin Bitcoin principles embodied in my preferred alt master Blockchain.  
i cant change my vote this time is that by design?

[tvbcof]

It's not an Alt. And won't survive as one.

Every incompatible protocol difference is an 'alternative'.  This includes the so-called 'core'.  If something doesn't survive it loses the 'alt' label.

I like the origin Bitcoin principles embodied in my preferred alt master Blockchain.  
i cant change my vote this time is that by design?

I was going to say 'my bad', but it seems that I can no longer select the updatable radio button.  Perhaps since I change the poll text to match cypherdoc's new one (with my own propagandist spin of course.)

[cypherdoc]

If you assume that, then just stop now and shoot yourself. Game over. We will sink into a Dark Age and everything will be expropriated.

I assume mankind wants to fight when given the tools to do so.

Bingo!

The system the bastards rely on doesn't run without the knowledge capitalists. We run their system.

If even a few % of us start working on an ecosystem of solutions, they are toast.

They must obscure any takedown as DDoS or hackers, because if they simply filter data on the internet backbones, this will be a clear signal to the hackers that we've entered a war of totalitarianism. If they overtly declare war on hackerdom, they will lose and they know it.

So instead it will be proxy battle.

you know, you two should just move here and stay here.  then you can circle jerk one another.

you were made for each other.

[Natalia_AnatolioPAMM]

I wish you had added an option for "support block size increase but only by consensus BIP". Many of the yes votes are conflated into that.

good point. i would vote for that one for sure

[tvbcof]

If you assume that, then just stop now and shoot yourself. Game over. We will sink into a Dark Age and everything will be expropriated.

I assume mankind wants to fight when given the tools to do so.

Bingo!
...

you know, you two should just move here and stay here.  then you can circle jerk one another.

you were made for each other.

What, and leave you all alone on your gold thread to continue to display your years long man-crush on Mike and Gavin?

[tvbcof]

Checkpoint update (Tue Jun 23 10:06:41 PDT 2015):

 - Cypherdorc:

Question:    Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes    64 (69.6%)
2.  no    28 (30.4%)
Total Voters: 92

 - Here:

Question:    Will you support switching Bitcoin over to Hearn's XT alt with it's exponential bloat by the first of the year 2016?
Fuck No!    9 (39.1%)
Hell Yeah!    14 (60.9%)
Total Voters: 23

[tvbcof]

Cypherdoc's poll seems to have gotten a recent infusion of  interest on the XT side of things not reflected in mine.  Just a bump to remind the interested to make 'their' thoughts known as widely as possible.

[Peter R]

Checkpoint update (Tue Jun 23 10:06:41 PDT 2015):

 - Cypherdorc:

Question:    Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes    64 (69.6%)
2.  no    28 (30.4%)
Total Voters: 92

 - Here:

Question:    Will you support switching Bitcoin over to Hearn's XT alt with it's exponential bloat by the first of the year 2016?
Fuck No!    9 (39.1%)
Hell Yeah!    14 (60.9%)
Total Voters: 23

If you had used the exact same wording as Cypherdoc, this would have actually been an interesting experiment.  Would the polls have had statistically-significant differences?

[cypherdoc]

Checkpoint update (Tue Jun 23 10:06:41 PDT 2015):

 - Cypherdorc:

Question:    Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes    64 (69.6%)
2.  no    28 (30.4%)
Total Voters: 92

 - Here:

Question:    Will you support switching Bitcoin over to Hearn's XT alt with it's exponential bloat by the first of the year 2016?
Fuck No!    9 (39.1%)
Hell Yeah!    14 (60.9%)
Total Voters: 23

If you had used the exact same wording as Cypherdoc, this would have actually been an interesting experiment.  Would the polls have had statistically-significant differences?

With that wording, you don't seriously think he's interested in running an experiment here do you?

[tvbcof]

If you had used the exact same wording as Cypherdoc, this would have actually been an interesting experiment.  Would the polls have had statistically-significant differences?

With that wording, you don't seriously think he's interested in running an experiment here do you?

Could be more of a 'probe' or even a 'honeypot'.  Hard to know.

[Natalia_AnatolioPAMM]

If you had used the exact same wording as Cypherdoc, this would have actually been an interesting experiment.  Would the polls have had statistically-significant differences?

With that wording, you don't seriously think he's interested in running an experiment here do you?

Could be more of a 'probe' or even a 'honeypot'.  Hard to know.

I'd say more of a probe

[TPTB_need_war]

Cypherdoc's poll seems to have gotten a recent infusion of  interest on the XT side of things not reflected in mine.  Just a bump to remind the interested to make 'their' thoughts known as widely as possible.

I notice it correlated with when I wasn't posting, and then as soon as I posted, the poll went back our direction.

Clearly politics is battle of filibuster, because the minds of the voters are malleable.

[TPTB_need_war]

Cypherdorc (blew a fuse and) locked his thread, so we must continue the discussion over here...

Edit: I can't find anything in the Blockstream whitepaper to support tvbcof's claim that one can recover their assets from an attacked chain. The closest is section 4.2 Fraudulent transfers, but the only really viable action there is to dilute everyone's BTC by the amount of the stolen coins.

Who is going to do that, some administrator? A bankruptcy trustee? No.

The best that could be achieved would be to build in some sort of rules like that into the scripts. No concrete method for doing that is proposed, but even if it were, it couldn't possibly handle all possible failures, since some if not all failures are by definition unanticipated. In the event that the state of a side chain were scrambled, there would just be no way to know who should be able to redeem.

For this reason, even the hint (or in some cases merely a rumor) of a problem on a side chain will lead to a run-on-the-bank scenario.

The movement of coin assets from one chain to other can't realistically be done piecemeal at a moment's notice via the SPV (as you point out far too much risk to allow that), instead atomic swaps should be used.

The SPV proofs should only be used for those willing to accede to very long contest period, say 30 days or so.

Speculators are not going to do this for free. Thus rapidly moving assets between side chains is going to be lossy, i.e. you won't get 1 BTC for the 1 BTC you swapped (when demand exceeds supply) but going the other direction you will get more than 1 BTC (when supply exceeds demand) unless of course you accede to the long contest period.

Side chains which enforce a longer minimum contest period will have more lossy atomic swaps, but gain confidence.

I am going to notify Adam and Gregory that they need to be more realistic and incorporate this into their whitepaper.

Edit: reorganizations can also impact atomic swaps, but the losses are localized to only the parties to the swap, thus no run on the coin in general. Swap participants should set timelocks with duration appropriate to the risks they want to take.

[TPTB_need_war]

the way it would need to happen in normal circumstances is for the scBTC to be mined back to BTC, by reversing the proof, most likely via merge mining.  since the most common cause of a failure is likely to come from a 51% of the SC since it is inherently less secure (<100% MM'd) by definition being able to get mined back is not going to happen.  after all, that would be the purpose for the attack; to kill off everyone's scBTC while simultaneously shorting scBTC on an exchange while going long BTC on the MC.

that would be a fun attack.

Then it won't happen with my consensus design for PoW because my design can't be 51% attacked. All such attacks are filtered out by a clever aspect of the design and this proof of filtering could in theory be incorporated into an SPV.

Checkmate dorc.

[Adrian-x]

I wish you had added an option for "support block size increase but only by consensus BIP". Many of the yes votes are conflated into that.

good point. i would vote for that one for sure

TPTB this is saying you would only vote yes if it were centrally controlled by gate keepers!

[tvbcof]

I wish you had added an option for "support block size increase but only by consensus BIP". Many of the yes votes are conflated into that.

good point. i would vote for that one for sure

TPTB this is saying you would only vote yes if it were centrally controlled by gate keepers!

6 months from now is not compatible with the BIP process, development, testing, etc.  Hearn is completely aware of this and had dropped all pretenses of 'consensus' in lobbying for a 'benevolent dictator' codebase management framework for Bitcoin.

Thus, as it stands, I believe my choices are a fairly accurate reflection of the realistic options which map to the real world.

I'll try to update my poll in conjunction with cypherdoc's going forward.  This one was put together without much time for thought but I'll try to be more a bit more thoughtful on the next one.