Gold collapsing. Bitcoin UP.

go1111111

Active Member
No, there is a massive difference on how the transactions are handled by non-upgraded clients (and miners): with current bitcoin rules you can't rob funds from people because a miner is not able to forge the signature of a user and hence create a viable transaction that gets accepted from an old client.
There is a difference in what non-upgraded nodes will see, but we're talking about actual stolen funds. As in, will miners actually be able to spends the funds on the dominant chain? If the economic majority is behind SegWit, then no amount of hashpower will be able to "steal" the funds on the chain that the economic majority cares about.

The original quote was misleading because it assumed the economic majority would stop caring about SegWit if miners 51% attacked the chain, just because non-upgraded nodes would see the spends as valid.

On the other hand, with segwit, a coalition of bad miners just have to not enforce segwit and collect the funds sent via anyone can spend transaction: the old nodes will accept it just fine.
The old nodes will see it as accepted, but their funds on the dominant chain won't actually be gone, assuming the economic majority is behind segwit. These users just need to upgrade their wallets and they'll see that their funds haven't been stolen on the chain that the economy cares about.

As a practical matter, this issue is politicized enough that a no-SegWit chain will probably survive in some form, and it will probably have some small value, so users may want to take some action to keep the coins they have on a minority non-SegWit chain.
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@Richy_T (@Norway): Yep. I think I figured out his new nick on /r/btc as well. @cypherdoc, take notice, your style is likely too unique to hide in this space ...

That said, I feel there's no reason to air details about my strong suspicion on what his new nick is publicly. He likely has good reasons to use a new nick.
[doublepost=1495796591][/doublepost]@freetrader: Indeed. I can however imagine that miners might want to be somewhat more sluggish with lifting the limit, to help them do some fee extraction :)

Inching along the line of extracting some fees but not killing competition or growth, like it is clearly happening now.

I imagine blocksize adjusting by 'miner cartel' so that fees are ~5ct or so.

The idea that miners will go and cause a tragedy of the commons situation of run-away very low fees (which due to @Peter R.'s arguments is impossible to happen - at least anytime soon - anyways) is proven empirically wrong by the time it still takes to lift the 1MB limit ...

I also sometimes ponder whether, if one likes algorithmic decisions long term, BIP100 with exactly a 50% limit would make most sense. As it would be closely matching Nakamoto consensus, without any further 'gentleman's agreement on not orphaning each other's blocks'. A perpetual 50% cartel with changing constituency.

Basically 50% decide the blocksize through the BIP100 proposal, and you have a 5%/2weeks growth cap to make the blocksize-scared folks happy.

For some weird reason, I am also more and more optimistic that the limit will go away soon. The palatable weakness and desperation ("Emergency") in actions like this:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014419.html

is an indication, IMO.
 
Last edited:

Dusty

Active Member
Mar 14, 2016
362
1,172
The old nodes will see it as accepted, but their funds on the dominant chain won't actually be gone, assuming the economic majority is behind segwit. These users just need to upgrade their wallets and they'll see that their funds haven't been stolen on the chain that the economy cares about.
I know, but we were talking about differences between normal transactions and segwit ones.
In this respect there are scenarios (however borderlines they are) where funds can be stolen by the miners, while with "normal" bitcoin transactions, not.

As a practical matter, this issue is politicized enough that a no-SegWit chain will probably survive in some form, and it will probably have some small value, so users may want to take some action to keep the coins they have on a minority non-SegWit chain.
More than that, while most of txs in non-segwit chain can be replayed safely on the segwit chain, there are segwit txs that if (when) replayed on the non-segwit chain allows the miners to claim all the transferred funds.

This can give an advantage in non-segwit chain because the users will know that using a segwit transaction they will lose the control of their coins on the other chain...
 

go1111111

Active Member
I know, but we were talking about differences between normal transactions and segwit ones.
In this respect there are scenarios (however borderlines they are) where funds can be stolen by the miners, while with "normal" bitcoin transactions, not.
There are situations where normal Bitcoin funds can be stolen by miners, if you make assumptions similar to the ones needed for claiming that SegWit funds will be stolen. The difference is that if normal funds are stolen, users need to "upgrade" their wallets to see the chain on which the funds are stolen. In the segwit case, users don't need to upgrade.

I say they're similar because for fund stealing in the segwit case, users have to essentially not care about the rules of segwit, if 51% of miners don't care. A similar assumption is that users wouldn't care about current Bitcoin rules, if 51% of miners didn't care about them. If users didn't care about those rules, then upgrading to a wallet where normal spending rules were relaxed isn't completely far fetched.

There is a difference between the two scenarios, but it's one of degree. We're quite sure users won't start viewing it as acceptable to steal regular funds. We're less sure how they'll feel about segwit rules. In either case, the funds are protected to the degree that people care about the rules though. The issue of whether users need to upgrade or not is less fundamental than the issue of which rules users care about.
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
Not that age matters, but all looked to be in their twenties, which is something I've noticed before: the mean age of a small blocker is less than that of a big blocker.
I see a lot of other people here have quoted you on this, and I have to do it too. This fact struck me at the Scaling Bitcoin conference in Milan. There were so many pretty young baby faces at the main conference. Some were even wearing the free T-shirts with the word "ACK" on the chest. YES-boys.

But at the almost illegal free speech event, "Hard Fork Café", the kids were gone. Grey hair, wrinkles & true grit was the style. (Except for Jihan and Haipo, lol.)

It's a reason 18-22 year old guys are soldiers and cannon fodder. It's not just because they are physically strong. They are also very easy to motivate against their own interests (which they are not very aware of.) Take a bullet for your buddy!

It's time for the mature men to clean up this mess ;)
[doublepost=1495846878][/doublepost]BTW, I got in touch with @cypherdoc , but he can't come to the special "Gold collapsing, Bitcoin UP!" event I am organizing on wednesday 28th of june in Arnhem.

Relax, guys! I'll give you more info on this, very soon!
 

albin

Active Member
Nov 8, 2015
931
4,008
Total speculation here, but I get the distinct impression that the goal of the crusade against SPV is to make mobile wallets full nodes in blocks-only mode with aggressive pruning. This is super feasible today even at much higher blocksizes (you don't get the p2p overhead of relaying tx's and you don't store full history), since the limiting factor here is .... wait for it ..... utxo set size.
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@albin: I don't understand in which sense an aggressively pruned node (or any pruned node) is a full node? Full node used to refer to those which stored the entire blockchain, has that definition altered or is there another sense to it?
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
I thought the distinguishing feature of Core's sense of "full node" was that they validate "all" the transactions, and pruning would just be keeping less of the full blockchain history (i.e., one year, rather than all the way back to genesis). So not "all" the tx in the sense of all the way back to genesis, but all in the sense of "not just my own tx" (i.e., not SPV).

Core not only has the wrong model of how Bitcoin actually works, they also want to transform it into that wrong model.

Core's model: "0-conf is insecure!"
Core's action: Implement RBF, which really makes it insecure

Core model: "SPV wallets don't work"
Core action: Undermine them further with Segwit

Core model: "Big blocks are burdensome"
Core action: Make increasing blocksize more burdensome with Segwit
Core possible next action: Get everyone to run a "full node" on their phone at all costs so that big blocks are nearly impossible
 
Last edited:

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
@majamalu sorry just forwarding the post, I wasn't involved. try jonald_fyookball on reddit or slack and if you haven't already, PM solex for an invite to the unlimited slack - unfortunately it's where lots of the conversation is happening these days.

@Zangelbert Bingledack Mmmmm..... I wonder where we've come across that philosophy before?

“When bitcoin first came out, I was on the cryptography mailing list. When it happened, I sort of laughed. Because I had already proven that decentralized consensus was impossible.”
proceeds to break bitcoin. :oops:

One of Maxwell’s roles at Blockstream is the creation of new talent to help drive bitcoin development. “The real problem is just expanding the base of people who can do this stuff,” he said.
Proceeds to make the code more complex, alienate everyone, and drive the new talent into alternate currency development. :confused:

The guy is contradiction personified.
 

jbreher

Active Member
Dec 31, 2015
166
526
@albin: I don't understand in which sense an aggressively pruned node (or any pruned node) is a full node? Full node used to refer to those which stored the entire blockchain, has that definition altered or is there another sense to it?
Yes, somewhere along the way, the lexicon has been coarsened. However, when Satoshi said 'node', he meant miner. I suggest we adopt the term 'fully-validating wallet' to make the distinction clear.
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
I've recently been using the term "archiver" or "blockchain archiver" for what Core calls "full nodes" (especially the unpruned ones), but let's examine the terms again more carefully to see if we can really iron things out.

First of all, the wallet functionality is separated out now in Core clients so their "full nodes" aren't necessarily wallets.

More importantly, there is (except under Segwit) in a sense no meaningful block validation other than mining itself: if your archiver "invalidates" a block (e.g., because blocksize was too big) and then the hashpower majority validates it by putting it into the most-PoW chain and mining several blocks on top of it, who are the real block validators here?

What the archivers do validation-wise is check *transactions* (ensuring that the sigs are valid and the outputs are not already spent). They cannot validate or invalidate *blocks* though, unless we are merely talking about identifying a block with an invalid tx.

In all other cases (which constitute the Bitcoin security expectation, except under Segwit where many miners might mine validationlessly as they wait for "delayed" witness data), their "invalidation" of the block can be overturned by a miner, making their block invalidation meaningless. Likewise their "validation" of a block could be overturned by a miner if the miner wants to follow more restrictive rules (or even technically for any reason or whim the miner wants), making their block validation meaningless as well.

So I think this brings me to an improved understanding, that "full nodes" are validators in the sense that they validate transactions, but not in the sense of validating blocks. Only miners validate blocks. These tx-checking archivers ("full nodes") can meaningfully invalidate a block only in the sense that they can check that a block contains an invalid tx, but notably - especially under Segwit - this doesn't always mean it won't become part of the longest chain and the miners won't doublespend the second-longest "all tx valid" chain into oblivion, a scenario where Bitcoin is broken of course, but the point is your "full valdiating node" cannot save you against a majority of hashpower that has run amok.

In other words, the only case where "full nodes" can be said to serve as block validators, for more than a couple comfirmations, is one where Bitcoin is broken anyway and they've merely alerted you to that a couple blocks earlier. After a couple of confirmations, the "advantage" your all-tx-checking archival wallet has over SPV wallets here is a Pyrric one: you simply learn the coins you just avoided being fooled into thinking you received are actually worthless anyway, even if you had received them properly, as all BTC have gone to zero.

Thus we might as well just call them general tx checkers, because clearly that checking can also tell you whether a block is a candidate to be accepted into the Bitcoin blockchain in terms of tx validity alone (except when Bitcoin is broken due to miner incentives being severely misaligned). Miners are the ones who actually vote on those candidates (and technically they could even vote on non-candidate invalid-tx-containing blocks if they wanted to destroy Bitcoin, backed by the power to doublespend the longest chain of only-valid-tx-containing blocks to death). And while Bitcoin is premised on miners not voting for blocks that contain invalid tx, it is NOT premised on miners only voting from among the blocks that "full nodes" consider valid for any *other* reason besides tx validity (this is the Core / small blocker misunderstanding).

Miners = block validators = nodes = block voters

Core "full nodes" = general tx-checking archivers (or all-tx-validating archivers if you like), with optional wallet attached

Pruned Core "full nodes" = general tx checkers (or general tx validators), with optional wallet attached

SPV wallets* = specific-tx-checking wallets (with enhanced SPV able to check deeper in the chain for the ancestry of those tx? - an idea @awemany has suggested)

*I think calling them "SPV nodes" kind of plays into Core's hands, in that they want everyone to see something other than miners as also being "nodes," as they view Bitcoin as something other than a mining (=block validating) network, so that they can pretend that their general tx checkers ("full nodes") have a say in governance by having some kind of meaningful vote on which blocks become part of the Bitcoin blockchain.
 
Last edited:

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
Juicy find by /u/jessquit that I think @cypherdoc will appreciate:

http://www.luxcapital.com/news/the-2-biggest-emerging-opportunities-in-cryptocurrency/

In this long-forgotten 2014 article, a Blockstream investor explains the pitch he received from Adam Back and Austin Hill as essentially "the stream cannot be unblocked, so let's divert it." Clearest statement on Blockstream's business plan I've yet seen, and comports fully with the idea that Core must "block the stream" to ensure Blockstream flourishes.
 

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
@awemany

I think this is the article you were hoping for, covers and expands on our recent chat.

https://medium.com/@adam_selene/segregated-witness-or-separated-legality-eefba390f95

Thanks Adam well written.

"Consequently, I can see no way for either miners, wallets, exchanges or other bitcoin providers to ever allow themselves to prune information associated with signatures. The idea of being able to do this and not breach financial services legislation within the US is at best opportunistic and at worse criminal. The tortious nature of claims against organisations failing to maintain this information can be easily foreseen."
Pretty sure there will be concerns in the UK and Commonwealth too.

"I am yet to investigate all the intricacies that are associated with segregated witness, particularly those of a deep technical depth. At this point I already have to express concerns, not with the technology but with the claims, I really fail to see the ability to save space. I see that anyone running a node could potentially be in breach of certain financial services legislation within the US that require the retention of documents. In the coming weeks I will investigate this further, but for the moment, I simply note that this is something to consider strongly.

I advise any organisation considering the adoption of the strategy to look deeply into the impact of removing a digital signature from a transaction.

Please note, this is not legal advice and I’m not your lawyer."
Looks like that 60% discount we were sold, might not be so easy to prune away afterall?

Those poor Segregated Wizards. :D
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
Thanks. SegWitters should address this, it is their uphill battle. They want to change the status quo - which is scaling Bitcoin on-chain, despite the current hiccup and bullshitting by a particular set of people.

Having said that, what I miss in this legal analysis angle is whether there's any legal difference between pruning spent transactions and pruning witness data, and why that is so.

But if witness data cannot be legally pruned in the U.S., that already means that the supposed 60% further space savings by SegWit pruning are unavailable - to legally operating businesses in the U.S.

Which then - even if the separating step doesn't do so much in terms of changing the legal landscape - means that there is still one reason less to go with this complex contraption rather than simple on-chain scaling.

Besides that, I have never seen a good and sound argument why pruning the witness data helps space-saving to begin with: I can only see that pruning witness data is a viable idea if a transaction is buried deeply enough in the chain. But then you could simply prune the whole transaction itself, as written in the whitepaper.