Gold collapsing. Bitcoin UP.

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@Richy_T

no, the 4 has changed to a 2:

"(ie transactions + witness/2) is set to 1.5MB"

remember that it was arbitrary from the beginning.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
this part is a bit self serving on Corallo's part:

"Due to the several non-linear validation time issues in transaction
validation which are fixed by SegWit's signature-hashing changes, I
strongly believe any hard fork proposal which changes the block size
should rely on SegWit's existence."

note he doesn't mention anything about how SWHF discounts by 50% LN multisigs which are larger and could be more complex, again encouraging a move to LN. one thing i'm trying to track down is if 3 of 3 and 4 of 4 multisigs are a part of LN payment channels future? anyone?

also, this part we need to have someone like @Gavin Andresen evaluate to see whether or not these sigop limits are too excessive or strangling to regular tx's that some ppl might still want to use. i'd like to know if they unfairly advantage the SW tx's:

2) In order to prevent significant blowups in the cost to validate
pessimistic blocks, we must place additional limits on the size of many
non-segwit transactions. scriptPubKeys are now limited to 100 bytes in
size and may not contain OP_CODESEPARATOR, scriptSigs must be push-only
(ie no non-push opcodes), and transactions are only allowed to contain
up to 20 non-segwit inputs.
Together these limits limit
total-bytes-hashed in block validation to under 200MB without any
possibility of making existing outputs unspendable and without adding
additional per-block limits which make transaction-selection-for-mining
difficult in the face of attacks or non-standard transactions. Though
200MB of hashing (roughly 2 seconds of hash-time on my high-end
workstation) is pretty strongly centralizing, limiting transactions to
fewer than 20 inputs seems arbitrarily low.

Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from
1-per-50-bytes
across the entire block to a per-transaction limit which
is slightly looser (though not too much looser - even with libsecp256k1
1-per-50-bytes represents 2 seconds of single-threaded validation in
just sigops on my high-end workstation).
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
so last week we get Peter Todd throwing that bomb about partitioning risks with SWSF.

today @BlueMatt throws out another bomb, the SWHF.

trouble in SegWit-Land?
 
  • Like
Reactions: majamalu

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
@Richy_T

no, the 4 has changed to a 2:

"(ie transactions + witness/2) is set to 1.5MB"

remember that it was arbitrary from the beginning.

All done with much consultation and discussion with the stakeholders. Which is why it is the first time I've heard of it. :/

Actually, that doesn't make any sense (but what does?) since the idea was to leave the block size limit at 1mb but grow the blocksize through accounting trickery. By that logic, you can change the factor but not the 1mb part.

Oh wait, that's a HARD FORK proposal. In which case, there's no need for such fuckery. You can set an overall block size limit or a limit for the UTXO part and a separate limit for the segwit part and then handle the prioritization accounting with a formula CHOSEN BY THE MINERS.

This is part of why such a fucked up hack was a bad idea in the first place. Now people are trying to follow the form of the fucked up hack when trying to do things the right way.

A byte is a byte. Count it properly.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
new poll above. please vote.
 

tynwald

Member
Dec 8, 2015
69
176
"You do not have permission to view this page or perform this action." - Though I seem to be logged in.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
my bet is that core dev has gotten some bad news from miners re: support or lack thereof for SWSF
 

Bloomie

Administrator
Staff member
Aug 19, 2015
510
803
All, if you're having a forum-specific issue, please report it by either starting a new thread in the Meta section or by PM'ing me.

@tynwald When exactly did you encounter the message, and has it happened more than once?
 

rocks

Active Member
Sep 24, 2015
586
2,284
my bet is that core dev has gotten some bad news from miners re: support or lack thereof for SWSF
Miners are getting a good hard look at their options.

On one hand you have classic, the code changes are minimal and easy to understand. That vast majority of line changes was code related to regression testing that Gavin put in to cover every possible code branch.

On the other hand you have SFSW. The code changes are massive in comparison and change fundamental data structures and consensus code. Any miner running their own version will have a difficult time patching their modifications into 0.12. On top of this there is little testing of SFSW available despite the fact it changes so much more.

On top of this: a) 0.12 includes RBF which almost all miners have come out against, I think the only reason core added the option to turn it off was because so many miners balked at it (this is called listening to your users according to core), and b) the adoption rates for 0.12 are horrible compared to classic so far, classic is gaining nodes the way a new release of core used to. This is telling

Which would you choose?

If I was a miner or pool operator I would be seriously questioning the competency of the 0.12 team. SFSW is a roll out worthy of a grad student project.
 
Last edited:

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
The whole idea that we need to concoct schemes to reduce UTXO is completely wrongheaded. Similar to block size, UTXO is a valuable resource that has benefits as well as costs. UTXO is the Ledger of bitcoin balances, and the more Bitcoin is adopted, the larger UTXO will need to grow.

The balance of how large the UTXO set grows should not be manipulated. The people who benefit from UTXO entries, and pay for the resources, should make those decisions. If there are "externalities" or mismatches between the parties who benefit, and those who expend resources on it, then market mechanisms can and will be developed to balance the costs and benefits.

It is a mistake to constantly focus on minimizing costs and resource use, while ignoring the potential upsides of growth. It reveals a small-mindedness and lack of imagination.

We should be planning for massive growth, and preparing to maximize the upside from this growth. Yes, it is good to be concerned about potential problems and work on solutions to mitigate growing pains. But let's be optimistic! Growth is good, Bitcoin is succeeding, and the future is bright!
 

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
Matt Corallo's just proposed SegWit hard fork on btc dev ml

[bitcoin-dev] On Hardforks in the Context of SegWit


edit:
not a real SegWit HF.

After reading more carefully (not too much since I've developed some kind of allergic reaction to BS doublespeak) it seems to me that the proposal is a mix of classical, no pun intended, BS non sense (SegWit HF only after a SegWit SF(?) with a 1 year(!) grace period for the former). Corallo is a master of this art, second only to Maxwell.
Waltzing Mattilda

So they gave me a tin hat and they gave me a gun
And they sent me away to the war

And the band played Waltzing Mattilda

 

YarkoL

Active Member
Dec 18, 2015
176
258
Tuusula
yarkol.github.io
@sickpig

I don't understand this part about op_return. The witness part is currently in the coinbase correct? :

"Move SegWit's generic commitments from an OP_RETURN output to a
second branch in the merkle tree."
I'm not 100% sure of this interpretation, but I think it means that instead of the current design, where the segwit data merkle root is being referenced in special OP_RETURN output in the coinbase tx, he is proposing that the segwit merkle root is to be attached as a second branch (extending from the root) in the standard merkle tree (referenced in block header). Apparently there are some efficiency gains in this.
Gavin A. suggested something very similar here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011920.html
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
Yes, that part is obvious. He is proposing to give the new witness merklle root its own separate place in the header which is cleaner and requires a HF. But I've never heard of op_return being used in the current SF design. It was always just a merklle root insertion in the coinbase.
 

albin

Active Member
Nov 8, 2015
931
4,008
@Mengerian

One aspect to the utxo that I've been kicking around in my head for a while now is the relationship between tx fees, bitcoin valuation, and set size. It seems like alot of perverse things could happen under a forced fee market wrt to maintaining utxo bloat by essentially stranding outputs as economically infeasible to spend. Massive waves of price appreciation (and concurrent drops in tx fees in nominal terms) seem like a natural mechanism to counter this, assuming tx volumes are not intentionally pegged at capacity. This is something Mike Hearn has gotten heavily attacked for well after the fact, but cutting the default min relay fee after the fall 2013 rally probably had really positive effects.

For example, I bet that there are quite a few small hobbyist pool miners from late 2013 / early 2014 who maybe played around with very modest setups of a few GH/s with Block Erupters and such who weren't very saavy about it, somewhere got the impression that they should be paranoid about leaving any balance at all on a pool, so they have a tremendous number of tiny outputs to the same address. I have a friend who's exactly in that boat, sitting on a bunch of 0.01 outputs from BTCGuild.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
"still in design"

Goddammit, I keep hearing this from core dev yet at the same time they've been holding up a simple block size increase to deal with all the high fees and delays. @Peter R graph has been projecting these problems for almost a year now yet these irresponsible idiots have been playing around setting up their corporate payout structures and doing dog and pony shows to "feed themselves" for the next 20y.
[doublepost=1455010744][/doublepost]
@cypherdoc
I guess the final design hasn't been finalized yet... You could have the segwit merkle hash in the message field in the coinbase, but that already is reserved for extranonce, so OP_RETURN would make sense.
Don't forget this insertion into the coinbase has been touted with much fanfare crediting Luke for an incredible insight worthy of a Nobel Prize in software development. He's been since strutting his stuff around reddit with all sorts of crazy economic ideas.
 
Last edited:

YarkoL

Active Member
Dec 18, 2015
176
258
Tuusula
yarkol.github.io
I like to keep the technological and personality issues separate. Indeed, I'm thoroughly disgusted with the "civil war"; I tend to view all this as an intensed debate between two differing schools of what I call "crypto-economics" for lack of better term.
 
  • Like
Reactions: AdrianX

tynwald

Member
Dec 8, 2015
69
176
"still in design"

Goddammit, I keep hearing this from core dev yet at the same time they've been holding up a simple block size increase to deal with all the high fees and delays..
Some of them act like they are coding superstars, yet the designs seems "hacked" and without concern for the technical debt being piled on.
[doublepost=1455024178][/doublepost]
All, if you're having a forum-specific issue, please report it by either starting a new thread in the Meta section or by PM'ing me.

@tynwald When exactly did you encounter the message, and has it happened more than once?
saw the message after I voted, happened when I backed up and tried again. Now I can see poll results and no option to vote.