Bitcoin Forum
January 16, 2019, 07:32:34 PM *
News: The copper membership price will increase by about 300% around Friday.
 
  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 87 88 89 ... 549 »
761  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.
762  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.
763  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.
764  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.
765  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.
766  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?
767  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.
768  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.
769  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.
770  Bitcoin / Development & Technical Discussion / Re: Could the Intel vulnerability have compromised private keys? on: January 05, 2018, 05:28:22 PM
Why do you trust dedicated hardware wallets more than a general purpose laptop? Have you audited your Trezor/Ledger or whatever you are using chips?
Have you audited your general purpose laptop and all of the chips it is using? It is far easier to audit the hardware wallet if you know what you are doing. Furthermore their firmware and bootloaders are mostly open source (for the Trezor, they are all open source, for Ledger, only partially) whereas the firmware for your laptop is most definitely not.
771  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-QT Constantly Crashing on: January 05, 2018, 05:19:38 PM
It looks like your wallet.dat file is corrupted. Did you move the file while Bitcoin Core was running?

If you have a backup of your wallet.dat file, you should restore that backup. You will need to stop Bitcoin Core, copy the wallet.dat in the datadir to somewhere else (don't delete it), copy your backup wallet.dat into the datadir, and start Bitcoin Core.
772  Bitcoin / Development & Technical Discussion / Re: bitcoin is decided by port and algorithm? on: January 05, 2018, 05:16:15 PM
so if i set it to be smaller than 2016, for example set it to be 100, I will not eat my coin after the first 100 blocks?
Not necessarily. You may need to increase what the maximum target value is (i.e. decrease minimum difficulty) if you are also changing the target interval time between blocks.
773  Bitcoin / Bitcoin Technical Support / Re: Database corrupt on re-start [Was: Bitcoin-qt cannot read the database, closing] on: January 05, 2018, 07:15:14 AM
I did not delete anything.  I'm not familiar enough with BitCoin-QT files (yet) to know what is appropriate to delete.
If the reindex fails, you should delete the highest numbered blk*.dat and rev*.dat files in the blocks/ folder in the datadir.

I think maybe for small users like me, with no understanding of application internals, BitCoin-QT application may not be sustainable. 
This rarely happens and is usually not Bitcoin Core's fault. In many cases, it is just spurious/random corruption (cosmic rays, random bit flipping, etc.). Other times it is a hardware problem.
774  Bitcoin / Bitcoin Technical Support / Re: Database corrupt on re-start [Was: Bitcoin-qt cannot read the database, closing] on: January 05, 2018, 04:46:22 AM
Have you tried deleting the highest numbered blk*.dat and rev*.dat files and then reindexing (deleting those files will force a reindex anyways)? This will remove the corrupted block (and a few others) which will then be redownloaded after the reindex completes.
775  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-qt cannot read the database, closing on: January 05, 2018, 03:06:37 AM
I'm not seeing my post that has the debug log excerpt, showing a normal restart followed by BitCoin-QT panic shutdown and corrupt database error message.  Were you able to view that portion of the log? 
That post was deleted because individual posts cannot be migrated to a different thread. Please repost it.
776  Bitcoin / Development & Technical Discussion / Re: How to transfer/import a segwit (P2SH-P2WPKH) address into Bitcoin Core? on: January 05, 2018, 02:26:56 AM
I had tried to do that on the console ("addwitnessaddress [the_legacy_address_that_appeared]", but it gave me the error:

"Public key or redeemscript not known to wallet, or the key is uncompressed (code -4)"

(I did not rescan, as it seemed the addwitnessaddress command wasn't successful.)

There's something I do not know or understand about segwit's functionning, and so I have no clue how to progress forward with that.
What would that mean?
Oh, since you are coming from Armory, this is going to be slightly painful.

Segwit only allows compressed public keys, but Armory only uses uncompressed public keys. In order to use Segwit, Armory will compress the keys on-the-fly, but the export will still give you the uncompressed version.

Go to http://github.com/pointbiz/bitaddress.org and download the git repo. That is the source code for bitaddress.org which is a website that is reasonable trusted to not steal your private keys. By downloading the source code, you can access the website locally and thus not send any private keys to a website. Even so, once you finish doing this, you should move your coins immediately to a new address and never use this address (both the segwit and legacy versions) ever again.

Open the file bitaddress.org.html in your browser (double clicking it should do that automatically) and choose the option for "Wallet Details". Enter your private key into the box and click "View Details". Scroll down and copy the string from where it says "Private Key WIF compressed". It should begin with a "K".

Import that string into Bitcoin Core. It is the private key that corresponds to the compressed public key. Then use addwitnessaddress on the imported address.
777  Bitcoin / Bitcoin Technical Support / Re: 256: absurdly-high-fee on: January 05, 2018, 02:19:06 AM
The transaction is just extremely large and thus has to pay a high fee. The actual fee rate is pretty low, but Bitcoin Core has a hard limit for what it considers to be an absurdly high fee. That limit is 0.1. Any transaction that pays more than 0.1 BTC in transaction fees, regardless of the fee rate, will be rejected with this error. It is not consensus invalid, it is just non-standard.
778  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-qt cannot read the database, closing on: January 05, 2018, 02:13:21 AM
his is not proof-positive that the hard drive is OK, but it's a reasonable indication that the problem lies elsewhere.  The drive itself is a high-reliability HP spinning SATA drive for use in servers.  It's almost new.  Odds are good that it's OK.  
If you think it is hardware, check your RAM.

This is the time when I tried to restart bitcoin-QT.  The QT app wrote a blank line with a time stamp, followed by about 20 linefeeds. 
That's normal.

Debug log excerpt follows:
This is a clean shutdown.

Can you post what the log of when you started it up?
779  Bitcoin / Development & Technical Discussion / Re: Lightning Network: If your whole balance is very low, can you spend it? on: January 05, 2018, 02:08:20 AM
Getting into the LN thing, every answer opens up a new question... so you have to tie an amount (from single address) to a establish a channel.  Sort of staking?  I can see how this can work for regular large payments, say with an exchange, however its a big ask to expect people to do this for small payments.  It seems like putting up a credit tab with the shop/bar and you have to hit a minimum spend to make it worthwhile.
You can route payments through people, and have payments routed to you through people. You don't have to just transact with the other person in the channel.

The cost of on-chain transactions will likely increase.
In the short term on-chain transaction fees will likely decrease. In the long term, if more people use Bitcoin, fees will increase, but less so to levels that they would be without LN.
780  Bitcoin / Development & Technical Discussion / Re: Would it cost anything to open a Channel on Lightning Network? on: January 05, 2018, 02:05:47 AM
Huh  So back to square 1, we need to pay fees to open the channel each transaction?  Or we keep our own channel open (tieing wallet balance) hope our recipient is on LN with an open channel?
No, you only pay a fee when opening and closing a payment channel. Once the channel is open, you can transact freely (i.e. as many times as you want) with the other person in the channel at no cost. If you want to transact with someone outside of the channel but there is some route to them through LN channels, then you can use your same channel to pay that other person by routing a payment through other channels. This routing of payments will either be extremely cheap or have no cost, depending on whether node operators in the route charge a fee for being routed through.

If you are just going to make a single transaction with someone and you don't plan on using them to route payments to other people, then you should not create a channel for that. Just make a normal Bitcoin transaction.
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 ... 549 »
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!