Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
I'm ready for the fork away from Block stream Core to happen so that we can get on with life.
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).
"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).
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
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:
"You do not have permission to view this page or perform this action." - Though I seem to be logged in.
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:
- 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!
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
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
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
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.
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:
YarkoL
Active Member
@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.
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.
"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]
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]
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
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]
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.
Latest threads
-
HIRE TREK Tech Corp Today: A Story of Financial Recovery
- lynettegregory262
- 0 replies
-
-
Members online
No members online now.