|
We shouldn't hold an idea that someone is out to get us. Forks happen, their intent is impossible to know. Increasing the block size gives an obvious benefit, so we can't just claim that it is an attack. People can run whatever they want and no one should be attacked for it. No one can hurt you on the blockchain. It is a consensus. If people want a different consensus, then let them have it, it is their right.
That being said I think Bitcoin should avoid any hard forks unless it is necessary. I believe that stability of the technology is very important for it's success.
This is up to the users what they want to use, but I am just making points on why I believe people shouldn't support Segwit2x even tho there is nothing wrong with supporting it if you believe it is a right choice.
I believe that Segwit2x came too early and is putting way to much at stake and therefor puts the users on more pressure to make a choice on something that might not be necessary at all. We haven't seen if Lightning network and Segwit is enough for scaling the Bitcoin network and no replay protection means that you have to make a choice.
It just seems to rushed and to forced for no good reason. If people believe in Segwit2x then that is completely reasonable, but if they believe that they have to activate it in a month, I would say that that is unreasonable. Not wrong or evil, just unreasonable.
|
|
|
|
|
I could imagine that one day a certain amount of most popular blockchains store hashes of blocks from other popular blockchains. That way they kind of secure each other with each others consensus algorithms.
When it comes to competition, they only compete economically as two blockchains may exist for the same purpose. However, if we end up with two blockchains after the Segwit2x block, these blockchains will compete in a lot more serious sense, since there will be no replay protection, they will not be able to coexist in the same user base. As using one means you have to ignore the other one or use them as one blockchain. You won't be able to safely split your coins.
|
|
|
|
The miners however are a vulnerable to majority attacks and I don't know how Bitcoin miners usually run their rigs. Always assumed that it is either by Linux or a embedded system in their miners which they access through webpages on LAN.
Don't overestimate the security. The way I understand mining works is that you have a driver software for the miner apparatus, in case of an ASIC or a video card possibly similar. Then you have the miner software, which communicates with the driver, which communicates with the mining hardware. So the point of failure is still the main computer that controls the miners and is connected to the internet or a mining pool. A million things can go wrong, from potential DDOS, MITM of the pool server, all sorts of nasty stuff. Luckily in mining there is a clear financial stake, so it's in their best interest to figure out if they have been compromized, otherwise they lose a lot of money. McAfee talked about this recently: https://www.youtube.com/watch?v=syI9X_uKvUAThat sounds pretty bad. Sooner or later there will be malware that will have a built in capability of conducting a 51% attack using miner rigs if it reaches a majority hashrate by infection. This just seems like an accident waiting to happen then. |
|
|
|
|
Pa ako nastavimo da budemo aktivni ovde, onda nam mozda i daju board pa da mozemo da pravimo vise topic-a.
|
|
|
|
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.
It is not even about the stable hashrate. These rapid increases in the mempool come out of nowhere. If they all of a sudden come out on the logger chain, you are stuck and the other chain will catch up by the time your transaction is confirmed in the longer chain. So this problem isn't just going to go away in few weeks, it is there forever. These two chains can't safely coexist. Using one means that you completely ignore the other as it doesn't exist. |
|
|
|
So it's a hard fork but with backwards compatibility?
I read on the bitcoin site, not sure if this is useful, but segwit addresses are acceptable in older versions as well but there must be a confirmation from the segwit address to the legacy address before it will be added (basically, it doesn't accept the transactions in the network, just ones already in the blockchsin). Anything segwit comparable and onwards will still use it as if it were a legacy address though.
No. There is no backward compatible hard forks. That is pretty much a definition. Bitcoin Cash was a hard fork, Segwit was a soft fork. People don't need to update to new clients to still accept Segwit blocks. People do need to update to a new client to use Bitcoin Cash as old Bitcoin clients will not accept the 8 mb blocks. As I understand when you send to a segwit address an old node will see those funds to be spendable by anyone, since you don't need a signature in the input for the transaction to be valid. In segwit signatures are detached from the transactions. The point is that miners agreed with the segwit activation that they will not accept transactions that spend from segwit address without providing a signature that is outside the transaction. |
|
|
|
The lack of replay protection is a huge problem as well, I don't think there is a way to safely transact your coins only on one chain. It would be a race in the best case scenario and one chain will almost always win and put the coins in danger on the other chain.
The just means that the it is unlikely that these chains will coexist. As they won't be able to safely so a compromise might be necessary.
This puts everything on bigger stakes as well. I think this could be a very big deal. It is basically miners vs developers. And users might be on the Core side, but no one can be sure. So anything ca happen.
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-locktimeWell, the article makes some assumptions, but ok. Either way it still rests on the race. There are quite real risks, you can't deny that. Transactions get stuck really often, sometimes for days. You do this and the other chain could very well catch up at that point. For example, even tho Bitcoin Cash had a smaller block height it also had emptier blocks (kinda goes together as a consequence of lower support, but doesn't have to be as in this one user and mining support could differ a lot more, also Bitcoin Cash had 8 times the capacity of Bitcoin and S2x will have only 2 times). Either way, the transactions got accepted in Bitcoin Cash in the next block while Bitcoin had a huge problem with too many transactions of which some have to be stuck for days, just because there were to many of them for what Bitcoin could handle. So this article didn't talk about the average block times after the fork which will change rapidly and the transaction increase that might follow and clog the network. It is a lot more complicated that that. The point is that if your transaction is stuck for long enough on the bigger chain, the shorter one will catch up. That is a risk. A quite real risk. 10 blocks given here as an example is nothing for the time your transactions can get stuck for more then you expected. No fee estimation will give you such a precise approximation due to transaction acceleration and the possible rapid increase in new transactions. People had their transaction stuck for weeks during the last fork. Those are thousands of blocks, not 10. 10 blocks is like an hour and 40 minutes. You need to be very precise in your estimation for this to work, which we saw is a very very difficult job, which is far from the "safe" option. |
|
|
|
why not use online walllet like blockchain.info to reduce the computer storage ?
Because what is the point of Bitcoin if you need to trust the third party with your bitcoins? It is required to download the entire blockchain, otherwise, transactions and balance are outdated. There are services who provide the blockchain as a download, so you don't have to connect to nodes who are syncing slowly. After this process, you can prune the blockchain. You can just download it with the network, there is no benefit if you don't sacrifice the security and download the chainstate as well. |
|
|
|
Yeah, I heard about this. Very bad news. However, only people who updated during that time period were infected. And I would say that Windows users hate updates, which is a security problem on it's own, but this time might save them. Wow. You just butchered the statistics here.  Those are the stats of OSes reported by the browsers "collected from W3Schools' log-files since 2003", not the Bitcoin nodes. No it is intersection of correlated samples, while the error margin increases if we mix 2 samples together that are not entirely correlated, since the W3Schools data is a general data it should pretty much be ok to use it. After all we dont what OS the nodes use there is no way to verify that. I am sure the amount of Linux users amongst nodes is higher, but it's not higher by a lot. I see people mining on Windows all the time, even in Monero which supposed to be a ultra high-tech currency which didn't have a GUI wallet just now recently so you'd think that only sophisticated console Linux nerds would use it, but nope, there are plenty of Windows users out there too, which is funny since Monero is the supposed "privacy" currency while Windows 10 is a literal privacy nightmare. Yeah. It isn't good anyway. I have hopes, but it still makes sense that a majority is Windows users. However, you really only need to be connected to one good node out of many to be secure, as it will provide the "longest" chain. The miners however are a vulnerable to majority attacks and I don't know how Bitcoin miners usually run their rigs. Always assumed that it is either by Linux or a embedded system in their miners which they access through webpages on LAN. |
|
|
|
I think the Bitcoin transaction time is 10 minutes per post. But to make sure that your Bitcoin account will avoid the block is to make sure that your time interval is range from 30 to 45 minutes in every post that will you make. You must remember that when your Bitcoin account is block, it is hard to get it back. As a simple reminder, make a post in every 30 to 45 minutes to avoid blocking you Bitcoin account. And last, make a table of time for you to assure that you follow the correct interval time of posting in Bitcoin.
You misunderstood something here. I don't know what you mean by "post". There are no "posts" in Bitcoin network. I thought you might be talking about posting on this forum, but you said transaction time so that makes no sense. Also there is are no time intervals defined in the Bitcoin blockchain, it is just mathematical puzzles that are likely to be guessed by the network on average with 10 minutes of guessing. These puzzles are readjusted every 2016 blocks to adjust to the current guessing speed of the network. Some people refer to Bitcoin addresses as accounts, so I guess that is what you are talking about. There are no blocks on your address. You can send whatever amount of transactions you want and your address will never be blocked by the network. Anyone can make as many addresses as they want as well in a fraction of a second. Blocks aren't necessary since you pay a fee for every transaction to be included in the blockchain. You also don't need to do anything every 30 or 45 minutes or anything like that. Neither on the network nor on this forum. |
|
|
|
Interesting! In your opinion, how has the btc fork affected the bitcoin community so far? any concerns in the future? Thanks in advance for your opinion
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. What is the big difference in this hard fork from Bitcoin Cash is the amount of miner support. Currently around 90% of hashpower (few big mining pools) support it. But not many users or Core developers do. This makes the outcome a lot more uncertain then with Bitcoin Cash. The lack of replay protection is a huge problem as well, I don't think there is a way to safely transact your coins only on one chain. It would be a race in the best case scenario and one chain will almost always win and put the coins in danger on the other chain. The just means that the it is unlikely that these chains will coexist. As they won't be able to safely so a compromise might be necessary. This puts everything on bigger stakes as well. I think this could be a very big deal. It is basically miners vs developers. And users might be on the Core side, but no one can be sure. So anything ca happen. |
|
|
|
bitcoin-qt when i run the program that will start to download blocks how can i stop that? this process will destroy my internet traffic
my questions are:
how can i stop that?
is this a necessary process? and do i need to let that download them all?
Since Bitcoin Core is not a light client, it is necessary if you want to be able to see the current state of the network. Which means the balances of the addresses. You can't really know if you received your bitcoins or if you successfully sent them if you don't download the whole blockchain. The download process is not as much as bandwidth intensive for very long, it takes some CPU later on. The process will probably take around a week or more and will take around 150GB of your hard drive, maybe more. Running a full client has it's costs and benefits. As a benefit you will get a full security and help the network by providing the security for the ones that can't afford to run a full client. |
|
|
|
You can use over TOR that would avoid the block. If TOR was not blocked!
Tor is pretty hard to block. Even China is having a hard time doing it and they have thousands of people employed on trying to block all of the bridges. It will be even harder with IPv6 probably. There are also Blockstream satellites by now that cover almost the whole world. Only Asia left, should be finished by the end of the year. These satellites freely broadcast the blockchain and you can by all of the equipment for like 100$. The satellite is amazing. And the 100$ is kind for every one. But I think not only needs downloading the signals from SAT, but also need uploading the data to the SAT. Does the price including the up-way equipment? As I understand, they don't do up. You couldn't upload even if you wanted to, they have their own transmitters for that. I assume that the idea here was that it is simpler to bypass restrictions to upload then to download. If you are to post a transaction, you can just go to one of many sites and post the raw hex transaction and they will broadcast it to the network for you. Also with the Lightning Network there will be off chain transactions for which you won't need to upload transactions to the blockchain, but will still need to download the blockchain for security reasons (to know if the other party closed a channel). |
|
|
|
Is the security of the Node network in Bitcoin or for that matter any other altcoin (for other altcoins with low node count it's much worse) a mirage given how most users use closed source OS for mining and node hosting? - At the moment we have 9468 operational nodes.
- According to latest stats only 6% of users use Linux.
This means that only 568 nodes are potentially secure, the others are very likely a smokescreen. 94% of the Nodes are very likely vulnerable to any kind of cyberattack, which is a lot higher than 49% on which the node security relies. Call me crazy, but I don't regard closed source virus infested crap OS-s viable for any kind financially sensitive project. These closed source OS-s are really a joke, and they are a joke on you guys who are using them not knowing what kind of potential backdoor or malware it could have, and on us who should have here a secure network of decentralized nodes..... WHICH COULD TURN INSTANTLY INTO A FUCKING BOTNET IF A SOPHISTICATED HACKER COULD INFECT THEM. Wow. You just butchered the statistics here. Those are the stats of OSes reported by the browsers "collected from W3Schools' log-files since 2003", not the Bitcoin nodes. First of all, I would hope that Bitcoin community uses open source OSes in a bigger percentage then W3Schools visitors, due to the whole point of Bitcoin being transparent and all. So this forums stats would be a lot more accurate of course, but still not quite there. Running a full node is a whole different story then browsing the Internet, it is more like running a server. After all, you need to have an open connection to the Internet for this, so you would need to setup port forwarding or use Tor hidden services. Servers are usually Linux systems, for stability and security reasons. So that could impact the stats the most. I guess you could try to scan the Bitcoin nodes for other ports opened on those IPs for hopes of Windows users forwarding more ports. That would make it possible to figure out the OS of the node with some degree of accuracy. But it is obvious that precise stats are impossible to come by. |
|
|
|
So as I understand, you sent bitcoins to some address that was somewhere meant to be used as a Bitcoin Cash address. Now the addresses are the same thing in Bitcoin and Bitcoin Cash, but their balances can differ on the two networks. Now those coins were sent to some address in an online wallet that is called Bleutrade and they don't appear since Bleutrade only shows the Bitcoin Cash balance of that address and not it's Bitcoin balance, correct? I don't really know how Bittrex knows this tho, since no one can really know is an address intended to be use as BCC or BTC address just by looking at them. They are definitely wrong when they call it a BCC address, as there is no such thing. Addresses are the same thing in both, they can just have different balances on them. What you need to do, if this is the case, is to go to that Bleutrade wallet where you sent those coins, even if they don't show up, and find a way to export the private keys for that address. Navigate around, I never used that wallet personally, so I can't be more precise. They're lying to you...
You can easily import a bitcoin private key/bitcoin cash private key into another wallet. BCC is a soft fork of BTC, therefore, BCC private keys have the exact same format as BTC private keys.
They probably don't want to help you as it takes them time for something they consider to be your mistake (even though it is probably recommended tha they set the bcc and btc deposit addresses to the same unless a user requests a different one for eac wallet to resolve this issue). However, good luck in getting your coins back!
I guess it is just a slip of the tongue here and that you meant to say a hard fork. |
|
|
|
Hmmmm.... Ya I don't know they make it sound like it is so easy when its not. What is this ss7 ?
There is a wikipedia article for more information https://en.wikipedia.org/wiki/Signalling_System_No._7I still don't think it's easy and it is ment to be a second defense not primary. I dont use SMS though I use the authenticator and I'm sure it's very safe.
It is true that it is usually a second defense, although there are often account recovery options using a mobile phone. I am not sure about the authenticator, but if it works when your phone is not connected to the Internet then it is using SMS and the SMS might not be encrypted. |
|
|
|
I see people calling for 2FA as a safety mechanism for their accounts even tho there is a huge vulnerability in the mobile networks known for years now. 2FA just increases the complexity of the attack, it doesn't stop it at all. Here is an article from The Hacker News that came out today about using 2FA on Bitcoin online wallets like Coinbase, although they say that it isn't a vulnerability in Coinbase at all but in the mobile system design flaws instead. https://thehackernews.com/2017/09/hacking-bitcoin-wallets.htmlThe conclusion here is that you shouldn't consider a mobile network safe. |
|
|
|
I want to know where I should look to learn to code for the bitcoin blockchain or the necessary steps? I don't mind if it's hard work or time consuming, I'm a complete rookie but I do not mind learning. If you have any material, sites, or wish to help me directly email me bitcoinvegan@protonmail.comIf you are looking for coding for Bitcoin then that is a one thing, but it is different if you are looking to make programs on the blockchain, which can't really be done on Bitcoin as much as on Ethereum. |
|
|
|
Hvala svima na odgovorima.Sta mislite o tome da ovde pokrenemo raspravu o tome ko prati koji coin i misli da ima svetlu buducnost nesto kao kutak za trejdere.Naravno cisto informativno svako iznosi svoje misljenje i na kraju svako donosi svoju odluku.
Evo ja da krenem prvi, trenutno imam dosta verge i cekam da ga prodam jer uskoro treba da se pojavi na binance i hitbtc berzama pa ocekujem pump.Za long mi je lbc za nekih mesec dana bi trebali da izbace search opciju i da konacno moze da se koristi aplikacija i lbry coin krece da se trosi
Sto da ne? Neka kaze svako sta ima. Ja samo Bitcoin gotivim, nemam neke bas nade u ostale, bar ne dugorocno. Nikad nisam cuo ni za verge pre ni za lbry, koliko vidim prvi je kao monero, samo ima algoritam koji je vise podlozen centralizaciji, a drugi je nesto kao za deljenje videa? Tako nesto...Steem je vec popularan za vesti i deljenje tekstova ( i slika ja mislim), a postoje i oni za cuvanje fajlova kao sto su Storj i Sia koji bi vrv mogli da se koriste u istu svrhu za video. |
|
|
|
I just had a mental breakthrough and realized that increasing block size would make the fees go down because it allows for faster transaction frequency... So all the debate about block size is also about the transaction fees. Now I am inclined to think that increasing block size is good. What are the arguments in favor of small block sizes?
I totally agree with you on using altcoins because bitcoin fees are too high. I personally use Ripple to transfer cheap between crypto exchanges, other people use litecoin, ...
I believe that the argument is that it will cause centralization because only big data centers would be able to run full nodes. And that the block size increase needs a hard fork, which means that it forces old nodes to upgrade to new software. The point is that Core believes that change is not necessary and it has it costs, so they try to go around it with the Segwit softfork. @andreibi And is Segwit + Lightning incompatible with large block sizes? I am long on both bitcoin core and bitcoin cash, I want both to succeed, I just would like to know what are the arguments for low block size.
Segwit and LN are compatible with large block sizes, which is exactly what a upcoming hard fork in the second part of November is trying to do. The so called Segwit2x will increase the block size from 1 mb to 2 mb, since Segwit is already activated on the Bitcoin network. It has a support from big mining pools for now, but the Core team and many users don't really support it. We will see how it turns out. The fork is more unpredictable then the Bitcoin Cash fork, since it has a bigger support and the split could be bigger. |
|
|
|
|
Show Posts
