Bitcoin Forum
December 12, 2018, 01:18:34 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 547 »
1221  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core developers along with Blockstream are destroying Bitcoin on: October 05, 2017, 04:00:00 PM
This is just not true. Please stop spreading FUD.

Blockstream does not control Bitcoin Core; out of the five people who have commit access, only one person is a Blockstream employee (and founder). The others either work for their own companies that they founded or are part of the MIT DCI. In all contributions this year (since Jan 1 2017), there have been 41 contributors. Of those, I count 8 Blockstream employees or contractors related to Blockstream (of which at least 3 are founders of the company, and 2 don't really seem to work for Blockstream but are listed on their website), 2 that work for the MIT DCI, 6 Chaincode Labs employees (one person overlaps with Blockstream) and 22 people who work for other companies (only one or two per company), work for their own companies that they created, or are independent contributors contributing whenever they feel like. Many of the Blockstream contributors contribute rarely and also do so when they feel like; they are not paid to work exclusively on Bitcoin Core.

Blockstream does not need to influence or change Bitcoin in order to have products. They already have the Liquid sidechain which is a product for exchanges and it does not need Segwit or other changes to Bitcoin's consensus rules. This sidechain was already in use before Segwit activated.

Some days after hurricane Irma there was a fundraiser for one of the Core developers, whose house had been damaged by hurricane. The goal of the fundraiser was to raise 5 Bitcoins for the Luke Dash jr(Bitcoin Core developer) in order to fix his house and property.

Luke Dash has developed first Bitcoin mining pool in 2011. At that time Bitcoin was worth around 0.3$.
Someone who knew about Bitcoin in 2011 and devoted it's time to work on the project, did not invest anything?!?! That tells us, that Luke Dash is not a speculator, he does not know anything about economics, all he is - is a programmer and that's all he knows to do.
Do you not think that maybe he has spent those coins? Maybe he speculated in the early days and lost money in the number of scams and exchange collapses (e.g. MtGox) which leaves him with little to no Bitcoin today. Luke has a family (a rather large one too) which he has to support; do you not think that perhaps he has used many or all of his Bitcoin to help support his family and do other things which require money?

So Luke Dash obviously doesn't own (m)any Bitcoins considering he needed to raise funds for the repairs of his house and property, so he can only make money by getting paid from Blockstream for the development.
Luke is not a full time employee of Blockstream; he is an independent contractor. I don't think he is paid much for doing that considering that he has not done much for Blockstream and is not being paid by Blockstream to work on Core (according to some conversations I have had with Blockstream employees).

And i would guess most other core members are like this. They are programmers. They enjoy coding and improving Bitcoin as they did from the start. They did not buy Bitcoins hoping they would get rich, but they probably looked at it from a programming perspective.
Their salary now depends on Blockstream and they have to follow the rules.
As I said earlier, that is not true at all. Blockstream is not the only company paying people to work on Bitcoin Core and they do not control Bitcoin Core.

Core members have said it in the past that increase of the block size would be okay, even up to 8MB!!
Source? IIRC the only "okay" increase was up to 4 MB, which is what Segwit does.

So what is wrong with the segwit2x now that it is considered an attack?
The fact that it is being done by an agreement made by a bunch of corporate executives and miners in a backroom deal without consulting the community or the technical community (which includes much more than just Bitcoin Core developers).

Is there any good argument against Blocksize increase? And don't mention the blockchain getting too big. In one year the blockchain has grown from 85GB to 135GB, increasing by 50GB. With 2x block size increase, this would be 100GB per year. The cost for storage is rapidly decreasing as technology is progressing, and in 10 years the estimate block size(with segwit2x) would be 1,135TB. At current prices this would cost around 50$, and we all know in 10 years 1TB of storage could cost a few dollars.
And how many people actually run a full node? It seems all nonsense to me.
It is not the storage requirement that is the problem, it is the bandwidth and computing requirements. Clearly you do not understand the nuance and other consequences of a block size increase. It not only requires more disk space (which is trivial) but it also requires full nodes to consume even more bandwidth and data and may not be able to support larger blocks. So we would see a decrease in full nodes from a number that is already pretty low, less than 10000 full nodes. A full node consumes somewhere around 300-500 GB of data per month, and that is with 1 MB blocks. With segwit, that size will be even larger, and with 2X, potentially more than double. In the worst case, it would be 8 times that amount. In the US, some ISPs (like Comcast) are instituting data caps at ~1 TB of data per month. Bitcoin nodes are likely to be consuming nearly all of that data (thus restricting the amount of data that home node operators can use for other things) or even exceed the data cap if Segwit2x were to pass. This will cause the entire network to lose nodes as users turn them off so that they have enough data to do other things that consume a lot of data, but not as much (e.g. watch 4K Netflix).

Furthermore, larger blocks can require more computation to validate and thus a malicious block that takes several seconds (which is ages in computer time) to validate now would be even worse if the block size were to be increased even more.

Lastly, there are many other considerations that you need to look at when increasing the block size. Things like UTXO set growth, initial sync time, hardware requirements, etc.
1222  Bitcoin / Development & Technical Discussion / Re: Vanity wallets on compressed addresses on on: October 05, 2017, 03:11:19 PM
So each private key can ultimately produce two different addresses - one compressed and one uncompressed?

And different private keys can produce the same address
Yes, in theory. It has not happened yet.

(i.e. there are 2^96 private keys for each address)?
Not necessarily.

So they're the same keys but when hashed produce different addresses?
1223  Bitcoin / Project Development / Re: Digital Bitbox (a hardware wallet) Discussion on: October 05, 2017, 04:21:43 AM
Thanks for clearing that up, I was not aware for that. What other prominent altcoins use ECDSA, or rather which ones don't use ECDSA?
The vast majority of altcoins use ECDSA. Any coin that is based off of Bitcoin Core will likely use ECDSA. Litecoin certainly uses ECDSA.

Is there software support for any of those other coins yet?
I don't know. Digital Bitbox themselves do not really offer a wallet to use. So it depends on all of the other wallet developers to support it.
1224  Bitcoin / Development & Technical Discussion / Re: Vanity wallets on compressed addresses on on: October 05, 2017, 02:54:54 AM
Regarding compressed/ uncompressed addresses, why does list compressed addresses next to uncompressed ones? When you create a compressed address is this in fact a new address from the 2^160 pool of public keys?
There is no pool of 2^160 public keys. It is a pool of 2^160 addresses, not public keys. There are 2^256 private keys and each private key has exactly one public key, so 2^256 public keys. Each public key can be represented in two ways, in uncompressed form and in compressed form, so there are 2^257 representations of all public keys. Each representation of a public key corresponds to exactly one address because it is a hash of a representation of a public key. Because of the pigeonhole principle, more than one public key can correspond to the same address (and thus an address can have more than one corresponding private key).
1225  Bitcoin / Project Development / Re: Digital Bitbox (a hardware wallet) Discussion on: October 05, 2017, 02:51:32 AM
So the bitbox actually just acts like a "gateway" or second layer of encryption for signing messages and transactions?
Kind of.

The best description for it is a signer-on-a-stick. It holds private keys and gives you an ECDSA signature for whatever data you give it (and a few other things, but those are less relevant). It does not matter whether you are signing messages, transactions, or arbitrary data, it will sign it. This means that it works for anything that needs an ECDSA signatures, including things that are not cryptocurrencies.
1226  Bitcoin / Development & Technical Discussion / Re: Vanity wallets on compressed addresses on on: October 05, 2017, 01:58:43 AM
1) I was interested in creating a vanity wallet on, but it points me to the vanity pool website to paste my public key and there's no field to do so. Is the vanity pool website defunct?
Yes. If you want to generate a vanity address, it is recommended that you do so yourself on your own hardware using the vanitygen software.

2) On, why do addresses and their corresponding compressed addresses show different transaction information on Aren't they essentially the same address?
No, they are not the same thing. An address corresponds to the hash of a public key. The hash of an uncompressed public key will be different from a compressed public key, so there are different addresses and thus different transaction histories.
1227  Bitcoin / Development & Technical Discussion / Re: BTC-1 - Trojan Update! on: October 05, 2017, 12:19:12 AM
btc-1 already prefers connecting to other btc-nodes. So they will be fine.
That only works if the service bit is advertised. This commit gives btc1 node operators the option to hide that service bit, so the preferential peering will not be as effective or may not work.

Once fork happens think nodes will ban others that send invalid blocks/txs. And both btc-1 and core will instantly think the fork block from the other chain is invalid - and then some tx's soon after that.

So actually even if you are isolated - once you get a load of invalid tx's you will then ban them and connect to someone else.. (I think...)
The transaction format does not change so not all transactions will be invalid. Because they do not implement mandatory two way replay protection, the majority of transactions will be valid on both chains, so nodes will not disconnect and ban each other because of transactions.

Nodes will be disconnected and banned because of blocks. The block at the fork height must have a block weight larger than 4 million, in theory (not sure whether this is actually how it is implemented). This means that that block will be invalid to Bitcoin Core nodes. However the way that Bitcoin Core bans and disconnects peers for invalid blocks (and the same way that btc1 does) is a bit weird. It will only ban the first node that relays it an invalid block. So this means that each new btc1 block found will result in Bitcoin Core banning only one btc1 node that it is connected to. For each non-btc1 block found, each btc1 node will ban one Bitcoin Core peer. So at the time of the fork, the network will not split cleanly and there will still be many btc1 nodes connected to Bitcoin Core nodes even though they are following different consensus rules.
1228  Bitcoin / Project Development / Re: Digital Bitbox (a hardware wallet) Discussion on: October 05, 2017, 12:11:18 AM
The Ledger Nano S and Trezor are definitely better by my standards because they both include altcoin support, something the bitbox lacks.
That's actually not true. The Digital Bitbox supports any cryptocurrency that uses ECDSA as a signing algorithm. The digital bitbox is unlike other hardware wallets, it is just a signer. This means that you actually have to have software that understands the transactions and prepares them to be signed unlike the Trezor and Ledger Nano S which do that preparation on device (which is why they have to support individual altcoins). The Digital Bitbox can support any altcoin using ECDSA so long as the software that you are using supports the Digital Bitbox.

aren't supported in any major wallet (Mycelium, Electrum)
That's not true either. Electrum supports using the Digital Bitbox.

How heavy is it? What is the construction materials like? I hope it is not that heavy. The heavier the item is, the more chances it gets messed up if you accidentally drop it. I'm kinda looking for a secondary hardware wallet which i will give to my fiancee for her spending.
The digital bitbox is very light and small. It has no screen and is about the size of a small USB flash drive.
1229  Bitcoin / Development & Technical Discussion / Re: BTC-1 - Trojan Update! on: October 04, 2017, 06:18:26 PM
So it's basically a mechanism to bypass or to try to hide the service bit so they are not detected and disconnected from the network?
Yes. But they really wouldn't be disconnected from the network because not all of the network has upgraded to using Bitcoin Core 0.15. They can still connect to earlier Bitcoin Core versions like 0.14.x and 0.13.x.
1230  Bitcoin / Development & Technical Discussion / Re: What is the blockchain technology? on: October 04, 2017, 06:16:39 PM
1. Are all private blockchains permissioned or what makes a blockchain private?
A private blockchain could be one which is simply not available to the general public, e.g. a piece of software that is only distributed to a certain number of people. Of course, to keep the blockchain private, a permissioning system would probably have to be in place.

2. If a private blockchain has only one permissioned entity that can append new blocks ("miner") and it doesn't do any PoW or PoS, how close this entity becomes to a traditional middleman? I understand that they can't alter transactions is they are signed by digital signatures, but what they can possibly do?
It is no different from a traditional middleman. That single entity can alter the transaction history and censor transactions because the PoW is what makes the Bitcoin blockchain immutable. Such a private blockchain would be centralized and no better than a central SQL database. In fact, it is worse than a central SQL database because it is more inefficient than such a database.

3. Are they vulnerable to some attacks that don't exist in decentralized blockchains?
Certainly. Permissioned blockchains require using different cryptography and have completely different security models, so is vulnerable to different attacks than a decentralized blockchain.
1231  Bitcoin / Development & Technical Discussion / Re: BTC-1 - Trojan Update! on: October 04, 2017, 06:10:25 PM
So yes, they try to keep the network as tight as possible as long as the consensus is the same. Sounds valid. But to defer solving a possible lack of nodes right until the point where the hardfork occurs seems kinda insane to me.
They don't want their nodes to be disconnected from the rest of the Bitcoin network. However this commit really just does them more harm than good.

btc1 implements a preferential peering policy like Bitcoin Core does for segwit. However that policy relies on the service bit, so by disabling the service bit means that they a) won't be disconected by Bitcoin Core 0.15 and b) are less likely to be able to find other btc1 peers so when the fork happens, they are even more vulnerable to being isolated from the network.

This change really is an emotional reaction to Bitcoin Core 0.15's disconnection of their nodes.
1232  Bitcoin / Development & Technical Discussion / Re: How would I create a bitcoin blockchain bootstrap file(s) ? on: October 04, 2017, 03:33:09 PM
looks like I chose another folder.  Is there a blockchain file name I can search the computer for to find the folder?  It was early this year I installed it on this machine so my memory is gone.
Search for wallet.dat. That is your wallet file and it is located in the datadir. When you copy the datadir to a new computer, make sure you do not copy the wallet.dat file.
1233  Bitcoin / Development & Technical Discussion / Re: BTC-1 - Trojan Update! on: October 04, 2017, 03:29:16 PM
The nodes would split off anyway as soon as the hardfork occurs. Unless core is already pre-emptively rejecting btc-1 nodes for reasons that I'm not aware of, I doubt that there is need to cut these nodes off as long as they follow consensus.

Either way I don't fully get the rationale behind this. Is it to mask their numbers? Even so, what would that accomplish, other than general chaos? I see neither SegWit nor SegWit2x nodes benefiting from being unable to determine whether they follow the same blockchain.
Bitcoin Core 0.15.0 will disconnect (note disconnection is not the same as banning) any peer which has the segwit2x service bit set. The reason for doing so is to avoid a sudden change in network topology at the time of the fork. It allows Bitcoin Core nodes to ensure that they are connected to other Bitcoin Core nodes and btc1 nodes to ensure that they are connected to other btc1 nodes prior to the fork so that when the fork happens, some nodes (either btc1 or Bitcoin Core) don't find themselves suddenly isolated from the reset of their consensus network. It makes the fork happen more smoothly so that btc1 nodes are not surrounded by only Bitcoin Core nodes (and thus be isolated) and vice versa.
1234  Bitcoin / Development & Technical Discussion / Re: Potential SHA256 Mining Speedup (2.3%) on: October 04, 2017, 03:50:24 AM
I just mentioned the 128 rounds to calculate the % reduction in overall calculation, 3 out of all 128 rounds (ignoring the other calculations that need to be done).
If you are counting all rounds, then it's 192 rounds. The first SHA256 requires 128 rounds (because the header is larger than 512 bits) and the second only requires 64 rounds (because it is hashing the 256 bit hash).
1235  Bitcoin / Development & Technical Discussion / Re: Node gets stalled stop receiving connections on: October 04, 2017, 03:44:14 AM
Nothing looks wrong with your node. It is likely that bitnodes' crawler is just unable to connect to your node for some reason so it thinks that you are no longer on the network. However bitnodes is not definitive and it is fine if your node is not listed on their website. You have multiple connections to the network and are clearly in sync, so everything is fine.

The reason your connection count is so low is likely because your node appears to be IPv6 and TOR only. This means that you are very limited to the number of peers that you are able to connect to (not many use IPv6 or TOR).
1236  Bitcoin / Development & Technical Discussion / Re: How would I create a bitcoin blockchain bootstrap file(s) ? on: October 04, 2017, 03:41:36 AM
Awesome! By the way, what folder is the data folder?  I might have done a configuration or registry key to change the folder too.  If not, what files to windows search for to find the folder?
The first time you started Bitcoin Core, you were prompted to choose a datadir. If you did not choose a custom one and left the default, then it will be in C:\Users\<your username>\AppData\Bitcoin
1237  Bitcoin / Bitcoin Technical Support / MOVED: XBT vs BTC & Wallets on: October 04, 2017, 03:40:49 AM
This topic has been moved to Trashcan.

1238  Bitcoin / Armory / Re: XBT vs BTC on: October 04, 2017, 03:40:02 AM
The software does not care about any abbreviations. Armory will be using BTC for any Bitcoin denominated things. The abbreviations are a human abstraction, the network doesn't care.
1239  Bitcoin / Development & Technical Discussion / Re: Potential SHA256 Mining Speedup (2.3%) on: October 04, 2017, 01:33:09 AM
Given that there are 128 rounds
The second sha256 hash is only hashing 32 bytes (the result of the first sha256 hash) so there are only 64 rounds for that.

Note that the difficulty IS NOT determined by "number of 0's" but rather that the target must be less than a certain value. This happens to result in the hash having a lot of 0's in front of it, but that is not actually what is being checked.

Also, the hash that is actually produced is the byteswapped version of what we actually see presented to us. I'm not sure if that effects this.
1240  Economy / Currency exchange / Re: Sending BTC to my company bank account on: October 03, 2017, 09:59:57 PM
No. Bitcoin is not fiat and is not part of the traditional banking system. You must convert your Bitcoin to your local currency before you can deposit the money into a bank account. You can do that through various online exchanges.
Pages: « 1 ... 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 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 547 »
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!