Bitcoin Forum
November 17, 2018, 07:54:12 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 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 ... 547 »
281  Bitcoin / Bitcoin Technical Support / Re: Electrum doesn't restore right wallet address on: April 23, 2018, 08:20:28 PM
Your address for Bitcoin Core is a segwit address. However there is currently no standard way for exported private keys to indicate that the address to create is a segwit address. When you import that into any wallet, it will assume that the private key is for the non-segwit address, and thus you get the non-segwit address in Electrum.

AFAIK there is currently no way to import private keys for segwit addresses from Bitcoin Core to Electrum.
282  Bitcoin / Development & Technical Discussion / Re: Can coinbase transaction contains multiple destinations? on: April 23, 2018, 01:35:40 AM
Thanks, another question, can the coinbase output be P2SH address? And can it be segwit?
Yes. The outputs for a coinbase transaction are just like outputs for any other transaction.
283  Bitcoin / Development & Technical Discussion / Re: Can coinbase transaction contains multiple destinations? on: April 23, 2018, 12:50:01 AM
Can coinbase transaction contains multiple destinations, or does it have to be one output? For example, for the current reward 12.5, if set the coinbase tx to send 10 to one address and 2.5 to another, is it a valid coinbase tx and will it get confirmed by the network?
Yes, you can have a coinbase transaction with multiple outputs. The sum of the outputs just needs to be less than the block reward (block subsidy plus transaction fees).
284  Bitcoin / Armory / Re: Armory 0.96.4 release on: April 23, 2018, 12:48:37 AM
quick question.  if i want to build from source in Ubuntu, which one of these do i download:

Source code (tar.gz)
armory_0.96.4_src.tar
Source code (zip)
Downlaod armory_0.96.4_src.tar. The other ones are automatically generated by Github and do not have all of the necessary components.
285  Bitcoin / Bitcoin Technical Support / Re: script.bin on: April 22, 2018, 10:13:25 PM
A script is a sequence of bytes that gives instructions to the script interpreter. It is not human readable data and attempting to interpret the raw bytes as text as you have done will result in garbage (which is what you are seeing). Typically people examine scripts encoded in hexadecimal or they decode the script into text that represent the opcodes and data provided in the script. The data is usually in hex.

What are you trying to do with the script?
286  Bitcoin / Development & Technical Discussion / MOVED: atomic coin forked on: April 22, 2018, 04:20:33 PM
This topic has been moved to Trashcan.

Duplicate
287  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 21, 2018, 07:55:57 PM
can i addnode= from local LAN that's running a full node to my spv wallet to sync from alot faster then say using the internet? Reason i run 2 copies is i hate copying that 150 gb of data over my network ~ 30 mins to backup the entire blockchain
No, you cannot sync from an SPV wallet, that's not how Bitcoin works.

How long does it normally take for the PPA repository to catch up with the latest version?
Sometimes it can take a few weeks.
288  Bitcoin / Development & Technical Discussion / Re: send bitcoin from BTC network to BCH network on: April 20, 2018, 03:30:30 AM
It is not possible to send BTC to BCH and vice versa. They are two completely separate coins with their own networks and blockchains. BTC and BCH are completely incompatible.
289  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 18, 2018, 02:49:35 PM
hello

i mine now with 6 gtx 1060 3gb card bitcoin core on simpel miner but i find not a good setting
can some one hulp me thx

You cannot mine Bitcoin with GPUs. You won't have enough hash power to mine anything.
290  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 18, 2018, 03:48:33 AM
SO Bitcoincore there is nothing innovative
Not at all. Bitcoin Core is simply not implementing the Lightning Network because that is a completely separate thing which other people are already experts in and doing. There's no point for Bitcoin Core to do anything with layers on top of Bitcoin, it has to handle the base layer.
291  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 17, 2018, 11:43:03 PM
Bitcoin Core is not a Lightning Network?
No. Bitcoin Core is a node and wallet software for Bitcoin. It is unrelated to the Lightning Network. Bitcoin Core does not have the functionality for the Lightning Network.
292  Bitcoin / Development & Technical Discussion / Re: Why isn't Satoshi's one-time address-key pair proposal implemented? on: April 17, 2018, 11:36:24 PM
In electrum wallet the default is to use 1 receiving address. Although multiple addresses are generated when I initially create a wallet, they are never used (not even for change) unless I specifically transfer funds to them. I don't know why.  
I have never seen this behavior before when I use Electrum. It always gives a new address when I click on "Receive".

Is electrum a bad implementation?
No.
293  Bitcoin / Development & Technical Discussion / Re: to what degree could lightning network improve speed? on: April 17, 2018, 08:13:54 PM
The Lightning Network can theoretically allow for infinite number of transactions per second.

however, the main issue are transaction fees which should be almost zero. I am not sure LN will solve that.
The fees for transactions made over the Lightning Network will be near 0.
294  Bitcoin / Development & Technical Discussion / Re: Why isn't Satoshi's one-time address-key pair proposal implemented? on: April 17, 2018, 08:06:29 PM
Why isn't this implemented in Bitcoin Core wallet
It is, and many wallets do use a new keypair for every single transaction. New keys and their addresses are generated every time you get an address to receive Bitcoin. New keys and addresses are generate for every time a change output is needed.

In fact, the only wallets that don't are poorly written wallets that people should not use. Every major wallet software available uses new addresses for change and for receiving.

or enforced as a verification rule?
It can't without being a hard fork because keys have been reused in the past already. Furthermore it reduces the usability of addresses because you can't just post a donation address and receive at it multiple times. It also reduces the usability of paper wallets. This cannot be a consensus rule without disrupting a lot of things.
295  Bitcoin / Development & Technical Discussion / MOVED: Error while compiling the daemon (Cryptonote) on: April 17, 2018, 06:18:59 PM
This topic has been moved to Trashcan.

Duplicate
296  Bitcoin / Bitcoin Technical Support / Re: Old wallet.dat file, synched up, can't send BTC out. on: April 17, 2018, 02:32:23 AM
I believe this was pretty much abandoned since the performance updates to Bitcon Core actually made it sync from scratch faster than you could download and use a bootstrap.dat. I believe this occurred around version 0.14
No the change happened with version 0.10.

Well, I'm hozed and so is about 36.27BTC with it. Ugh..

The wallet/dat file keep saying it's corrupt and crashing the bitcoin wallet, I tried it on 3 different pc's and installs.
Changing the install and computer is not going to fix the fact that the wallet file itself is corrupted. That has nothing to do with the software.

First make a backup of your wallet.dat file. Then try starting Bitcoin Core with the -salvagewallet option. Please also post the contents of your db.log and debug.log files so that we can see what kind of corruption is occurring (sometimes this information is logged).
297  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 16, 2018, 06:22:27 PM
Can I work macOS Sierra?
Yes.

Loosing the wallet after changing the location does not seems good though. Is there any way that we can use to save wallet, even after the location is lost?
What do you mean by "location is lost"? The wallet is a file, and if Bitcoin Core does not know where the wallet is, it cannot load it.
298  Bitcoin / Development & Technical Discussion / Re: Lightning Network / Bitcoin scaling question on: April 15, 2018, 10:59:56 PM
"No one ever claimed that". You did! You said increasing the blocksize would have a worse effect than I can imagine!
I was responding to
Third bolded part:
takes the assumption that Satoshi had some divine knowledge that 1MB was the perfect blocksize and anything larger would lead to the network unraveling.
No one is assuming that Satoshi had divine knowledge or that 1 MB is the perfect block size. Nor did I say that 1 MB is the perfect block size. That is not what the argument is about. It is about the status quo and how changing the block size changes the status quo to something that is worse than now. And such changes have effects that many people do not consider.

I'm saying Bitcoin Core should be doing lots of research on exactly how larger blocks will affect the network,
Do you think that people aren't doing that?

Nothing more clearly shows that the whole argument against increasing blocksize is purely just for the sake of arguing!
Did you not read anything else I said? It is not for the sake of arguing. Do you think that the Bitcoin Core developers are just saying "NO" and then sitting on their asses doing nothing? It isn't because "we don't feel like it" or "we just want to argue". There are reasons for not increasing the block size, it is not just for the sake of arguing.

Instead, for years they have opposed any talk of increasing the block size.
That is simply untrue. Again, segwit increases the maximum size the block message can be. That is, by definition, a block size increase. Furthermore there has been extensive discussion about this topic in the development IRC channels, on the Bitcoin-dev mailing list. There is no opposition to any talk of increasing the block size, Not only that, but several Core developers have proposed their own block size increase BIPs, none of which have gotten consensus. The opposition is to the constant rehashing of the topic. This has been discussed so many times and the same things are said by both sides that it is, at this point, pointless to continue discussing the same things. If you are going to say that the Bitcoin Core developers are censoring the topic, that is also simply untrue. The Bitcoin Core developers are not involved in the moderation of any forums where the topic is discussed.
299  Bitcoin / Development & Technical Discussion / Re: Lightning Network / Bitcoin scaling question on: April 15, 2018, 08:59:00 PM
First bolded part:
okay you're just playing dumb to try to argue with me here. I was obviously talking about blocksize increase. As I mentioned optimizing what can be fit into current blocks plenty of times. Bitcoin core IS against onchain scaling by increasing the blocksize. Segwit is not an example of that, it just optimizes what can be fit into that 1mb block.

Second bolded part:
The block size is not 4mb, it is 1mb. It would take a hard fork to increase this. Segwit did not increase the block size one bit (or byte  Tongue), it is still 1mb. Segwit moved stuff around so more txs can be put into that 1mb. It's block weight is 4mb I believe, but block size is still 1mb just as its always been.
Segwit doesn't optimize anything. If anything, it actually makes transactions physically larger if you use P2SH-P2WPKH. Segwit redefined what block size meant by removing it entirely. The actual size of a block message that is received over the wire can be up to 4 MB. Of course you can (and yo are) argue that the block size hasn't changed because the MAX_BLOCK_SIZE variable did not change, but at the same time, that variable also no longer exists in the code.

Third bolded part:
This whole idea that increasing the size a bit would lead to unimaginable problems takes the assumption that Satoshi had some divine knowledge that 1MB was the perfect blocksize and anything larger would lead to the network unraveling.
No one ever claimed that.

If Satoshi had chosen 500KB instead of 1MB you'd be arguing how an increase to 1MB would be disastrous since 1MB means more centralization than 500KB.
We would be, because 1 MB means more centralization than 500 KB. In fact, some people (luke-jr) argue that we should decrease the size of blocks because that will lead to greater decentralization and that the status quo is too centralized. But the number itself doesn't matter. What matters is the current status quo and how that would be changed. If Satoshi had chosen 2 MB and people were trying to increase that, then the same argument would be happening whenever that limit was hit.

The developers of Bitcoin Core are not arguing for a specific magic block size. What we are arguing for is a block size that is no worse than the status quo. The baseline is what we currently have. Whatever we do in the future cannot be any worse than what we have. If the cost to increase the block to some size were negligible, then we would be for it. However the cost to increase the block size limit to some size greater than what it is now is considered to be non-negligible and thus we are not for increasing the block size yet. Once computing power, network bandwidth, etc. have increased to the point that an increase has negligible cost, then it will probably happen. The current size of blocks are already what is believed to be the most that the network can currently handle if all blocks were absolutely full. While we wait for that day, we will continue to think of other solutions that allow more transactions to be shoved into the same amount of space.

I'm more interesting in what solutions outside of LN have been proposed or do people think are possible to make bitcoin scale, because segwit and LN alone don't even come close. Blocksize increase is absolutely necessary but it too is only one solution that alone doesn't come close to solving things. I've heard of MAST and Schnorr but I don't really know what they do. I've heard of side chains which seems like a great solution but I don't know how practical or feasible they are. Anyone have details or opinions about these things or know of other solutions? The bottom line is we need as many solutions as possible implemented (absolutely including blocksize increase) if bitcoin has any chance of scaling to keep up with the growing demand in the long term.
There are currently known transaction capacitiy increases that are being worked on. The three most active ones are Key and Signature aggregation (previously known as Schnorr signatures), MAST, and Sidechains. Key and Signature aggregation and MAST both make the size of transactions smaller while retaining Bitcoin's security and with the added benefit of additional privacy. Sidechains are more similar to the Lightning Network (but sidechains are not the Lightning Network nor is the Lightning Network a sidechain) in that it moves transactions off of the main blockcahin.

Key and Signature Aggregation allows for one signature to be the combined signature for several different public keys and messages. This means that a transaction with many inputs only needs to provide one signature that covers all inputs instead of a signature for each input. Furthermore, multisig transactions can then have one signature and possibly even just one public key while still allowing for a threshold of signatures (combined into the one signature) be required. In the case of multisig, key aggregation hides how many participants were in the multisig and how many were required to sign the transaction. With only one signature, transactions with many inputs will be smaller.

MAST allows for large scripts to be compressed. The branches of a contract that are not relevant are compressed down into a hash when such a script is spent from. The ideas of Graftroot and Taproot expand this further. All of these also provide additional privacy by hiding information (in the form of a hash) that is otherwise unnecessary for validating a transaction. While MAST, Graftroot, and Taproot can make transactions smaller, they are only really effective with large complex scripts which are not all that frequent. Their primary purpose is privacy. However they are also useful in the Lightning Network because the Lightning Network uses large complex scripts in commitment transactions so these three can be used to shrink those scripts.

Sidechains move transactions off of the main blockchain into individual blockchains that are connected to the Bitcoin blockchain but not everyone needs to know about them. They are similar to the Lightning Network in that transactions occur off of the main blockchain and thus free up space on the main blockchain for other transactions.

And of course there will be solutions that have yet to be discovered. Like the Lightning Network, these solutions are not the end all be all of solutions to Bitcoin's transaction capacity issues. There will certainly be more, people just need to think of them and design them. Those solutions have not yet been discovered.
300  Bitcoin / Development & Technical Discussion / Re: Lightning Network / Bitcoin scaling question on: April 15, 2018, 06:56:29 PM
I'm not sure what things you're talking about for making transactions occur less frequently
The Lightning Network is an example of this. It makes onchain transactions occur less frequently because transactions are moved elsewhere but still use Bitcoin.

But bitcoin core seems ideologically against this, when is is so obvious that it is needed.
This is categorically false. Segwit is an onchain block size limit (redefined to block weight) increase that allows for more transactions.

What Bitcoin Core is ideologically against are changes (especially hard forks) that are controversial and whose effects are unknown. There's more to a block size limit increase than just the number of transactions that can fit in a block. There are considerations such as the computational power required to validate a worse case scenario block, the amount of network bandwidth it takes to transmit a block, the effect that having large blocks will have on the UTXO set, etc.

Bitcoin Core is opposed to changes that reduce the decentralization aspect of Bitcoin. And a hard fork changing the block size limit is one of those things.

but it is technically by far the easiest solution to say all at once boost transaction capacity by say 4 or 8 times with a very simple change.
This is also untrue. Increasing the block size limit is actually very difficult. First of all, the change is not just a one line change or very simple. It requires deployment code which can be very complex and has to handle various edge cases. It involves testing code to make sure that software don't break. It requires convincing everyone to agree that the change is necessary and good (which can be difficult) and convincing everyone to upgrade to the latest software (because actually increasing the limit requires a hard fork so everyone must upgrade).

So an optimized 1mb being increased to 8mb block is a much bigger deal than a non-optimized (the original blockchain) 1mb to 8mb increase.
First of all, the block size limit is not 1 MB, it is 4 MB. This is due to segwit.

Secondly, increasing the block size by 8 times will likely have a worse effect than you can imagine because you are not considering edge cases, worst case scenarios, and all of the nuance involved in block validation and propagation. And of course, increasing the block size limit inherently increases the centralization of Bitcoin because it increases the cost required to operate a full node.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 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 ... 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!