Bitcoin Forum
November 17, 2018, 07:57:00 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 87 ... 547 »
721  Bitcoin / Bitcoin Technical Support / Re: Why is it called child pays for parent ? on: January 05, 2018, 01:59:46 AM
I'm just wondering exactly why it was called this? Surely it could of been called "adjust fee" or something simpler?
No, it could not have.

Child Pays For Parent is called such because you are creating a new transaction which spends from the transaction that you want to change the fee of, hence it is a child transaction of the parent unconfirmed transaction. This child transaction contains a high enough transaction fee to pay for the parent. Hence Child Pays For Parent.

The other "adjust fee" method is called Replace By Fee. With Replace By Fee, you are creating a conflicting transaction that pays a higher transaction fee and replaces the original lower fee one.

So because there are multiple methods to increasing the transaction fee, it can't just be called "adjust fee".
722  Bitcoin / Development & Technical Discussion / Re: HELP: Recover Bitcoins mined using 0.3.23 client on: January 05, 2018, 01:57:25 AM
I installed bitcoin core and replaced the wallet but I could not see my BTCs. So I became nervous again. I read several forums and they said it was normal to have a 0 BTC if the wallet replaced was old (from 0.3.23 client)
If Bitcoin Core is not fully synced, you will not see any Bitcoin.

First of all a doubt. I received all my BTCs mining. This means that all my reception addresses should not contain balance?
No, they should have a balance.

I checked each one of my 30 addresses BitcoinCore found in my wallet in BlockChainInfo, and none of them has balance. This means I lost my BTCs?
If you do not see a transaction history for those addresses, then that means that those addresses never had any Bitcoin, be that through normal transactions or from mining. If you do see a transaction history and there are transactions that send money from those addresses, then the Bitcoin has been sent elsewhere.

Do you think there is a solution? I read about extracting the private key using pywallet. Is this trustful? Which is the best way?
There is no need to do that if the wallet is not corrupted.

If Bitcoin Core is not fully synced, then let it fully sync. Once it is synced, you will know if you have any Bitcoin or not. If not, then there is no way to recover any of those Bitcoin because the private keys are probably gone and are not part of the wallet that you have.
723  Bitcoin / Development & Technical Discussion / Re: How to transfer/import a segwit (P2SH-P2WPKH) address into Bitcoin Core? on: January 05, 2018, 01:50:42 AM
But if I try to import the private key of a segwit (P2SH-P2WPKH) address into Core (through the console) it gives me a legacy "1" address that doesn't correspond to my segwit address
Use addwitnessaddress on the legacy address that is imported. Then rescan the blockchain.
724  Bitcoin / Development & Technical Discussion / Re: Question regarding Lighting Network on: January 05, 2018, 01:47:30 AM
the real question: when will it be implemented?  Tongue
It is already implemented and almost done. It is actively being used on the testnet and multiple demonstrations of lightning on the Bitcoin mainnet have already been done. Once any of the major implementations of LN reach a release version and the Lightning 1.0 spec is finalized, you can consider lightning "released".
725  Bitcoin / Development & Technical Discussion / Re: Can Lightning network work decentralized ? on: January 05, 2018, 01:39:00 AM
1) Users need to be online all the time! If somebody is offline he can NOT process a transaction for you, this means that that person breaks the route, which is a huge problem. Banks on the other hand will of course be online 24/7
Not necessarily. If only one node's HTLC success transaction is broadcast, then all nodes in the route can take their payment and make their payment simultaneously even if one or more of them is offline.

2) Monetary incentives for centralization! Everybody who helps processing your transaction gets a small fee. So if there's a route with 10 people in it, then a bank with a direct route can charge 9.99x the fee for one hub and still be cheaper! So the bigger a hub becomes, the smaller the routes will become and the more they can charge. This of course works as a huge snowball for size and is a huge incentive to become as big as possible.
I don't think the fee will be a centralization pressure. It will be a race to the bottom because there will be competition and it will be easy for new nodes to compete. So sure your "bank" charges 9.99 as their fee for one route. Now I create my own node and I get a couple of channels, not as much, but still many. If you route through me, you may still have to go through 4 other nodes. I can then charge 5 as the so the total route fee is 9 (5 + 4*1). Now that "bank" has to lower his fee to remain competetive, and so on and so forth. It will be difficult for any one node to get a monopoly and maintain it and make LN centralized. Even then, anyone can still make their own node and make channels without the permission of the "central nodes". So there will certainly be lots of competition and that makes it decentralized. You can close a channel without the other party agreeing to it, so you can switch to using a competitor at any time. You can even close your channel and fund the opening of a channel with someone else at exactly the same time in the same transaction, so you won't have to pay more in transaction fees.
726  Bitcoin / Bitcoin Technical Support / Re: Question on Bitcoin-Qt v0.8.5-beta on: January 05, 2018, 01:31:46 AM
If it has, it probably has a low fee and won't confirm any time soon.
Various network relay rule changes have likely made the transaction non-standard and thus not relayed, in addition to a very likely low or zero transaction fee.
727  Bitcoin / Development & Technical Discussion / Re: bitcoin is decided by port and algorithm? on: January 05, 2018, 01:30:33 AM
why the first 2016 blocks different?
Because the difficulty adjustment algorithm won't kick in until after the first 2016 blocks, so only after the first interval will your blockchain be different. If you change the retarget period, it will be the minimum of 2016 blocks and whatever you set the retarget period to be, i.e. if the retarget period is smaller than 2016, it will be that. Otherwise it will be 2016 blocks.
728  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-QT Constantly Crashing on: January 05, 2018, 01:27:41 AM
Can you post the debug.log? It usually contains more information than the dbLog.
729  Bitcoin / Development & Technical Discussion / Re: Question about locktime on: January 05, 2018, 01:23:07 AM
It's an arbitrary large number.
730  Bitcoin / Development & Technical Discussion / Re: Lightning Network: If your whole balance is very low, can you spend it? on: January 03, 2018, 11:11:56 PM
Would it be reasonable for the coffee shop to pay transactions fees for you?
No it is not. It would be reasonable for you to open a channel with your employer who also has a channel open with that coffee shop. Your employer would pay the transaction fees for you, and then you can pay the coffee shop. Later the employer would pay your through that channel.

Is this supposed to be a common use case scenario?
No. As I said earlier, LN is not for spending from small outputs once but rather spending from large outputs in small amounts many times. The common use case scenario is that you put in (for example) 0.01 BTC into the channel with the coffee shop. Then over the course of months or years, you slowly pay the coffee shop 0.00001 BTC per coffee but without actually making any on-chain transactions and paying their transaction fees.
731  Bitcoin / Development & Technical Discussion / MOVED: Bitcoin PrivKey question - I found TWO privkeys for ONE address on: January 03, 2018, 10:46:07 PM
This topic has been moved to Trashcan.

Trashcanned upon request.
732  Bitcoin / Development & Technical Discussion / Re: bitcoin is decided by port and algorithm? on: January 03, 2018, 07:07:51 PM
For the bitcoin source code. If I change from 10 minutes one block to 5 minutes one block and also I changed the port, whether I still face th possibility that my new coin will be merged with bitcoin due to the longer blockchain?
Changing the difficulty adjustment calculation to target 5 minutes should make it not be wiped out after the first 2016 blocks. The first 2016 blocks can still be the same as Bitcoin's and could wipeout your chain.
733  Bitcoin / Bitcoin Technical Support / Re: Question regarding BIP-112, BIP68 CSV and nSequence on: January 03, 2018, 07:06:16 PM
convert the lock number of 169 into binary

pad some zeros at the end to make it 16 bits long
Bitcoin uses little endian numbers, so these need to be reversed.

Otherwise, that looks correct.
734  Bitcoin / Development & Technical Discussion / Re: require a TX-level PoW nonce to inhibit spam? on: January 03, 2018, 06:59:40 PM
I'm not proposing that individual people would have to submit PoW, but instead that individual transactions would. Thus, a single transaction with many hundreds of outputs or inputs would require a relatively large PoW, but a transaction where the entire balance of one address is transferred to another address would not. (This has been my working definition of spam: transactions of the former type rather than the latter.)
I don't think spam transactions have been large transactions, rather they are small ones and there are lots of them. So this wouldn't help. Perhaps if you inverted it, smaller transactions have a higher PoW. But then spammers would just make large transactions. And if you penalized large transactions, they'll make smaller transactions.

Furthermore, as I said earlier, getting an ASIC or a GPU or two would basically make this completely useless unless you can somehow adjust the difficulty to the volume of transactions a person is creating. If I were a spammer, I could get an ASIC and just churn out spam anyways because the ASIC is going to blow through whatever difficulty you set unless that difficulty is specifically being adjusted for my spam.

Now you might say that getting an ASIC or GPU is costly and thus prohibitive, but it has been theorized that many of these spam attacks are coming from miners who want to increase the fee rate and thus increase their mining profits. So if a miner is mounting a spam attack, they can take a single ASIC machine that is being used for mining and repurpose it to get around the PoW limitation. They would still be able to churn out spam transactions as quickly as before.

Lastly, as ranochigo said, your proposal would have a detrimental effect on the UTXO set. You would be encouraging the creation of UTXOs when what we want to do is encourage the consumption of UTXOs. By making large transactions costly, people will make smaller transactions and likely with change (so likely 1 input and 2 output transactions) which will result in a net increase of UTXOs. This is not very good for Bitcoin, and it has the effect of grinding down one's UTXOs into dust thus making it hard to spend any Bitcoin later.
735  Bitcoin / Bitcoin Technical Support / Re: PSA: how to get baddress from bitpay URI (now REQUIRED) on: January 03, 2018, 06:51:19 PM
Nice find!

I can't imagine that Bitpay is going to leave that there any longer though, it seems like a mistake for them to do so and now that it is publicly known, it will probably go away.

Also, this link
does not work, probably because the invoice expired already.

I've also been toying with creating a Python script to extract it... but will just use this trick for now Wink
You can use the one I wrote:
736  Bitcoin / Development & Technical Discussion / Re: Lightning Network: If your whole balance is very low, can you spend it? on: January 03, 2018, 06:45:43 PM
Still don't understand how would you spend 0.00001 if you cant you can't even open a channel with that amount.

Now you can't spend it because fees on chain are bigger than that. Will opening channels be cheaper in the future?
You don't necessarily have to be the one paying the fee. Both parties in the channel can fund the channel in the same funding transaction. So if you only have 0.00001 BTC, you can have the other party be the one who pays the transaction fee. They might do this if the channel is not only for you to buy a coffee but rather that you are also expecting to get paid by this person or route incoming payments through them.
737  Bitcoin / Development & Technical Discussion / Re: require a TX-level PoW nonce to inhibit spam? on: January 03, 2018, 06:12:41 AM
It wouldn't work. If the PoW for transactions was SHA256d, you could just buy an ASIC and spam transactions. If it were something else, you can use GPUs and it would be just as effective. Making the difficulty adjust to transaction size would be completely pointless since spam transactions are typically not large. Furthermore, you couldn't just make it based on the person who is sending it since Bitcoin does not use an accounts based system. It is difficult (nearly impossible) to know whether two transactions were created by the same person, so you can't make the difficulty adjust to the person. So this idea of adding a PoW to each transaction is pointless and wouldn't reduce anything, at least with Bitcoin's design and security model.
738  Bitcoin / Development & Technical Discussion / Re: Lightning Network: If your whole balance is very low, can you spend it? on: January 03, 2018, 06:05:02 AM
If you have to use someones elses payment channel to get through, how is it decided how much fee are you paying the channel owner?
The channel owner determines that fee. If you don't like their fee, then you can choose to use a different channel to route your payment through.

If you can't spend small amounts, then how will it solve micro-transactions, or having unusable wallets with amounts smaller than fees?
It isn't really that you spend small amounts, but rather that you can send and receive many small amounts without paying a lot in fees.
739  Bitcoin / Development & Technical Discussion / Re: Can Lightning network work decentralized ? on: January 03, 2018, 05:55:53 AM
BTW does BTC even supply for such a mechanism that it can cancel all payments if one fails ? Otherwise nobody would use it (who wants to pay 80% of a product and thus not receive the product) and your example isn't even valid
Yes, there is a mechanism to cancel a payment. Anyways, currently it isn't even possible to have a partial payment. The way that routing works is that the sender chooses the nodes to send through and will only initiate the process if it knows that the payment will happen (barring circumstances involving malicious actors or unforseen circumstances).

Actually I don't think this is correct. In A -> B -> C then C first finalizes payment from B by sending the pre-image to B. Then B does the same with A, exactly like explained here:  How is this different from a lending situation ? You ask your friend to pay for the pizza and after he paid for the pizza, you pay him.
No, that's not how it actually works on the technical level.

At the technical level, every node in the route first creates an HTLC offered output and HTLC received output in the channels that the payment is being routed through. This effectively locks in the coins and the order of those outputs being created is not guaranteed. I.e. A could offer the HTLC to B before B offers to C, in which case B owes A money. But just as likely is B offers C the HTLC output before it receives the HTLC from A, in which case A owes B money. In either case, neither party actually gets any money, so no money actually exchanged hands nor is anything actually owed. If B fails to offer the HTLC C, A will get his money back when the HTLC times out and B will not be able to have gotten any of that money at all. When the preimage is passed down the route from D to A (let's add one additional hop for this example), none of the parties in the route is able to get more money than they are supposed to even if they don't reveal the preimage to the next person. With lending money, the lender can steal the money, but in LN, the "lenders" (i.e. nodes in the route) cannot.

The reason for this is slightly complicated. In a route A -> B -> C -> D, D must reveal the preimage R in order to be paid. He can do this by either broadcasting the C -> D Commitment transaction and the HTLC success transaction (so he spends the HTLC output from the commitment tx) or by telling C what R is (and thus keep the channel open). If he broadcasts the HTLC success, then both B and C know what R is since R is in that HTLC success and can immediately broadcast their HTLC success transactions, so they are paid and pay money at exactly the same time.

If D gives C R and they settle off chain (to keep the channel open) but C refuses to give B R, he is actually out money since he has already settled the HTLC offered output but not his HTLC received. C is now short the money that he gave to D. Note that this is different from lending because this is not B refusing to give C his money but rather C refusing to take it. The only way C can take that money is if he gives B R or if he broadcasts the commitment transaction and HTLC success transaction. Either way, B will get R and he will end up paying the money to C as that is how HTLCs work.

The payment of the HTLCs is guaranteed because of the commitment transactions. HTLCs are part of the commitment transaction which is signed by both parties in the channel. In the B -> C channel, B cannot revert his HTLC without C agreeing to revert it. If he chose to broadcast an old commitment which did not have this HTLC, then he will be subject to C's revocation transaction which can take all of B's money. The way that HTLCs work is that if you can show that you know R, then the payment is guaranteed because you can spend that output. So once C knows R, his payment is guaranteed unless he waits too long and the HTLC times out. But then that is still not lending as B did not refuse to pay C but rather C refused to take money from B.

So in no way is this actually lending. No node has more money than they are supposed to. HTLCs are not a promise that you will give them the money (as it is with lending) but rather a guarantee that they will get the money. Nodes must forward R down the route otherwise they will be losing money. There is no situation where a node can get more money than they are supposed.

Note that this only works when R goes from D -> A. If it went from A -> D, then it would be lending and a node could defraud the next node in the route. But LN goes the other way, so that is not a problem.
740  Bitcoin / Development & Technical Discussion / Re: Can Lightning network work decentralized ? on: January 02, 2018, 11:34:16 PM
But let's say I want to pay an airline ticket for $1200. I have 4 channels with 4 friends. Two of them have $350 freely available each and two of them have $250 available each. However one of them has a route with friends who only have $200 available. Now I can't pay for the ticket even though I'm a frikkin' (bitcoin) millionaire myself Smiley It would make SO much more sense for me to just open 1 channel with a bank, but some cash in it and I'm done! I can now at least determine myself how much I can pay and I'm not dependent on the wealth of my friends (or their friend's friends).
That's completely untrue. You are then dependent on the wealth of that "bank", how many channels it has open, and how much it owns on each channel. You are not done, and there is no guarantee that said "bank" will be any better than your 4 friends. Suppose that bank is just like friends, but with more channels that lead to dead ends and not the airline you want to pay. Now you're stuck. It's exactly the same as with your friends, and not any better nor any worse.
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 ... 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!