Bitcoin Forum
September 23, 2018, 03:13:40 PM *
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 ... 544 »
961  Bitcoin / Bitcoin Technical Support / MOVED: attention scammed user @hefty on: November 06, 2017, 04:11:13 PM
This topic has been moved to Trashcan.

962  Bitcoin / Development & Technical Discussion / Re: Technical questions about blockchain on: November 05, 2017, 11:19:03 PM
Ok, right, yes there are no servers, but in solo mining, the mining software (the client) must connect to any available bitcoin node
Usually mining software connects to a miners own node, not just any node. Any node likely does not have the required interfaces exposed to the general internet so you can't just connect to any node to get the information.

to ask for difficulty and a challenge, the miner search a hash that meets the requirements and send it back to a node or many with the hash and his address.
No, that's not how mining works.

The mining software will ask the node for the information necessary to construct a block. This is usually the block version, current difficulty, previous block hash, and branches of the merkle tree (including leafs, i.e. transactions themselves). The mining software then constructs the block by assembling the block header and filling in the details that it needs to, e.g. the coinbase transaction with the payout to his own address. When the mining software has completed a block, it then submits the entire block (header and transactions) to the node. It does not give it a hash or many hashes and an address; it gives it the full block usually.

Between, I cant figure out how to adjust the difficulty, right now I implemented the way you told me,

A node sends the miner a target, and the miner has to find a hash below the target.

So just for testing purpose my current target is:

target = 115792089237316195423570985008687907853269984665640564039457584007913129639936 (2^256)

Every 2 block i adjust difficulty, for every 2 block it should need 2 mins, so my ratio would be:

ratio = 2/120 (0,016666667)

So, right now with my current target, 2^256 block are created instantanly, the time what i need to press "mine" button, 2 block are created in 7~ seconds, so actual ratio would be:

actualRatio = 2/7 (0,285714286) ( a lot easier )

At this step i can't figure out how to relation ratio and actualRatio and target to set target to my ratio, to adjust the difficulty.

What do i need to adjust the target with ratio and actualRatio?
I highly suggest that you read the source code in Bitcoin Core that calculates the difficulty for each block:

To calculate the next proof of work, you multiple the last block's target by the amount of time it actually took, then divide it by the time you want it to take. You have a formula that looks like this:
(Last block's target)/X = (wanted time)/(actual time)
Then you just solve for X. In your example, you would do
Because we are dealing with integers here and not decimals, this is just the floor of that, so your target would be 1985007244068277635832645457291792706056056879982409669247844297278510793827474 .
963  Bitcoin / Development & Technical Discussion / Re: App that can generate addresses from private key in bulk? on: November 05, 2017, 11:02:54 PM has a bulk wallet generation thing where you can generate as many private keys and their addresses as you want.
964  Bitcoin / Bitcoin Technical Support / Re: increasing transaction fee failed ? on: November 05, 2017, 11:01:06 PM
It means that there is not enough money in the transaction to increase just the transaction fee. Your wallet is likely increasing the fee by decreasing the amount that is sent to a change address. It will not decrease the amount that you originally requested to send. Since your transaction does not have a change output, there is nowhere for it to increase the fee from so it fails to increase the fee.
965  Bitcoin / Development & Technical Discussion / Re: Bitcoin Scalability? on: November 05, 2017, 03:59:46 AM
I think the way the scalability problem is "left" unresolved does support conspiracy theory of how AXA , etc. has bought over bitcoin.
That conspiracy theory is categorically false. A lot of your "questions" are things that are leftovers from Satoshi's designs that require a hard fork to change, and we are hesitant to have hard forks willy nilly.

1) allowing poweful hardware to having mining advantage is simply against distributed consensus.
That is a natural progression of technological advancement. A Proof of Work system will always result in an arms race of who can get the best and fastest mining hardware. It doesn't matter whether it's CPUs, GPUs, or ASICs. Those who have the most money to sink into building massive mining farms are those who are going to have an advantage. Proof of Stake isn't any better (in fact it's worse and has several of its own severe issues).

There is no need to have transfer fees, incentives, etc, to motivate these mining conglomerates.
Why is there no need? We need fees and the block subsidy to incentivize miners to continue to mine and secure the blockchain. Without them, mining would not have had a start at all and there would be no incentive to mine blocks. Remove those incentives now and miners will have no incentive to continue to mine blocks, so mining will stop.

If the next day, their rigs are all destroyed - it is better for bitcoin; there are million of desktops in India, Indonesia, China who would willingly do the mining provided
They would, if there were an incentive to do that. There is no incentive to continue to mine (and expend energy and money) if there were no incentives. Furthermore, the difficulty of mining is so high that the combined computational power of people's desktops is likely not enough to mine blocks at the current pace. Not only that, but people also want to be able to use their computers to do other things too, so you can't expect everyone to dedicate all of their computing power to mining. Having the difficulty this high has benefits too; it makes performing attacks much much harder. Having a high difficulty means that the blockchain is very secure; it is extremely expensive and computationally difficult to rewrite history. That is a good thing.

the protocol is design to have one-node-one-vote.
While have "one node one vote" is a great idea in theory, reality tells us that this is basically impossible. Nearly all Proof of Work algorithms have been shown to be performed on GPUs, so in order for "one node one vote", every node would need to have several powerful GPUs to mine. Furthermore, as technology gets better, it is likely that such algorithms will eventually have ASICs built for them; nothing is really ASIC resistant.

As of now, you cannot  stop others to think the "open source" developers have not been bought.
And you cannot stop me from telling you that such statements are wrong and very harmful to the community. Furthermore you have provided no evidence that "the developers have been bought", just nonsense that shows you don't understand how this system works.

Myth: bitcoin does not have the drawback of fiat money - the total BTC number is 21 million.
The developers could change the codes tomorrow to allow 1000 million BTC in 2140!
No they could not. Such a change requires a hard fork and requires all miners and users to upgrade their software to support that. It is highly unlikely that the Bitcoin Core developers would be able to convince the entire Bitcoin community to adopt such a change.

They could then sweet talk about how it would benefit bitcoin, etc.
The Bitcoin Core developers have been horrifically bad at "sweet talking" people into doing what they want. Look at how long it took to activate segwit; if the developers could "sweet talk" people into doing what they want, why wasn't segwit activated as soon as possible? For that matter, why haven't all forks activated as soon as they could (CSV did not, CLTV did not, etc.)? The Bitcoin Core developers would not be able to "sweet talk" anybody into doing anything; they're good with code, not words.

It is still all politics. This myth is very good to bring in those who have been told the evil of fiat money. But now, we have these "open source" central bankers deciding on the money supply.
Except those central bankers don't decide on Bitcoin or its money supply and you have provided no evidence to back up your claim, just nonsense statements that are clearly false.

Yes absolutely correct but why the dev team donot want to increase the block size to 2mb and why are they opposing.
The maximum block size was already increased with Segwit to 4 MB. Segwit2x saying that it increases the block size to 2 MB is completely false; it increases the block size to at most 8 MB. To say that it does not is false and lying. The absolute size of blocks currently have already exceeded 1 MB since segwit activated.

The Bitcoin Core developers have already stated why they are opposing Segwit2x. It has been widely published already. I'll give you a quick run down:
  • The fork was done extremely hastily with little to no apparent testing or preparation
  • The fork does not do anything that is on the hard fork wishlist to fix any of the bugs that currently exist in Bitcoin that require a hard fork to fix. It literally does one thing, but hard forks should include as many things as possible to reduce the need to fork again later
  • 8 MB blocks are currently too large for the network to handle. They are still vulnerable to several attacks and makes those attacks worse. 8 MB blocks will increase the requirements for running a node (more computing power, network bandwidth, storage space, etc.) and as such will likely decrease the already fairly low node count.
  • We have only recently activated Segwit and we don't know how that will effect Bitcoin and the economy. We should wait for Segwit to be actively used and assess later whether a further block size increase is necessary.
966  Bitcoin / Bitcoin Technical Support / Re: Posting Transaction with C# NBitcoin on: November 05, 2017, 03:36:40 AM
You transaction is completely invalid and a double spend.

Your transaction spends from the 0'th output of 64c1fe8c9ebc8193b5f876e7aefdf5099661faaba3b73c6901f7433818ca5572 which has a value of 0.00496229 BTC. However you are creating two outputs with values 0.00496229 and 0.00474081. However this is clearly invalid because the value of your outputs is greater than the value of your inputs (i.e. spending more money than you are allowed to).

Furthermore, the input that you are spending was spent in 3e342736e6c2472327c8d925e56f02b213f2d79a65015957a2f1b68d8ecda9cd which is already confirmed, so your transaction is a double spend and thus even more invalid.
967  Bitcoin / Bitcoin Technical Support / Re: Error parsing JSON when executing gettxoutproof on: November 04, 2017, 06:24:35 PM
You need to put single quotes around the brackets for the JSON to be parsed properly. You command should be
gettxoutproof '["01500dcfab73c06ae62ac75d8abb1c5a5537dbd12dc04a10da23ca1a712c416b"]'
968  Bitcoin / Development & Technical Discussion / Re: Segwit Addresses explorer? on: November 04, 2017, 06:18:58 PM
BIP171/Bech32 is a draft (but with a very high probability of being final) so it is possible that the addresses format may change.
It's BIP 173, not 171.

That is not how BIP drafts work. Once a BIP is in the BIP repo, it is practically final. The spec can't be changed too much by that point. Draft just means that it is not widely deployed on the network yet, not that it is still being drafted and can change at any point.

Bech32 is finalized, just not widely deployed so it's BIP status is not final. Also, there are still several things that are listed as draft even though they are widely deployed to the network and won't be changing, e.g. BIP 152 (compact blocks).
969  Bitcoin / Development & Technical Discussion / Re: Do run a Bitcoin Core FULL NODE Now! on: November 03, 2017, 09:42:43 PM
Core has the HD flag today, but doesn't seem to have deterministic stuff implemented.
HD literally means Hierarchical Deterministc. Bitcoin Core allows you to make an HD wallet, so it is deterministic. What Bitcoin Core does not have is the mnemonic or seed phrase. That is completely unrelated to HD wallets; it is a totally separate BIP and not required to have an HD wallet.
970  Bitcoin / Development & Technical Discussion / Re: Where/how is on disk/network block size determined and stored? on: November 03, 2017, 09:38:13 PM
1. Where is the size of the actual block stored in the message? Do you just send a TCP message ahead of the block that says "hey, the next block is 875,489 bytes long!" or is it encoded somewhere in to the block structure itself (apparently it isn't in the block header)?
Bitcoin has several P2P network messages, one of which is the Block message. Each P2P message (not just the block message) has a message header which contains information about the rest of the message, including the size in bytes of the message. You can read about the message header here:

2. Similarly, on disk, where is the record of how big each block is (so the filesystem knows how much data to read)? Is that in the chain state database, or it is stored in the BLK*.dat files themselves? Or somewhere else?
The blocks are stored disk as they are received over the network (without the P2P message header) with an additional compact size unsigned integer before the block indicating its length.
971  Bitcoin / Development & Technical Discussion / Re: Difference between SegWit addresses on: November 03, 2017, 02:36:46 PM
Is the sensitivity of case really important? I'm sure most people use their mouse to copy and paste the address.

In situations where people don't copy and paste, it helps to reduce the chance of errors.
Not only that, but the bech32 addresses use BCH codes (well BCH-like codes) which are an error correcting code. Bech32 addresses can detect up to 4 errors when entering the address and tell you where those errors are. They can also correct up to 2 errors (IIRC) but no wallet will actually do error correction for you because that is a good way to accidentally send money elsewhere.
972  Bitcoin / Bitcoin Technical Support / Re: How can I send a message with a transaction? on: November 02, 2017, 06:04:08 PM
The message that Satoshi included in the Genesis block is actually part of the Coinbase transaction of that block. Specifically, in the input of any Coinbase transaction, you can include whatever data that you want. Satoshi chose to put a string there. So if you want to do the same thing, then you must be a miner and set whatever you want in that part of the coinbase transaction of your blocks.

There are other ways to embed data in transactions. You can use an OP_RETURN output which allows you to make a provably unspendable output that has arbitrary data in it.
973  Bitcoin / Development & Technical Discussion / Re: Payment No. 1: A Closer Look at the Very First Bitcoin Transfer on: November 02, 2017, 03:09:23 PM
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 is the address that Hal Finney said was his according to OP. This had been silent since 2009 till it moved 0.034337 BTC to 1Nt1SwDjXmbF61XDq7vjA51hbUuzKU97Lq in JUNE THIS YEAR!!

This is the only address funded by original Satoshi Bitcoins that showed activity recently!!
It means nothing. Hal left his Bitcoin to his family so they have control of his private keys. It is likely that they are only now figuring out what to do with his Bitcoin and how to move it around.
974  Bitcoin / Bitcoin Technical Support / MOVED: New to bitcoin on: November 02, 2017, 02:52:40 PM
This topic has been moved to Trashcan.

Zero value intro post
975  Bitcoin / Bitcoin Technical Support / Re: FORGOT PRIVATE KEY on: November 02, 2017, 02:03:24 AM
If you do not have access to any file which contains it or you do not remember any passwords that would allow you to access the private key, you cannot recover it and any Bitcoin associated with that key is lost.
976  Bitcoin / Development & Technical Discussion / Re: Have Transaction Malleability been solved with segwit? on: November 02, 2017, 12:42:59 AM
Hello, I was reading about transaction malleability and wondering if segwit solved it?
As far as my understanding of transactions in block goes, segwit's main purpose was to move signature to the different place in transaction hierarchy (from inputs section to whole new section). That effectively means that transaction ID represented by hash of transaction inputs+outputs+signature can't be tampered with anymore.
Segwit defines new output types which have their signatures moved to a new field called the witness. The witness is not part of the txid so the txid only consists of data that cannot be changed. Only transactions which spend from the segwit output types are non-malleable.
977  Bitcoin / Bitcoin Technical Support / Re: Bitcoind starts at reboot but RPC calls wont work on: November 01, 2017, 06:38:42 PM
Add -daemon to the crontab command or add daemon=1 to your bitcoin.conf file.
978  Bitcoin / Bitcoin Technical Support / Re: 2 inputs - 2 outputs - different size? on: November 01, 2017, 03:28:02 PM
And now check this one:
Here, blockexplorer states 663 bytes as the transaction size which is nearly double than the 370 bytes.

What is wrong with my assumption?
There are multiple types of inputs and outputs, Your formula only works for one specific type of output and its spend in an input. The above transaction spends from a different type of output and creates a different type of output so your formula does not hold.
979  Bitcoin / Development & Technical Discussion / Re: Bitcoin Scalability? on: November 01, 2017, 03:19:50 PM
What is the advantage of having smaller blocks?
Smaller blocks can propagate with less latency and bandwidth and also require less resources to validate. Smaller blocks allow for more people to run full nodes as the network bandwidth requirements are lower. Larger blocks will likely lead to fewer full nodes and an increased orphan rate.

All of the data gets converted to a merkle root at a later date anyway so there shouldn't really be a size problem should there?
No, that does not happen. The section about that in the whitepaper only refers to on disk storage for which we have a much more efficient method: pruning. The network and computational requirements still exist as full blocks still need to be uploaded and downloaded and then verified.

Besides, I thought that the block size is undetermined anyway - It's up to the miners to choose how many transactions they want to put in each block.
There is a maximum block size which full nodes enforce.

Is there something in the current protocol that is stopping miners from including, let's say, 100,000 transactions in each block?
The maximum block size which has been redefined by segwit to be block weight.
980  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: November 01, 2017, 03:15:52 PM
I take it you're arguing that SPV wallets don't "verify transactions" but they verify that the transaction is included in a block?
Yes. SPV wallets are not actually verifying the transaction itself as they can't. They can only check whether it is in a block, and even then, they have to trust that the data they are getting from the node is correct as they can't verify whether a block is valid without having verified the full blockchain.
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 ... 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!