Bitcoin Forum
November 17, 2017, 07:37:09 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 94 »
  Print  
Author Topic: Re: Der Aktuelle Kursverlauf blockgrösse  (Read 172780 times)
Limx Dev
Legendary
*
Offline Offline

Activity: 1134


www.bitsend.info


View Profile
March 06, 2017, 11:19:28 PM
 #181

UASF ist die härtere Variante meines Vorschlags:

Wobei eine Evolution machbar wäre - die Lösung wartet auf Aktivierung. Es zeichnet sich aber am Rande ab, dass das Pool-Mining das zentrale Problem (pun intended) an der Sache ist. D.h. die tatsächlich sinnvolle Lösung zur Änderung der Blockgrösse wäre eine Änderung des Hash-Algorithmus. Die sanfte Methode wäre, die entsprechenden Blockade-Miner in den Arsch zu treten indem  ihren Blöcken ein geringerer Stellenwert eingeräumt wird.

Während mein Vorschlag lediglich darauf abzielt, Blockade-Miner etwas auszubremsen, wirft UASF die Blockierer einfach aus dem Netz. Letztendlich ist beides eine mögliche und sinnvolle Option, da sich mehrere tausend Nutzer nicht von 3-4 Poolbetreibern erpressen lassen sollten.

Und wie willst du die Mehrheitsmeinung der User feststellen?

Bitcoin funktioniert immer noch so, daß dies per PoW geschieht. Die Miner entscheiden.

Bisher generieren die Miner die Blöcke, aber alle Knoten müssen diese Blöcke verifizieren. Wenn ich alleine, die Blöcke der Blockierer nicht mehr weiterleite, passiert gar nichts. Machen das sehr viele Knoten, dann verliert ein blockierender Miner immer mal wieder einen Block gegen einen Miner, der die Weiterentwicklung nicht blockiert. Er hat statistisch gesehen weniger Glück beim Finden von Blöcken und somit einen ökonomischen Nachteil.

Jeder Knoten kann sich ohne weitere Nachteile entscheiden, bestimmte Blöcke nicht mehr weiterzuleiten. Genauso wie ein Miner beliebige Transaktionen in einen Block aufnehmen kann, kann sich jeder Knoten entscheiden, welche Blöcke er weiterleiten möchte und welche nicht.


Theoretisch ein guter Ansatz. Das ablehnen von nur einen Block führt zu einen Fork beim Node oder zu einem Orphan beim Miner. Das verifizieren ist eigentlich nicht mehr als ein paar Prüfffunktionen die da durchlaufen insbesondere ob der Hash schwer genug ist und ob es zum nbits des Headers passt.

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Segwit | Core 0.14 | Masternodes
XEVAN | DK3 | Electrum soon
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
Litebit.eu | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
1510947429
Hero Member
*
Offline Offline

Posts: 1510947429

View Profile Personal Message (Offline)

Ignore
1510947429
Reply with quote  #2

1510947429
Report to moderator
1510947429
Hero Member
*
Offline Offline

Posts: 1510947429

View Profile Personal Message (Offline)

Ignore
1510947429
Reply with quote  #2

1510947429
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1510947429
Hero Member
*
Offline Offline

Posts: 1510947429

View Profile Personal Message (Offline)

Ignore
1510947429
Reply with quote  #2

1510947429
Report to moderator
1510947429
Hero Member
*
Offline Offline

Posts: 1510947429

View Profile Personal Message (Offline)

Ignore
1510947429
Reply with quote  #2

1510947429
Report to moderator
1510947429
Hero Member
*
Offline Offline

Posts: 1510947429

View Profile Personal Message (Offline)

Ignore
1510947429
Reply with quote  #2

1510947429
Report to moderator
mezzomix
Legendary
*
Offline Offline

Activity: 1904


View Profile
March 07, 2017, 06:49:19 AM
 #182

Das Verifizieren beinhaltet auch die Signaturprüfung aller Transaktionen im Block. Mein Vorschlag zielt aber gar nicht darauf ab, einen Block abzulehnen, sondern den unerwünschten Block nicht weiterzuleiten (Relay). Das führt erst dann zu einem Orphan, wenn es ein anderer Miner schafft, einen bevorzugten Block gleicher Höhe zu erzeugen.
curiosity81
Legendary
*
Offline Offline

Activity: 1694



View Profile
March 07, 2017, 07:12:50 AM
 #183

Hier noch der Artikel zu BU-Blocks:

https://bitcoinblog.de/2017/03/07/antpool-erzeugt-ersten-bitcoin-unlimited-block/

Und der entsprechende Artikel was UASF ist:

https://bitcoinmagazine.com/articles/latest-twist-block-size-debate-called-uasf/

Donate Anti-Cancer Research:
http://www.indysci.org/mission.html
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
March 07, 2017, 07:23:19 AM
 #184

UASF ist die härtere Variante meines Vorschlags:

Wobei eine Evolution machbar wäre - die Lösung wartet auf Aktivierung. Es zeichnet sich aber am Rande ab, dass das Pool-Mining das zentrale Problem (pun intended) an der Sache ist. D.h. die tatsächlich sinnvolle Lösung zur Änderung der Blockgrösse wäre eine Änderung des Hash-Algorithmus. Die sanfte Methode wäre, die entsprechenden Blockade-Miner in den Arsch zu treten indem  ihren Blöcken ein geringerer Stellenwert eingeräumt wird.

Während mein Vorschlag lediglich darauf abzielt, Blockade-Miner etwas auszubremsen, wirft UASF die Blockierer einfach aus dem Netz. Letztendlich ist beides eine mögliche und sinnvolle Option, da sich mehrere tausend Nutzer nicht von 3-4 Poolbetreibern erpressen lassen sollten.

Und wie willst du die Mehrheitsmeinung der User feststellen?

Bitcoin funktioniert immer noch so, daß dies per PoW geschieht. Die Miner entscheiden.

Bisher generieren die Miner die Blöcke, aber alle Knoten müssen diese Blöcke verifizieren. Wenn ich alleine, die Blöcke der Blockierer nicht mehr weiterleite, passiert gar nichts. Machen das sehr viele Knoten, dann verliert ein blockierender Miner immer mal wieder einen Block gegen einen Miner, der die Weiterentwicklung nicht blockiert. Er hat statistisch gesehen weniger Glück beim Finden von Blöcken und somit einen ökonomischen Nachteil.

Jeder Knoten kann sich ohne weitere Nachteile entscheiden, bestimmte Blöcke nicht mehr weiterzuleiten. Genauso wie ein Miner beliebige Transaktionen in einen Block aufnehmen kann, kann sich jeder Knoten entscheiden, welche Blöcke er weiterleiten möchte und welche nicht.


Ja genau, das Node-Netzwerk kann das "orphaning risiko" für die Miner erhöhen. Dadurch ergibt sich die Möglichkeit, daß sich die Blockgrößte auf ein gesundes Maß einpendeln kann, sozusagen ein forwährender, verteilter Entscheidungsprozess wie groß die Blöcke sein dürfen. Der Miner muss entscheiden wie groß er den Block macht: sein Vorteil an mehr tx: mehr Gebühren, sein Nachteil: erhöhtes Risiko den gesamten Block reward + fees komplett zu verlieren. (Peter Rizun hat dies ja auch erarbeitet: ("A fee market exists without a blocksize limit": youtube, paper)


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
butch3r
Member
**
Offline Offline

Activity: 118


View Profile
March 07, 2017, 07:40:24 AM
 #185

Gibt es denn schon eine Deadline bis wann sich etwas bezüglich der Blocksize ändern muss? Oder ein Ablaufdatum für die BU/Segwit Debatte?

Ich habe gestern für einen Kumpel, der kein Paypal hat ein spiel bei Steam mit Bitcoin gekauft. Wir die Bestätigung gab es dann am nächsten Morgen. Tolle Werbung für Bitcoin...
Queenvio
Hero Member
*****
Offline Offline

Activity: 671



View Profile
March 07, 2017, 07:54:22 AM
 #186

Glaube nicht, dass es dafür ein genaues Datum gibts. Entscheidend am Ende das Netzwerk.

Aber BU holt im Moment wieder auf, was die Debatte wieder anheizen wird.

Verstehe auch nicht, warum man BU nicht in de core implementiert, so müssen wir warten bis SW genug Zustimmung hat und dann evtl das gleiche Spiel noch mal mit eine. hardfork. Besser jetzt schon einbauen, dann ist die Verbreitung zu dem Zeitpunkt wo man es aktivieren will schon gegeben.

Limx Dev
Legendary
*
Offline Offline

Activity: 1134


www.bitsend.info


View Profile
March 07, 2017, 08:31:54 AM
 #187

Gibt es denn schon eine Deadline bis wann sich etwas bezüglich der Blocksize ändern muss? Oder ein Ablaufdatum für die BU/Segwit Debatte?

Ich habe gestern für einen Kumpel, der kein Paypal hat ein spiel bei Steam mit Bitcoin gekauft. Wir die Bestätigung gab es dann am nächsten Morgen. Tolle Werbung für Bitcoin...

Ja gibt es ...ich glaube 1 Jahr nach update 13.1

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Segwit | Core 0.14 | Masternodes
XEVAN | DK3 | Electrum soon
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
Litebit.eu | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
mezzomix
Legendary
*
Offline Offline

Activity: 1904


View Profile
March 07, 2017, 08:40:35 AM
 #188

Die Blocksize per Hard-Fork zu erhöhen ist überhaupt kein Problem. Lege einen Termin fest und hole die Zustimmung eines jeden Knotenbetreibers ein, dass er zu diesem Termin sein System auf die aktuellste Version umstellt. Bei manchen wird es nicht so einfach wie beim normalen Heimanwender, da dort weitere Infrastruktur läuft. Diesen Betreibern wird die Community sicher Hilfe in Form von Entwicklungsleistung/Geld anbieten.  Undecided

Wäre es so einfach, hättet ihr alle schon seit mindestens 10 Jahren IPv6 im Produktivbetrieb und wir hätten IPv4 schon abschalten können. Komischerweise machen die meisten immer noch IPv4 und kommen dann hier mit solchen komischen realitätsfernen Vorschlägen bezüglich der Blockgrösse. Man schaue sich https://bitnodes.21.co/nodes/ an. Wer soll diese Knoten alle kurzfristig umstellen und wer bezahlt dafür?!

Hinweis: Bei mir läuft seit über 15 Jahren IPv6 und ich habe mit einer sofortigen (1-2 Wochen damit ich die Patches einspielen/portieren kann) Umstellung der Blockgrösse auf bis zu 8MB auch kein Problem.

Ich lehne es ab, Vorschläge von Leuten zu aktzeptieren, die von Anderen immer Dinge fordern, selber aber nicht bereit sind das geringste zu tun. Den Schuh darf sich nun derjenige anziehen, dem er passt.  Embarrassed
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
March 07, 2017, 09:44:12 AM
 #189

Glaube nicht, dass es dafür ein genaues Datum gibts. Entscheidend am Ende das Netzwerk.

Aber BU holt im Moment wieder auf, was die Debatte wieder anheizen wird.

Verstehe auch nicht, warum man BU nicht in de core implementiert, so müssen wir warten bis SW genug Zustimmung hat und dann evtl das gleiche Spiel noch mal mit eine. hardfork. Besser jetzt schon einbauen, dann ist die Verbreitung zu dem Zeitpunkt wo man es aktivieren will schon gegeben.

Richtig, es gibt kein Datum. BU hat auch kein aktivierungs-treshold. Sobald ein miner sich sicher genug fühlt, kann er einen 1.1 MB block minen und dann haben wir den hardfork (oder split, aber hoffentlich nicht). Das wird aber dauern... wird keiner machen ohne 75% oder wahrscheinlich noch viel mehr support sowohl von den anderen minern als auch von den nodes.

Segwit sieht nicht gut aus. Mal sehn ob core wirklich versuchen will das mittel UASF durchzuprügeln. Ich halte das für keine gute Idee.

Ich favorisiere folgende Lösung: die Entwickler tun sich zusammen und bauen "Segwit as HF + BU". Das wäre meiner Meinung nach Mehrheitsfähig (nach einem recht langen Weg, allerdings). Wenn da ein breit genuger Konsens erreicht werden kann, dann wäre das die Gold-Lösung und ohne große Gefahr einzuführen.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
March 07, 2017, 09:45:15 AM
 #190

Gibt es denn schon eine Deadline bis wann sich etwas bezüglich der Blocksize ändern muss? Oder ein Ablaufdatum für die BU/Segwit Debatte?

Ich habe gestern für einen Kumpel, der kein Paypal hat ein spiel bei Steam mit Bitcoin gekauft. Wir die Bestätigung gab es dann am nächsten Morgen. Tolle Werbung für Bitcoin...

Ja gibt es ...ich glaube 1 Jahr nach update 13.1

Ja, dann ist segwit abgelaufen (oder aktiviert). Aber das ist ja nicht das Ende der Debatte. Ist ja nicht so, daß dann automatisch BU eingeführt wird. Dann haben wir halt 1MB erstmal und immer noch Kapa-Probleme.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
March 07, 2017, 09:47:39 AM
 #191

Ich lehne es ab, Vorschläge von Leuten zu aktzeptieren, die von Anderen immer Dinge fordern, selber aber nicht bereit sind das geringste zu tun.

Ich hoffe du meinst nicht mich. Da müsste ich mich wehren und dann bekomme ich wieder ein zu großes Ego vorgeworfen... ;-)

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
mezzomix
Legendary
*
Offline Offline

Activity: 1904


View Profile
March 07, 2017, 12:01:08 PM
 #192

Ich favorisiere folgende Lösung: die Entwickler tun sich zusammen und bauen "Segwit as HF + BU". Das wäre meiner Meinung nach Mehrheitsfähig (nach einem recht langen Weg, allerdings).

Also ich bin dagegen. segwit + einmalig 2-8MB wäre für mich kein Problem. Blankoschecks auf zukünftige Erhöhungen stelle ich nicht aus.

Ich lehne es ab, Vorschläge von Leuten zu aktzeptieren, die von Anderen immer Dinge fordern, selber aber nicht bereit sind das geringste zu tun.
Ich hoffe du meinst nicht mich. Da müsste ich mich wehren und dann bekomme ich wieder ein zu großes Ego vorgeworfen... ;-)

Den Schuh darf sich nun derjenige anziehen, dem er passt.  Embarrassed

 Wink
commander11
Sr. Member
****
Offline Offline

Activity: 310


View Profile
March 07, 2017, 12:28:11 PM
 #193

SEGWIT wird nie KOMMEN es war eine TOTGEBURT

Totaler Blockstream Crap Code .


Das ihr das immernoch nicht checkt hier  Shocked Shocked Shocked
flora_digitalis
Sr. Member
****
Offline Offline

Activity: 312


View Profile WWW
March 07, 2017, 12:33:20 PM
 #194

SEGWIT wird nie KOMMEN es war eine TOTGEBURT

Totaler Blockstream Crap Code .


Das ihr das immernoch nicht checkt hier  Shocked Shocked Shocked

Kurze Frage: Wieviel bekommst Du von Ver für Deinen Crap Talk hier?

commander11
Sr. Member
****
Offline Offline

Activity: 310


View Profile
March 07, 2017, 12:46:44 PM
 #195

Ver  =?

Ich bin wohl der einzigste hier der liest was die Miner sagen und technisch Versierte User im gegensatz zu den Core Lemmingen hier

in der DE Community.^^


Ich mine mit 5 s9 Ants BU  und du Huh 


ONE HASH ONE VOTE


Würde mal das Whitepaper lesen um Bitcoin zu verstehen an deiner Stelle^^

mezzomix
Legendary
*
Offline Offline

Activity: 1904


View Profile
March 07, 2017, 01:26:00 PM
 #196

ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.

So ist es korrekt, nennt sich dann Konsens.
ImI
Legendary
*
Offline Offline

Activity: 1694



View Profile
March 07, 2017, 01:34:03 PM
 #197

ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.

Mir wäre lieber ONE BTC ONE VOTE. Diejenigen welche auch tatsächlich Bitcoin halten sollen bestimmen wo es lang geht.

Auch die Umsetzung wäre extrem simpel, einfach abstimmen per signed Message und Problem gelöst.

Keine Miner und keine (nie gewählten oder sonstwie legitimierten)  Developer die über alles bestimmen.

mezzomix
Legendary
*
Offline Offline

Activity: 1904


View Profile
March 07, 2017, 02:54:23 PM
 #198

Das wäre dann PoS (Proof of Stake). Damit gibt es dann aber wieder andere Probleme. Ist eben nicht alles schwarz oder weiss.

Mal abwarten, wie sich die Sache entwickelt.
commander11
Sr. Member
****
Offline Offline

Activity: 310


View Profile
March 07, 2017, 04:22:02 PM
 #199

ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.

Mir wäre lieber ONE BTC ONE VOTE. Diejenigen welche auch tatsächlich Bitcoin halten sollen bestimmen wo es lang geht.

Auch die Umsetzung wäre extrem simpel, einfach abstimmen per signed Message und Problem gelöst.

Keine Miner und keine (nie gewählten oder sonstwie legitimierten)  Developer die über alles bestimmen.




solche abstimmung gibts grad steht alles in Reddit ist 80  zu 20 %  kann jeder mit seinen Coins Signieren läuft aktuell sowas

einfach mal Ver Twitter schauen da war der link oder auf R btc
mezzomix
Legendary
*
Offline Offline

Activity: 1904


View Profile
March 07, 2017, 04:51:20 PM
 #200

Ich mache gar nicht mit, weil ich das für sinnlos halte. Sollte BU nach  XT/Classic scheitern, dann werden wir bald darauf den nächsten "tolle" Hard-Fork präsentiert bekommen und dieselben Leute werden wieder die versuchen, die weitere Entwicklung zu blockieren.

Es ist relativ klar, dass aktuell >50% der Knoten mit segwit umgehen können und >99% der Knoten auch nach dem Soft-Fork ohne Veränderung mit dem System arbeiten können. Dagegen sind <10% der Knoten in der Lage mit einem Hard-Fork umzugehen. Diese Nutzer alle zum einem terminierten Update (Hard-Fork) zu zwingen halte ich für groben Unfug. Das Ganze kann nur den Zweck haben, die weitere Entwicklung zu blockieren.

Revolution (ein Hard-Fork) funktioniert mit keinem grösseren funktionierenden technischen System. Evolution (ein Soft-Fork) ist dagegen tägliche Praxis. Nicht Umsonst gibt es bis heute keine revolutionäre Umstellung von IPv4 auf IPv6. Kein grösseres Betriebssystem bekommt eine revolutionäre Umstellung der Schnittstelle hin, nach der sämtliche Software neu angepasst werden muss. Bei Geld sehe ich revolutionäre Änderungen noch kritischer. Trotzdem hätte ich persönlich kein Problem mit einer Änderung der Blockgrösse (bis 8MB) - gehöre damit aber vermutlich zur kleineren Gruppe unter den Bitcoin Nutzern.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 94 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!