The following was quoted on and linked from reddit: If segwit were to be a hardfork? What would it be?
Would it change how transaction IDs were computed, like elements alpha did? Doing so is conceptually simpler and might save 20 lines of code in the implementation... But it's undeployable: even as a hardfork-- it would break all software, web wallets, thin wallets, lite wallets, hardware wallets, block explorers-- it would break them completely, along with all presigned nlocktime transactions, all transactions in flight. It would add more than 20 lines of code in having to handle the flag day. So while that design might be 'cleaner' conceptually the deployment would be so unclean as to be basically inconceivable. Functionally it would be no better, flexibility it would be no better. No one has proposed doing this.
Is the following suggestion a solution to that? The position of a transaction in the blockchain should define which version of the rules is applicable to it
What keeps us from using the old way of calculating a txid for transactions in prefork-blocks and the new way after the fork? ------ Also, Tyler Nolan has a similar suggestion: One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.
You could have a rule that you can refer to inputs using either txid or normalized-txid. That maintains backwards compatibility. The problem is that you need twice the lookup table size. You need to store both the txid to transaction lookup and the n-txid to transaction lookup. The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid. This means that each transaction only needs 1 lookup entry depending on its version number. If transaction 1 transactions cannot spend outputs from transaction 2 transactions, then the network will eventually update over time. It is still a hard-fork though. Is that applicable / workable? |
|
|
|
If/(when) segwit SF is abandoned/(postponed), a 2mb increase, in its simplest safe form, should be implemented. (no partisan additions)
Is that compromise?
That will buy time for a proper re-assessment for all in the Bitcoin space.
Abandon/postpone segwit sf? (How) do you think that could happen? |
|
|
|
I confirm, we've been waiting for some deliveries and setting up the bundle now in the eshop, it will go live within these days.
Can you give us any price estimation for those last twenty units? Will they be priced similarly to a normal Trezor, or go for the 3 BTC or so that molecular estimated the early ones sold for? I suspect it'll be the second option, but we can always hope.  Given these were given basically as a "thank you" for early supporters of the project, I sure hope they sell for a steep, steep premium above "normal" trezors. Tbh, I would auction them off to the highest bidders, really. |
|
|
|
... und Du gib Dich nicht für qwk aus!  Ach Mensch, Mario. Lass ihn doch. Wo bleibt eigentlich Greshams morgentliche News-Show? Oh, der ist wohl bettlägerig. Naja, dann gute Besserung! |
|
|
|
A strong malleability fix _requires_ segregation of signatures.
No, none of the alleged benefits of SegWit requires segregation of signatures: * Malleability could be fixed by just skipping the signatures (the same data that SegWit would segregate) when computing the txid. * GREATER bandwidth savings could be obtained by providing API/RPC calls that simple clients can use to fetch the data that they need from full nodes, sans the signatures etc. This enhancement would not even be a soft fork, and would let simple clients save bandwidth even when fetching legacy (non-SegWit) blocks and transactions. * Pruning signature data from old transactions can be done the same way. * Increasing the network capacity can be achieved by increasing the block size limit, of course. It seems to me many people have a problem with segwit because of the "hackish" softfork and/or because of the change of the economic model (2 classes of blockspace). If we did the points listed by JorgeStolfi above as a hardfork, would that be an option for the proponents of segwit? Seems to me such a hardfork could gain wide consensus, maybe wide enough to be considered safe by everyone? It would certainly appeal to the people who just want a simple blocksize increase and it should (I don't know, though) also satisfy the people who want segwit now. What would be missing compared to segwit? fraud proofs? change of economic model? Yeah, both hackish (although possibly beautiful code) and the economic model, if I understand that correctly. I don't think segwit could ever achieve HF consensus, my opinion. However if a winning hard fork was achieved, I would respect that. A soft fork is not right here, and could well be considered an attack. Why not 2mb first, which is on every partisan roadmap. Then segwit maybe. maybe not. (I am assuming 2mb is more easily coded than segwit, and not as complicated as segwit as was stated earlier. Although the ease of coding is only a small part of the reason segwit should not be introduced yet. certainly not introduced by core. a SF attack on nodes.) I didn't mean "do segwit as a hardfork", I meant do a hf that achieves the same things (more capacity, malleability fix, bandwidth savings, prune signatures from storage,...) just more -- let's say -- directly. A package with something for everybody but nothing too bad for anybody to swallow. A compromise. That's why I was asking wether the "change of economic model" (which would be missing from that package) was something core devs couldn't live without. So far I haven't seen this desirability in itself argued, seemed to me this was understood by everyone as just a side-effect of soft-forking higher capacity. |
|
|
|
@mezzomix, ich danke dir für deine Meinungen/Analysen bzgl. segwit.
Pfff. Ich geb mir solche Mühe und werd' im Regen stehen gelassen   peinlich peinlich, ich hab gedacht dein langer post sei von mezzomix. War schon sehr verblüfft und hatte mich gefreut über seine Meinungsänderung. Verdammt. Keine Ahnung wie ich da drauf kam, er hat ja nicht mal gepostet auf dieser Seite. Ich bitte um Vergebung! Post editiert. Danke qwk für deine Meinung / Analyse! |
|
|
|
A strong malleability fix _requires_ segregation of signatures.
No, none of the alleged benefits of SegWit requires segregation of signatures: * Malleability could be fixed by just skipping the signatures (the same data that SegWit would segregate) when computing the txid. * GREATER bandwidth savings could be obtained by providing API/RPC calls that simple clients can use to fetch the data that they need from full nodes, sans the signatures etc. This enhancement would not even be a soft fork, and would let simple clients save bandwidth even when fetching legacy (non-SegWit) blocks and transactions. * Pruning signature data from old transactions can be done the same way. * Increasing the network capacity can be achieved by increasing the block size limit, of course. It seems to me many people have a problem with segwit because of the "hackish" softfork and/or because of the change of the economic model (2 classes of blockspace). If we did the points listed by JorgeStolfi above as a hardfork, would that be an option for the proponents of segwit? Seems to me such a hardfork could gain wide consensus, maybe wide enough to be considered safe by everyone? It would certainly appeal to the people who just want a simple blocksize increase and it should (I don't know, though) also satisfy the people who want segwit now. What would be missing compared to segwit? fraud proofs? change of economic model? |
|
|
|
@mezzomix qwk, ich danke dir für deine Meinungen/Analysen bzgl. segwit. Manchmal muss man mich auf den Teppich zurückholen, ich werde leicht emotional bei dem Thema. Im Ether findet grade der erste richtige abverkauf statt  . endlich mal. Aber da geht noch was, noch ist's in etwa dasselbe Kaliber wie vor ~ 10 Tagen.  Die Linien sind eher willkürlich. Könnte mir aber vorstellen, daß es noch bis 0.02 (untere Linie) oder sogar 0.015 (vorletztes Hoch) runtergeht die Tage. Mehr glaub erstmal nicht. Was meint ihr? Auch notable: Bitcoin hat jetzt nicht soo viel zugelegt. Vielleicht ist einiges in fiat geflossen, das ist ja jetzt seit Montag durch bitfinex noch einfacher geworden. |
|
|
|
Danke qwk und molecular! Weil man die alten clients "verarscht". Ein teil der Blockchain (die neuen segwit transaktionen) kommen in einen 2ten Bereich, den die alten clients nicht sehen (und auch nicht verifizieren können). Im Prinzip könnte man sagen es wird eine 2te chain (sozusagen merge-mined) auf bitcoin draufgesetzt.
Was ich noch nicht ganz verstehe: Heißt das dann, dass die alten Clients die "Segwit-Transaktionen" gar nicht verarbeiten? Das würde ja bedeuten, Blöcke, die von alten Clients gemint werden, enthalten die Segwit-Transaktionen nicht. Könnte das nicht zu Problemen führen? Heißt dass dann vielleicht, dass Segwit produktiv erst dann genutzt werden kann, wenn schon die große Mehrheit der Clients umgestellt hat? Und wäre es nicht theoretisch möglich, einen zweiten Teil des Blocks auf ähnliche Weise mit "normalen" Transaktionen zu füllen? Die alten Clients würden dann jeweils max. 1 MB verarbeiten und den Rest ignorieren? Oder wäre das vom Aufwand schon vergleichbar mit Segwit und die Segwit-Lösung ist auf andere Weise den heutigen Transaktionen überlegen? Das sind 2 interessante Gedanken. Ich bin leider auch kein Experte was segwit angeht, das Ding hat viele Ecken und Kanten, leicht zu verstehen ist es nicht. Zu deinem ersten Gedanken "mining mit alten clients". Ich glaub du kannst auf jeden Fall die alten (nicht-segwit)-Transktionen minen und einen überall gültigen Block herstellen. Was ich auch nicht verstehe: für den "alten" miner sehen die segwit-transaktionen wie "ANYONECANSPEND" aus. Wenn das bedeutet was es heisst (was glaube ich so ist), dann könnte der Miner theoretisch transaktionen minen, die diese outputs ausgeben, ohne dazu passende segregierte Signaturen. Für die neuen miner wäre der block dann "invalid". An diesem Punkt verstehe ich dann nicht mehr, wieso das kein hardfork sein soll, da offensichtlich neue Regeln hinzukamen, die bestimmte 'alte Blöcke' invalidieren. Das ist die Definition von hardfork. Also hier leider nur ein großes Fragezeichen von mir. Weiss es jemand anderes? Zum zweiten Punkt "2te gleichartige merge-mined chain mit kompatiblen token" (wobei ich nicht weiss, ob der merge-mined Begriff hier passt, könnte aber sein). Hmm, vielleicht hast du hier grad eine "elegante" Lösung gefunden einen relativ simplen (simpler als segwit) Blocksize increase zu soft-forken. Bloss blöd (aber das ist glaub bei segwit auch so): die user müssen mit 2 verschiedenartigen Coin-Klassen klar kommen. Neuen und alten. Die neuen wären wahrscheinich billiger zu transaktionieren und würden sich evtl. schnell durchsetzen. Irgendwie denk ich grad: "Ist segwit etwa soetwas wie eine verkleidete merged-mined side-chain?". Ich weiss auch nicht: 1 MB -> 2 MB soll man Jahrelang testen und nicht überstürzen weil gefährlicher hardfork, aber so ein dickes Ding wie segwit wird dann eben mal unwiederbringlich rein-gesoftforkt (wieso ist das besser, es müssen irgendwann auch alle upgraden) ohne daß die Funktionsweise und/oder Implikationen von den meisten überhaupt verstanden werden. Begründung: es löst viele Probleme (wessen Probleme?), wir können in Zukunft einfacher Änderungen durchführen ohne euer zutun und wir wissen einfach am besten was gut ist (für wen?). Also vertraut uns, wir sind Experten. Nicht sehr bitcoin-like, oder? Und wie zum Geier erklär ich das alles einem potentiellen Newcomer? Wie soll der (oder ich) jemals dieser Technik vertrauen die keiner mehr versteht? |
|
|
|
aber was soll nun scrypt bringen? das gleich problem, riesen miningfarmen.. dann doch gleich neoscrypt ein PC ein miner
scrypt- variante: 2) Changing the POW is meant to create a risk to the miner community. If a new-POW branch starts to gain traction, hopefully that will motivate more to increase the block size, rather than to keep blocks artificially small and risk a different branch taking over.
3) I believe the optimizations that were possible with SHA256 make for a very unfair and unbalanced mining community, and has been a main factor in the centralization we have seen.
I believe we can do better than SHA256 and other alt coin attempts, to create a mining algorithm that after full optimization still has more balanced and fair economics. I am basing this view on past experience in porting many software algorithms to FPGA and ASIC implementations (which is a very specialized skill set) and having an intuitive understanding of what types of algorithms are difficult and/or not worthwhile to fully convert to power hungry ASICs.
The POW I am creating will after fully optimized have characteristics similar to the FPGA era of Bitcoin mining, during this era capital costs were much higher than electricity costs and low cost electricity was not as much as an advantage. This POW will also likely not fully optimize to an FPGA, but to a low power CPU core connected to external low power DRAM. This will produce a better environment IMHO.
wie gut das klappen kann? keine Ahnung. EDIT: ansonsten bleibt nur die Hoffnung, daß es so läuft wie antonopulous es beschreibt und sich das mining wieder dezentralisieren wird, weil asics am high-end der technologie ankommen und dann irgendwie doch für jeden erschwinglich werden (und in jedem Haarfön stecken?) |
|
|
|
- The POW algorithm will changed
EDIT: aber so ist OpenSource. sie wollen spielen können. ja genau, lass uns doch spinnen / spielen. |
|
|
|
The above with the OP_RETURN is how the witness root hash (the hash of the wtxids where the wtxids are leaves on a hash tree). This is added to the Coinbase transaction of the block. The point of doing this is to commit the witnesses to the blockchain without adding all of the witnesses to the size calculation of the blockchain except for these 38 bytes.
So this is kind-of like a merge-mined witness chain? |
|
|
|
Hold up. I'd like to hear from Wuille (one of the creators of segwit) about the size difference between a standard 2-input, 2-output transaction and its equivalent using segwit, for a fully-validating node. No need to attack with sarcasm.
BTW, I am also curious if the O(n^2) sigops issue can be solved in a much more simple way.
That leads me to another question I've been having that hasn't been answered as far as I know. If segregating the signatures out of the tx leads to a stable txid (malleability fixed), then why can't we simply fix malleability independantly by simply ingoring the signatures when hashing the txid? |
|
|
|
Es wäre tatsächlich besser die SegWit Variante auch in der Hard-Fork Variante einzuführen und am besten gleich noch ein paar andere Änderungen (Blockgrösse, UTXO Commitments, Mining Algorithm) mitzunehmen.
Das Ganze dann mit einer entsprechend langen Vorlaufzeit (und nicht sofort über's Knie gebrochen) und ausreichendem Konsens. Aber wer hat dafür jetzt noch die Nerven, wo es sowieso nur noch um Rechthaberei geht und ein sinnvoller Hard-Fork damit praktisch unmöglich geworden ist?!
schon SatoshisBitcoin gesehen? Ein "spin-off" (also fork von der Bitcoin chain). Erstmal vor allem 2 MB (später flexible) und neuer algo (daher auch "full fork" genannt): 'ne scrypt-variante. Wer Bock hat kann am Wochenende beim öffentlichen Test-Fork mitmachen. Macht echt Spass volle Bitcoin-Blöcke zu minen, eheheh. Hab 10 erwischt in 5 Stunden beim letzten Test am Wochenende. Macht irgendwie Spass nicht immer nur stier rumzulabern und sich zu streiten, sondern zumindest mal was zu tun, wie konstruktiv auch immer das am Ende sein mag... |
|
|
|
Hab mal 'ne Frage zu Segwit: Warum ist für eine Erhöhung der maximalen Blockgröße ein Hardfork nötig, während für einen offensichtlich weit aufwändigeren Protokollwechsel wie Segwit ein Softfork ausreicht?
Weil man die alten clients "verarscht". Ein teil der Blockchain (die neuen segwit transaktionen) kommen in einen 2ten Bereich, den die alten clients nicht sehen (und auch nicht verifizieren können). Im Prinzip könnte man sagen es wird eine 2te chain (sozusagen merge-mined) auf bitcoin draufgesetzt. |
|
|
|
Könnte der erste Schritt sein. Die Überlastung unseren Netzes? Schritt 2, https://coin.dance/nodes 3213 Classic nodes 4745 Core nodes Schritt 3, Netzsplit? Wieso Überlastung? Mehr nodes machen das Netz höchstens stabiler. |
|
|
|
|
I really don't understand why we need to force our beloved wallet devs through this complicated mess. New address format? How to explain to users? All infrastructure needs to be upgraded... What a gargantuan task...
Why do we need segwit again?
|
|
|
|
keep calm, stay tuned. everything will be fine.
you sound like the city loudspeaker voice in a bad 1984 movie or something. |
|
|
|
|
Show Posts
