Bitcoin Forum
December 11, 2018, 06:42:30 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 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 547 »
701  Bitcoin / Bitcoin Technical Support / Re: How to construct transactions starting with bech32 addresses? on: January 11, 2018, 11:21:27 PM
Read BIPs 173: http://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki and 141: http://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
702  Bitcoin / Bitcoin Technical Support / Re: BitcoinCore node crashing on: January 11, 2018, 11:19:14 PM
Bitcoin Core is unable to write to your wallet file. Make sure that your user has the permission to write to the wallet.dat file.
703  Bitcoin / Development & Technical Discussion / Re: OP_CSV, opt-in RBF, and making outputs invalid after timelock on: January 11, 2018, 01:58:45 AM
My question is essentially: is there any way to make it so that Alice could not spend the output after the relative locktime has passed?
No, there is no way for that currently.
704  Bitcoin / Armory / Re: Using Armory on the BCH chain on: January 10, 2018, 05:04:35 PM
what is that, btw?:  P2SH-P2PK.  pay to public-key?  isn't that an old relic from the past?  wasn't the Base58 format introduced way back when to obscure the public key?  unless of course, the P2SH part obscures it via the redeem script...but for what purpose?
Yes, it is pay to pubkey. The P2SH part obscures that because the pubkey is part of the redeem script. The reason for doing P2PK instead of P2PKH is that it takes up less space than P2PKH nested in P2SH.
705  Bitcoin / Development & Technical Discussion / Re: How does HD wallet recovery from seed recovers all used addresses? on: January 10, 2018, 05:03:09 PM
On high level, I understand that all wallet addresses private/public keys are define from single private key,
No, they are not. Each address has exactly one corresponding public key, and each public key has exactly one private key. The seed is used to derive the private keys.

What I do not get, how the wallet app that I would use for potential recovery process "knows" how many addresses I actually generated/used and have unspent outputs (meaning BTC).
As Ledger generates new derived address for each tx and presumably new address for each tx change, there can be arbitrary number of addresses that had been used - and this is uknown to the recovery seed / wallet.
It doesn't know, it just guesses. Private keys and their addresses are derived in the same order and thus are given out and used in the same order. So when you restore a seed, the wallet will scan the blockchain for transactions and generate some number of addresses ahead of the last address known to have a transaction currently in the scan. This number of addresses is called the gap limit, and is typically 20. Every time a transaction is found corresponding to an address in the gap limit, it will refill the gap limit by generating more addresses.

How does then the recovery wallet app rebuilds from seed the wallet with all relevant addresses?
Read BIPs 39 and 32. BIP 39 specifies how the mnemonic is generated and then interpreted as a seed value. BIP 32 specifies how that seed value is used to generate the master private key and then how all other private keys are derived from that master private key.
706  Bitcoin / Electrum / Re: Victim of now-known exploitation in versions 3.0.4 and under on: January 10, 2018, 04:55:52 PM
so don't even know where to start to try and get my money back, if I can,
You can't. Bitcoin transactions are final once confirmed.

and how to prevent whatever has happened from happening again.
Update your software.

How do you know that you were a victim of that vulnerability? Was your wallet encrypted? If so, you were not a victim of that vulnerability. Did you have your web browser open to random, unknown, and possibly malicious sites? If not, then you were not a victim of that vulnerability. Just because there was a vulnerability does not mean that you were automatically a victim of it. It is also possible you just have malware on your computer and that is stealing your money, in which case you will need to remove said malware.
707  Bitcoin / Bitcoin Technical Support / Re: Anybody tried running lightning node on bitcoin blockchain? on: January 10, 2018, 04:49:23 PM
How do you find the experience (especially without segwit)?
Currently LN software only work when segwit is activated. There is no "without segwit".
708  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.1 Released on: January 09, 2018, 11:10:02 PM
is this when the bitcoin cash crap started? was the 0.15.1 release the catalyst?
No, it was not.

I have a problem with Bitcoin cash Bitcash (BCC) corrupting the Bitcoin (BTC) database.  I have to reindex both and still they get stuck at the fork of BCC off of BTC chain on August 1, 2017.

Anyone else been having this problem???  any solution?  perhaps running BTC and BCC on different computers?Huh  any other solution to the corrupting DB problem?    - Thanks
Use a custom datadir for one of the nodes. Both will attempt to use the same datadir and that will be very problematic because they are two distinct blockchains.
709  Bitcoin / Development & Technical Discussion / Re: P2SH-P2WPKH (Segwit) change addresses in Bitcoin Core - how? on: January 09, 2018, 10:55:10 PM
Thanks a lot, will check this... any idea when 0.16.0 could be likely released?
0.16.0 will be released soon after PR #11403 is merged. When that will actually be, we don't know and cannot give a date.
710  Bitcoin / Development & Technical Discussion / Re: Dividing miner reward over a k-length jumping window on: January 08, 2018, 07:57:31 PM
Why ? Can't we learn the identities of miners simply by checking the k-length window blockchain? Of course I meant, in my original post, we divide the reward to miners of the window. I'm not talking about distributing the reward to whole network.
Oh, you meant looking back through the last k blocks. That was not clear in the OP.

This would not necessarily work since a coinbase transaction can pay to multiple outputs, i.e. pay multiple people simultaneously instead of just one person/entity.

Edit: My reading comprehension is way off today.
711  Bitcoin / Development & Technical Discussion / Re: How to spend from a segwit address in Bitcoin Core? on: January 08, 2018, 07:54:22 PM
The private key is enough to determine the segwit address, although you may need to tell whatever other wallet software you choose to use to generate such a segwit address.
712  Bitcoin / Development & Technical Discussion / Re: Can Lightning network work decentralized ? on: January 08, 2018, 07:52:30 PM
Some simple math.
Assume we have 30 mil bitcoin users.
Every user should open a LN channel and close LN channel.
Bitcoin can handle 300 000 transactions per day.
30 mil users should wait for 100 days so every one can open a channel, and 100 days to close a channel if there is no other transactions besides LN settlements in bitcoin network.
300 mil users should wait 1000 days, so every user can have openned LN channel.
Bitcoin can't even adopt Lightning Network without big blocks. LN official release will lead just to another huge fee spike, and since LN channels should be restarted regularly bitcoin network can be clogged by LN settlements.
It's extremely unlikely that every single user is going to attempt to open lightning channels simultaneously on the day that a fully released software for LN is available. It is extremely unlikely that every single user is going to attempt to close their lightning channels simultaneously. As with literally every other release of a new technology in Bitcoin, it's going to take months, probably years, before LN is actually widely used. Just look at how long it took for P2SH to become widely used. And how long it has taken for segwit. This situation you are describing is extremely unlikely to happen.
713  Bitcoin / Development & Technical Discussion / Re: Dividing miner reward over a k-length jumping window on: January 08, 2018, 06:26:24 PM
It's expected that, especially once the coinbase reward is gone, this will result in miners competing for "juicy" txs and hence damaging the stability of the system. See http://dl.acm.org/citation.cfm?id=2978408 for future reference.
This behavior is known as fee sniping and there are things that are working already to protect against it. First of all, by having more fees in unconfirmed transactions than can be cleared by a block, miners will be more incentivized to mine those unconfirmed transactions because they can make just as much or more money than by fee sniping. Secondly, many wallets are now implementing anti-fee sniping measures such as locktimed transactions. By setting a transaction's locktime to be the block height when a transaction was created, the wallet prevents a miner from being able to orphan that block and fee snipe and include new transactions because the new transactions cannot be included in that replaced block. So this reduces the amount of money that can be gotten by fee sniping which makes miners less incentivzed to do so.

I've been thinking if it's possible to overcome this simply by changing the rewarding mechanisms of Bitcoin. So let's say we keep a k-length jumping window, take sum of fees in that window and divide it evenly to miners. So if we have k=4 and 1st block has 20 in fees, 2nd has 20 in fees, 3rd has 10 in fees and 4th has 30 in fees each miner will get (20+20+10+30)/4 = 20 in fees.
It's impossible to know how many miners there are and impossible to detect if someone is is pretending to be multiple miners so that they get paid more and everyone else gets paid less.
714  Bitcoin / Development & Technical Discussion / Re: Bip143 hashing examples question on: January 07, 2018, 10:54:43 PM
This actually raises another question that how VerifyScript() works if scriptSig is empty and scriptPubKey "OP_DUP OP_HASH160 1d0f172a0ecb48aee1be1f2687d2963ae33f71a1 OP_EQUALVERIFY OP_CHECKSIG" which fails on OP_DUP with empty stack but it's something I'll have to figure out by myself.
Segwit does not use that as the scriptPubKey. Only segwit output scripts use BIP 143.
715  Bitcoin / Development & Technical Discussion / Re: Bip143 hashing examples question on: January 07, 2018, 09:55:13 PM
Is this really a bug in the example or I miss something?
You are missing something. The first input is not a segwit input, so the hash calculation for that was ignored and skipped over. The second input is a segwit input, and is P2WPKH. This means that the scriptSig will be empty. The txwitness field contains the signature for the second input.
716  Bitcoin / Armory / Re: Restored wallet, Comment fields are missing? on: January 07, 2018, 05:43:21 AM
The comments are not part of the backup nor are they part of the blockchain or stored anywhere else. The comments are local to your wallet file only, and if you do not have the original wallet file, then the comments are gone.
717  Bitcoin / Development & Technical Discussion / Re: Masterblocks: Scaling Blockchain by summarizing balances on: January 07, 2018, 05:39:46 AM
First of all, the idea is not new and has been proposed multiple times throughout the years. But those proposals never actually go anywhere.

I see at least two things wrong with this proposal right of the bat.

First is this idea of balances. You are effectively introducing an accounts system, but Bitcoin does not work on an accounts system. Introducing an accounts system also introduces several other issues. First and foremost is transaction replay. Suppose, after a masterblock, your balance is 1 BTC and you want to send me 0.1 BTC. Since you are using a balance and not the UTXO set system, I can just keep replaying that transaction sending me 0.1 BTC. To the network, it looks like you just keep sending me 0.1 BTC, there is no way to differentiate between you sending me 0.1 BTC and me replaying the same 0.1 BTC transaction. Secondly, as you mention in the document, this doesn't work with scripts like multisig. In order to support those you have to have even more stuff that makes this more complicated. Then there's the problem with making transactions. Now you need to have multiple transaction types, one for spending from a balance, one for spending from balance with weird scripts, and the normal transaction type. This is complex and prone to error.

Instead of this balances thing, it would be much easier to effectively have one giant transaction in that masterblock which spends all previous UTXOs and creates new UTXOs. Those with the same scripts are combined so that each output has a unique script and the value of the output is the sum of all of the UTXOs for that script. This avoids all of those problems I mentioned earlier.

Next, there is a problem for new nodes. When you start up a new node, how does that node know that it is using the correct blockchain? How does it know that the balances are correct? There isn't anything that prevents an attacker from creating essentially a fake masterblock and giving it to new nodes. Since new nodes don't have the full block history, how can they be sure that the masterblock is actually valid?
718  Bitcoin / Development & Technical Discussion / Re: Issue about Segwit HD on: January 06, 2018, 06:22:07 PM
This thread proposes changes to BIP49 to address segwit compatibility issues
It's better to do this on the bitcoin-dev mailing list.

What would happen if you recover a wallet  using seed words ?
That is orthogonal to BIP 49. That is something to do with BIP 39 and is unrelated to key derivation. Unfortunately BIP 39 does not have a versioning scheme to give seeds version numbers.
719  Bitcoin / Development & Technical Discussion / Re: bitcoin over quantum machinery on: January 06, 2018, 06:16:18 PM
There's already several threads about Bitcoin and quantum computers. Please learn to Google or use the search function.

Locked.
720  Bitcoin / Development & Technical Discussion / Re: bitcoin is decided by port and algorithm? on: January 06, 2018, 06:14:12 PM
maximum target value is which parameter? How to increase it for example
That's the powlimit variable found here: http://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L83. To increase it, just make the number bigger.
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 ... 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!