Bitcoin Forum
February 18, 2019, 09:13:56 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 ... 551 »
1  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.17.1 Released on: February 17, 2019, 06:10:51 AM
welp i am 17.1 and getting warning: unknown block versions being mined.. and i not mining Sad
That's unrelated to whether you are mining or not.

I believe that warning is being caused by miners using asicboost which modifies the version number.
2  Bitcoin / Development & Technical Discussion / Re: bitcoin transaction: offline relay vs off-chain processing on: February 17, 2019, 12:28:23 AM
I didn't find anything describing how to verify transactions offline (without going through the p2p network) in the article.
Blocks were received over Blockstream satellite which only works in one direction (satellite sends to you). These blocks can be verified without needing any network connection.

First of all I think it is too much to call such a simple model offline transaction it is just confusing, using a non-ip relay network to send your transactions doesn't make bitcoin or its transaction processing offline.
No one said that it was offline transaction processing. What he did was offline transaction relay. Relay and processing are two different things.

Offline processing is already a thing. You don't need an internet connection to process the blockchain if you already have it.

Alternatively I'm working on a true offline technology which I prefer to call it off-chain transaction processing that I will discuss in more details about it in next posts. For the starter I wanted to know how do you guys think about this subject and perceive this term: off-chain transaction processing. Heads up, I'm not talking about LN or side chains, ... it is bitcoin transactions being processed offline.

Again it would be easy to denounce such a concept as paradoxical or ambiguous but as I said, trivial takes are not helpful.
Saying things like: "Hey, as long as we are speaking of bitcoin transactions, they are processed on-chain", wouldn't help as we are all aware of that.

To be a bit more specific by off-chain bitcoin transaction processing I mean a technology that allows wallets to exchange bitcoin txns, just like paper money/bills, multiple times with multiple parties engaged without leaving any trace on the blockchain other than circumstances that one of the parties, decides to deposit it.
That is not "offline". Off chain does not mean it is offline, and vice versa. E.g., Lighting can be done offline, but it is still kind of on-chain (as it relies on funding and closing on chain). Likewise, you could say Lightning is off-chain (The actual transactions are off chain) but not offline.
3  Bitcoin / Bitcoin Technical Support / Re: Question on structure of Segwit part of transaction on: February 17, 2019, 12:21:50 AM
Segwit is specified in BIPs 141, 143, and 144.
4  Bitcoin / Bitcoin Technical Support / Re: Wallet backup - New to Bitcoin Core on: February 13, 2019, 10:28:33 PM
What I find odd is that in the bottom right corner of my I can see that "HD key generation is enabled".
It was my understanding that HD wallets basically mean you write down a recovery seed and you can always restore your wallet using that seed. Does this mean that my initial wallet back up after downloading Core is sufficient and that I don't have to do a backup every week or so?
HD wallets do not necessarily have a recovery seed or mnemonic for you to write down or remember. It just means that all of the private keys are derived from a single random number. All you need to do is protect that and have that random number in order to regenerate all of your private keys and thus access your Bitcoin again. Some wallets will represent this random number as a string of words for you to remember, hence a recovery mnemonic. However Bitcoin Core does not do this. That random number is stored in the wallet.dat file. So you just need to protect and backup that wallet.dat file in order to be able to access your private keys.

As for how frequently to backup, it depends on how many transactions you are doing and how important it is for you to know what those transactions were for. In terms of private keys and access to your Bitcoin, backing up once and having the same backup duplicated in multiple places is probably enough. But once you restore, you will lose any metadata that you had for your transactions. So you would lose things like address labels and transaction comments which may be important to you. If you want to keep those, then you should backup periodically. How frequently is up to you.

Also, you should make a backup if you ever happen to give out more than 1000 addresses. This is because Bitcoin Core's lookahead keypool is 1000 addresses. If you happen to give out 1000 addresses but don't receive Bitcoin at any of them, but on the 1001st address you give out you do receive Bitcoin, when you restore from your backup, the lookahead keypool won't be large enough to see that 1001st address and add that transaction to your wallet. So at a minimum, you should backup every 1000 addresses given out. But that's a lot of addresses and you probably won't give out that many addresses so quickly.
5  Bitcoin / Bitcoin Technical Support / MOVED: Generate address from mnemonic seed on: February 12, 2019, 01:24:54 AM
This topic has been moved to Trashcan.

Duplicate
6  Bitcoin / Development & Technical Discussion / Re: Submitting CPFP transaction with zero-fee parent on: February 07, 2019, 02:05:08 AM
But is it actually possible to submit them somehow to the network "as a package"?
Unfortunately there is not. However there was some discussion about this and I believe someone is working on it.
Would you please do some digging and submit a link?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html

That message and thread talks about CPFP and Lightning. It brings up package relay since that is a prerequisite for that.
7  Bitcoin / Development & Technical Discussion / Re: Submitting CPFP transaction with zero-fee parent on: February 06, 2019, 08:21:27 PM
But is it actually possible to submit them somehow to the network "as a package"?
Unfortunately there is not. However there was some discussion about this and I believe someone is working on it.
8  Bitcoin / Development & Technical Discussion / Re: Why signing same message with same private key is yielding different signatures? on: January 31, 2019, 05:53:37 AM
That's really interesting actually. But for OP's case, if the random number wasn't generated using the message itself (which I assume is the most common way nowadays as each unique message will have its own number), how do verification algorithms verify all the signatures above?
If you are interested in seeing how ECDSA works and understand the equations, have a read of the Wikipedia page
9  Bitcoin / Development & Technical Discussion / Re: Why signing same message with same private key is yielding different signatures? on: January 30, 2019, 09:17:43 PM
How many such combinations are possible?
Infinitely many.

The signature algorithm used in Bitcoin is called ECDSA. One part of creating a signature with ECDSA is generating a random number (known as a nonce) and combining it with the private key. Every time you make a signature, you generate a new random number. This nonce is very important and cannot be known to anyone else or be used in different signatures. Otherwise the private key can be derived from the signature. This is what you are observing here.

However some software will, instead generate the random number by hashing the private key and the message being signed. This will make a number that is random enough, secret (because the private key is also secret), and extremely unlikely to be seen in different signatures. This will result in the same signature when you signing the same message multiple times.
10  Bitcoin / Development & Technical Discussion / Re: Why don't we prune to scale? on: January 29, 2019, 07:12:42 PM
I maintain that your "need for trust" issue is not correct though I admit that there is something to pay when you get such a huge utility, unlike what you say, it is not about trust, it is about desired security level against long range attacks
A large part of the desired security level against long range attacks is reducing the need for trust. I do not think that there is enough utility to be gained from cutting off blockchain history and using an initial state to warrant the decrease in security. Of course, this is just opinions between multiple people and no one is going to convince the other that they are correct. So I will stop responding to you.
11  Bitcoin / Development & Technical Discussion / Re: con-current validation engine for bitcoin-core on: January 29, 2019, 04:17:24 PM
There are couple of reasons i see the validation process is done linearly. First of all leveldb (database of UTXO set) does not support multi-threading. And there are static variables defined inside `validation.h` keeping track of state of blockchain. Maybe I'm wrong.
The state of the blockchain must be updated synchronously and in order of blocks. Otherwise you will run into concurrent update issues which will affect consensus.

That's not a requirement to reach consensus. One can do so after evaluating asynchronously. And merging the result to take final decision.
This is certainly possible. The question is, Is it needed. As domob did point out. It will probably have no effect with current CPUs available. I reckon many cores can change the game. In which verification time of input coins are done faster than validating a block and fetching UTXOs.
If you validate blocks out of order, then a block may contain a transaction which spends an output that is in a block that you have not yet validated. And if you are processing the transactions in a block out of order, then you may have a transaction which spends an output of a transaction that is found earlier in the block which you may not have validated yet.
12  Bitcoin / Development & Technical Discussion / Re: Why don't we prune to scale? on: January 29, 2019, 04:08:13 PM
There is absolutely _no difference_ between booting from the hash of the genesis and the hash of a UTXO set at given height in terms of resistance to forge, both are immune to forge as long as the node we are booting from is able to convince us about the raw data each hash is committed to.
That is completely wrong. First of all, nodes do not just have a hard coded hash of the genesis block. The genesis block is small, so it is hard coded into the software itself. Furthermore, because the genesis block is small, one can visually inspect the hard coded value and see that it is correct. Furthermore, it is extremely obvious if you have the wrong genesis block: none of the blocks that you have will show up on any node you connect to or on any block explorer!

But a UTXO set as initial state, that's very different. Hardcoding a UTXO set is unfeasible because it is large. Because it is large, you can't visually inspect it and make sure that there are no unexpected UTXOs there. If it is wrong and does omit or have an extra UTXO, you can't tell that you have the wrong UTXO set until a UTXO you don't have or an extra UTXO you have is spent causing a hard fork. Sure hard coding a hash would help, but you are still trusting that the UTXO set that matches that hash is correct.

These are two different things, to say that they are the same is disingenuous.

Miners couldn't collude for inserting malicious UTXO commitment to blocks, for the same reason that they couldn't do it for any other form of malicious data: full nodes will reject such blocks and commit to the alternative healthy chain.
New nodes coming online won't know. Under this scheme, a new node that comes online is unable to verify that their initial UTXO set is correct. They can be forked off onto a separate chain which has an invalid initial UTXO set and the new node would have no idea.

Speaking of centralization, let's take a look at trade-offs involved:

Current Situation
pros:
  • secure against complete chain rewrite attacks
  • nothing else
You forget a few.
  • Almost no trust in any third parties required. The only trust necessary is in developers for software whose code can also be independently audited
  • The entire history from the beginning of Bitcoin is verifiable

  • downward compatibility and software bloat because of the need for re-running the protocol from root
Have you looked at Bitcoin Core in regards to the consensus rules? There's very little bloat because the protocol really hasn't changed that much. Those things that would cause bloat have been reduced to simple if statements or outright removed (BIP 34 style activation has been entirely removed and those soft forks are activated by block height/block hash or enforced from genesis).

  • inherent resistance to change and evolution in time
Why is that a con? The blockchain is supposed to be immutable after all. Not only that, but BItcoin does evolve, just slowly and cautiously, as you should be when dealing with a system that handles large amount of money.

  • Great decentralization effects because of realization of fast and cheap fully functional nodes
There's more to decentralization than just more nodes. More nodes does not mean more decentralization. Take Ethereum for example. It has many light nodes, but I would not say it is decentralized. They are centralized under the Ethereum developers who can just say "we're having a hard fork at this time" and then say "sorry guys, hard fork canceled" and the entire network just does as they say. That is not decentralization, but they have many nodes.

  • Improved software quality because of significant reduction in need for downward compatibility.
Just about everything that is currently needed for consensus validation would be needed in the UTXO commitment model. In fact, this would cause more bloat because now we have to handle a new rule: UTXO commitments. All of the other things needed for backwards compatibility like non-segwit outputs still need to be maintained.

cons:
  • vulnerability to ultra-long/complete chain rewrite attacks which are not practical anyway
  • nothing else
You forgot a few:
  • Increased trust in third parties
And if you are talking about UTXO commitments in every block, there's more cons:
  • Additional time to validate and produce blocks due to the need to hash the UTXO set
  • Issues with commitments themselves where they do not necessarily commit to all UTXOs or collide and commit to UTXOs that do not exist



Now I'm not saying the UTXO commitments are universally bad. It is an active area of research and someone may come up with a breakthrough which allows us to do this kind of pruning trustlessly. However, as it is now, UTXO commitments introduce more trust in others, and pruning the blockchain so that it is just an initial UTXO set from which blocks are built on is simply introducing too much trust to the system.

But UTXO commitments will certainly be useful even if they introduce more trust. Instead of pruning the blockchain to some initial state, they would allow for a faster sync. You can do a sort of Hybrid sync where you use a UTXO set initially and check it against UTXO commitment in blocks so that you can be synced very quickly. Then in the background the blockchain can be downloaded and checked. This would allow the best of both worlds: you can have a faster sync and reduce your node's resource usage, and the full history is still verifiable and you can verify that the UTXO set you received initially is correct. This would be optional: for those who want to have a faster sync and don't care that they are trusting others, they can use the UTXO commitments. For those who want a faster sync and are okay with initially trusting but later verifying the UTXO set, they can use the hybrid sync. And for those who want to have the least amount of trust in others and to verify everything, they can do the full sync of the blockchain.
13  Bitcoin / Development & Technical Discussion / Re: con-current validation engine for bitcoin-core on: January 29, 2019, 03:18:36 PM
There are couple of reasons i see the validation process is done linearly. First of all leveldb (database of UTXO set) does not support multi-threading. And there are static variables defined inside `validation.h` keeping track of state of blockchain. Maybe I'm wrong.
The state of the blockchain must be updated synchronously and in order of blocks. Otherwise you will run into concurrent update issues which will affect consensus.
14  Bitcoin / Development & Technical Discussion / Re: Why don't we prune to scale? on: January 29, 2019, 12:20:12 AM
What you are describing is an idea that has been floating around for several years now. You're not the only one to think of it.

The reason it has not been implemented is because it introduces some centralizing trust. Right now, a new node coming only has to verify every single block and confirmed transaction since the beginning of Bitcoin. In doing so, they are able to build the UTXO set themselves and check that everything is correct. The only trust is that the genesis block is correct, and if it is not, it's extremely obvious that it is wrong. However changing it so that the "genesis" is really the UTXO set at a certain height means that there is going to be more trust. Now you have to trust that the UTXO set is correct. But without having the full blockchain history, how can you prove that that UTXO set really was the UTXO set at the cutoff point?

Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.

To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.

There are other possibilities too that have been discussed elsewhere. But the issue with this idea in general is that it involves more trust. And in a system where the goal is to have as little trust as possible, that is just not going to happen.
15  Bitcoin / Development & Technical Discussion / Re: How 51% attack is deterministically implemented on testnet? on: January 28, 2019, 03:19:41 PM
Is disconnecting one node from chain for some time will do the it properly or other nodes recognize it once it is added to the chain ?
Yes, disconnecting your node from the network would work fine. You don't even need to disconnect though. Bitcoin Core has an invalidateblock command which you can use to tell your node to mark a block and all of its descendants invalid. That will force you onto reject new blocks and you can then make your own blockchain fork starting from that point.

yes, I know but simulating these attacks require creating two blocks at the same time which the fake chain is longer that the true chain. Since for test I mine with bitcoin built-in miner I have no idea how to create two blocks at the same time. There is always a delay(at least in timestamp). Son the step by step scenario seemed a bit confusing at first sight.
The timestamp doesn't matter.
16  Bitcoin / Development & Technical Discussion / Re: Var length integers on: January 25, 2019, 05:52:14 PM
voltage?

This is just how you store integers. For integers that have a value less than 0xFD, you just have the integer as a single byte by itself. For an integer between 0xFD and 0xFFFF inclusive, you put the byte 0xFD followed by 2 bytes representing the integer. For integers between 0x010000 and 0xFFFFFFFF inclusive, you put 0xFE followed by 4 bytes representing the integer. Lastly for integers between 0x0100000000 and 0xFFFFFFFFFFFFFFFF, you put 0xFF followed by 8 bytes representing the integer.
17  Bitcoin / Development & Technical Discussion / Re: Bitcoin core node with watch-only [electrum generated] on: January 21, 2019, 12:23:30 AM
But there is no parameter to automatically get the bitcoin-cli to notify me whenever one of the watched addresses receives a payment ? Do I have to make a query to get balances after every new block is found ?
You can start Bitcoin Core (bitcoind) with the -walletnotify=<cmd> option where <cmd> is a command that you want Bitcoin Core to execute every time a new transaction to the wallet is received. Read the help (start with -help option) for more info on how to use it.
18  Bitcoin / Development & Technical Discussion / Re: Bitcoin core node with watch-only [electrum generated] on: January 20, 2019, 09:08:44 PM
You cannot import extended public or private keys into Bitcoin Core.

You can import the addresses that you would like to watch using the importaddress or importmulti commands. You should still see notifications for transactions to and from watch only addresses. To be able to see watch only balances and transactions using RPC, you will need to set the watch_only parameters to true for the commands that have that (e.g. getbalance, fundrawtransaction, etc).
19  Bitcoin / Development & Technical Discussion / Re: Do I need to compile a wallet each time I do changes to it? on: January 20, 2019, 09:04:23 PM
Yes, you need to always compile it. A lot of things are set dynamically through code and not through the UI forms.
20  Bitcoin / Bitcoin Technical Support / Re: Encrypt RPC calls? on: January 20, 2019, 02:28:04 AM
No. Bitcoin Core does not supported encrypted RPCs. However you could use a reverse proxy which uses HTTPS to encrypt traffic from your RPC client to the proxy. The proxy decrypts the RPC and forwards it to Bitcoin Core.
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 ... 551 »
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!