Are you starting to get it now?
(fingers crossed that the penny has dropped)
I know you're not talking to me, but I think I understand now: the NOP really is something that invalidates a tx in the context of relaying and mining it because the assumption is that this NOP isn't there for fun, but it really is not a NOP for the author of the tx or the miner of it. I just don't know the new meaning of the NOP so I don't touch the tx with a ten foot pole... who knows wether that script returns true or false? On the other hand a NOP in a tx in a block already mined by someone else is not offensive: the assumption is that it was assigned some meaning I don't yet know about and the block was mined by a miner that *does* know about that new meanig and he has verified the tx' validity. |
|
|
|
It was explained to you that the op code is *valid* in the context of validating a block (so of course the block would not be rejected by older software). Why do you think it is called a NOP?
It's called a "No OPeration" because it doesn't do anything (except maybe wait a clock cycle or so) in the context of script execution.. So it will not influence the result of the script execution. However there could still be a consensus rule that says: scripts shall not contain NOP instructions. What exactly is the "context of validating" a block? Validating it for wether it should be included in finding the longest chain? So are you saying a block containing a tx with a NOP will be accepted as part of the longest valid chain by core 0.11, 0.12? There are different validation rules depending upon whether you are mining, relaying or verifying a block (i.e. context).
So the rule about a NOP is not the same rule in all three situations (something that you just don't seem to be able to grok).
I understand that. For example BitcoinUnlimited will not relay some blocks if they are too big for the values given in configuration, yet it will still accept it as a valid block for mining. The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today)
so maxwell here seems to be saying that in the context of relaying a tx, relaying a block and mining, a tx containting a NOP (is that any different from "a reserved script NOP", btw?) instruction or a block containing a tx containing a NOP instruction will not be relayed (in case of a block or tx) and will not be considered when finding the 'longest' chain to mine on? That seems hard to believe. So I'm putting a NOP into a script and that means the tx wont be relayed by standard core nodes and it wont be mined by a miner who runs a core node? Is that what he's saying? Is it true? |
|
|
|
I am working on my next ETH rig, OLIVE....  I'm happy about ethereum because it brings those kinds of pics back to this thread. Love it! |
|
|
|
|
@mezzomix: wie immer picke ich mir die Punkte raus in denen wir uns einigermassen einig sind.
segwit so schnell durchzuprügeln ist verantwortungslos und vor allem unnötig.
|
|
|
|
Das war schon immer so und wird immer so bleiben. Vom Sesterz bis zum Euro.
So lange es "Geldsozialismus" (nach Roland Bader), oder Staatsgeld oder Zwangsgeld gibt.
...sagte ein Mensch namens "Greshamsches Geld" auf einem Bitcoin-Forum ;-) Ist also klar als Handlungsvorschlag zu verstehen, oder? Ist meine vollste Überzeugung. Marktgeld contra Staatsgeld Gold sehe ich als Marktgeld gegenüber Dollar, Euro... Staatsgeld Unsere Chancen stehen eigentlich sehr gut. Frühere Befürchtungen von wegen Bitcoinverbot sehe ich nicht mehr. Fehlt eigentlich nur noch mehr Akzeptanz bei den Menschen und eine wachsende Infrastruktur um Bitcoin herum. Mehr Zahlungsdienstleister. Aber die brauchen auch wieder Kunden. Dafür werden diejenigen aber die Banken der Zukunft sein. Bin voll bei dir. Bloss Befürchtungen vor einem Verbot hatte ich früher garnicht. Mittlerweile mit den Anschlägen schon. Wenig, aber schon. |
|
|
|
Das war schon immer so und wird immer so bleiben. Vom Sesterz bis zum Euro.
So lange es "Geldsozialismus" (nach Roland Bader), oder Staatsgeld oder Zwangsgeld gibt.
...sagte ein Mensch namens "Greshamsches Geld" auf einem Bitcoin-Forum ;-) Ist also klar als Handlungsvorschlag zu verstehen, oder? |
|
|
|
I"M BACK BABY!!!!!!!!!!!!!!!!!!
OK. Now, to prove your allegiance to this forum, you need to troll your own thread in the other forum, and get banned there.  Haha, not going to happen, especially because those intentions are now known  |
|
|
|
Running .9.2 on windows 64, 100% synced, status says:
...v1, up to date, 8+0 connections
can someone give me explicit instructions to get connected?
thanks
 I'll do a little googling, see if I can figure it out from there. thanks Smooth UPDATE: On the side of my ISP provided router, is a nice little label with a GUI access address, user name, and password. From there, flying by the seat of my pants, I created some rules that now allow a gratifying number of incoming connections good job. you're really doing your username justice |
|
|
|
they seem gone (getting site errors).
What was the price tag?
TREZOR Metallic & Cryptosteel $999 Unique combination of the First Edition TREZOR Metallic and First Edition Cryptosteel. Oh, allright. Thanks for the info. I was going to go off on a rant (having payed roughly $550 (?) for my metal trezor when they were on preorder back in 2013 for 3 BTC). Now I know roughly what it's worth. Screw collecting for me, though. I'm using the thing, scratching it and everything ;-) Same for my alpaca socks, haha. |
|
|
|
they seem gone (getting site errors). What was the price tag? |
|
|
|
Vergrößerung ohne Hardfork?
Das geht laut Definition nicht: ein hardfork erlaubt Dinge, die vorher nicht erlaubt waren (z.B: einen 1.2 MB großen Block). Um potentiellem Einwand gleich zu begegnen: Segwit ist auch keine Erhöhung der maximalen Blockgröße, sondern eher eine Sidechain. Ah, da fällt mir eine Analogie eine (das mögen die Leute ja): SegWit ist wie beim Motorrad der Beiwagen: kann man unnötiges Gepäck auslagern (der Rucksack kommt weg), macht die Sache aber komplexer und vor allem: ändert die Fahrphysik nicht unerheblich. Treffend, oder? Zur beurteilung von SegWit via Analogie (wird ja auch gerne gemacht): Hängt wahrscheinlich sehr mit dem Charakter (Stil) des Fahrers zusammen, ob man sowas will oder ob man dem 2ten Mitreisenden einfach auch ein Motorrad und seine eigene Freiheit gönnt. |
|
|
|
Poloniex ist sicherlich derzeit der beste und "vertrauenvollste" Exchange wo man angemessen Zinsen bei angemessenen Risiko bekommt. Von anderen würde ich derzeit die Finger lassen.
Hat hier jemand Erfahrungen welche Exchanges die attraktivsten Zinsen fürs Lending abwerfen?
bitfinex? |
|
|
|
molecular und der spiegel artikel. so war es bei mir auch. immerwährendes danke an molecular  das forum hab ich leider erst zwei jahre später gefunden. Ich freue mich wirklich daß ich so einen positiven Einfluss haben durfte . |
|
|
|
Früher war das auch so, aber seit Mike Hearn und Gavin Andresen begonnen haben Stunk zu machen und danach noch andere auf den Zug aufgesprungen sind ist leider im gesammten Projekt das Chaos ausgebrochen. Egal, die Stressmacher halten den Kurs auf niedrigem Niveau stabil und in einigen Jahren ist das Thema sowieso Geschichte.  lol! Jetzt sind auch noch "die Stressmacher" schuld daß der Kurs nicht abgeht. Ich zähl mich mal dazu und lach mich schlapp, wenn ich darf. Am blocksize-limit und der ständigen Aufschieberei und Begrenzerei kann's ja nicht liegen. Wir haben ja segwit... ist ganz toll und wer das mit dem "Scaling" nicht glaubt: segwit hat ja auch noch andere Vorteile. lol, echt geil. Auch am Interessenskonflikt einiger Core-Entwickler kanns auch nicht liegen, die haben ja nur Bitcoins bestes im Sinn und sind unfehlbare Experten. In einem sind wir uns wenigstens einig: in einigen Jahren ist das Thema Geschichte... so oder so... ich blicke einfach nicht durch. beide seiten haben gute argumente. was mir aber sorgen macht: wie soll dieser konflikt aufgelöst werden? der bitpay kompromiss von sich automatisch anpassender blockgröße scheint mir vielversprechend zu sein, aber hat das eine chance? https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawikiirgendwo habe ich gelesen, dass wir eine neue stufe in der Bitcoin entwicklung erreicht haben. und sie wurde begrüsst. alternative konzepte kämpfen um den durchbruch. der durchbruch wird über die nodes erfolgen.meiner meinung nach wird es auch einen positiven "nebeneffekt" geben. sollten wir uns einer kritischen marke (75% oder 95%) nähern wird jede seite versuchen neue nodes an den start zu bringen um die marke zu überschreiten. wir werden dann neben der ständigen steigerung der hashleistung wahrscheinlich noch eine zunahme der full-nodes sehen was das netzwerk zusätzlich stärken wird. Das fett markierte verstehe ich nicht. Wie soll der Mechanismus funktionieren? Nodes sind billig. Sibylle sagt: läuft nicht. |
|
|
|
ich blicke einfach nicht durch. beide seiten haben gute argumente.
was mir aber sorgen macht: wie soll dieser konflikt aufgelöst werden? der bitpay kompromiss von sich automatisch anpassender blockgröße scheint mir vielversprechend zu sein, aber hat das eine chance?
Der Kompromiss war 2 MB und wurde abgelehnt. Jeder hardfork wird abgelehnt. Es geht auch nicht um Argumente, sondern darum wer die Macht hat. |
|
|
|
Früher war das auch so, aber seit Mike Hearn und Gavin Andresen begonnen haben Stunk zu machen und danach noch andere auf den Zug aufgesprungen sind ist leider im gesammten Projekt das Chaos ausgebrochen. Egal, die Stressmacher halten den Kurs auf niedrigem Niveau stabil und in einigen Jahren ist das Thema sowieso Geschichte. lol! Jetzt sind auch noch "die Stressmacher" schuld daß der Kurs nicht abgeht. Ich zähl mich mal dazu und lach mich schlapp, wenn ich darf. Am blocksize-limit und der ständigen Aufschieberei und Begrenzerei kann's ja nicht liegen. Wir haben ja segwit... ist ganz toll und wer das mit dem "Scaling" nicht glaubt: segwit hat ja auch noch andere Vorteile. lol, echt geil. Auch am Interessenskonflikt einiger Core-Entwickler kanns auch nicht liegen, die haben ja nur Bitcoins bestes im Sinn und sind unfehlbare Experten. In einem sind wir uns wenigstens einig: in einigen Jahren ist das Thema Geschichte... so oder so... mensch mole, ohne dich und SPON wäre ich nicht zum Bitcoin gekommen, oder vieleicht dann erst sehr viel später. ich hatte schon angst, dass du hier gar nichts mehr schreibst. was sagst du dazu? passender vergleich oder? Anyway, I like the comparison of Bitcoin to toilet paper on public toilets (slightly rephrased from Samson Mow’s interview):
"If someone loots all the toilet paper from the public toilet, is the solution to double the amount of toilet paper stocked each day?"
I mag slush. Hatte ihn ja auch ein bisschen besser kennengelernt in Prag, London und Amsterdam. Er ist einer von denen, der's allen recht machen will und man hört aus seinem Post schön raus, daß er es sich's mit keinem verkacken will. Kann ich auch verstehen.. sowohl menschlich (ich bin auch so einer) als auch als Pool-Betreiber und SatoshiLabs owner. Ich finde allerdings einige seiner Argumente ziemlich an den Haaren herbeigezogen. Die fäkal angehauchte analogie von Mow zählt aber dazu (siehe passende reddit-Diskussion. Inhaltlich entzweit sich das ganze ja an der Frage was genau Spam ist. Öfter als alle 2 Tage kacken? 2 mal am Tag kacken? Ausländer die kacken? Kackende Nazis? Ich finde Analogien immer schweirig und bei Bitcoin oft noch mehr, da Bitoin sich oft unintuitiv und unkonventienell verhält. Und ich gebe ganz ehrlich zu, daß ich in letzter Zeit öfters mal keinen Bock habe zu posten (btctalk, reddit,...). Ich kann die ganze Diskussion bald nicht mehr hören (mir Bluten schon die Ohren, immer derselbe Käse und nix ändert sich) und die Sache hat sich so langsam von "inhaltlich" zu "aus Prinzip" verlagert... vielleicht sogar auf eine persönliche Ebene. Ich kann z.B. Todd und Maxwell nicht (mehr) ausstehen. Narzissmus, Perfektionismus und verletzte Riesen-Egs sind Eigenschaften von Menschen die mich wirklich auf die Palme bringen. Ich kann mich auch nicht entsinnen von denen groß was mitbekommen zu haben 2011 als ich zu Bitcoin dazukam. Jedenfalls hingen die nicht auf #bitcoin-dev ab und das war damals die"Schaltzentrale" von Bitcoin. Also hab ich jetzt ein Problem damit, wenn diese Herren großen Kinder sich als alleinige Inhaber der Autorität hinstellen (bezahlt von Blockstream) und behaupten das 1 MB limit (von dem damals auch nie die Rede war, jedenfalls nicht als Bestandteil der "goldenen Regeln") müsse bleiben und dabei auch noch einen Interessenkonflikt haben der klarer nicht sein könnte. Da will der kleine Rebell in mir einfach einen Hardfork. Von mir aus auf 1,001 MB blocksize limit. Ich will einfach wissen, daß (ob??) wir uns gegen einen Angriff der die Coredevs unterwandert und die Miner unter Druck setzt (ob das jetzt im vorliegenden Fall so ist oder nicht ist egal) wehren könn(t)en. Wenn das nicht klappt dann werde ich zum trotzigen Kind wie Mike Hearn (mining centralized and corrupt, bitcoin broken), verkaufe 50% meiner sah256d-BTC und mache bei SatoshisBitcoin mit.... endlich wieder minen. |
|
|
|
Früher war das auch so, aber seit Mike Hearn und Gavin Andresen begonnen haben Stunk zu machen und danach noch andere auf den Zug aufgesprungen sind ist leider im gesammten Projekt das Chaos ausgebrochen. Egal, die Stressmacher halten den Kurs auf niedrigem Niveau stabil und in einigen Jahren ist das Thema sowieso Geschichte. lol! Jetzt sind auch noch "die Stressmacher" schuld daß der Kurs nicht abgeht. Ich zähl mich mal dazu und lach mich schlapp, wenn ich darf. Am blocksize-limit und der ständigen Aufschieberei und Begrenzerei kann's ja nicht liegen. Wir haben ja segwit... ist ganz toll und wer das mit dem "Scaling" nicht glaubt: segwit hat ja auch noch andere Vorteile. lol, echt geil. Auch am Interessenskonflikt einiger Core-Entwickler kanns auch nicht liegen, die haben ja nur Bitcoins bestes im Sinn und sind unfehlbare Experten. In einem sind wir uns wenigstens einig: in einigen Jahren ist das Thema Geschichte... so oder so... |
|
|
|
With regards to the O(N2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N2) performance assumes that the block contains a single transaction.
If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction? [/quote] Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines. |
|
|
|
The thread is luckily not dead.
Based on my observation over the past 5 years, each time the thread got boring , we were close to a MAJOR price move...
So it will be this time, too...
Of course there's a correlation of this thread's posting activity and market volatility. And yes: after the rain there will be sunshine. Up or Down? |
|
|
|
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? The first is possible but it is not optimal because it requires twice the lookup table size. The second is also possible but the issue is the hard fork. The problem is that hard forks shouldn't be done often and for small things like this. It would be better if it was packaged with other stuff that is desired that also requires a hard fork. If also has less functionality than segwit. Thanks for the info and those clarifications. I understand you take issue with hardforking in general and I don't want to downplay the inherent risks. I'm not suggesting to do a hard-fork just for this. I'm investigating the feasability of assembling a compromise package of changes. As you said: It would be better if it was packaged with other stuff that is desired that also requires a hard fork.
Mainly here I'm reacting to Maxwell saying txid change couldn't be deployed as a hardfork at all, because that quote very publicly being used on reddit to defend "segwit as a softfork". 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.
So that's basically FUD? |
|
|
|
|
Show Posts
