Bitcoin Forum
December 11, 2018, 08:53:17 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 ... 547 »
1201  Bitcoin / Development & Technical Discussion / Re: Bitcoind timing mishap? on: October 08, 2017, 04:25:48 AM
1. what is a timing mishap? i cant find any info on it ANYWHERE, maybe i am not searching right. why would this be happening?
A timing mishap in this context (with the pong message) is a pong message which has an old nonce value that is not expected. Can you please post your debug.log file with those values unredacted? Without being able to see what is actually being reported, it is hard to say what is wrong.

2. what are transaction verification flags? and how can i see them in bitcoin-cli?
Transaction verification flags are the rules that are used in validating transactions. These rules include the standardness rules and other node policy rules that are not consensus rules. You cannot see what they are in bitcoin-cli; you will have to look at the source code.

3. how can i see if bitcoind is serving the block or disconnecting before it serves the block, is there any way to get more detailed logging? or a way to snoop on the communication? can i tell who initiated the connection termination?
Run Bitcoin Core with the -debug option. You are already running with debug=net which is enough to determine whether a block is served before disconnecting. Blocks are definitely being sent before the socket is closed and disconnected.

4. can a protocol version 70000 communicate effectively with 70015?
Yes.

5. is there any reason a regtest enviornment would act differently from mainnet in regards to block/transaction flags or the way the locktimes are set? i really dont know where to even look here. all i know is bitcoind nodes sync but have timing mishaps, bitcoinj cant pull FULL .
The block and transaction verification flags have nothing to do with the networking. All consensus rules are the same, but some node policy rules are relaxed to allow for non-standard transactions. locktimes are a consensus rule.

for the record, bitcoinjs full node code mirrors satoshi's exactly, it has to, so i have read. so im not sure how it communicates but i assume the same way bitcoind clients communicate.
The protocol has changed since the full node stuff was written and it has not really been updated since. It is also experimental.
1202  Bitcoin / Armory / Re: armory won't sync on: October 08, 2017, 04:15:11 AM
Is Bitcoin Core installed? If not, install it.

If it is installed, is it running? Is it fully synced?
1203  Bitcoin / Project Development / Re: Bitcointalk Account price estimator on: October 08, 2017, 04:14:42 AM
How can I add this script to my site?
This is not a script. It is a server software.

Any step by step guide available?
Read http://github.com/achow101/BitcointalkAccountPricer/blob/master/INSTALL.md
1204  Bitcoin / Armory / Re: Connection to bitcoin core client lost....... on: October 08, 2017, 02:06:36 AM
Use Armory 0.96.3
1205  Bitcoin / Alternative clients / Re: Unspent outputs and funds missing from Jaxx wallet while pairing Android and PC on: October 07, 2017, 08:00:46 PM
I only have the one backup phrase.  That was from when I opened the Android app and that's the phrase I used on my computer.  I'm 100% certain of that.  I mean, does everyone believe that these wallets work perfectly all of the time?  One seems to have zero recourse.  At least with a bank I would.    
You have the backup phrase. Restore your wallet from that backup phrase. That's what the backup phrase is for.

Just because you don't know what you are doing does not mean that all is lost. Just because you don't know what you are doing does not mean that no one else knows what they are doing.
1206  Bitcoin / Bitcoin Technical Support / Re: Getting BTC\ETH address on: October 07, 2017, 07:58:52 PM
You will get addresses when you get a wallet. The wallet software will handle all of that for you.
1207  Bitcoin / Bitcoin Technical Support / Re: transaction stuck on: October 07, 2017, 07:15:00 PM
It sounds like you sent USDT to a Bitcoin address. USDT is not Bitcoin and is incompatible with Bitcoin (although apparently it uses the same address format). It is possible to recover your coins, but that is very difficult and requires handling private keys and installing a USDT wallet. However it seems like you sent USDT to Coinbase, and it is likely that they are not able to do this. Besides the fact that it requires a lot of work, their private keys may not necessarily be accessible to be imported into a USDT wallet. Your coins are probably lost, and there certainly is no transaction that is stuck.
1208  Bitcoin / Alternative clients / Re: Unspent outputs and funds missing from Jaxx wallet while pairing Android and PC on: October 07, 2017, 07:10:13 PM
I open a Jaxx wallet on my Android and make several deposits totaling just over 1 BTC (not chump change for me).
Then I install the PC version and the Android balance doesn't show there.  I pair the wallets per their instructions and voila - the Android balance disappears.
You paired in the wrong direction. If you scanned a QR code or entered the backup phrase from your computer onto your phone, then that is wrong. You should have entered a backup phrase from your phone onto your computer.

My understanding of these unspent outputs is that they are generally a fractional remainder of a bigger amount/transaction - that is, the final balance would NOT be the same as the amount received.
No, that is not how unspent outputs works. The final balance would only not be the same as amount received if you have spent any Bitcoin.
1209  Bitcoin / Bitcoin Technical Support / Re: unconfirmed Transaction on: October 07, 2017, 06:47:18 PM
is this only way to accelerated  Transaction or there are more services ??
Some other mining pools may also offer acceleration services. I don't remember. However any mining pool operator can accelerate transactions for you.
1210  Bitcoin / Bitcoin Technical Support / Re: Moving BTC from outdated version of core and Effects on BCH on: October 07, 2017, 06:45:58 PM
so will I need to update the software first and then switch to pruned mode?
You don't have to, but I recommend that you do.

At that point how long do you think it would take to sync?
It depends on your hardware and network connection. It can take anywhere from a few hours to a few days.
1211  Bitcoin / Development & Technical Discussion / Re: Bitcoin-cli move? on: October 07, 2017, 06:44:56 PM
Thank you. If so, what is the best way to have a multi account wallet where you manage 10 - 100 - 1,000 - 100,000 accounts all with different balances?
Use your own account system. Use an external database to handle your accounts and what each person's balance is. Don't try to make each address belong to certain accounts (the Bitcoin Core accounts system doesn't really work like that anyways). Or you can use the multi-wallet feature and have each wallet be an "account". However Bitcoin Core may not be able to handle hundreds or thousands of wallets with multi-wallet. It really is not designed for that use case.
1212  Bitcoin / Development & Technical Discussion / Re: Bitcoin-cli move? on: October 07, 2017, 06:00:26 PM
Thanks. Since it is deprecated, it is not advised to use it any more?
Yes. The accounts system (and thus the move command) is slated to be removed soon.
1213  Bitcoin / Bitcoin Technical Support / Re: Moving BTC from outdated version of core and Effects on BCH on: October 07, 2017, 05:58:48 PM
Can I simply move coins using core to my ledger by sending them to my ledger address using the core client?
Yes.

Do I need to sync the client before it will allow me to send the coins? 
If you have not received any coins after the time that your wallet is synced up to, then no.

If I send the coins will I lose my BCH?
No. BCH is an altcoin and anything that happens on BTC has no effect on BCH and vice versa.

If not how would I send my BCH?
You need to get a BCH client that can read your wallet file or you can import your private keys into. You can use the Bitcoin Core analogous software for BCH which is Bitcoin ABC.

Am I at any risk of a replay attack if I send my BTC and leave the BCH on the core wallet address?
No.

Any other considerations to be aware of when sending coins on an outdated version of core?  I don't plan on using core once I've moved coins to my ledger.
Node policy has changed since 0.8 which makes some transactions that 0.8 may produce (just due to randomness) to be non-standard and thus not likely to propagate well. Furthermore, fee estimation has changed to be much better, and priority has been removed which will also effect how your client sets a transaction fee so you may end up paying too low of a fee for your transaction to confirm quickly. I highly suggest that you upgrade to Bitcoin Core 0.15 and let it fully sync. You can use pruned mode so that it takes up only a few GB of space instead of 140+ GB.
1214  Bitcoin / Bitcoin Technical Support / Re: unconfirmed Transaction on: October 07, 2017, 05:54:30 PM
Those two services are owned by mining pools. They can choose the transactions that they want to include in a block. Usually these are chosen by transaction fee rates, but they have custom changes (or are using Bitcoin Core's prioritisetransaction command) which allows them to make a transaction be more likely to be chosen by their transaction selector so it will confirm sooner by being included in one of their blocks.
1215  Bitcoin / Development & Technical Discussion / Re: Bitcoin-cli move? on: October 07, 2017, 05:49:46 PM
move is a deprecated command that only effects Bitcoin Core's internal accounts system. The accounts system is deprecated. All that move does is that it changes some entries in the internal accounts system. No transactions are actually made.
1216  Bitcoin / Project Development / Re: Bitcointalk Account price estimator on: October 06, 2017, 05:35:40 PM
I had tried several times accessing the website www.bctalkaccountpricer.info but unfortunately the website having a hard time to load. Is the server down?Are you also experiencing this? Is there any alternative website to use for checking bitcointalk account? Thanks in advance.
Loads fine for me.
1217  Bitcoin / Development & Technical Discussion / Re: Random Question about Blockchain and AI on: October 06, 2017, 12:45:22 AM
This thread is attracting a lot of spam and very little thoughtful discussion (besides the fact that the idea is complete nonsense). Therefore it will be locked.
1218  Bitcoin / Development & Technical Discussion / Re: Will quantum computing kill crypto? on: October 06, 2017, 12:43:57 AM
This thread is attracting a lot of spam and very very little thoughtful discussion, so it will be locked.
1219  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core developers along with Blockstream are destroying Bitcoin on: October 05, 2017, 08:22:11 PM
Anyways do you have any prediction over what is going to happen? Since those exchanges will list segwit2x as the Bitcoin, this will be the "legitimate" bitcoin /most used, most traded, priced the highest.
Not necessarily. A lot of exchanges have not said whether or not they are supporting Segwit2x and what they are going to do about it. I don't think many exchanges will list Segwit2x as Bitcoin as many people have threatened to sue them, and at the very least, it will be some very bad PR for them.

Why doesn't core just say okay and agree on the 2MB fork? Because i would say this could get ugly otherwise ruining both of the Bitcoins.. :/
First of all, it is not a 2 MB fork, it is an 8 MB fork. Calling it 2 MB is disingenuous.

Why should Core do something that we believe is harmful to the network? Sure, it might avoid a split now, but it can have huge negative consequences in the future that we want to avoid.

Also if the majority of the hash power goes to segwit2x, the old chain will be stuck and useless. So doesn'+t seem like there is much choice?
No. Miners do not control Bitcoin. Just because the hash rate moves does not mean that Bitcoin is redefined to whatever the hash rate wants. The hash rate will follow whatever makes them the most money (unless they are insane). If few users are using Segwit2x-coin and few exchanges list segwit2x-coin, then miners won't mine it for long as there is no money to be made there. Even if they did go to Segwit2x-coin and stuck with it, Bitcoin Core could do a counter hard fork which both implements a Proof of Work change and implements a lot of features on the Bitcoin hard fork wish list which Segwit2x has thus far refused to do.
1220  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core developers along with Blockstream are destroying Bitcoin on: October 05, 2017, 04:00:00 PM
This is just not true. Please stop spreading FUD.

Blockstream does not control Bitcoin Core; out of the five people who have commit access, only one person is a Blockstream employee (and founder). The others either work for their own companies that they founded or are part of the MIT DCI. In all contributions this year (since Jan 1 2017), there have been 41 contributors. Of those, I count 8 Blockstream employees or contractors related to Blockstream (of which at least 3 are founders of the company, and 2 don't really seem to work for Blockstream but are listed on their website), 2 that work for the MIT DCI, 6 Chaincode Labs employees (one person overlaps with Blockstream) and 22 people who work for other companies (only one or two per company), work for their own companies that they created, or are independent contributors contributing whenever they feel like. Many of the Blockstream contributors contribute rarely and also do so when they feel like; they are not paid to work exclusively on Bitcoin Core.

Blockstream does not need to influence or change Bitcoin in order to have products. They already have the Liquid sidechain which is a product for exchanges and it does not need Segwit or other changes to Bitcoin's consensus rules. This sidechain was already in use before Segwit activated.

Some days after hurricane Irma there was a fundraiser for one of the Core developers, whose house had been damaged by hurricane. The goal of the fundraiser was to raise 5 Bitcoins for the Luke Dash jr(Bitcoin Core developer) in order to fix his house and property.

Luke Dash has developed first Bitcoin mining pool in 2011. At that time Bitcoin was worth around 0.3$.
Someone who knew about Bitcoin in 2011 and devoted it's time to work on the project, did not invest anything?!?! That tells us, that Luke Dash is not a speculator, he does not know anything about economics, all he is - is a programmer and that's all he knows to do.
Do you not think that maybe he has spent those coins? Maybe he speculated in the early days and lost money in the number of scams and exchange collapses (e.g. MtGox) which leaves him with little to no Bitcoin today. Luke has a family (a rather large one too) which he has to support; do you not think that perhaps he has used many or all of his Bitcoin to help support his family and do other things which require money?

So Luke Dash obviously doesn't own (m)any Bitcoins considering he needed to raise funds for the repairs of his house and property, so he can only make money by getting paid from Blockstream for the development.
Luke is not a full time employee of Blockstream; he is an independent contractor. I don't think he is paid much for doing that considering that he has not done much for Blockstream and is not being paid by Blockstream to work on Core (according to some conversations I have had with Blockstream employees).

And i would guess most other core members are like this. They are programmers. They enjoy coding and improving Bitcoin as they did from the start. They did not buy Bitcoins hoping they would get rich, but they probably looked at it from a programming perspective.
Their salary now depends on Blockstream and they have to follow the rules.
As I said earlier, that is not true at all. Blockstream is not the only company paying people to work on Bitcoin Core and they do not control Bitcoin Core.

Core members have said it in the past that increase of the block size would be okay, even up to 8MB!!
Source? IIRC the only "okay" increase was up to 4 MB, which is what Segwit does.

So what is wrong with the segwit2x now that it is considered an attack?
The fact that it is being done by an agreement made by a bunch of corporate executives and miners in a backroom deal without consulting the community or the technical community (which includes much more than just Bitcoin Core developers).

Is there any good argument against Blocksize increase? And don't mention the blockchain getting too big. In one year the blockchain has grown from 85GB to 135GB, increasing by 50GB. With 2x block size increase, this would be 100GB per year. The cost for storage is rapidly decreasing as technology is progressing, and in 10 years the estimate block size(with segwit2x) would be 1,135TB. At current prices this would cost around 50$, and we all know in 10 years 1TB of storage could cost a few dollars.
And how many people actually run a full node? It seems all nonsense to me.
It is not the storage requirement that is the problem, it is the bandwidth and computing requirements. Clearly you do not understand the nuance and other consequences of a block size increase. It not only requires more disk space (which is trivial) but it also requires full nodes to consume even more bandwidth and data and may not be able to support larger blocks. So we would see a decrease in full nodes from a number that is already pretty low, less than 10000 full nodes. A full node consumes somewhere around 300-500 GB of data per month, and that is with 1 MB blocks. With segwit, that size will be even larger, and with 2X, potentially more than double. In the worst case, it would be 8 times that amount. In the US, some ISPs (like Comcast) are instituting data caps at ~1 TB of data per month. Bitcoin nodes are likely to be consuming nearly all of that data (thus restricting the amount of data that home node operators can use for other things) or even exceed the data cap if Segwit2x were to pass. This will cause the entire network to lose nodes as users turn them off so that they have enough data to do other things that consume a lot of data, but not as much (e.g. watch 4K Netflix).

Furthermore, larger blocks can require more computation to validate and thus a malicious block that takes several seconds (which is ages in computer time) to validate now would be even worse if the block size were to be increased even more.

Lastly, there are many other considerations that you need to look at when increasing the block size. Things like UTXO set growth, initial sync time, hardware requirements, etc.
Pages: « 1 ... 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 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 ... 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!