Bitcoin Forum
November 18, 2018, 07:47:38 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 66 67 68 ... 547 »
341  Bitcoin / Development & Technical Discussion / Re: The “26 blocks fork” in April 2013 on: March 30, 2018, 09:08:27 PM
My question is Why do we call it a fork given that one part wasn't able to build new blocks?
They were able to build new blocks, and new blocks were in fact being built on both sides of the fork.

What happened was that miners who were using Bitcoin 0.8 had the majority of the hash rate, so they were finding blocks that were invalid to 0.7 nodes. IIRC miners still use 0.7 nodes were able to find blocks, just much more slowly. Then once the fork was known to have happened, the Bitcoin 0.8 miners downgraded to 0.7 and resumed mining on the 0.7 fork of the blockchain. Once that fork over took the 0.8 branch, all nodes once again began using the same blockchain as the chain valid to 0.7 was valid to 0.8 and had more cumulative work.

I suggest you read the post-morten BIP, BIP 50
342  Bitcoin / Development & Technical Discussion / Re: Must all nodes run Bitcoin core on: March 29, 2018, 06:44:27 PM
Provide an example of any consensus rules that have ever been enforced on the Bitcoin network that were not introduced by the developers working on the core client.
BIP 91 Reduced threshold for enforcing Segwit activation. It happened but code enforcing BIP 91 was never merged into Bitcoin Core. The author of the BIP is also not someone that many would consider to be a Bitcoin Core developer.
343  Bitcoin / Development & Technical Discussion / Re: bech32 generation in the GUI question on: March 29, 2018, 05:05:34 PM
What, are you saying that you will not be able to choose between nested and bech32 format anymore? from what I understand, it reads as if they will remove the checkbox... why? How will I choose what format do I want to generate then?
No, the "New" button in the "Receiving Addresses" dialog was removed. You can still generate bech32 addresses with the "Receive" tab; nothing has changed there.
344  Bitcoin / Development & Technical Discussion / Re: Why is private key in wallet 214 bytes? on: March 29, 2018, 03:39:47 PM
I see, the 214 bytes is made of version + private key + parameters + public key.
Another question, when the wallet is encrypted, the ckey entry for private keys only contains 48bytes, which is 32 bytes private key + 16 bytes IV, is that right?
Yes

Why the different db store strategy?
For compatibility reasons. Earlier versions of Bitcoin Core (including the original Bitcoin 0.1.0) used OpenSSL to do key operations. When keys were written to disk, they used the OpenSSL format which includes all of this extra data. Later, when key encryption was introduced, it was decided that for encrypted keys we could use a different format (since encrypted keys are already backwards incompatible with earlier versions). So for encrypted private keys, we only store what we need, not the full extra stuff. We could bump the wallet version and change the unencrypted key storage format to just be the private key, but no one has bothered to do that and it really isn't all that important.
345  Bitcoin / Development & Technical Discussion / Re: Why is private key in wallet 214 bytes? on: March 29, 2018, 06:42:03 AM
Those additional bytes are for the elliptic curve parameters and the full public key. This format is described in http://www.secg.org/sec1-v2.pdf section C.4
346  Bitcoin / Development & Technical Discussion / Re: If there is no bitcoin-cli file in VPS server? on: March 27, 2018, 04:50:06 PM
You interact with bitcoind with the JSON-RPC protocol. So you can use cURL to do that. Or you can just copy a version of bitcoin-cli to your server. It's just a wrapper that can speak the JSON-RPC protocol, particularly for bicoind. It is a separate portable binary.
347  Bitcoin / Development & Technical Discussion / Re: It is NOT secure to use hardware wallets (and it never was) on: March 27, 2018, 04:47:56 PM
I'm not objecting just confused: Is it about firmware, BIOS, fucking NVIDIA device drivers or what? We have Linux and Free BSD, don't we? Is it impossible to have Core's wallet running on top of a clean installed Linux?

I'm seriously interested in your term 'closed source computer', actually it is my main research topic for the last couple of years, I'm just wondering how deep is your interpretation of this concept and whether you have developed any idea as an alternative?
There's more to a computer than just the OS. A lot of firmware such as processor microcode are closed source. So it doesn't matter whether the OS you use is open source; if the firmware for your hardware and the hardware itself is closed source, then you are at risk of that closed source being malicious or containing something that can be exploited. One example of this is the Intel Management Engine which could allow someone to remotely access and control your computer and there's no way to disable it because it is baked into the hardware and firmware, both of which are also closed source.
348  Bitcoin / Development & Technical Discussion / Re: strMainNetDNSSeed and pnSeed? on: March 27, 2018, 04:41:57 PM
stdMainNetDNSSeed is the array of DNS seeders for the mainnet. DNS Seeders are used by Bitcoin Core on the first run to get nodes to connect to.

pnSeed is an array of fallback seed nodes that Bitcoin Core can connect to if it is unable to find nodes to connect to from its own database or from the DNS seeders.
349  Bitcoin / Bitcoin Technical Support / Re: I've been fight the core download for months on: March 27, 2018, 04:45:33 AM
The error with peer banning is happening because a block that it read is probably corrupted and that block is marked as invalid. Then Bitcoin Core will try to continue to sync from its peers, but those peers are sending it the block that it had marked invalid so it will ban those peers. Eventually it will ban everyone it could get a connection to. To fix the peers banning problem, stop Bitcoin Core, delete the file named peers.dat, and start Bitcoin Core again.

I suspect that you have a hard drive failure. You have experienced what appears to be two cases of corrupt blocks on your hard drive. I suggest that you run hardware diagnostics to see if it finds anything wrong with your hard drive. You should stop running Bitcoin Core for now as it won't be doing anything if it can't sync the blockchain.
350  Bitcoin / Development & Technical Discussion / Re: Is bip125-replaceable set to 0 on confirmed txes? on: March 27, 2018, 04:37:12 AM
gettransaction for a tx that was sent with RBF shows "bip125-replaceable": "no".
Is the flag reset once a tx gets into a block?
Yes (basically). Once a transaction is confirmed, it is, by definition, no longer replaceable under BIP 125, therefore the field bip125-replaceable will say "no".

The current way is more confusing, as one expects the command to interpret the bit data of the transaction.
There's actually a bit more to whether something is actually replaceable than just the signalling. That is included in the checks for labeling a transaction as replaceable.

Knowing that RBF can't be used on txes already in a block seems self-evident? Especially to people who would use commands to check it.
Just because a confirmed transaction signals it does not necessarily mean that it was actually replaceable when in the mempool.

(Can anyone move the thread to Development & Technical Discussion?)
I moved it for you, but next time, do it yourself (OPs can move their threads) or use the report to moderator link.
351  Bitcoin / Bitcoin Technical Support / Re: bitcoin-qt shows "n/a" instead of address after "payment to yourself"? on: March 27, 2018, 04:28:54 AM
And by the way, why does GitHub call it also commited on 3/19/2018, besides the original date of 10/10/2017?
Commits were last pushed on 3/19/2018 while the commit date is 10/10/2017. This happens because people will amend their commits and force push, but amending does not modify the commit date.
352  Bitcoin / Bitcoin Technical Support / Re: How safe is it to reuse existing blockchain files? on: March 27, 2018, 04:26:02 AM
I have seem conflicting arguments on this. The purists argue that you should never reuse files, and the rest say that it's safe because these files cannot be manipulated in any way in which would put your new node in trouble... thoughts?
Without the chainstate, it doesn't matter because your node will validate the blocks anyways and fetch whatever it doesn't have.

The argument only matters if you are copying over the chainstate too since then you have to trust that the chainstate you are copying has not been modified. Usually you can trust yourself and your computer so it really isn't an issue. It's only an issue if you have malware or someone has maliciously accessed your computer.
353  Bitcoin / Development & Technical Discussion / Re: What is key pool used for? on: March 25, 2018, 01:35:06 AM
I'm not sure as to why the keypool is still being used
To make it easier to implement HD into Core with minimal review. There are plans to generate HD keys on the fly instead of storing them in a keypool.
354  Bitcoin / Development & Technical Discussion / Re: bech32 generation in the GUI question on: March 24, 2018, 01:47:44 AM
This is a known issue. Just use the receive page.
355  Bitcoin / Development & Technical Discussion / Re: Bitcoin branch - multiple blocks on: March 22, 2018, 10:40:06 PM
I must have gotten something mixed up... isn't a coinbase a fee that the miner gets payed just for mining the block? He could really mine a block with only his coinbase transactions... basically he can decide not to include any additional transactions?
Yes. There is only one coinbase transaction per block. The coinbase transaction includes the payout for the block subsidy and the sum of the transaction fees in the block.

If so, then any other transaction he includes in his new generated block can make him money OUTPUT_1_amount - OUTPUT_2_change = transaction fee.
The transaction fee is the input amount - output amount.

So by mining a block he gets a coinbase amount (reward) + all of the transaction fees. So he broadcasts the message that he mined it... block is on the blockchain...transactions are considered valid...
The miner broadcasts the block itself. He doesn't just say that a block was mined. Miners also do not dictate what transactions are valid; a miner could include an invalid transaction in a block and the block would be rejected by all other full nodes on the network.
356  Bitcoin / Development & Technical Discussion / Re: Bitcoin branch - multiple blocks on: March 22, 2018, 10:06:54 PM
Now, if this scenario happens, does this mean that two transaction fees will be payed for the same transaction? First time it entered the block (that ended up in the "shorter" chain) and second time when that transaction was once again pulled from unconfirmed transaction pool and put in the new block (that hopefully ends up on the  "correct" chain)

From miners point of view, the second transaction fee should be necessary because it is not the second miners problem that the block from the "first" miner ended up in the "short" chain. But then again, who is paying for the second fee?
No.

Transaction fees are collected by the miner, not really actively paid to the miner. They are the difference between the value of the inputs and the value of the outputs. Transaction fees are collected by the miner when they mine a block including the transaction. The fee is paid to the miner via the coinbase output which the miner generates. It is the same output that also pays the block subsidy (the 12.5 BTC reward a miner gets for mining a block).

In a situation for an orphan block, the miner whose block is orphaned receives no payment at all; he does not receive any transaction fees nor does he receive the block reward. This is because the transaction that contains that payment is the coinbase transaction of the orphaned block and so it does not become part of the main blockchain.

Because of this, your second question is invalid.
357  Bitcoin / Development & Technical Discussion / Re: It is NOT secure to use hardware wallets (and it never was) on: March 22, 2018, 07:02:31 PM
Just because there are vulnerabilities found does not mean that they are inherently insecure. Do you say the same things about software wallets too (many of which have had vulnerabilities found and patched, just like with these hardware wallets)? Do you say the same thing about the general purpose computer you use which you don't even know how it works? Every piece of software and many pieces of hardware will have some vulnerability found in them; given enough time, it's almost inevitable.

Worth mentioning, that the guy who found this exploit is 15 ys young.
That's slightly misleading. This 15 year old has dedicated a lot of time into working on hardware wallets, particularly in their firmware. He's been involved in numerous other vulnerability discoveries in the past with Trezors (and possibly Ledgers). The kid is very smart, probably smarter than you when it comes to hardware wallets. He's not just some random 15 year old who found this; he actually dedicated a lot of time into learning about how hardware wallets work and has been working with them for years.

Not 100% true, from what he said it was vulnerable to the "Evil Maid attack"
https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/
I don't think you understand what an evil maid attack is. It is, by definition, a physical access attack. You need to have physical access to the device in order to perform any of the known vulnerabilities (which have since been patched). An evil maid attack means literally that someone (like a maid) enters your room physically and does something malicious to a device (hence an evil maid).

Which took them close to 4 months to put out and still is not properly alerting & forcing users to update.
Vulnerabilities take time to fix and release. They can't just publish that there is a vulnerability or details about the vulnerability before a fix is available. It probably took them 4 months to figure out a solution. Also, Ledger can't force users to update, and there has been plenty of alerting (which, by the way, also cannot be forced).

Assuming you can trust everyone who handled the package from when it left their shipping dock till when it wound up in your mailbox.
There's a hardware and software attestation process that you can go through to ensure that your Ledger has not been tampered with.

What is the source for the 4 months? As far as i know this has been fixed pretty fast..
https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/
Scroll down to "Disclosure timeline"
358  Bitcoin / Development & Technical Discussion / Re: What are the markers byte in wallet file on: March 22, 2018, 06:43:56 PM
Hi, is this necessary? my understanding is Berkeley DB already keeps track of data item's length internally, for every db get operation, the Dbt return its data as well as the length.
The lengths are there because of Bitcoin Core's serialization framework. It tends to prepend everything with the length and it's kind of annoying to make it not do that. It's easier for it to just do that for everything because some things need to be length prepended and others don't, and it also depends on the use case (e.g. in transactions, length prepending is necessary, but not necessarily for the databse, but the same data ends up in transactions as well as in the database).

Also, Bitcoin Core tends to have multiple things concatenated in each key or value so the length prefix helps to differentiate between the two (e.g. each key in the wallet is some string followed by the actual key like a public key, so the length prefix lets us know where the string ends and the pubkey begins).
359  Bitcoin / Bitcoin Technical Support / Re: I've been fight the core download for months on: March 22, 2018, 04:55:19 AM
Your copy of the blockchain contains a corrupted block. You will need to delete the corrupted block and reindex the blockchain which will take several hours. To do this first stop Bitcoin Core. Then go to blocks folder in the Bitcoin data directory (for you that is C:\Users\john-asus\AppData\Roaming\Bitcoin\blocks) and delete the files blk00589.dat and rev0589.dat and any blk*.dat and rev*.dat files that have higher numbers. Then start Bitcoin Core again. It will tell you that it needs to reindex the blockchain, click Yes and let it do that. Once it finishes, it should resume syncing the rest of the blockchain. Note that the reindex will appear as if it is syncing the blockchain; it is not.
360  Bitcoin / Development & Technical Discussion / Re: What are the markers byte in wallet file on: March 22, 2018, 04:51:25 AM
So I tried to figure out the content of the wallet file, and a dump shows that each key value is prefixed with a non-printable mark, even when the data item is valid printable strings, what's the purpose of these markers bytes, like
Code:
\07, \09, \0a
etc.
Those aren't marker bytes. They are length prefixes. The specify the length of the following piece of data.
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 ... 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!