Bitcoin Forum
February 18, 2019, 09:16:28 AM *
News: Latest Bitcoin Core release: 0.17.1 [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 66 67 68 69 70 ... 551 »
381  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?
382  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.
383  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.
384  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.

385  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).
386  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 16, 2018, 06:22:27 PM
Can I work macOS Sierra?

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.
387  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.
388  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.
389  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.
390  Bitcoin / Development & Technical Discussion / Re: Lightning Network / Bitcoin scaling question on: April 15, 2018, 05:36:54 PM
Is it just me or does it seem that Lightning Network is only one piece of what Bitcoin needs to scale?
Yes, Bitcoin will need more changes in order to have more transaction capacity. No one is claiming that the Lightning Network is the end all be all of scaling solutions nor is any claiming that we won't need to do anything else. Those who are don't understand how Bitcoin or the Lightning Network work. It would be naive to think that the Lightning Network would magically solve all of our problems.

Here's my thinking:
Lightning Network you have to open and close payment channels on the blockchain. Your funds are stuck in the payment channel until you close it. So if you are a company using the Lightning Network to get paid you are gonna probably have a bunch of different payment channels open and occasionally close them in order to actually get your money. And as a company selling things you're not going to be sending that money back out through the payment channel, so there is no reason to just keep the payment channel open to make payments, you're just gonna close them to get the money every once in a while. Let's say the company closes a payment channel on average once a month, though likely i think it'd be a shorter period than that.
Not necessarily. If you are a merchant, then you probably have a lot of channels open. So this means that you can act as part of a route for someone else's payment. People can route payments through you and when you need to pay for something, you can route payments through one of your customers.

For consumers, you're gonna open a payment channel with some funds, now occasionally you might get more money from people sending you money like how people use venmo. But generally if you're using LN to buy things your funds are gonna run out even if your friends occasionally send you money venmo-style, so you need to close the payment channel in order to make a new one with new funds. Lets say the typical person funds there payment channel for a month, so you can pay your monthly costs and then you make a new one.
Not necessarily. You can make a single on chain transaction to someone who offers a rebalancing service. So you would pay some amount in an on chain transaction and then the service would send money through the Lightning Network to you so that your payment channel shifts money back to your end of the channel so you can continue to spend it. This would be cheaper than closing and opening the channel as there would only be one transaction fee to pay instead of two.

Doesn't this show pretty obviously that Bitcoin needs larger blocks
Yes. People who directly work with the technology know this and are constantly thinking of ways to increase transaction capacity. Increasing the block weight limit is not the end all be all solution either. Many other things can be done to increase transaction capacity as well. It is a known issue and is even directly addressed in the Lightning Network paper.

2. Side chains - is this the only real solution? I don't know much about side chains, how it would work exactly or their technical feasability. But if you have some network of child sidechains that handle a set of txs and everyonce in a while square back up with the main bitcoin blockchain that would seem to solve the problem. I imagine each tx from a sidechain would be very large since it moved a bunch of money around. So let's just say the bitcoin blockchain can on average handle one sidechain tx (the sum of all sidechain txs) each second and sidechains square up with bitcoin once each block (once ~10 min). Sidechains you have much quicker blocks so their txs get confirmed much faster, though i guess a tx would still need the main blockchain confirmations to be truly confirmed. Anyways, at a rate of one sidechain squaring up with bitcoin per second you can have about 600 sidechains. If each sidechain can handle the throughput of the original bitcoin blockchain (1mb every 10 minutes) then it would allows bitcoin to scaled by hundred of times its current ability. This is global scaling ability. The exact numbers are just guesses of course, maybe one sidechain squaring up with bitcoin would actually take up more than one second worth of txs on the main blockchain. But this seems theoretically the only doable way to truly scale bitcoin.
Sidechains are one of the known methods to increase transaction capacity. However there are still methods that have not yet been discovered, and still methods that we know about that have not been implemented yet. Things such as Key and Signature aggregation will increase transaction capacity by decreasing the size of transactions. It's not just about making blocks bigger or faster or having more blocks; we can also do things to make transactions smaller or transactions to occur less frequently which will help Bitcoin have a higher transaction capacity.
391  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 15, 2018, 05:25:21 PM
Is this new version supported for Lightning Network ?
No. Bitcoin Core is not a Lightning Network software.
392  Other / Meta / Re: Can we ask technical questions about lightning network here? on: April 14, 2018, 03:33:37 AM
393  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 13, 2018, 08:09:57 PM
The rpcpassword and rpcuser for php rpc jason bugs seem not fix?
What bugs? We can't fix bugs that we don't know exist (i.e. no one has reported it to us or we haven't experienced it ourselves). AFAIK, there are no bugs, so you're probably just doing something wrong. Also, rpcpassword and rpcuser are deprecated.

I still cannot just put the password and the user in the bitcoin.conf.
How so? Create or edit the file and just put
394  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 13, 2018, 03:41:59 PM
recommended fee seems always off no way to fix this?
Off in what way? Too low? Too high?

There is no way to change or "fix" the estimated fee unless you modify the source code. Also, just because it seems wrong does not necessarily mean that it is wrong.
395  Bitcoin / Development & Technical Discussion / Re: Lightning Network -QA on: April 12, 2018, 03:19:27 PM
understand, thanks. But how can I open bi-directional channel with any node?

how can I open such channel with some (not mine) node?
Using whatever channel opening functionality the LN software you are using provides. All channels are bidirectional; it doesn't matter who creates them, both parties in the channel can send money to and receive money from the other party in the channel.
396  Bitcoin / Development & Technical Discussion / Re: Bitcoin transaction signature on: April 12, 2018, 03:16:40 PM
In my view it will be more logical if:
1. The Sender knows the Receiver Public key
2. When Sender creates an Output - he encrypts this SINGLE OUTPUT with the Receiver Public Key and puts this encrypted output as and additional field (with name HASH for example)
3. When the Receiver wants to spend the Output - he decrypts the HASH field with his Private Key and compares the encrypted bytes with the output bytes - if they equals - means the Receiver can use the Output
Or maybe the Sender can sign the Output with the Receiver Public key(but I'm not sure that it would work ...)

I'm pretty sure that bitcoin transactions are very safe the only thing what confuses me - is a bit complex mechanism of verification)
This is no publicly verifiable and thus cannot work. A transaction needs to be verifiable by everyone, not just by one person.

You are failing to consider the case where an address is reused and the public keys are thus revealed to the world. Without a signature check, anyone could spend from an output that has an output script that was reused (i.e. reused addresses). You are also failing to consider the integrity aspect of signatures.
397  Bitcoin / Development & Technical Discussion / Re: -rescan from blockheight? on: April 12, 2018, 03:07:41 PM
Use the rescanblockchain RPC command which takes a height parameter.
398  Bitcoin / Development & Technical Discussion / Re: Bitcoin transaction signature on: April 11, 2018, 06:56:39 AM
Signature verification has a two-fold effect. First it ensures that the person who is spending the UTXO proves that they have the private key associated with the public key that hashes to the provided hash. Secondly, and possibly most importantly, a signature commits to the data in the transaction - i.e. it ensures that the transaction itself has not been modified without the spender knowing.

A digital signature requires two things: the private/public keypair, and a message to sign. So in the case of Bitcoin transactions, the message to sign is the transaction itself (in most cases) but without signatures because a signature can't sign itself. With OP_CHECKSIG, if the transaction itself has been modified in some way (e.g. inputs added, outputs added, output values changed, etc.), then the signature will fail to validate because the message that is being used to validate the signature with has changed.
399  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: April 11, 2018, 03:05:48 AM
Once downloaded how long will it take to sync?
It depends on your hardware. It will take somewhere between a few hours and a few days.
400  Bitcoin / Development & Technical Discussion / Re: Is the network under attack in some way? on: April 11, 2018, 03:04:45 AM
Where do you see these numbers?

Within the last 24 hours,
Therein lies your problem. Your sample size is not large enough. You can't just say "daily transaction count has dropped" from just looking at one sample. This is simply variance, some days people decide to make less transactions. Such statistics can also be effected by the software that is measuring those numbers as they can be incorrect.
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 66 67 68 69 70 ... 551 » is not available or authorized for sale. Do not believe any fake listings.
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!