Bitcoin Forum
September 25, 2018, 04:15:05 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  Home Help Search Donate Login Register  
  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 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 ... 544 »
981  Bitcoin / Bitcoin Technical Support / Re: I found a better way of estimating on-chain BTC volume, on: October 31, 2017, 10:48:40 PM
Instead of requesting each transaction individually, request the block with verbosity level 2 (just another parameter with the value 2). This will also include the JSON data for each transaction instead of just the txids.
982  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: October 31, 2017, 06:19:27 PM
Listening and non-listening nodes do exactly the same thing. They still send and receive blocks and transactions from their peers and will relay blocks and transactions to their peers.
Do non-listening nodes change their 8 peers more often than listening nodes?
Connections, both inbound and outbound, are rarely closed unless one peer goes offline. So listening and non-listening nodes will change their peers at about the same frequency. Outbound connections in general might change more frequently as we have stricter criteria for who we connect to and when to disconnect from them than we do with inbound peers.
983  Bitcoin / Development & Technical Discussion / Re: What to do for Nov 2017 hard fork. on: October 31, 2017, 06:17:17 PM
then what do you suggest mate? if someone has funds on electrum?
Are you blind? Is my signature visible?
That commit was reverted: https://github.com/btc1/bitcoin/commit/98c0af58c29efbecba25818adb5531fa8c3d0506 so that is no longer a viable method.
984  Bitcoin / Development & Technical Discussion / MOVED: Difficulty and mining relation on: October 31, 2017, 03:39:34 PM
This topic has been moved to Trashcan.

Duplicate thread
985  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: October 31, 2017, 03:38:26 PM
Come on we're playing semantics. Yes, obviously a SPV wallet doesn't fully verify like a full node does, but it does simply verify transactions which is the point. It has limited trust to a third party and since the information it receives from a third party is cross verified with others and
The point is that SPV wallets can't and don't "simply verify transactions". There is no verification that can be done without having the transactions that a transaction spends from.

it is deep in the blockchain, there's a fair assumption of truth in it.
That's also not true. A transaction is not necessarily deep in the blockchain. SPV wallets allow you to receive unconfirmed transactions and sometimes spend from them. You can also spend from transactions with one confirmation; those are definitely not "deep in the blockchain"

The point is that every person isn't going to run a full node, and you want all users to have a decentralised self verifying experience. SPV nodes on mobile are the best answer to this.
Yes, I agree that not everyone is going to run a full node, but current SPV wallets are not a decentralized self verifying experience at all.
986  Bitcoin / Development & Technical Discussion / Re: Generate block by the help of cgminer and getblocktemplate on: October 31, 2017, 03:34:28 PM
I changed the difficulty in the GetDifficulty() function in the following file.
~/bitcoin/src/rpc/blockchain.cpp.

I set a huge big number such as 99999999999999999.
That is not at all how difficulty works and not where it is changed. What you changed was the output of an RPC command, not any actual internal behavior.

First of all, Bitcoin does not actually use the difficulty number in mining. It uses a 256 bit integer called the target and a block's hash must be less than that target value. That target value is in turn used to calculate the difficulty value for us humans to understand, but the difficulty value itself is not used in Bitcoin anywhere.

I simply want to know the difference between block generation speed in two cases; when difficulty is set to 1 and when is changed to 1.0e+15.
Do change the difficulty, you will need to change this value to false: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L281 and modify these two functions: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L49 and https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L13 to give you a target that matches the difficulty that you want to have.
987  Bitcoin / Development & Technical Discussion / Re: Reusing receive address doesn't reduce tx size on spending, right? on: October 31, 2017, 04:25:59 AM
Could you have all your coins sent to a single address, and then make a second transaction of all those coins once again to a single address? Would that reduce the UTXO set?
Yes, you could do that. That would reduce the UTXO set. You wouldn't need to have all your coins sent to the same address in the first place, although if they were, there is then no harm to your privacy.
988  Bitcoin / Electrum / Re: Electrum wallet shows "replacable" after transaction on: October 30, 2017, 07:24:34 PM
Thank you for the answer.
Does that mean that the transaction will be executed later or do I have to raise the fee? I could do that. The Elektrum wallet allows to that.
What is the best thing to do? But not do the same transaction again, right?
The transaction will confirm eventually, you do not need to do anything. If you think the transaction is taking too long to confirm, you can increase the fee.
989  Bitcoin / Development & Technical Discussion / Re: Reusing receive address doesn't reduce tx size on spending, right? on: October 30, 2017, 07:24:18 PM
Is there a standard way to generate P2PK receive addresses?
No.

Aren't 1-prefix addresses just for P2PKH?
Yes.

BTW, a few posts were deleted from this thread, which happens a lot on the forum. How come?
A lot of them are spam or low value. I will delete posts from people who clearly do not read the thread and just post the same thing that someone else posted earlier in the thread.
990  Bitcoin / Electrum / Re: Electrum wallet shows "replacable" after transaction on: October 30, 2017, 03:24:16 PM
Replaceable means that the transaction conforms to BIP 125 and can be replaced by a transaction which spends the same inputs but includes a higher transaction fee.
991  Bitcoin / Bitcoin Technical Support / Re: I have lost my Bitcoin, is there anything I can do? on: October 30, 2017, 03:21:14 PM
Post your debug.log file.
992  Bitcoin / Development & Technical Discussion / Re: Generate block by the help of cgminer and getblocktemplate on: October 30, 2017, 03:18:10 PM
Hi there,

I want to analyze relation between “difficulty” and mining speed in my own private network. I mean I want to see how difficulty influence on the generation rate of producing block.
I ran the bitcoin and cgminer at the same time. Cgminer can see the bitcoin network which is already running. When I generate a block by “bitcoin-cli –datadir=”a given node directory” geneate 1” command, I can obviously see that cgminer informed about it and update the blockchain height. Since bitcoin in regtest mode generate block immediately and without mining,
You actually were mining. Bitcoin Core contains mining code for regtest. The difficulty of regtest is low enough that a CPU can mine a regtest block nearly instantaneously. The generate and generatetoaddress commands will perform mining operations.

I have decided to generate a transaction by these following commands:

Add=Bitcoin-cli –datadir=first_node_path getnewaddress
Bitcoin-cli –datadir=second_node_path sendtoaddress $Add 10

I expect this command generate a block but it is not true and no block was generated after this commands.
As there shouldn't be. Those are not mining commands, so blocks will not be mined after they are run. Blocks are not found for every single transaction.

To mine on the regtest network, you just need to use Bitcoin Core's generate or generatetoaddress commands.
993  Bitcoin / Development & Technical Discussion / Re: Reusing receive address doesn't reduce tx size on spending, right? on: October 30, 2017, 03:14:37 PM
You can't have two transactions with the same tx id in the blockchain, as tx id is calculated based on transaction contents. If that was possible you would be able to send the same transaction twice, meaning you would spend the same coins twice and double the balance of the receiving address.
There actually are multiple transactions in the blockchain which have the same txid. These transactions are coinbase transactions included in blocks prior to the deployment of BIP 30 and BIP 34 (and were the impetus for BIPs 30 and 34). Only the most recent transaction of a transaction with duplicate txids is the one that is considered to be spent from and included in the UTXO set. The other transactions with the same txid have provably burned coins as they are unspendable. BIPs 30 and 34 have since disallowed duplicate txids and made it nearly impossible for duplicate txids to occur (except when there are hash collisions).
994  Bitcoin / Development & Technical Discussion / Re: Proposal: How to cull the blockchain on: October 30, 2017, 03:06:57 PM
Thanks for that info. Can you tell me who is working on this? Any links to working docs/discussions/dev-lists? In my opinion, this is the last technological hurdle that Bitcoin needs to jump before it is ready to scale to widespread adoption - that's why I care about this issue a lot.
Pieter Wuille has been working on this. A mailing list email about this is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html

What he has been working on is a way to do rolling UTXO set hashes so that the UTXO set can be committed to the blockchain to allow for UTXO set syncing. Once we figure that out, the rest is fairly trivial.
995  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: October 30, 2017, 03:03:58 PM
SPV does verify. I don't know what definition you're using when you say it doesn't self-verify, but it does verify transactions itself and doesn't rely on a trusted third party to verify.
That is untrue. A SPV wallet cannot fully verify a transaction. It does not have the UTXO set, so it cannot fully verify it. Even if it does know the previous transactions, it does not know the transactions that those spend from and so on. If it did, it would basically be a full node, which they are not. Because an SPV node does not have the UTXO set and has not verified the chain of transactions that a given transaction is part of, it must trust the node that gave it the transaction and trust that that node gave it the right transaction and that the transaction was valid to it. Without the previous transactions, it cannot verify that the input script is correct. Without the previous transactions, it cannot verify that the amounts in the outputs are valid.
996  Bitcoin / Development & Technical Discussion / Re: Proposal: How to cull the blockchain on: October 30, 2017, 04:49:46 AM
Thanks for the feedback. Now that you've put it that way, it makes me think that this could be seen as a "full node with fast p2p join" protocol, where the small, latest suffix of the blockchain (+snapshot) is utilized to bootstrap the full node, but the full node operator could set an option to continue pulling in archival data from other archiving full-nodes after the blockchain suffix has been verified and the full node has gone online.
This idea is known as UTXO syncing and is something that has been proposed and though about for several years now. It is still being worked on and to enable UTXO syncing would require a fork. Enabling UTXO syncing requires that each block commits to the entire UTXO set. People are working on ways to securely and efficiently commit the UTXO set but all of that is still being researched.
997  Bitcoin / Development & Technical Discussion / Re: Node is unreachable on: October 30, 2017, 04:47:02 AM
Is it possible to send/receive via QT but my port 8333 is not accessible?
Yes.

Just because bitnodes is unable to connect to your node does not mean that your node is offline or not connected to the network. That website only knows about nodes which accept incoming connections. It is likely that your node does not accept incoming connections (i.e. your router or something else blocks incoming connections to port 8333). Your node can still make outgoing connections and connect to other nodes so you are still connected to the Bitcoin network. Even with just outbound connections, you are still contributing to the network as you are still receiving, verifying, and relaying all blocks and transactions.
998  Other / Meta / Re: Bitcoin forum shows me comments only on: October 30, 2017, 03:31:46 AM
I don't think you understand how forums work. This is not like Reddit where the topic is a link to something else. Each topic is a thread where people make comments about whatever they want. The first post of the thread is "the topic". Everything else is a response to that post (or another post in the thread). This is analogous to self posts on Reddit except there are no comment threads where people respond directly to a comment like on Reddit. Because all other posts are responding to the same topic, each post is titled with "Re: ..." automatically as that stands for "reply about X".
999  Bitcoin / Electrum / Re: Understanding Electrum Codes on: October 30, 2017, 03:27:13 AM
May I enquire on where I can start with if I want to further optimize Electrum's lightweight performance?
Performance doing what? Electrum does a lot of things and each has its own "performance". These include things like syncing, network bandwidth, key generation, storage, etc. What kind of performance do you want to optimize?
1000  Bitcoin / Bitcoin Technical Support / Re: Transfer BitCoin Core 13.0 wallet to new 15.0 version? on: October 30, 2017, 03:23:36 AM
Can I update to the 15.0 wallet and NOT have it re-download the whole blockchain again?
Yes, you can. The normal update process of just installing Bitcoin Core 0.15.0.1 on top of Bitcoin Core 0.13 (i.e. overwriting the previously installed version with new binaries) does not destroy any blockchain data. Even uninstalling Bitcoin Core 0.13 does not delete any blockchain or wallet data. All of that is stored separately from the installation itself. So yes, you can just download and install Bitcoin Core 0.15 and not have to redownload the entire blockchain. It will, however, take a while to start up with Bitcoin Core 0.15, especially if you were using Bitcoin Core 0.13.0. This is because it both needs to update the database structure (this changed in 0.15) and, if you were using 0.13.0, it will need to redownload the blocks that were found after segwit's activation so that it has them in the segwit format.

The Bitcoin blockchain seriously needs to be clipped off.  Take off the first 470,000 or so blocks and begin from there, no one has enough hash power to mine their own new blockchain with a 51% attack anymore.  Downloading most of that 145GB blockchain is simply ridiculous.
Doing that violates Bitcoin Core's security model and there are so many things wrong with doing that that can be attacked. Clearly you have not thought through ramifications of doing so or you do not understand the ramifications of doing that.
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 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 ... 544 »
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!