Bitcoin Forum
May 25, 2024, 02:06:00 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 ... 590 »
2101  Bitcoin / Bitcoin Technical Support / Re: Moving BTC from outdated version of core and Effects on BCH on: October 07, 2017, 06:45:58 PM
so will I need to update the software first and then switch to pruned mode?
You don't have to, but I recommend that you do.

At that point how long do you think it would take to sync?
It depends on your hardware and network connection. It can take anywhere from a few hours to a few days.
2102  Bitcoin / Development & Technical Discussion / Re: Bitcoin-cli move? on: October 07, 2017, 06:44:56 PM
Thank you. If so, what is the best way to have a multi account wallet where you manage 10 - 100 - 1,000 - 100,000 accounts all with different balances?
Use your own account system. Use an external database to handle your accounts and what each person's balance is. Don't try to make each address belong to certain accounts (the Bitcoin Core accounts system doesn't really work like that anyways). Or you can use the multi-wallet feature and have each wallet be an "account". However Bitcoin Core may not be able to handle hundreds or thousands of wallets with multi-wallet. It really is not designed for that use case.
2103  Bitcoin / Development & Technical Discussion / Re: Bitcoin-cli move? on: October 07, 2017, 06:00:26 PM
Thanks. Since it is deprecated, it is not advised to use it any more?
Yes. The accounts system (and thus the move command) is slated to be removed soon.
2104  Bitcoin / Bitcoin Technical Support / Re: Moving BTC from outdated version of core and Effects on BCH on: October 07, 2017, 05:58:48 PM
Can I simply move coins using core to my ledger by sending them to my ledger address using the core client?
Yes.

Do I need to sync the client before it will allow me to send the coins? 
If you have not received any coins after the time that your wallet is synced up to, then no.

If I send the coins will I lose my BCH?
No. BCH is an altcoin and anything that happens on BTC has no effect on BCH and vice versa.

If not how would I send my BCH?
You need to get a BCH client that can read your wallet file or you can import your private keys into. You can use the Bitcoin Core analogous software for BCH which is Bitcoin ABC.

Am I at any risk of a replay attack if I send my BTC and leave the BCH on the core wallet address?
No.

Any other considerations to be aware of when sending coins on an outdated version of core?  I don't plan on using core once I've moved coins to my ledger.
Node policy has changed since 0.8 which makes some transactions that 0.8 may produce (just due to randomness) to be non-standard and thus not likely to propagate well. Furthermore, fee estimation has changed to be much better, and priority has been removed which will also effect how your client sets a transaction fee so you may end up paying too low of a fee for your transaction to confirm quickly. I highly suggest that you upgrade to Bitcoin Core 0.15 and let it fully sync. You can use pruned mode so that it takes up only a few GB of space instead of 140+ GB.
2105  Bitcoin / Bitcoin Technical Support / Re: unconfirmed Transaction on: October 07, 2017, 05:54:30 PM
Those two services are owned by mining pools. They can choose the transactions that they want to include in a block. Usually these are chosen by transaction fee rates, but they have custom changes (or are using Bitcoin Core's prioritisetransaction command) which allows them to make a transaction be more likely to be chosen by their transaction selector so it will confirm sooner by being included in one of their blocks.
2106  Bitcoin / Development & Technical Discussion / Re: Bitcoin-cli move? on: October 07, 2017, 05:49:46 PM
move is a deprecated command that only effects Bitcoin Core's internal accounts system. The accounts system is deprecated. All that move does is that it changes some entries in the internal accounts system. No transactions are actually made.
2107  Bitcoin / Project Development / Re: Bitcointalk Account price estimator on: October 06, 2017, 05:35:40 PM
I had tried several times accessing the website www.bctalkaccountpricer.info but unfortunately the website having a hard time to load. Is the server down?Are you also experiencing this? Is there any alternative website to use for checking bitcointalk account? Thanks in advance.
Loads fine for me.
2108  Bitcoin / Development & Technical Discussion / Re: Random Question about Blockchain and AI on: October 06, 2017, 12:45:22 AM
This thread is attracting a lot of spam and very little thoughtful discussion (besides the fact that the idea is complete nonsense). Therefore it will be locked.
2109  Bitcoin / Development & Technical Discussion / Re: Will quantum computing kill crypto? on: October 06, 2017, 12:43:57 AM
This thread is attracting a lot of spam and very very little thoughtful discussion, so it will be locked.
2110  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core developers along with Blockstream are destroying Bitcoin on: October 05, 2017, 08:22:11 PM
Anyways do you have any prediction over what is going to happen? Since those exchanges will list segwit2x as the Bitcoin, this will be the "legitimate" bitcoin /most used, most traded, priced the highest.
Not necessarily. A lot of exchanges have not said whether or not they are supporting Segwit2x and what they are going to do about it. I don't think many exchanges will list Segwit2x as Bitcoin as many people have threatened to sue them, and at the very least, it will be some very bad PR for them.

Why doesn't core just say okay and agree on the 2MB fork? Because i would say this could get ugly otherwise ruining both of the Bitcoins.. :/
First of all, it is not a 2 MB fork, it is an 8 MB fork. Calling it 2 MB is disingenuous.

Why should Core do something that we believe is harmful to the network? Sure, it might avoid a split now, but it can have huge negative consequences in the future that we want to avoid.

Also if the majority of the hash power goes to segwit2x, the old chain will be stuck and useless. So doesn'+t seem like there is much choice?
No. Miners do not control Bitcoin. Just because the hash rate moves does not mean that Bitcoin is redefined to whatever the hash rate wants. The hash rate will follow whatever makes them the most money (unless they are insane). If few users are using Segwit2x-coin and few exchanges list segwit2x-coin, then miners won't mine it for long as there is no money to be made there. Even if they did go to Segwit2x-coin and stuck with it, Bitcoin Core could do a counter hard fork which both implements a Proof of Work change and implements a lot of features on the Bitcoin hard fork wish list which Segwit2x has thus far refused to do.
2111  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.
2112  Bitcoin / Development & Technical Discussion / Re: Vanity wallets on bitaddress.org/ compressed addresses on directory.io on: October 05, 2017, 03:11:19 PM
So each private key can ultimately produce two different addresses - one compressed and one uncompressed?
Yes.

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?
Yes.
2113  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.
2114  Bitcoin / Development & Technical Discussion / Re: Vanity wallets on bitaddress.org/ compressed addresses on directory.io on: October 05, 2017, 02:54:54 AM
Regarding compressed/ uncompressed addresses, why does directory.io 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).
2115  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.
2116  Bitcoin / Development & Technical Discussion / Re: Vanity wallets on bitaddress.org/ compressed addresses on directory.io on: October 05, 2017, 01:58:43 AM
1) I was interested in creating a vanity wallet on bitaddress.org, 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 directory.io, why do addresses and their corresponding compressed addresses show different transaction information on blockchain.info? 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.
2117  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.
2118  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.
2119  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.
2120  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.
Pages: « 1 ... 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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 ... 590 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!