Bitcoin Forum
January 23, 2019, 12:04:30 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 71 72 73 74 ... 550 »
461  Bitcoin / Development & Technical Discussion / Re: Can hardware wallets suffer from ransomware? on: March 12, 2018, 04:42:55 AM
But I thought about it... can hardware wallets get encrypted by ransomware?
No.

Hardware wallets ONLY execute things from their firmware; you cannot get a hardware wallet to execute arbitrary code (barring some major vulnerability). Furthermore, hardware wallets are not just generic storage devices, so a computer infected with malware can't read or write arbitrary data to a hardware wallet as it would with any normal storage device.

Some hardware wallets (like the Ledger Nano S) have apps that can be loaded onto the device to run things. If the app were malicious, maybe it could do something which is like ransomeware. However apps are isolated within the device itself (at least for the Ledgers) and don't have access to read and write arbitrary data to and from the devices internal memory (barring some vulnerability).

or there are some at least theoretical ways to get inside the device with some malware?
In theory, if the user is incredibly stupid, some malware could flash a new firmware to the device (which requires the user to push physical buttons on the device itself in order for a new firmware to be flashed) which then results in the stored seed being stolen. In practice, no, there isn't.
462  Bitcoin / Development & Technical Discussion / Re: When first run the wallet, connect to seed nodes, then? on: March 10, 2018, 07:06:44 AM
Then it means DNS seeders has automatically updated by connected clients, fetch its ip address, and record and add it to seeder's own file, become bigger while time goes?
Yes. The DNS seeders maintain their own databases of nodes and have their own crawlers. They crawl the network to find nodes. Of course nodes are removed from the database as nodes drop offline so it doesn't grow infinitely big.

And about how to setup DNS seeder, this is valid? https://bitcointalk.org/index.php?topic=599623.0
Looks like it is.
463  Bitcoin / Development & Technical Discussion / Re: When first run the wallet, connect to seed nodes, then? on: March 09, 2018, 05:00:30 AM
Bitcoin Core uses a thing called DNS seeders. These are not websites; they don't serve HTML. They are just special domains where asking for the domain's DNS records (i.e. resolving the domain name) will return you the IP addresses of several nodes that you can connect to. These nodes are then connected to get more IP addresses to connect to.

If the DNS seeders are offline, there are a set of hard coded seed nodes as well. The same thing is done with the hard coded seed nodes as with the ones returned by DNS seeders. The only reason to use DNS seeders is that they are more up to date and accurate. Hard coded seeds are only set prior to release, so they could be outdated.
464  Bitcoin / Development & Technical Discussion / Re: Mainnet-node and testnet-node on the same server - how? on: March 09, 2018, 01:36:31 AM
Renaming a program is not going to change the behavior of the program, which is what you want to do (change it from using mainnet to using testnet).

To start bitcoind in testnet mode, use -testnet.

That they use the same bitcoin.conf file is known, you can use the -conf option to choose a different config file for one of your nodes.
465  Bitcoin / Development & Technical Discussion / Re: Idea: Transaction propagation optimization on: March 09, 2018, 01:28:39 AM
Your proposal is not all that new, it's very similar to BIP 37. BIP 37 uses bloom filters to allow a node to only receive transactions that the node wants. It is specifically used by lite wallets in order to avoid downloading the entire blockchain. However BIP 37 has its downfalls; specifically it is computationally expensive for the full node serving the data, and it does not preserve privacy well (an issue specific to wallets).

However, there is one problem with your idea: what do you choose to filter? And with a filter, how do things not in the filter get transmitted through the network to the miners? How do you guarantee that someone will relay your transaction? The flood protocol practically guarantees this. But having everyone filter out transactions to relay would result in a lot of transactions being missed and thus not relayed.
466  Bitcoin / Development & Technical Discussion / Re: Lightning - Question to understand atomic transactions over the network on: March 09, 2018, 01:23:26 AM
I understand the network like this.

1) Sender is searching the best route through all nodes to reach the target.
2) Sender is encrypting the selected route node by node (onion routing)
3) Sender send coins to the first node using a payment channel between sender and first node
4) The next node decrypts the follow up node and continue sending coins to the next node over the next payment channel
5) continue with 4 until the target node is reached.

In my understanding, whenever I send something over the payment channel, this transaction is completed and not reversible (this is maybe the point where I'm wrong).
So, when I have 10 nodes in my selected route, and node 5 in my list is down. How does the network make sure, that the 4 nodes before are doing a rollback to give back the coins to the sender, so the sender can try a different route.
That's not how payment routing actually works. That's just the messaging protocol to transmit some information between nodes.

The actual payment part works through Hashed Time Locked Contracts (HTLCs). So node A offers a HTLC output to node B. In order for node B to spend from that HTLC (thus being paid by node A), he needs to provide the preimage to some hash in addition to his own signature. After some timeout, node A can take the money back with a signature of his own.

In LN, the HTLCs are used to make the payments between the nodes. They use the same hash so they all have the same hash pre-image required. So if any one HTLC is spent, all HTLCs in the route can be spent since the hash pre-image is revealed during the spend. If the hash preimage is never revealed, then the coins are never sent to the other party. This makes it atomic.

As a shortcut (to avoid on chain transactions for each HTLC) LN uses the onion routing method you described. The hash preimage is given to the recipient by the sender and that is transmitted to each node in the route so that they all have the hash preimage. Once both nodes in the channel have the hash preimage, they resolve the HTLC off chain. If some nodes are not able to transmit the hash preimage to settle the HTLC off chain, then the node that was able to settle with one peer but not the other can settle on-chain, and in doing so, reveals the hash preimage for the remaining nodes to settle (either on chain or off chain, as necessary). That node is incentivized to settle on chain because he would actually be losing money by not settling.
467  Bitcoin / Development & Technical Discussion / Re: Odd questions, what I am missing? [RPC call] on: March 09, 2018, 01:06:34 AM
1) As far as I know and can see it should do name resolution, but since this is the 1st time I am actually doing it this way does it, or am I just assuming that it does?
[
You are assuming that it does name resolution, but AFAIK, it does not. Just because a different software does name resolution (indicating that the machine is capable of doing so) does not mean that bitcoin-cli will do name resolution.
468  Bitcoin / Development & Technical Discussion / Re: Setting up a private chain/testnet : reverse engineering the blockchain code on: March 09, 2018, 12:57:20 AM
The consensus rules are what define a blockchain. You cannot create a blockchain without the consensus rules. You need to implement your consensus rules in a software that is then used to create a blockchain.

Typically people who are doing this will just clone an existing coin and modify it. You will need to understand how that coin works and what your modifications must be. This isn't something that is beginner friendly nor is there a beginner "how to do" guide available. This is specialized knowledge that not everyone can do.
469  Bitcoin / Development & Technical Discussion / Re: Why per-wallet db.log and database? on: March 09, 2018, 12:48:20 AM
Both the file db.log and the directory database are files used by the BDB database engine. The directory database is a temporary directory that is used to store data about the wallet while the wallet database is open. If Bitcoin Core is uncleanly closed, the BDB database will also be uncleanly closed. If it is uncleanly closed, then in order to open it again without having any problems, you must have the database directory as it contains some BDB state data. If they are separated (wallet.dat moved out or database is deleted), then the wallet database can be corrupted and private keys corrupted. This can result in a loss of funds.

Having separate wallet directories containing their own database environments allows for better dynamic wallet handling and a failure to close the BDB environment cleanly may only just effect one wallet instead of all wallets.
470  Bitcoin / Bitcoin Technical Support / MOVED: CEX.IO SCAM? or Any suggestion?? on: March 07, 2018, 04:44:33 AM
This topic has been moved to Trashcan.

Duplicate
471  Bitcoin / Armory / Re: Haven't received a payment to armory? on: March 06, 2018, 02:44:40 PM
What version of Bitcoin Core are you using?

Try updating Armory.
472  Bitcoin / Development & Technical Discussion / Re: Has anyone got a link to Satoshi's first implementation of Bitcoin? on: March 06, 2018, 02:39:07 PM
Some of the early distributions (code and compiled binaries) are available here: http://satoshi.nakamotoinstitute.org/code/
473  Bitcoin / Development & Technical Discussion / Re: What do you think of this change on the GUI on: March 04, 2018, 06:14:58 PM
What's the input size for non-Segwit P2SH?
It depends on the script wrapped by the P2SH address. It could be 0 bytes, or it could be 10000 bytes (the maximum scriptsig size).
474  Bitcoin / Development & Technical Discussion / Re: What do you think of this change on the GUI on: March 04, 2018, 06:41:10 AM
What's the actual-bytes transaction size (or, well, per-input size) in the case of P2SH-P2WPKH versus P2PKH or "legacy" single-key P2SH?
The actual byte size for a P2PKH input is 148 bytes. For a P2SH-P2WPKH input, it is 171 bytes. For a P2WPKH it's also 148 bytes.

However the actual byte size doesn't really matter. Blocks are not limited by size but rather by weight. And transaction fees are actually by weight or virtual size (weight/4) and not actual size. So th weight for a P2PKH output is 592. For P2SH-P2WPKH it is 360 and P2WPKH it is 268. So as you can see, the segwit inputs consume less weight and are thus cheaper to spend.

Is it currently possible to sign a message with a P2SH-P2WPKH address?
No. There is no standard for signing messages with segwit addresses yet. That's something that is being worked on. Note that messages aren't actually signed with an address. Rather they are signed with a public-private key pair which can correspond to multiple addresses. Your wallet software will calculate the public key for a message and convert that into an address. A wallet could just as easily show you a P2SH-P2WPKH or P2WPKH address instead of a P2PKH address when it is verifying a signed message. What needs to happen is a specification for signing messages with a script which can thus be generalized to signing with an address. Such messages and signatures would actually correspond to addresses and not a public key which your wallet just turns into an address.
475  Alternate cryptocurrencies / Altcoin Discussion / Re: Why it does not change script address prefix? on: March 02, 2018, 03:31:31 PM
What exactly are the lines you changed (as in post the code snippets for your changes).
476  Bitcoin / Development & Technical Discussion / Re: Will it ever be possible to separate chainstate and blocks folder? on: March 02, 2018, 03:27:28 PM
But I remember I asked about symlinking method to separate chainstate folder from blocks folder and also other members also asked about it and basically the consensus was that it was very unsafe and would corrupt the block or chainstate files... what has changed since then? Or when you say possible, you mean it can be done but it is still unsafe even with the latest version? Im just not sure what you mean.

I think you mean that nothing has changed and it's still unsafe but I want to be sure... but I predict that im going to be stuck with an HDD.
Nothing has changed and it's probably still unsafe to symlink the blocks folder.
477  Bitcoin / Development & Technical Discussion / Re: What do you think of this change on the GUI on: March 02, 2018, 03:26:29 PM
What's the point of not keeping it? Some people will only accept legacy payments and they have they right to do so, and people have their right to use legacy at any time.

It would not be any more confusing than having that "Generate Bech32 address" button which already exists there.

And like I said, this could be hidden by default and shown if you enable advanced features on the menu.

In any case, noobs in general don't use full nodes. Anyone using a full node knows what that is anyway.
The idea to use dropdowns came up frequently in discussions on how to support getting segwit addresses in the GUI. We decided to stick with the checkbox approach because we want to encourage users to use segwit. The only reason to have the checkbox is to let people use bech32 addresses when they want to and default to backwards compatible p2sh-segwit addresses. There's little reason to use legacy addresses except out of principle (i.e. those who hate segwit). For such people, they can start Bitcoin Core with addresstype=legacy, and hopefully those options will be available from the settings menu too (there's an open PR for that).
478  Bitcoin / Development & Technical Discussion / Re: Error "Potential stale tip detected, will try using extra outbound peer" on: March 02, 2018, 05:27:32 AM
Did you reset your datadir before trying with the new genesis block? Reset as in delete the blocks and chainstate folders.
479  Bitcoin / Development & Technical Discussion / Re: Error "Potential stale tip detected, will try using extra outbound peer" on: March 02, 2018, 04:06:20 AM
So nonce and genesis hash is different with [ assert(consensus.hashGenesisBlock == ] part?
Of course it will be, that's how mining works!

The nonce is part of the block header which is used for computing the block hash. It is what is changed to make a valid proof of work. Your nonce and thus the genesis hash were invalid, the script produces values that will be different which will be valid.

So then this means genesish0 is not work with current source? (litecoin 0.15.1)
No, it worked correctly, just that the script is a little wrong. It still found a valid block, but it printed the wrong value for the block hash. You can see that the block hash was printed in your error, it's 0000c978c4bf731c7e48018bc21f658b37394b5d18bd2ceca383768387578d76. So you need to set your genesis block assertion to that value.
480  Bitcoin / Development & Technical Discussion / Re: SegWit, Industry standard for the future? on: March 02, 2018, 03:59:39 AM
With the SegWit2x, the existing bitcoin transactions will not be congested (at least 2-3 years), and then there will be more intelligent two-layer protocols. .
Segwit is not the same as Segwit2x.
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 ... 550 »
Bitcointalk.org 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!