Alles klar.
Wollte nur meine Restzweifel loswerden. Hab mir das eh schon so gedacht.

Schönen Tag noch.

Hallo zusammen,

Ich habe mich kürzlich auch versucht schlau zu machen wie es mit der Steuerpflicht bei Bitcoins aussieht.
Bin bei meiner Recherche auch auf die Seite des BMF gestoßen und habe dort auch mitgenommen, dass Privatveräusserungen nach einer Behaltedauer von mehr als einem Jahr nicht Steuerrelevant sind.

Habe dann aber auch mal bezüglich der Spekulationsgeschäfte im EStG etwas nachgeforscht.

Bin dabei auf folgende Seiten gestoßen.

http://www.geldmarie.at/steuern/aktiensteuer.html
https://www.wko.at/service/steuern/Die-Besteuerung-von-Wertpapieren.html

Kurz gesagt steht da, dass es die Haltefrist von einem Jahr (bei Aktien und dergleichen) nicht mehr gibt und jede Veräusserung Steuerpflichtig ist (27,5% auf den Gewinn).

Jetzt glaube ich zwar nicht, dass Bitcoin unter die Regeln der neuen Wertpapier KESt fällt, weil ich das neue Gesetz in Zusammenhang mit Bitcoins nirgendwo gesehen habe, würde mich aber trotzdem um eine Klarstellung freuen,  ob diese KESt bei Bitcoins Anwendung finden könnte oder eben nicht.

Danke und Grüße, Kogs

I found some confusing answers here and also some not 100% correct answers.

For the upcoming Segwit2X fork (if they will not add replay protection in the last minute before forking) here are some points to mention.

• Have your Bitcoins on addresses where you control the private key. If they are on a legacy address or on a Segwit address does not matter
• You will have to split the coins on your own in any case if you don't want to lose the coins for one side
• Some people here say, that for a replay of a transaction on the other side "someone else" need to take the transaction and broadcast it on the other side.
  This is not true.
  With the upcoming fork, the legacy chain and the Segwit2x chain broadcast their transactions to the same network. So, whenever you send a transaction (does not matter on which side), the transaction will always find a way to the nodes of the other chain (they are in the same network, they share the same transaction pool and so on). This causes always a replay of any transaction sent to the network.
• The only save way to split the coins I know is with a time locked transaction.
  The idea here is, that after a split both chains will have a different hash rate. So it is very unlikely that they find new blocks with the same speed. The chain with more hash rate will find blocks faster than the one with less hash rate.
  
  Let's assume the chain splits at block height 1000 (I know the current block height is higher, but just as example).
  This means, that from block 1000 on, the blocks will look different.
  Lets say with hash rate of Chain A they will find blocks every 20 minutes, Chain B find blocks every 40 minutes. After 6 hours Chain A created 18 blocks (block height 1018) and Chain B created 9 blocks (block height 1009).
  
  Now comes the magic part.
  You create a transaction with the bitcoins you want to split and send them to a new address you created before (important, you need to send to an address you control the private key!!). The transaction should have the nLocktime Parameter set to the block height of the longer chain. In this example, set the nLocktime to 1018. This means, that this transaction is only allowed to add to a new block if the block height of the chain is equal or higher than 1018.
  Chain A has height 1018, so if you payed enough transaction fee, the transaction should be put into one of the next blocks.
  Chain B has height 1009, so this transaction with the locktime 1018 will not be mined into the next blocks. It will wait in the transaction pool until Chain B reaches height 1018.
  When this transaction got one confirmation on Chain A, you create a second transaction to a different address you created (also your own address), but this time without time lock.
  The second transaction will be picked up by Chain B and put into one of the next blocks. This makes the first unconfirmed transaction invalid on Chain B. The second transaction itself is invalid on Chain A, because the Bitcoins were already used in the first transaction.
  If everything was working fine, you should have your coins on a new address on Chain A and another new address on Chain B.
  
• There is a chance, that this coin split might not work the first time.
  For example, if your first transaction did not get confirmed, before the second chain reach the nLockTime block height. In this case, you just wait again, until the two chains have a different height (maybe 10 to 20 blocks difference), and try again (that's the reason why you should always do this split and send the coins to your own addresses, so you can repeat in case it did not work the first time).

I hope that it is understandable what I wrote there  

One challenge is to create this nLocktime transaction, as I don't know any "easy" way to create them. Wallets usually don't support to create them directly...

Don't know if Ledger wallet is able to do it?

Only YOU need to save your private and public key (private key is enough, because the public key can be created out of the private key if you lose your public key).

Nobody else need to know which public or private keys exists or were used.

Some basics:
Private/public key pairs have the following attributes

• A private key can be created randomly
• You can create the public key out of the private key with some mathematical rules
• You CANNOT create the private key out of the public key -> so you can safely pass the public key (in Bitcoin it's actually a hash of the public key) to anyone without risking they can create the private key out if this public key
• You can sign a message (in Bitcoin the message is a transaction) with your private key
• You can prove with the public key, that a message was signed by the corresponding private key

With this in mind let's assume, you own 1 Bitcoin which was previously sent to one of your Public keys.
If you want to spent this 1 Bitcoin, you need to create a transaction.
Within this transaction you need to prove, that you own the private key of the public key which holds the 1 Bitcoin.
You can do this, by signing the transaction with your private key. As we learned above, when you sign something with your private key, anybody else can check with the public key (which is also included in the transaction), that the signature was created by your private key.
In the transaction you also pass a recipients public key where you want to send the Bitcoin.

This transaction is passed to the Bitcoin network (send the transaction to each Bitcoin node which is connected to your Bitcoin node (Wallet)). Each node will verify if this transaction is valid. One check to verify is, if your created signature matches with the public key which holds the Bitcoin. If you sign with a wrong private key, the transaction is invalid and will not be forwarded to the next  Bitcoin node. If it is valid, it will be forwarded to all other nodes in the Bitcoin network.
After some time, a miner will take your transaction and put it in one block he mined.

This shows, that it is not needed to track which public keys were already used.
You just prove that you are the owner of the private key by signing the transaction.

Here are some of them.

@aantonop ‏
@WorldCryptoNet ‏
@jimmysong ‏
@ToneVays ‏
@theonevortex ‏
@WhalePanda ‏
@jfnewbery ‏
@brian_armstrong ‏
@eric_lombrozo ‏
@LukeDashjr ‏
@SatoshiLite ‏
@VitalikButerin ‏
@petertoddbtc ‏
@jgarzik ‏
@barrysilbert ‏
@gavinandresen ‏
@rogerkver ‏
@ErikVoorhees ‏
@coinbase ‏
@BitcoinMagazine ‏
@coindesk ‏

Regarding the technical part of Bitcoin, I can recommend the book "Mastering Bitcoin" from Andreas Antonopoulos. It gives a great insight view of Bitcoin.

On social media I used to check the r/Bitcoin Reddit, but I think it does take too much time to filter good from bad topics.
In my opinion twitter is the better source to get news if you find some people to follow who have good knowledge in this space.
I'm also subscribed to the Bitcoin Dev Mailinglist and some Bitcoin github projects to learn about new stuff happening with Bitoin.

Just want to add something I haven't thought before.

The nLocktime way does work, as long as you transfer your coins to one of your own addresses (what you actually do, when you want to split them).

So even if the nLocktime does not work correctly the first time, and the transaction got replayed, you can try again and again until it worked, just from the new address.
In this case you would not risk to lose your coins, but it might take long and could be expensive depending on how many transactions you need to finally split your coins on the networks.

But that's only needed in case of no replay protection. I still hope they work on something like this.
Some people claim, that the Segwit2X developers are working on the client - just not on github, but internally. Hopefully this is true and they also think about a replay protection.
Nevertheless, hiding what you are doing in an open source project is not something that generates trust...

Wouldn't a termograph image change all the time? Environment could influence the image (is it hot or cold). Someone who just did a workout, long walk, hot or cold shower or whatever would produce a different image. Someone who gain or lose weight would have a different image.

Even if it would be unique and don't change over time, how do you get all those images in a trustful way to the blockchain? How can you prevent uploading fake images?
Would you need to confirm your image for every transaction or only for the initial spread?

Can confirm, blk0925.dat has also been last updated on 7/6/2017 on my system.

Ok, understood. You use symlinks directly to the files, not to the whole directory. Makes sense, I haven't thought about this.

And thanks for describing the way to split the chain after the fork.
Just in the case someone download a complete new version of the blockchain, it might get tricky to find the correct last common data file as all files would have more or less the same time stamp (+/- 1 or 2 days, depends on download and validation speed).

You are right. This is something what could be a real problem. If the same chain hopping happens like with Bitcoin Cash, you can run in exactly your described situation.
I guess the only secure way would be just to wait until both chains have a stable hash rate to minimize this risk.

Nevertheless I also would prefere that the Segwit2x devs implement a replay protection. Even if the timelock trick would work 100%, with the current clients it is too complicated to do for the average user.

One not meant seriously, but working way is the following:

• Create a fork from bitcoin github
• Change some consensus rules with which the core developers are not happy with
• do big advertisement why your incredible idea is better than what the core developers are doing
• find followers who also spam social networks to convince people to change from "bitcoin core" to your "bitcoin awesome"
• do the fork
• bingo, you have a new altcoin with a big userbase
• in the best case you also convince merchants, payment processors, exchanges etc. from your idea and just take over the brand "Bitcoin" for you
• One disadvantage is, that you might not get rich with this idea, because you cannot premine a new currency to give you an advantage over all the other people. But even for that I have an idea for you. Change the consensus rules in that way, so you can redeem Satoshis 1 million bitcoins and send it to an address you control. After all you don't want to start the new currency with at least 1 million burnt or unused coins 

Whoever finds similarities in the past or future, may keep them.

There is a safe way to prevent a replay attack with the nLocktime feature of bitcoin.

Checkout the link which explains how it works.
https://freedomnode.com/blog/79/how-to-prevent-replay-attack-by-splitting-coins-in-the-event-of-a-bitcoin-chain-split#h-locktime

Good question. From the sources I receive my information from I get the feeling, that the majority of interested bitcoin users (people who follow bitcoin news, are somehow active on twitter/reddit or here in this forum) have closed the case Bitcoin Cash. This topic is not that hot anymore as both sides have their preferred solution now and are more or less happy with it.

The segwit2x topic is much more a topic at the moment as it will produce another hardfork in November. None of the sides really want to split Bitcoin again, but the positions on both sides are cemented. No one want to move towards the other side. So I think a split will definitely happen. The big fight until this split will be, who can convince the majority of miners, nodes, users, eco system etc. for their side.

The segwit2x fork will definitely create more chaos as the 2x supporter don't plan to implement a replay protection. Experienced Bitcoin users might not have a problem with it, because there are ways to safely split their coins in case of the fork, but the average user might not have the knowledge to do it. And people who never heard before about that fork may lose some money because of missing replay protection. Also people who don't control their own private keys, might not get access to their new "free" coins.

So, my biggest concern is the missing replay protection. The real support for one of the two sides we will only see after the fork happened. Hard to predict the future.
Also I'm concerned that in future this kind of forks could become common practice. I think this could weaken the Bitcoin brand in the worst case.

In terms of Bitcoin, I think the Bitcoin Core developers and their supporters have done more "proof of work" for their side, than the segwit2x developers/community.

I also think the easiest way not get any conflict with the data directories you should create two different users.
Run bitcoin core with user 1 and bitcoin abc with user 2.

If you build the bitcoind yourself from source, you should NOT execute the "make install" command. This would copy the bitcoind to /usr/local/bin. If you would do this for both versions, you will only have one bitcoind installed correctly, as for both clients the executable is named 'bitcoind'

Instead you should execute the bitcoind from the build directory of your source (usually found in bitcoin/src/bitcoind).

If you use precompiled clients from tar balls, you can also execute the bitcoind executable directly from the directory you extracted it.

To speed up syncing I would start only the bitcoin core (version 0.15 - bit faster than 0.14) first to get the complete blockchain.
After finished syncing, copy the complete datadir from core to the abc datadir and then start the bitcoin abc.

I'm just not sure if copying the datadir will work correctly with the blocks mined after the fork.
I've done this before the fork, so both blockchains were the same at that time. Now as they forked, maybe copying the datadir does produce errors with bitcoin abc.

Maybe someone can tell if this is an issue or not?


Isn't using symlinks dangerious? Even only for the blocks directory? Both clients would write into the same directory and also same files. Before the fork they were identically, but after the fork they look different. So I'm not sure if this would mess up the data files?

If the Ethereum developers don't reach the majority of people when they plan to do a hardfork, there is a big chance, that the network will fork.

But even if the chain forks, this does not mean, that the old chain can survive.
If you don't have a developer team which continues to work on the old version or people who are willing to keep the old chain alive, this old chain will become obsolete after some time.

The biggest problem with a fork is, if you have 2 or more parties who disagree with the changes. Even when everyone is OK with the new version, you might get a fork because some people are not aware of the new version. But after some time they will identify them self on a more or less dead chain and will switch.

I think a real fork, where both sides survive is more a political problem than a technical one. Bitcoin is the best example for this.

Fingerprint scanners are cheap, yes, but also useless.

Fingerprints can easily be faked. You could claim 1 coin over and over with a new set of fingerprints.
http://www.wikihow.com/Fake-Fingerprints

The CCC (Chaos Computer Club) did this with just a picture from a press conference from the German minister of defense, to prove that fingerprints are not secure at all.
http://www.tagesspiegel.de/weltspiegel/chaos-computer-club-hacker-kopieren-fingerabdruck-von-ursula-von-der-leyen/11163644.html

I also don't know why people think that a finger print can secure their smart phone, when the phone is covered with fingerprints from the owner which can unlock the device...

What about amputee? There is also at least one example with a person without fingerprints at all.
https://www.theguardian.com/world/2009/may/27/man-without-finger-prints

If I understood you correctly, you think, that one coin distributed to each person on earth would change, that poor people are poor.
I think, this will not change anything. You cannot make poor people get rich (or at least wealthy) with this methode.

Ok, let's do some math.
Lets's assume, that Satoshi is a really nice person and donate his 1m btc to create a new currency which is worth 1m btc.
With the current price of about 4000$ per Bitcoin, the market cap of this new coin would be 1,000,000 * 4,000$ = 4,000,000,000$.
At the moment there are about 7.5 billion people on earth. When each of them get one coin, this one coin would be worth 4,000.000.000 / 7,500,000,000 = 0.53$.
This calculation does not include the cost which would be needed to give each person one coin. If you would also calculate those costs, every coin would represent a big debt.

So, this would not change anything. Even with a price of 100,000$ per BTC such a new coin would only be worth 13.33$.

The new currency you want to spread out need to have a significant value to change anything. But this value does not come from thin air. Someone need to invest in it to give it the value it needs.
Just giving one coin to each person would not give this coin any value.

As much as I would love to see a better distribution of wealth, in the real world this will never happen. And unfortunatly this idea cannot work.
But prove me wrong. Maybe you have a better idea to give this coin the value it needs.

I guess no one  in this forum will be alive to see all bitcoins mined.

But maybe in the next decades someone find something to increase the lifespan.
Then the 100 year old members will explain to the 20 year old newbies, why all try to implement a secure POS failed in the last 100 years

There was an unusual raise of transactions yesterday. Over the weekend I saw about 100 - 500 pending tx in the mempool whenever I was watching. During the last week in average of about 1000 - 1500 pending tx.
Yesterday in the morning someone filled the mempool nearly instantly within some minutes with more than 30000 tx and also surprisingly high fees per tx.

Over the day those tx got confirmed and at the moment are about 10000 tx left.

I don't think this was a spam attack. So far it lasted more or less only one day.

Maybe one of the Chinese exchanges sent back the bitcoins to their owners before closing? I don't know. Could be anything...