Hmm, interessanter Ansatz aber ob das Finanzamt das auch so sieht halte ich nicht für so klar. Man sollte auf jeden Fall vorsichtig sein, ansonsten heißt es noch 10 Jahre hodln: §23 EStG Private Veräußerungsgeschäfte: "Bei Wirtschaftsgütern im Sinne von Satz 1, aus deren Nutzung als Einkunftsquelle zumindest in einem Kalenderjahr Einkünfte erzielt werden, erhöht sich der Zeitraum auf zehn Jahre;" 1. Es ist eine aufgedrängte Bereicherung. Wenn ich jetzt die BCC nicht mitnehme oder mitnehmen will, würde es dennoch meine Anschafffungskosten von BTC senken. Nein, in dem Spezailfall nicht. Wenn ich mich aus religiösen, ideologischen, persönlichen Gründen oder warum auch immer entscheide, eine der beiden Ketten zu ignorieren, dann hat das Finanzamt das zu akzeptieren, soweit ich damit verbindlich erkläre, eventiuelle Gewinne aus der anderen Kette mittels meines Eigentums am privaten Schlüssel nicht anzuschöpfen. Sollte ich meine Meinung nachträglich ändern, beantrage ich einfach eine diesbezügliche Neuberechnung der Steuern und alles ist gut, Hinterziehung nicht gegeben. Schwierig ist dann nur der letztere Fall: fallen 6% Zinsen so an, als wäre ich von Anfang an bestrebt gewesen, den Gewinn der alternativen Kette mitzunehmen oder ist der Zeitpunkt der Meinungsänderung maßgebend? Wenn man Steuerehrlichkeit voraussetzt, dann ja wohl letzteres. Das sehe ich anders. Es gilt das Zuflussprinzip. D.h., wenn mir das Geld entgültig zugeflossen ist, ist es egal, ob ich es will oder nicht. Ich kann nach dem Zahlen der Steuern es immer noch entsorgen. Wenn mir jemand Geld überweist, welches ich nicht haben will, müsste man es auch zurücküberweisen. Man kann natürlich mit dem Finanzamt darüber diskutieren, ob es zugeflossen ist, wenn ich den privaten Schlüssel nicht exportiert und in einem neuen Wallet importiert habe. Wohin sollte man die neuen Coins denn "zurück" überweisen? Man könnte Sie höchstens aktiv vernichten. Der Aufwand dafür wäre wohl kaum zumutbar. V.a. weil jeder mit einem Klon der Bitcoinbuchführung daherkommen kann. Ich würde also auch erwarten, dass Untätigkeit ausreicht um die neuen Coins "nicht an zu nehmen". |
|
|
|
|
Theory: People wisely want to move their funds off exchanges. For quite a lot it is much easier faster or safer or better (e.g. taxwise) to move BTC. So they convert the fiat they have sitting on exchanges driving up the price.
|
|
|
|
Bitcoin is fine, confirmed by price action. Segwit or BU will spook investors. Bitcoin is the gold standard of cryptocurrency, it is too big to change.
If we don't do anything we might as well bury Bitcoin right away. Altcoins will overtake quickly, just look at Litecoin. As for the price action it could mean: - current investors have no idea what they are doing
- current investors don't care
- current investors are optimistic a good solution will be found in time
- Bitcoin is undervalued despite the scaling discussion deadlock
I guess a mixture of the above... |
|
|
|
Please explain how a softfork would cause a chain split. A pool ignoring/banning/rejecting blocks/communication means it diverted from the chain protocol which equals to a chain split in my point of view.
FTFYa hard chain split is about the nodes(users) doing something to cause 2 chains. a soft chain split is about the pools doing something to cause 2 chains. EG a soft chain split is even though nodes dont have to do anything. pools ignore each other purely based on a version number where the pools then decide to either join X or ignore X and build on Y leading to the nodes that without doing anything end up following what they can happily accept A node will always follow the longest chain of blocks it considers valid. What have pools to do with it? Once again ignoring version numbers sounds like a protocol violation = hard fork.
i just read your reddit summary and laughed my head off..
Glad I could entertain you  you do realise the only establishment causing drama are the portfolio of DCG (blockstream, btcc, coinbase, and more) with all their REKT campaigns, accusations, Pow killing proposals, deadlines, blackmails, bribes.
Never heard about dcg before, quite interesting (though offtopic). Would be interesting to know how much of a stake they hold in all these companies listed on their website. Regarding your accusations I feel these rather come from the BU side (I read both r/btc and r/bitcoin). other non blockstream endorsed implementations are just plodding along not making threats and ven laughing at blockstreams attempt to get non-blockstream implementations to split, by simply saying 'no thanks w wanna stay as a peer network'
Sorry, I can't figure out what you are saying here. 
But quadratically with block size meaning at 16MB blocks or so a 30% miner might still be able to block all nodes permanently.
No. As I explained (did you even read?), parallel validation routes around the quadratic hash time issue. Yes I did but I realize now I took a wrong train of thought at some point, sorry. It's difficult to embrace a solution by someone with a track record as bad as BU recently if there is another more sustainable solution available by someone whose code I used without issue for years. I oppose The SegWit Omnibus Changeset mostly due to considerations other than segwit itself.
ok, this move the discussion forward. Namely: the SF nature;
As above: SF with hashrate majority safer than hardfork, replay protection is difficult the backdoor of versionbit changes;
From the other point of views it allows for easy upgrades. I can't imagine core could pull of anything that really goes against the will of the user majority. People would simply hard fork away. Same if they will not increase the block size if it is safely possible. and the centrally-planned magic 4:1 ratio.
Based on historic tx data and expected SW tx sizes I guess? This is concern trolling. But mostly because the 1.7x or 2x or whatever capacity increase it ends up being is too little
Better than nothing! And you are completely ignoring we need SegWit regardless of tx capacity. , too late,
Faster than anything else. and we'll just be back at this same argument before the year is up.
Possibly but by then we have learned more about larger blocks in a safe way. Also we will know more about about lightning and how much time it will be able to buy us. This could make a difference of a factor of ten or more and buy us quite some time. Think of it as an opportunity. We can always hardfork later on. |
|
|
|
OK, but I would call that a hardfork ('ignoring consensus orphaning mechanism').
soft forks do not need to result in a chain split hard forks do not need to result in a chain split soft involves just pool agreements to change something, thats just a network upgrade with one chain hard involves nodes agreeing to change something, thats just a network upgrade with one chain again soft forks do not need to result in a chain split hard forks do not need to result in a chain split when some pools disagree and decide to intentionally ignore/ban/reject blocks/communication and the opposition continues. thats a chain split when some nodes disagree and decide to intentionally ignore/ban/reject blocks/communication and the opposition continues. thats a chain split soft can intentionally cause a split hard can intentionally cause a split and again soft forks do not need to result in a chain split hard forks do not need to result in a chain split by thinking all "hard" actions = split.. and all "soft" actions = utopia.. that is taking softs best case scenario and hards worse case scenario. and avoid talking about the opposite Please explain how a softfork would cause a chain split. A node ignoring/banning/rejecting blocks/communication means it diverted from the chain protocol which equals to a hard fork in my point of view. |
|
|
|
How would you implement replay protection for a soft fork, there is only a single chain...
soft or hard. there are scenario's of staying as one chain (just orphan drama and being either small drama or mega clusterf*ck of orphans before settling down to one chain) dependant on % of majority.. but in both soft or hard a second chain can be produced. but this involves intentionally ignoring consensus orphaning mechanism.. in laymens: not connecting to opposing nodes to see their different rules/chain, to then build own chain without protocol arguing(orphaning) OK, but I would call that a hardfork ('ignoring consensus orphaning mechanism'). all the reddit doomsdays FUD is about trying to only mention softs best case, and hards worse case.
but never the other way around because then people will wise up to knowing that bitcoins consensus orphaning mechanism is a good thing and that doing things as a hard consensus is a good thing.
A SWHF certainly has it's benefits but SWSF is the superior solution IMHO. Some people may see this differently but I guess the majority would agree (if it is only because they trust Sipa and the other core people in their judgement). 5. Because of a block verification processing time vulnerability that increases quadratically with block size, increasing the block size is only possible AFTER SegWit is active and only for SegWit transactions.
False. Parallel validation routes around quadratic hash time issues, by naturally orphaning blocks that take an inordinate time to verify. I did not look into it but from what I hear it sounds more like a resource consuming band aid. Why not a proper fix with less CPU cycles? It is not so much a resource consuming band aid, as it is harnessing the natural incentive of greed on the part of the miners (you know, the same force that makes bitcoin work at all) to render the issue a non-problem. Seems like it gives an incentive to mine small blocks? One would have to check the implications of this change really thoroughly... Yes, it takes more memory to validate multiple blocks on different threads at the same time than a single block on a single thread. But this does not only lead to an incentive to not make blocks that take long to validate due to the O(n^2) hashing issue, it also provides a natural backpressure on excessively long-to-validate blocks for any reason whatsoever. Perhaps merely blocks that are huge numbers of simple transactions. And the resource requirements only increase linearly with the number of blocks currently being hashed concurrently by a single node.
But quadratically with block size meaning at 16MB blocks or so a 30% miner might still be able to block all nodes permanently. More importantly, as miners who create blocks exhibiting this quadratic hash time issue have their blocks orphaned, they will be bankrupted. Accordingly, the creation of these blocks will be disincentivized to the point where they just plain won't be built.
For an attacker disrupting the network for a while might pay of via puts or rising altcoins or just by hurting Bitcoin. Further, parallel validation is the logical approach to the problem. When one receives a block while still validating another, you need to consider that the first block under validation may be fraudulent. The sooner you find a valid block is the sooner you can get mining on the next block. Parallel validation allows one to find the valid block without having to wait until detection that the fraudulent block is fraudulent is accomplished. Not to mention the stunning fact that other miners do not currently mine at all while validating a block which may be fraudulent.
See above, might give a bad advantage to small blocks. Last, in the entire 465,185 block history of Bitcoin, there has been (to my knowledge) exactly one such aberrant block ever added to the chain. And parallel validation was not available at the time. But the network did not crash. It paused for a slight bit, then carried on as if nothing untoward ever happened. The point is that, while such blocks are a nuisance, they are not a systemic problem even without parallel validation. And parallel validation routes around this one-in-a-half-million (+/-) event.
This is because blocks were and are small. By all means, the O(n^2) hash time is suboptimal. We should replace it with a better algorithm at some date. But to focus on it as if it is even relevant to the current debate is ludicrous. It would be ludicrous even without the availability of parallel validation. The fact that BU implements parallel validation makes putting this consideration at the center of this debate ludicrous^2.
The superior solution is on the table, well tested and ready to be deployed. Parallel validation still require additional limitations as suggested by franky1 for larger blocks. Also let me remind you of the resource discussion further up. Of course it is relevant to this debate. Why do you oppose the technically sound and sustainable solution? Particularly as it happens to also bring other important benefits? |
|
|
|
5. Because of a block verification processing time vulnerability that increases quadratically with block size, increasing the block size is only possible AFTER SegWit is active and only for SegWit transactions.
False. Parallel validation routes around quadratic hash time issues, by naturally orphaning blocks that take an inordinate time to verify. I did not look into it but from what I hear it sounds more like a resource consuming band aid. Why not a proper fix with less CPU cycles? 4. There are two possible ways to deploy/implement SegWit, as a softfork or as a hardfork. SegWit as a hardfork would allow a slightly cleaner implementation but would also require replay protection (as the exchanges have specifically asked for lately). SWSF does not require replay protection assuming a hashrate majority. Replay protection is difficult thus SegWit as a hardfork would altogether cause more technical debt than SWSF. Also a hardfork is generally considered of higher risk and would take a longer preparation time.
Sorry, it seems people have had their heads FOHK'ed with (Fear of Hard Fork). It is not fear but the expectation of 'clusterfuck' (as you put it). There is little difference between the dangers of a soft fork and a hard fork.
In the event of a soft fork we have:
1.) The old chain exists with a more permissive set of rules.
2.) The new chain exists with a more restrictive set of rules.
Wait a second, there only exists a single chain as the old chain blocks are being orphaned (I am explicitly talking about a softfork with a hashrate majority as stated above). In a hard fork we have:
1.) The old chain exists with a more restrictive set of rules.
2.) The new chain exists with a more permissive set of rules.
So they look exactly the same during a chain split.
No, not at all. With the hard fork the old chain is not 'corrected' to follow the new chain. The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.
In the event of a successful soft fork, older nodes continue to operate as normal.
In the event of a successful hard fork, older nodes become unsynced and have to upgrade.
This is a big difference, isn't it? In the event of a contentious fork, hard of soft, it becomes an economically damaging clusterfuck until the winning fork is determined (the longest chain) or a bilateral split occurs (the minority chain implements replay protection)*.
Does a 70% hashrate majority still count as contentious? I don't think that would be a big problem for a softfork, the old chain would be forced to go along, but with a hardfork there would certainly remain two chains. * Strictly speaking the software forking away from the existing protocol (hard of soft) should be the version that implements relay protection as you cannot demand the existing protocol chain to change its behaviour. In practice though, the aim is not to create a permanent chain split and achieve consensus, so the minority chain should end up orphaned off, and any transactions that occur during any temporary chain split should end up confirmed on the main chain.
How would you implement replay protection for a soft fork, there is only a single chain... I am considering making my list above a reddit thread as I think it sums up the current situation nicely  |
|
|
|
I guess the thread title has not helped... it isn't going to be the last time and we'll never be able to continue in small words:)
Will give it another try: 1. There are certain structural oversights in Bitcoin that need to be fixed. Without fixing this altcoins will probably overtake Bitcoin in the long run. 2. SegWit has several benefits including short term higher transaction capacity, long term much higher transaction capacity through second level transactions and also safe (!) increasing of the block size. If Satoshi would design Bitcoin from scratch today he would probably do it somewhat similar to SWHF. 3. SegWit a good solution, ready for action and well tested. Even some of it's strongest opponents secretly admit it is "good" ( 'verified chatlogs'). 4. There are two possible ways to deploy/implement SegWit, as a softfork or as a hardfork. SegWit as a hardfork would allow a slightly cleaner implementation but would also require replay protection (as the exchanges have specifically asked for lately). SWSF does not require replay protection assuming a hashrate majority. Replay protection is difficult thus SegWit as a hardfork would altogether cause more technical debt than SWSF. Also a hardfork is generally considered of higher risk and would take a longer preparation time. 5. Because of a block verification processing time vulnerability that increases quadratically with block size, increasing the block size is only possible AFTER SegWit is active and only for SegWit transactions. 6. Any alternative to SegWit SF would take at least half a year longer in implementation and testing. 7. A mining hardware manufacturer and a rich guy are trying to prevent SegWit from being activated probably because of financial incentives and power political reasons ( 'verified chatlogs'). 8. Watching altcoins with SWSF flourish pressure from the users will become so high that Bitcoin finally will get SegWit SF, probably by the miners accepting it after all. |
|
|
|
This seems to be one of the center points of the discussion to me. Lauda, can you confirm I got it right? Wouldn't segwit hard fork be better than soft fork? 2.) There will be less technical debt by implementing segwit as a hard fork. The software kludges implementing it as a soft fork also creates huge maintenance risks in the future (segwit keys are 'anyonecanspend'). You are wrong here. Exchanges pointed out the need for replay protection for even slightly contentious hardforks a while ago. Replay protection is quite difficult and would cause more technical debt than SWSF. This makes SWSF the currently superior solution. Absolute bollocks. If SWSF becomes a contentious soft fork, you would still need replay protection. When there is a contentious fork, it makes no difference if that fork is hard or soft. You only need to implement replay protection if you want to cause a bilateral split, otherwise people will eventually unite behind a single chain, the one which has the most proof of work. The uniting behind one chain will happen sooner rather than later otherwise it is a complete clusterfuck. Maybe it was not clear but of course I am assuming a significant hashrate majority. Then there is no need for replay protection because the chain will always converge to the new chain. If you still disagree please explain. @franky1 SWHF shares most of the properties you are bashing. I can't see the point you are trying to make. What alternative solution do you propose? |
|
|
|
Wouldn't segwit hard fork be better than soft fork? 2.) There will be less technical debt by implementing segwit as a hard fork. The software kludges implementing it as a soft fork also creates huge maintenance risks in the future (segwit keys are 'anyonecanspend'). You are wrong here. Exchanges pointed out the need for replay protection for even slightly contentious hardforks a while ago. Replay protection is quite difficult and would cause more technical debt than SWSF. This makes SWSF the currently superior solution. Absolute bollocks. If SWSF becomes a contentious soft fork, you would still need replay protection. When there is a contentious fork, it makes no difference if that fork is hard or soft. You only need to implement replay protection if you want to cause a bilateral split, otherwise people will eventually unite behind a single chain, the one which has the most proof of work. The uniting behind one chain will happen sooner rather than later otherwise it is a complete clusterfuck. Maybe it was not clear but of course I am assuming a significant hashrate majority. Then there is no need for replay protection because the chain will always converge to the new chain. If you still disagree please explain. Segwit has its merits. However as a soft fork it is a dangerous software engineering hack which will burden the protocol forever. It cannot be reversed since it would be an 'anyonecanspend' free-for-all. And the potential for future developers to fuck this up is quite high. That's right, the high lords who developed segwit as a soft fork won't live forever.
Of course a hardfork is cleaner but the amount of tech debt the softfork causes is acceptable and it more than makes up for it in risk mitigation. |
|
|
|
Thanks everybody for the entertaining discussion in this thread, I learned something new about SegWit (WITNESS_SCALE_FACTOR). Thanks Lauda (and Sipa on IRC) for explaining. Wouldn't segwit hard fork be better than soft fork? 2.) There will be less technical debt by implementing segwit as a hard fork. The software kludges implementing it as a soft fork also creates huge maintenance risks in the future (segwit keys are 'anyonecanspend'). You are wrong here. Exchanges pointed out the need for replay protection for even slightly contentious hardforks a while ago. Replay protection is quite difficult and would cause more technical debt than SWSF. This makes SWSF the currently superior solution. |
|
|
|
....yeah... I don't think that works... For reasons others commented in the thread. Keep working on it though-- the mutually assured destruction angle seems interesting. It may be possible to salvage the concept. I might even give it a few cycles. Regarding deterrence it would be cool to change the PoW algorithm at the same moment BU activates. |
|
|
|
|
I read there is something like a christmas bonus in China, too. Like a "hong bao" (chinese new year gift) from companies to its workers. Does anybody know how high this typically is and when it is handed out? Could it have an effect on the price? Or rather after new year to make good use of the gifts?
|
|
|
|
At first I was very interested in Stellar with Jed's reputation of disruption. But the Facebook involvement in the inital giveaway spoiled it for me. And now again?  |
|
|
|
Is this another April Fool's prank?
Damn you caught me so quick! Could you try this again, delete everything related to bitcoin even in appdata.
DO NOT DO THIS!!!Yeah, that was a great suggestion. Possibly he realized it was a joke. I still think it's funny  |
|
|
|
Look at the balance on the left! WTF?! Windows, fresh install...  |
|
|
|
|
Show Posts
