text:
Single API to Get Fee Estimates for All Major Cryptocurrencies?
Many sites provide estimates of miner/gas fees for individual cryptocurrencies. For example, EtherScan provides gas estimates for ETH. BTC Network provides fee estimates for Bitcoin.
Both of these sites provide API functionality, but they are limited to a single cryptocurrency. If I wanted to integrate many cryptocurrencies into my site I would need to integrate a different API for each of the cryptocurrencies I support.
I'm looking for a site/solution that offers a single interface to obtain gas/transaction/miner fees for all major coins such as BTC, ETH, LTC, BCH, USDT, USDC, XRP etc. The API must also provide estimates based on the desired transaction confirmation times. In other words, I should be able to request estimated fee if I want 90% likelihood of confirmation within the next 30 min, 60 min, 600 min and so on.
Update: Can someone please explain in the comments why this is off topic? 1) this question IS applicable to Bitcoin (questions in which the answer is the same for Bitcoin are on topic) 2) I am not seeking a product or service review I am asking if such a service exists (it's a factual question) How does this question differ from:
Historical BTC data in JSON
API for automatical buying and selling coins in Java
Which asks for a specific service/API..

That "Historical BTC data in JSON" question is very old, presumably from before service recommendations were made off-topic.

@PieterWuille What about this one: https://bitcoin.stackexchange.com/questions/100649/any-charts-bots-out-there-for-volumes-going-from-private-unknown-wallets-to-know

@PieterWuille I interpret "seeking product or service reviews" as a question that  seeks a review of a particular service which is almost always "subjective" and prone to bias/spam, not a question that is  factual in nature (i.e, which website provides service xyz) as this kind of question is not likely to attract spam or  biased responses

@PieterWuille Also do you know when this rule was added? As I see dozens of questions that would violate this rule according to your definition

@PieterWuille what about this one: https://bitcoin.stackexchange.com/q/101723/78451

Questions about other cryptocurrencies are on-topic then when the answer is the same as if it were just asked about Bitcoin. E.g. "How does change work in Litecoin?" is equivalent to "How does change work in Bitcoin?".  I would consider this off-topic, because the answer is not the same as if you just ask it about Bitcoin specifically as you are looking for a service that covers a variety of currencies.


text:
Forgot password multibit
this is two weeks
I am trying to crack my MultiBit portfolio, I do not remember my password recorded in July; I have no old file save my wallet, the word must be no more than 15 characters and must be single and I need only 2-3 characters to remind me.
I looked all over the web and bitcoin forums looking for a solution, but being French, the English pages are poorly translated and difficult to understand. My English is not very strong. I asked walletrecoveryservives, but he couldn't figure out my password using the ideas that I gave him.
I have no more ideas; is the island cracker possible without ideas? Could you help me do it if it's possible?

What do you mean by island cracker?

Unfortunately, it is not possible to partially break a passphrase to get you some characters that could remind you. Depending on the algorithm and what character set was used this could take anywhere from months to centuries.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Filter transactions per block 50 BTC or Higher
I'm using the blocktrail python api, to try and display transactions above 50 BTC per block for a visualization project. I think I'm almost there but can anyone help me understand where I'm stuck?
client = blocktrail.APIClient(api_key="MY_APIKEY", api_secret="MY_APISECRET", network="BTC", testnet=false)

def getLargeTxs():
  block = client.block_latest()
  transactions = client.block_transactions(block)['data']
  over_50btc = [ item for item in transactions if blocktrail.to_btc( item['estimated_value'] ) > 50.0 ]
  return over_50btc

Thanks for your help

What's the problem with this program? What happens when you run it?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Who makes the decision about blocksize?
I have been running a full node for little less than a year and I am following the discussion around blocksize increase. I am for it.
Who actually can make a decision whether  the blocksize increase gets committed to the bt core? Is a majority vote from core devs required? Obviously Gavin Andersen, an outspoken core developer is trying to convince someone with his blog posts. Whom?
Also how can the public coordinate their desire for blocksize increase? Everyone posting in their blogs is not going to cut it, or?

Everyone. :) You choose by what software you run.

Who actually can make a decision whether the blocksize increase gets
  committed to the bt core?

Any person who has rights to commit changes to github.com/bitcoin.org

Also how can the public coordinate their desire for blocksize
  increase?

The only way is voting by hashpower. Have a look to BIP-16

That is kind of obvious answer, the person with commit access. So Gavin or any other dev can just commit the larger blocksize, with other devs possibly reverting it?

technically speaking, yes

I actually thought this is what the question was getting at also

This situation is unprecedented in the software world. In other peer-to-peer systems (think Skype or Bittorrent or whatever), software updates fix bugs or add new features, and if the user doesn't update their software the worst that can happen is that their program will run with some problems.
In Bitcoin the situation is drastically different because the system is entirely based on reaching consensus on something. Bittorrent or Skype don't really need to reach consensus on anything. Sure there's still a protocol that clients should follow for the system to work as expected, but even if these rules are slightly different from client to client, overall the system still functions.
With Bitcoin, consensus is what makes the whole system possible. The rules behind how to reach consensus are embedded (actually hardcoded) inside the client/node that all the people are running. Now, if there's some clients that have different rules than others regarding the consensus, then the whole system branches into different versions creating effectively different versions of Bitcoin.
In fact, one can go ahead and say that Bitcoin is exactly the set of rules (the actual algorithm) to reach consensus. If you're not using those rules, you're not using Bitcoin, you're using something else (Bitcoin 2.0, Litecoin 2.0, whatever...).
Now you understand why this is really an unprecedented situation in the software world (perhaps apart from the fork of 2013). If you change the rules then you're effectively creating a new version of Bitcoin and you must make everyone move onto your new version - and I'm not talking about only miners here; all people that are running clients on their phones, or on their computers; all the web wallets; all the exchanges. They all must update their code otherwise you've essentially created another system which is not Bitcoin.
So to answer your question about "who makes the decision about the rules", it's the actual people running the bitcoin software that decide at the end of the day.
EDIT as was noted in the comments, regarding the specific block size issue, SPV clients don't actually need to be updated because they don't check the size of the blocks - they trust the miners will do the checking for them.

It's incorrect to say that everyone must update.  SPV clients don't verify the block size, so they don't need to update.  The only software that needs to update are full nodes (because they verify block size).  (To actually make bigger blocks, some mining software may also need to be updated.)

This is true specifically for block size, but not for other rules of consensus which is the main point I was trying to make (will update my answer to be more clear).

The only parallel I can think of is Python 3.x not being back compatible with 2.x

Since you argue the counterpoint to @amaclin, it would be interesting to read why you think it is not mining that decides, but the people running the software. Perhaps you could elaborate on that point, since it is the main issue of the question.

@Murch many clients, not just miners, rely on independently verifying the blockchain. I would argue that there are many more of these clients than there are miners. Even if all the miners change to a new version, all the clients that haven't changed to the same version with the same rules will not accept the new blocks being mined. So it's not just the miners that decide.


text:
What could be the reason for one loop being significantly more power hungry on an SP20?
One of the loops on my Spondoolies SP20 is misbehaving. I underclocked everything but this loop (number 4) does not seem to care what settings I make. It seems to be running at twice the speed (and wattage) at times.
Why is this?

Transcription:
Asic Stats

Uptime:502 | FPGA ver:100
-----BOARD-0-----
PSU[UNKNOWN]: 0->120w[120 120 120] (->120w[120 120 120]) (lim=120) 0c cooling:0/0x0
-----BOARD-1-----
PSU[UNKNOWN]: 0->120,[120 120 120] (->120w(120 120 120]) (lim=120) 0c cooling:0/0x0
-----BOARD-2-----
PSU[UNKNOWN]: 0->121w(121 121 121] (->121w(121 121 121]) (lim=120) 0c cooling:0/0x0
-----BOARD-3-----
PSU[UNKNOWN]: 0->194w[193 193 194] (->194w(193 193 194]) (lim=120) 0c cooling:0/0x0
LOOP(0) ON
 0: DC2DC/1/:[vlt1:605 vlt2:610(DC1:794 T1:794 U1:727) 46W  76A 41c] ASIC:( 85c (125c) 670hz(BL: 670) 17 (E:192) F:8]
 1: DC2DC/1/:[vlt1:605 vlt2:610(0C1:794 T1:794 U1:727) 44W  72A 48c] ASIC:[ 85c (125c) 645hz(BL: 645) 15 (E:192) F:0]
LOOP[1] ON
 2: DC2DC/1/:(vlt1:593 vlt2:597(DC1:794 T1:794 U1:727) 43W  73A 53c] ASIC:[ 85c (125c) 640hz(BL: 640)  9 (E:193) F:0]
 3: DC2DC/1/:(vlt1:593 vlt2:597(DC1:794 T1:794 U1:727) 47W  79A 56C] ASIC:[ 85c (125c) 675hz(BL: 675) 17 (E:192) F:8]
LOOP[2] ON
 4: DC2DC/1/:(vlt1:599 vlt2:605(DC1:794 T1:794 U1:727) 45W  75A 41c] ASIC:[ 85c (225c) 660hz(BL: 660) 18 (E:193) F:0]
 5: DC2DC/1/:(vlt1:601 vlt2:605(DC1:794 T1:794 U1:727) 46W  76A 52c] ASIC:[ 85c (225c) 675hz(BL: 675) 15 (E:193) F:0]
LOOP[3] ON
 6: DC2DC/1/:(vlt1:654 vlt2:658(DC1:794 T1:794 U1:727) 74W 113A 68c] ASIC:[ 85c (125c) 895hz(BL: 895) 30 (E:192) F:0]
 7: DC2DC/1/:[vlt1:654 vlt2:658(DC1:794 T1:794 U1:727) 75W 114A 77c] ASIC:[100c (125c) 905hz(BL: 905) 23 (E:193) F:0]

[H:HW:1112GH,W:423,L:0,A:8,MMtmp:0 TMP:(28)=>=>=>(49,64)]
Pushed 28 jobs , in NW queue 4 jobs (sw:0, hw:0)!
min:14 wins:144[this/last min:6/18] bist-fail:253, hw-err:1
leading-zeroes:42 idle promils[s/m]:0/0, rate:1258gh/s asic-count:80 (wins:3+3)
Fan:70, conseq:200
AC2DC BAD: 0 0
R/NR: 487/0
RTF asics: 0
FET: 0:9 1:9
 0 restarted      0 reset          0 reset2         0 fake_wins
 0 stuck_bist     0 low_power      0 stuck_pll      0 runtime_dsble
 0 purge_queue    0 read_timeouts  0 dc2dc_i2c       0 read_tmout2   0 read_crptn
 0 purge_queue3   0 bad_idle
 0 err_murata
Adapter queues: rsp=2, req=20

EDIT: I have found out how to get rid of the problem: Setting the start volt 0.05 below max. voltage on all loops seems to have made it more stable and the problem vanished... I still don´t know how it came about but at least I found a workaround :)

What miner software are you using?

CGMiner as part of the original software on the SP20

@Foxy, I'm glad you've found the solution. If you answer your own question and mark the question as answered, it would help anyone else who had this problem find the answer quickly.

Copying asker's own answer, so that this question can be removed from the unanswered queue (assuming this answer gets upvoted).

I have found out how to get rid of the problem: Setting the start volt 0.05 below max. voltage on all loops seems to have made it more stable and the problem vanished... I still don´t know how it came about but at least I found a workaround :)


text:
"Hot", "Cold" & "Warm" Storage Wallets?
I've seen a number of sites advertise they support "hot", "warm" and "cold" wallet storage solutions (the only thing I haven't seen so far are "frozen" wallets).
What's the difference between the three? I think the difference between "hot" and "cold" wallets are pretty clear. But what makes a wallet "warm" instead of "hot" or "cold"?
P.S
I understand that at some level "warm" wallets are obviously more accessible than cold wallets (hence the name "warm") but how would they differ from a tech perspective - at what point is something hot and at what point is something warm?

Marketing, probably.

I call my wallets "cryogenic." But that's because I use one-off encryption software (running on an isolated device) that I wrote to convert a series of passwords I make up into a wallet address and save the private key NOWHERE until I generate it again at spend-time ;-)

In general terms, "hot" wallets store both the wallet address(es) and the private key(s) on a network-connected machine, readily accessible so you can spend your balance any time, with very little effort (and lower security).
Meanwhile, "cold" wallets store your private key(s) in an isolated "hardware wallet," on external storage media (which is a lot less secure, and I would consider a "warm" wallet), or on a piece of paper (search "bitcoin paper wallet"). In this way, the funds are "frozen," because no internet-connected device has the private key. This gives you great security, but is less convenient because you have to transfer the private key to a connected device (or use a connected device to send transaction info to a hardware wallet for off-network signing) before you can spend your balance.
As for "warm" wallets, I've seen descriptions of putting private keys in a separate HDD partition, or an encrypted archive file as "warm" wallets.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Multi Party ECDSA?
Are there any alternatives to the Multi Part ECDSA implementation contributed by ZenGo?

I know about this one by Binance but haven't tried it myself and don't know if it's been audited:
https://github.com/binance-chain/tss-lib

Interesting, both ZenGo & Binance seem to have been audited by the same firm (Kudelski Security)

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Safely Accept Bitcoin Payments with 0 Confirmations
GAP600 is a service (that has processed $5 billion in cryptocurrency) which allows exchanges and payment service providers to process Bitcoin payments instantly (0 confirmation trx). It guarantees a transaction against double-spend, expiration or other fraud even before it is confirmed by the Bitcoin network:

GAP600 facilitates instant, risk-mitigated cryptocurrency commerce by
enabling exchanges to recognize unconfirmed Bitcoin.. transactions as
final using a proprietary risk engine, which analyzes and performs
live risk scoring for each transaction as it reaches the mempool.

How is it possible to guarantee a transaction against double-spend, expiration or other fraud before it is confirmed by the Bitcoin network? What kind of "risk analysis" might be performed to achieve this result?
Note: My question is different from Looking for a tool that gives a score based on the likely hood of a 0-confirm deposit being douple spent because:
1) The question above explicitly asks for a open source tool to achieve the intended purpose. I am asking about what logical vectors might be used to achieve the stated goal (One example might be accepting transactions from addresses associated with well known exchanges such as Coinbase who are unlikely to perform a double spend)
2) The response in that question basically states that it is not possible to achieve this. It does not answer the question. As stated in the comments, it is demonstrably wrong as GAP600 is doing this along with several others.
3) To be clear, the possibility of accepting Bitcoin with 0 confirmations doesn't imply that every transaction will be accepted. If the risk is great enough the transaction will have to wait until 6 confirmations but it GAP600 is able to accept up to 85% of transaction with 0 confirmations
4) It is also possible that a transaction which is deemed un-risky will turn out to be a double spend however it is obvious that the likelihood of this happening is so minute that the value obtained from the other transaction will outweigh any loss from this error (this is my own assumption)

@chytrik Definitely not. Also, the highest voted answer (https://bitcoin.stackexchange.com/a/97203/78451) is demonstrable wrong as GAP600 (and possibly Gemini ) is able to guarantee up to 85% of all transactions against double spend etc. They've processed over $5 billion worth of Bitcoin and there are many prominent payment processors relying on their algorithm. You may not know how they do it, but there are definitely ways that this can be done.

How is it possible to guarantee a transaction against double-spend, expiration or other fraud before it is confirmed by the Bitcoin network?

It isn't really possible in the absolute sense, but you can could perhaps create an insurance fund of sorts, to help provide guarantees against the rare occasion one of your customers is defrauded.
However you fundamentally cannot know for certain whether or not any specific transaction will be confirmed, until it has been. Even if a transaction has been seen by every node on the network, a miner could craft a conflicting transaction, and include it in their next block (with a success rate equal to their percentage of the hashpower). No amount of risk analysis can change this fact.

What kind of "risk analysis" might be performed to achieve this result?

It is hard to say for certain.
You could attempt to track where transactions originate from, like for example if you see transactions coming from large exchanges or service providers that are well-known and trusted in the community. Those entities are probably less likely to attempt a double spend.
You could watch for transactions marked as 'replace-by-fee' (RBF), which is a technique employed by many wallets, which allows the user to increase the fee-rate on a transaction for faster confirmation. Transactions marked as RBF could be treated as less trustworthy in regards to 'zero-confirmation' assurances.
There are likely other ways as well, those are the first couple that come to mind.


text:
How can market-based transaction fees scale?
Can someone please explain to me what I am missing?
I don't see how variable, market-based transaction fees can scale. I go to a merchant's website to buy, how do I select a mining peer to pay transaction fee to? Do I attach some bounty that any peer can earn if that peer wins the Proof-of-Work block? But what if my bounty isn't high enough to attract a peer given high transaction volume competing for priorities? Or not enough to cover any peer's mining overhead. How do I know how much to bid to be sure my transaction completed in a timely manner?
This sounds very complex and unreliable and not at all like something that can scale to customers. Customers want to click one button and be done with the purchase and not waiting unknown hours debugging their payment processing. Amazon's One Click.
I don't see how with different peers charging different fees (to match their market dynamics), the sender of a transaction can know the amount to bid to get in the next block? It is impossible because the tx fees are not uniform and the random selection of the next peer is not knowable in advance.

I read that even Gavin has expressed his doubt that they will scale.

"I read that even Gavin has expressed his doubt that they will scale" Citation needed.

You don't need to select a mining peer to pay a fee to, and you wouldn't want to; you just want your transaction included in a block. This is why the transactions are passed around the peer-to-peer network, and the first to solve a block including it earns the fee.

@HighlyIrregular I was getting at not being able to know the relationships between how much you bid and the performance you will receive.

Yes, there should be an easy way to determine which fee to pay for a given transaction and how fast you wish for it to get in the blockchain. And it should be easy to try over with a higher fee if you see your transaction isn't going through. I'm sure we'll see those things in the future. But they have nothing to do with whether a market-based tx fee system can scale. Your only argument is that Gavin Andresen said something. What did he say?

The blockchain is public, and every block has (amongst other things) the following information for each transaction (or it can be calculated):

The size of the transaction, in bytes
The fee paid by the initiator of the transaction

Miners in future are likely to calculate the earnings per byte for each transaction when selecting which ones to include in a block, so that they earn the maximum profit from the block. At the moment they mostly just include them all, provided there is at least a token fee.
Furthermore, transactions that have not yet been included in a block are publicly available.
From this information a user could estimate the transaction fee they will need to pay to get their transaction included in the next block, or within one of the next few blocks. Of course in the long run, it won't be a user that has to seek out this information; it'll just be part of the information readily available as they initiate a transaction. At least, that's how I see it working.
The idea has also been floated that the receiver of a transaction could pay a small fee to get the transaction into a block sooner (to ensure they receive their payment).
Reporting on the level of fees needed to process a transaction is minimal at the moment because it's not particularly difficult to get transactions included in a block with either no fee or just a token fee (say 0.00001BTC). This is because we haven't hit the block size limit (at least, we're not constantly hitting it).

I still don't see how with different peers charging different fees (to match their market dynamics), the sender of a transaction can know the amount to bid to get in the next block? It is impossible because the tx fees are not uniform and the random selection of the next peer is not knowable in advance.

@ShelbyMooreIII, it's like a bidding process; think of transactions with a variety of fees waiting for inclusion in a block. Miners will construct a block containing the transactions with the highest fees until it reaches the maximum size, then try solve a hash for it matching the current difficulty. It'll be easy to see where the cut-off point was that meant a transaction was included or excluded.

So you are saying some peers will drop in and out of the race for the next block, depending on the level of transactions in the queue since their market costs of computing hashes vary by peer? Thus this modulates system-wide computation power like a yoyo, which then means scaling difficulty is. So then you shift the problem into oscillation. Which brings a whole another set of problems. The mining incentive needs to change slowly, not abruptly. That is crucial. For example pushing transactions around to miners that are and are not active, because we don't know a priori.

I realized early in my alternative design that the mining incentives could not vary significantly by block, else the system would never scale (at least efficiently). Take that golden rule to Gavin Anderson.

If half the computation power drops out, then the time to find the block doubles.

There is another problem. If you let tx fees vary, then the system can degrade to monopolistic control, because the monopoly will always accept 0 tx fee, so all other peers drop out. You simply can't get away from my rule that variable tx fees means we end up no scaling or monopoly. I am very fast with my reductionist logic. I don't know why my mind can do that faster than others. I guess bcz I see the generative essence of things. In this case it is that no floor price = monopoly can undercut all non-subsidized miners.

@ShelbyMooreIII, I see your point, but that's a different issue altogether and doesn't relate directly to the market for transaction fees; in the case you're talking about, it's an entity that's willing to process transactions at a loss, likely also with other malicious intent. That's a debate best left for a different question, such as "What motivation is there for a wealthy individual to monopolise mining by doing it for free thus making it unprofitable for others?". Going off on a tangent in this question is going to hinder discussion and peer review, which are both very important.

Yes, Bitcoin has a weakness, and that is that bad guys can achieve too much control through hashpower majority. That has nothing to do with transaction fees. You are saying that if the small guy charges a varying fee then the big monopolistic entity can force him out of business, but if he charges a fixed fee then they can't. This makes little sense. If they have enough hashpower they can force him out in both cases.

@Dr.Haribo I had already anticipated and refuted your logic in my prior answer about 51% attack and profitability. And note that 2 morons downvoted that answer. Either you design the system so the users can mine, or you design it so monopolists will control it. There is no middle ground. The government can create inflation or deflation in Bitcoin any time they want, they just did. "No inflation" in bitcoin is a delusion.

Fanatical fanboys need to think about the reality of relativity and the possibility of absolutes in our universe as it applies to bitcon and Ponzi Satoshi.

H.I. it is not a tangent-- the issue is inseparable! I told you this long ago, but can't seem to wrap your mind around all the dependent variables here. Putting the mining reward in a varying transaction fee instead of a fixed one and/or debasement, means you remove the profit for the 6 billion people who can compete with the miner willing to sell at a loss. Also if transaction fees are always set (0 or otherwise), then the miner selling at a loss gains no advantage over getting more transactions other than his hashing power which the profitable competition will then dilute.

@Shelby : You need to realize that derogatory statements such as "I told you long ago" don't help. And this is a place for discussion, not the spamming of your misplaced thoughts & ideas.

@ShelbyMooreIII If you're in a hurry and the prices are always low, you just pay an amount that you know is more than enough. If you're not in a hurry, it doesn't matter. And if the prices aren't always low, then the issue is the scalability of the transaction rate, not the scalability of the fee system. This really is a non issue. You can statistically predict, for a given fee, about how long it will take for a transaction to confirm. And you can pick the fee that meets your requirements. (If no fee does that, then, again, the issue is not fee scalability.)

Yes, market-based transaction fees can scale.
It has already been proven by Western Union, bank wires, etc. The market for transferring money is huge and people are already picking which service to use based on fees, among other things. So it has been proven to scale to the size of the current world economy. And I don't see any reason why it won't keep scaling.
Whether someone with hashpower majority can do bad things is a whole different issue. Can someone with hashpower majority orphan all other future blocks so that all future blocks are generated by them? Yes. Does that mean they can block your transactions from ever reaching the block chain or charge you horrible fees? Yes. A mining monopoly would be very bad for Bitcoin.
Another interesting issue is how Bitcoin can scale to become main stream. According to visa.com:

VisaNet authorizes, clears and settles an average of 130 million
  transactions per day in 200 countries and territories.

Can Bitcoin do that? See Bitcoin protocol / algorithm scalability
But back to your question. The market aspect of transaction fees is not a scalability issue.

Also, scalability of other factors in Bitcoin is not scalability of tx fees.

I like this answer. Even though maybe technically you can find problems with it, it addresses what your trying to do. I do not see how it is offensive can you at least point that out?

Some comments were removed, so I have now removed my comment about those comments. ;)

Ok so as far as I can tell based on my own analysis of this topic, there is no limit to number of transactions per block (no real limit ie. Transaction numbers much larger than 2^256). This is because the transactions themselves aren't saved, but the double sha256 merle tree. So what is passed along is a 256 bit number which doesn't grow per transactions. It seems any problem is miner politics.


text:
Higher cost running Antminer S9 w/ APW3++ when running at 220v?
There's plenty of discussions on 110v vs 220v on the web and I'm successfully running 2 Antminer s9's on a 30amp circuit at 110v (or maybe it's 120/125, I don't know how that works).
I have not hooked up a volt/watt meter tool up, but if the APW3++ is to deliver 1200 watts @ 110v or 1600 watts @ 220v, does that mean it will cost me more KwH's to run on 220v, therefore making it less profitable?

No it does not.

The AntMiner S9i 13.5 TH/sec model requires 101.5 Amps DC.  Since power (watts) is equal to voltage multiplied by amps, the total power consumed by the AntMiner is 1218 watts (+/- 10%).  Note, this is regardless of whether that's AC or DC, and regardless of voltage.  1218 watts is 1218 watts, or if you run it for an hour, 1.218 KW/hr.  In my case, that works out to about $54.44 USD per month, regardless of voltage.
The APW3++ power supply doesn't care what A/C voltage you supply it with, in the range of 100 to 240 volts, it simply converts that into the required amps output in DC.  If the AntMiner is puling 1218 watts, that will translate (at 93% efficiency) to 11.85 amps at 110 volts, or 5.43 amps at 240 volts.  Running two AntMiner S9s on a single 120 volt 15 amp circuit is pushing the boundaries of safe operation.  You should ensure you only run a single AntMiner per 110 volt circuit, unless those circuits are fed with 12 gauge or lower wiring, and are rated for at least 20 amps.
Attaching the APW3++ power supplies to 240 volt circuits simply means you are pulling less amps per hour than if it is connected to a 120 volt circuit, and you can connect two, or possibly three, AntMiners to a single 240 volt circuit.
So, to answer your question, no, it's not more expensive to run at 240 volts than 120 volts.  In fact, due to power efficiency, it's probably very slightly cheaper to run at 240 volts.

So i believe the wiring is only 14 gauge and the circuit breakers are 30amps. How do i know what gauge of wire I can use? If i change to 240v so that I can run more Antminer's on a single 30 amp breaker, what is the most number of Antminers I can run and what gauage of wire will I need?

You really should engage a local electrician to ensure you meet local code requirements.  If your house burns down because of incorrectly installed circuits, you could be completely liable.

If you try to run an s9 in your house you probably won't be able to sleep

@Learn2Mine - that depends on a lot of factors such as proximity of your head to the AntMiner, whether you have noise mitigation in place, etc, etc.  Also, some people like noise when they sleep.

Feeding 14 gauge wire on a 30amp breaker is likely a violation of your local electrical code. Depending on which spec you need to meet 30amp needs 10 or 12 gauge.

it is the same 110 vs 220 in household electrical it has nothing to due with the supplied voltage. a house service comes off the transformer with two legs of 240 or 220
then in the rails it is broken down into two seperate legs of 120
240 household circuit is two 120 combined normally you go on one rail of the 240 service.
the transformer does not care...so to say 240 or 120 saves you money is moot...the meter does not care.

It's generally the case that computer powersupplies are a couple percent more efficient on 240v than they are on 120v.  Running lower currents also results is less resistive losses in cabling (though if this latter effect isn't small you're overloading your cables).


text:
How many Namecoins are generated per block?
Is the block reward for Namecoin halving scheduled the same way as Bitcoin, or is there a different schedule?

Yes, it's 50, as documented here:
http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html
The reward for solving a block will halve every 210,000 blocks (around 4 yrs), like Bitcoins.
When namecoins are spent to register a domain name, they are destroyed. More details here:
https://github.com/vinced/namecoin/blob/master/FAQ.md
Note that even though the mining reward remains constant, the network fee to register a domain goes down quickly over time. Quote: "The network fee is initially high, but will be negligible after a couple of years. It is used to slow down the initial registration rate so that plenty of desirable names are left for late adopters."


text:
Why did bech32 define a new base32 encoding scheme rather than use an existing one?
There are multiple existing base32 encodings (RFC 3548/4648, z-base-32, Crockford's etc). Why did bech32 define a new one rather than use an existing one?

There are multiple aspects to the design of bech32. There is the choice of character set (i.e. which characters are included in the 32 options and which characters are excluded because they visually look like other characters e.g. 1 because it looks like l), the mapping of specific bits to this character set, the type of checksum to use and the final address structure.
BIP 173 explains the choice of character set.

The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.

The mapping of bits to bech32 characters is also included in the BIP.
e.g. 11 maps to t (3 on x axis and +8 on y axis) and 30 maps to 7 (6 on x axis and +24 on y axis)

Note that although 1 is included in bech32 addresses as a separator (see here) the character 1 is not included in the permitted character set of bech32. Nothing maps to 1 in this mapping.
Pieter Wuille explained the rationale for this bit to character mapping at SF Bitcoin Devs in March 2017:

The reason for this is we were able to select our code to optimize for low bit error rates. Wouldn’t it be great if we could choose the character set in such a way that 1 bit errors are more likely than non 1 bit errors. This character set is the result of another year of CPU time to optimize for this. We found a bunch of information on tables for similarity between various characters. What you can see on this slide, the z and the 2 are considered similar in some fonts or writing. As you can see they are 8 apart. One is 2 and the other is 10 so they are 1 bit apart. And r and t are 1 bit apart. And y and v are 1 bit apart. And x and k are 1 bit apart. And e and a are 1 bit apart. And s and 5 are 1 bit apart. And 4 and h are 1 bit apart. There are way more similar errors overlaid in this data that you can look for. It’s pretty cool. We made a character set that optimizes for 1 bit errors. As a result our code is distance 6 for 1 bit errors. If you just look at these 1 bit errors we guarantee 5 errors. If you only make errors like this you can detect 5.


text:
What does Bitcoin policy language offer the developer that Miniscript doesn't? What is the difference between Bitcoin policy language and Miniscript?
I understand that policy language compiles to Miniscript and Miniscript is encoded (correction) to Bitcoin Script. This is also a great resource on Miniscript: http://bitcoin.sipa.be/miniscript/ But I know very little about policy language and there doesn't seem to be too many resources on it online.
When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?
Correction: As James points out below Miniscript does not compile to Script. Ivy is a smart contracting language that compiles to Script. http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/

Both answers by James C. and sanket1729 are very good, but I wanted to give a very high-level answer:
Miniscript is an intermediate more structured representation for actual Bitcoin Scripts. It is useful as a toolbox because it simplifies static analysis of scripts, and things like generic signing.
The policy language is intended to simplify designing Scripts for humans.
The fact that Miniscript has a textual notation that looks similar to the policy language is probably confusing, but it is not primarily intended to be written by humans. The textual form exists to permit including Miniscript expressions inside output descriptors, and easily communicate them. To actually construct a Miniscript expression for a particular purpose, you'd generally use the policy language and compile it.

At a high level:

The policy is compiled to Miniscript.
Miniscript is encoded to Bitcoin Script. (One to One Mapping)
Bitcoin Script is decoded back to Miniscript. (One to One Mapping)
Policy and Miniscript can both be lifted to another representation for static analysis.

Following invariants are respected in Miniscript:
Let ms be a miniscript, s be bitcoin script, pol be policy

decode(encode(ms)) = ms
encode(decode(s)) = s
lift(pol) = lift(compile(pol))

I am not going into the details of lifting as it not directly related to the question.

When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?

I think this is question is best answered by an example.
Writing an efficient Miniscript directly from spending conditions is not trivial. Policy language is a more natural way to write the spending conditions. Consider a Hashlock example from Bob to Alice, your requirements are

Alice can spend the coins if they know a preimage for hash H
Funds are sent back to Bob after some time T, say 10 blocks

This naturally translates to the following policy:
or(and(sha256(H),pk(A)),and(older(10),pk(B))). Writing a Miniscript for this directly would be complicated and probably would turn out to inefficient. This is where the compiler can help you.
The compiler would then compile down to a Miniscript like the shown below.
andor(c:pk(A),sha256(H),and_v(vc:pk(B),older(10))) which has a one to one mapping to Script.
Note that it is non-trivial to directly write down this Miniscript and that it involves complicated fragments like andor.
The policy language additionally allows specifying the odds (by using @ as shown below) for a or branch which can help the compiler produce vbyte efficient Script. In the above example, we expect the Hashlock to succeed with high probability and the timelock branch to be almost never taken. We can use the odds in the policy language as follows:
or(99@and(sha256(H),pk(A)),1@and(older(10),pk(B)))
which then compiles down to a different Miniscript (note that pk(B) changed to pk_h(B))
andor(c:pk(A),sha256(H),and_v(vc:pk_h(B),older(10)))

Miniscript doesn't compile down to script. It encodes a subset of all Bitcoin script. It is a (very crafty) template language which reduces the Bitcoin script language to specific script expressions which are composable, which means the properties of a miniscript expression only depend on the property of its children. Properties include malleability, satisfaction, non-satisfaction etc.
Composability:

So for example, satisfying witness elements of or_b(X,Y) only depend on the satisfying elements of X and Y. The satisfaction of X and Y, in turn, only depend on their respective children ... until terminal expressions such as pk()/pk_h() are reached. Other properties are inheritable in the same way.
To determine the top-level properties of the miniscript, one simply needs to lift or "trickle up" the properties beginning form the terminal child expressions (leafs in our syntax tree). A safe top level expression should be of the Base=B type, which pushes zero or a nonzero value if the overall condition is satified, be satisfiable in a nonmalleable way (m) and require a signature (s).

Policy-to-Miniscript Compilation:

For a given policy, let's say AND(PK_A, OR(PK_B,PK_C)), there can be multiple miniscript solutions. Simply consider the multitude of miniscript expressions for AND/OR: and_vbn, or_bdci.
The compiler can iterate through miniscript expressions, to find one that has the lowest spending cost, and also be safe (Bms) on the top level. But different compilers may optimize for different things.
To answer your question: In that sense, Policy is a higher-level language than miniscript. Miniscript isn't a higher language than Bitcoin script, since it translates 1-to-1.
It is not possible to reason about script properties on the policy language level as it is with miniscript.

Static Analysis:

Given a Bitcoin script, it is now possible to parse it into miniscript (if it is indeed composed of miniscript expressions). Since miniscript is composable, we can "lift" all properties to the "top level" miniscript expression, and reason about properties of the resulting output script, which include satisfaction or malleability (Can I safely sign for this output, and how does the witness need to look like).

Thanks James. I'm going to correct the question as you're right. Miniscript doesn't compile to Script. Ivy compiles to Script. I'm getting confused. http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/

Hi Michael. I suppose policy only describes raw locking conditions. Miniscript is an implementation thereof for the script interpreter, in a way which allows one to be sure it is indeed a "safe" implementation. Your policy is not guaranteed to be safe (doesn't require a signature), for example. In that case, your policy-to-miniscript compiler should find no safe solutions.

Hi @JamesC., I did research on Miniscript for a speech I gave and reading your answer I know understand that I got the Policy / Miniscript / Script sequence wrong. Thanks


text:
What are the downsides to enabling potentially suboptimal or unused opcodes in a future soft fork?
It appears to me that there are various ways to build covenants and vaults with opcodes and sighash flags that are not yet enabled in Bitcoin (e.g. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, OP_CAT).
Assuming these are considered for the next soft fork in Bitcoin what downsides are there to just enabling all of them and seeing what people build with them?
Obviously taking up a reserved OP_SUCCESSx with a potentially suboptimal opcode is one downside. And in the worst case a botched opcode could mean that a UTXO might not be able to spent (or impose unacceptable verification costs on full nodes). Are there any other potential downsides?
I suppose this is partly answered by what motivated Satoshi to disable a lot of opcodes in 2010 which I'm not clear on. The motivation appears to be security but again I'm not clear on what exact attacks were possible with what opcodes and the severity of those attacks.

Hey, I've been seeing the tag [tag:opcodes] pop up a lot lately. I think it may be a subset of [tag:script]. What do you think? https://bitcoin.meta.stackexchange.com/q/1084/5406

Every piece of additional consensus logic has implementation and ongoing maintenance cost which is perpetual and can never be removed without potentially confiscating some user's assets.
When Satoshi disabled those opcodes he took a risk that doing so would destroy some user's funds, but Bitcoin was young, their usage was apparently non-existent, and those opcodes all could be used to cause effectively unbounded memory usage or memory corruption and crash nodes.  I don't know
if Satoshi necessarily realised that he might be destroying people's funds, but given the threat at that point in Bitcoin's life (while Bitcoins
had very little value), it was probably the right call. It wouldn't be anymore.
Any newly introduced functionality isn't just a risk to the user, it's a potential risk to the entire network-- since flaws in it could result in consensus inconsistencies, node crashes, increases in worst case processing times, or even remote code execution vulnerabilities.  Protecting against that requires review and testing resources which could otherwise be spent on other functionality.  The costs are not one-time-costs either, since the code must be maintained and bugs could be introduced later.
Additional complexity also makes life harder for alternative node implementations, since they also have to implement every consensus rule, and it works against the users freedom to modify their own node (or implement their own).  Because of these costs, "maybe someone will find it useful" isn't a really compelling argument.
The costs also mean that once some functionality is implemented there is reason to not implement something else which is partially redundant with it, so if flaws in a feature kill some uses but not all, it will be harder to get an improved alternative that covers all the uses deployed.
As far as the advantages of offering a simplified and mostly orthogonal instruction set, I don't think that itself matters much.  While a proliferation of operations is a nuisance for anyone authoring an analysis tool, people can generally subset script however they like.  Even if it would create a burden that users who need to jointly construct a policy have to agree on a common subset that their analysis tools are happy with, I think this cost could easily be offset by the added functionality.
If OP_BAR is a footgun and its redundant with OP_BAZ which is less of one-- just blacklist OP_BAR and only use OP_BAZ. But if OP_BAR is implemented first it may be difficult to make the case that that marginal improvement of OP_BAZ is worth its additional costs. So in that manner the implementation of a weak feature can get in the way of a stronger alternative that could have been done in the first place if an appropriate amount of effort had gone into it.  The same statement is true if you replace 'footgun' with 'inefficient'.
Sometimes poorly designed features can have negative system incentive effects.  For example, the original construction of time based nlocktime created an incentive for miners to lie about their current time, pushing it forward in order to be able to collect later nlocktime transactions and their fees.  If time based nlocktime transactions became very common, this could have eventually created a race to the bottom where all miners were setting their times as far forward as they could to maximise their fees, and potentially endangering the stability of the network as a result even for users that don't use locktime. Fortunately nlocktime was fixable in a compatible way. Similarly, poorly constructed features could unnecessarily fragment the anonymity set or  incentivise users to reduce privacy for everyone.
It's easy to imagine contrived features which would create negative systemic effects: E.g. OP_BOBSIG where a txout using it can be spent with no restrictions so long as Bob has signed the whole block -- an extremely efficient choice for those who trust Bob. And it seems harmless to people who don't use it, until you consider that it gives bob-trusters an unfair advantage, gives bob's mining an unfair advantage, and eventually might effectively hand control over the whole system to Bob.  But systematic effects are a less common concern, since they require a feature that is attractive enough for people to choose to use it but unattractive for the system as a whole.  It's still a factor that needs to be considered.
Other than in system effect corner cases most Bitcoin experts would agree that the owner of a funds should have complete freedom in how they choose to manage them-- even if that means they might sometimes choose an inefficient or less personally secure.  Best practices can be addressed outside of the system itself.  But because the consensus rules have to be implemented by all nodes and can't be removed, there are costs.  These costs create situations where the the choice between a poorly and a well constructed operation-- or just between two totally different operations-- is to some degree mutually exclusive.  Because of this a new feature not only needs to be safe for the network, it also ought to be clearly useful, and at least reasonably well designed-- otherwise it may use resources which could otherwise be used to deploy something more useful or better constructed.

This is such a brilliant answer, thanks Greg.

yeah, they have to work first, and be reasonably well tested.   op_ctv seems to meet this criteria, however.  the only real objection i can see is that "it might not be as good as the other ones"

There is another consideration other than ensuring bounded resource usage in all edge cases for an opcode which was briefly discussed by others on IRC that I'll summarize here.
There are different philosophical approaches to designing future opcodes for Bitcoin. One dimension is whether opcodes should be designed using a RIS (reduced instruction set) approach or a CIS (complex instruction set) approach. A reduced instruction set (RIS) approach leads to opcodes with minimal functionality but they can be combined like building blocks with other opcodes to create greater functionality (ie UNIX like). A complex instruction set (CIS) leads to opcodes that offer complete and particular functionality.
Another dimension is regarding safety and whether opcodes should be designed to prevent footguns, restricting programmers from building scripts that can be misused in ways that could potentially harm user security. The alternative is not to worry so much about user safety, allow maximal flexibility and push safety concerns to higher abstract layers (e.g. Miniscript, Policy, descriptors etc).
These two dimensions are not entirely orthogonal. If these dimensions aren't considered then you end up with a ragbag of new opcodes (and sighash flags) enabled and it is not clear what opcodes should be used for what and what guidance (if any) should be offered on how to use them safely. When Satoshi was enabling and disabling opcodes he/she didn't have the understanding that we have in 2021 and wasn't dealing with a system storing and transferring billions of dollars with higher layers dependent on changes made to the base layer.


text:
What is the difference between policy and consensus when it comes to a Bitcoin Core node validating scripts?
What is the difference between policy and consensus when it comes to a Bitcoin Core node validating transaction scripts? Can you give some examples of checks that are considered policy and checks that are considered consensus?
This question was asked during this Bitcoin Core PR review club session on PR 19698.
There was further discussion in this Bitcoin Core PR review club on PR 22871 and there is a section on policy in this Gloria Zhao gist.

The term "consensus checks" refers to the rules that determine whether a block is valid; specifically, if a consensus check on a block (or a transaction contained within a block) fails, then the block is considered invalid.  If we get to the end of the block and none of the consensus checks has failed, then the block is valid.
Policy checks are a superset of consensus checks (meaning that policy checks are in addition to consensus checks, so that passing policy checks implies passing consensus checks), and policy checks only apply to transactions that are being considered for addition to the mempool. The purpose of policy checks is generally to (a) close off DoS vectors and (b) to make future consensus changes safer to deploy, by preventing relay of transactions that would violate such future consensus changes well in advance.
You're specifically asking about transaction script checks, but note that there are many policy (and consensus) checks on transactions that occur outside of just script validation.  Also, the links in your question are to the "policy/" and "consensus/" subdirectories in Bitcoin Core's source tree, but there are many policy and consensus checks that happen outside of those directories.
Here are some examples of policy checks in script validation, that are not (yet) consensus checks. These first ones are from BIP62, which proposed a set of rules to limit transaction malleability.

STRICTENC
LOW_S
SIG_PUSHONLY
MINIMALDATA
CLEANSTACK

Here are some policy checks relating to making softfork deployment safe in the future:

DISCOURAGE_UPGRADABLE_NOPS
DISCOURAGE_UPGRADABLE_WITNESS

There are some miscellaneous other policy script checks, such as requiring that all pubkeys in segwit scripts be compressed, or that inputs to OP_IF/OP_NOTIF be minimally encoded. And then of course all future consensus changes (such as Taproot changes) that have not yet been activated on the network are policy checks as well. An (almost) full list of what transaction script validation checks are performed as part of policy checks when a transaction is being validated for the mempool can be found here. (Note that this list includes consensus checks as well.)
However that is not quite a complete set of transaction script validation rules that are enforced as policy checks. During mempool acceptance, we perform other checks on a transaction as well, some of which depend on a transaction's scripts. Some examples of these include:

Non-p2sh, non-segwit spends must be P2PKH, P2PK, or bare multisig
scriptSig or witness must be no more than a given size
Various rules on outputs created (no more than one OP_RETURN, must be P2SH/v0 segwit/P2PKH/P2PK/MULTISIG, value must be above dust threshold)
Limits on how many signature checks are performed by the transaction

There are a lot of these to list, but tracing the code in mempool acceptance (particularly here) and inspecting functions like CheckTransaction, IsStandardTx, and CheckTxInputs should yield the remaining policy script checks, on top of the ones enforced inside the script interpreter.
Transaction script consensus checks are a much smaller set. Some of the script flags that are now consensus checks include:

P2SH
DERSIG
NULLDUMMY
CHECKLOCKTIMEVERIFY
CHECKSEQUENCEVERIFY
WITNESS

The full list (with enabling conditions) can be seen here. Note that as consensus rules have changed in Bitcoin's history, not all the script flags mentioned in that function are enabled on all blocks.
Most (all?) of the remaining consensus checks performed on transactions can be found in ConnectBlock(), CheckBlock(), and ContextualCheckBlock().


text:
Do I need to run a full node before the 2X fork?
There is a meme out there that goes like this:
"Bitcoin Cash taught people they need to own their own private keys, segwit 2X will teach people they need to run full nodes"
Do I need to run a full node before 2X, or are my coins safe on Trezor?

Your coins are safe on Trezor, you don't need to run full node for coins unless you want to help mine.
If you want to access Segwit2X coin or any other BTC forked coins (in future) asap after the fork, then you should transfer your BTC coin to a lite client and get the private key of that wallet.
Or else, you can wait until Trezor supports Segwit2X coin, in that case, you will get those coins in Trezor itself.


text:
How does the ASIC Jalepeno connect to the Internet?
Does the ASIC Jalepeno miner need to be connected via USB for it to work properly (to access the Internet)?
I was hoping there was a wi-fi setup option but I don't see it.

Needs to be plugged it to the USB looks like.

The ASIC does nothing on its own - it is just hardware without any logic.
You need to plug it into USB and run a mining software (like cgminer) on the PC where the ASIC is connected to via USB.


text:
Mitigating a Double Spend Attack by Punishing the Attacker?
One of the main reasons it's not safe to accept Bitcoin with 0 confirmations is due to the possibility of a double spend (where Mr. Scammer first sends 1 BTC to Alice and then creates an identical transaction in which he sends the same 1 BTC to Bob or to another address controlled by himself. If the network ends up including the second transaction in the blockchain only Bob (or Mr. Scammer himself) will be viewed as the rightful owner of the coins and Alice will be left with nothing).
However, being that it is impossible to hide a double spend forever, and everyone on the network will eventually discover that Mr. Scammer double spent his coins, why is it not possible to penalize the double spender in order to reduce the economical incentives of doing so in the first place? For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we "burn" (or destroy) the locked up BTC.
Wouldn't this significantly reduce the likelihood of a double spend occurring in the first place?

Some people have actually created gambling games where a double-spend is deliberately created, and then they wait to see who the lucky winner is depending on which transaction is validated and which is rejected..  Its juvenile, but deliberate and (vaguely) fun.  Punishment is not necessary or appropriate for that.

This wouldn't be effective.
Say I want to transfer value worth $100. How much is it reasonable to ask me to lock up and for how long? Maybe we could tolerate forcing me to lock up $200 for an hour.
But I don't just have to do a double-spend. I can do a quintuple-spend. I can get $500 worth of value for my $100 payment and then, even if I forfeit an extra $200, I'm still well ahead. And now you've made payments far more painful for everyone since they need to have three times as much as the amount they want to pay just sitting around.

@_David Schwartz I did mention the issue of quintuple-spend as a comment to @chytrik answer. I don't see a way around this because even if we locked up 500% of the original transaction he could do a sextuple-spend (although I would be interested in knowing if it is significantly less likely to perform a sextuple-spend vs. a double spend) (continued)

However, I don't agree that this makes "payments painful for everyone since they need to have three times as much as the amount.." bec the idea is that this type of transaction would be tied to a specific type of address (say address starting with letter e). If a person knows in advance he will require  instant confirmation (say buying something at the grocery or paying for gas in his car) he can transfer the required funds before hand. The network will apply these rules only to this kind of address. When quick confirmation is no longer required he can move the funds back to a normal address..

@S.O.S I don't follow the point then. Is it to allow a special type of very expensive transaction just to provide rapid confirmation for low-value payments that are a tiny fraction of a person's balance? If so, I would say that's just an awful match for the way the bitcoin blockchain works because it doesn't have balances. If you're proposing an entirely new and radically different system, why make it slow for any payments?

Given two transactions that spend the same input, there is no way to know which one 'came first' or is the 'rightful' transaction. Because of this, it is very difficult to enforce a 'no double spend' policy in this way. How can you guarantee that you have the transactions ordered correctly? What happens if some nodes on the network see the transactions arrive in a different order? Or what if a scammer sends a payment, but then claims that a transaction that pays those same coins back to themselves is actually the 'first' transaction? Etc.
This is why the blockchain exists in the first place: to give an explicit order to the transactions which occur on the network. Attempts to make 'zero-confirmation transactions' as reliable as confirmed transactions will never succeed, and if they could, then we could just do away with the whole blockchain! Perhaps there are ways to make double-spend attempts less likely to be successful, but ultimately if you are accepting zero-confirmation transactions, then you are incurring some risk of being double spent against.

For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we "burn" (or destroy) the locked up BTC.

You have more or less described an escrow system, in which a third party is employed to ensure that the transaction in question proceed smoothly. This is possible today, and indeed some markets provide access to this sort of protocol.
Keep in mind: if you are requiring that the user lock up some coins on-chain as collateral... that will require a bitcoin transaction to create this 'locked up UTXO'. To create that UTXO you will have to wait for an on-chain transaction to confirm... and at that point you might as well just wait for the payment to confirm in the first place! If you don't wait for it to confirm then you're just back at square one in regards to double-spend risk.
Attempting to automate this doesn't seem viable, for reasons similar to those I mentioned in the first paragraph above.

My thinking is that the locked up funds would be sent to a custom type of address that is specifically designed to hold funds as collateral (it can be created by any individual just like a normal BTC address). The point is that no node/miner would accept  a transaction from this address unless the address maintains at least an equivalent amount of collateral compared to amount being spent

It is true that it would require a bitcoin transaction to lock up the UTXO (funds) initially but my thinking is that if a user knows they will need to performa transaction with quick confirmation time in the future transaction they could lock up some of their funds in advance in this kind of address. When this is no longer needed they can move funds to a normal address. It is not like a centralized escrow system as everyone on the network can easily know when a user attempts to double spend.

Perhaps the only flaw I can see with this system is in the event that Mr. Scammer tries to send the same Bitcoin not to one but to several individuals and each one of those individuals believes his  transaction is the only one that exists. In this case the only way to mitigate a "triple" or "quadruple" spend would be to lock up 300%  - 400% of the amount being sent but since the attacker could conceivably trick an unlimited number of individuals we would need to lock up an infinite amount of funds to fully protect against a double (multi) spend..

To be clear, I'm not saying this strategy should replace PoW. I'm saying it can work in harmony with PoW with the added benefit of be able to accept 0 confirmation transaction

You're going to need to be more clear about the specific technical mechanism that decides to burn the funds if a double spend attempt was found to exist. I don't think it is possible to build such a thing with bitcoin script, without using some sort of trusted oracle.


text:
Is there something about Bitcoin that prevents us from implementing the same privacy protocols of Monero and Zcash?
Certain coins like Monero and Zcash implement privacy protocols that make it nearly impossible to trace origin and destination of transactions - making them completely anonymous.
I'm curious as to why Bitcoin does not peruse a similar path to privacy.
Is there something about the Bitcoin Core code or the way Bitcoin functions at present that prevents it from pursuing this path in the future? Or is it related to extrinsic concerns that governments around the world might forcibly shut down the network if extreme privacy measures are employed?
Thanks

I'm curious as to why Bitcoin has not perused a similar path to privacy.

I want to start by commenting on the phrasing of this question. Bitcoin is defined by the consensus of its users, and isn't a central entity that can set a development goal or priority of what to work on. Individual people - including developers like me - have priorities on what to work on, but those might not be shared by everyone in the ecosystem, or even be opposed by some. Since invasive changes like the ones you're talking about need to be adopted by ~everyone to be successful, it's very hard to answer a question of the form "why does/doesn't Bitcoin do this?". A better way of phrasing is whether there is active research in some direction, or what challenges exist.

making them completely anonymous.

Privacy in cryptocurrencies is a complex topic, and isn't restricted to on-chain transaction linkage (which seems to be what you're talking about here). To give a few other examples:

P2P network privacy: network-level attackers can monitor how transactions propagate through the network, allowing correlation between transactions, even if no on-chain trace remains of this. Partial solutions against this exist (Tor, encrypted private channels, Dandelion, mixnet routing, ...), but things very much depend on how they are used.
Wallet infrastructure: the way people actually interact with the system isn't immune from privacy leaks. Lots of wallet software uses central servers (trusted to greater or lesser extent), and this isn't even restricted to blockchain access: have you considered how wallets get exchange rate information? This reveals "Bitcoin user on this IP!" to the service where they are getting it from. Additional layers of payment infrastructure add another dimension to this, with their own challenges.
Spending policy privacy (aka "smart contracts"). Any time someone does less than trivial things on-chain, it stands out. If tomorrow AwesomeCorp brings a new fancy secure wallet, and it's in practice the only thing out there that uses 5-of-7 multisig, then anyone can infer that any 5-of-7 scripts on chain are due to users of AwesomeCorp Wallet. This too is a privacy leak. A less far fetched example: you can trivially distinguish Lightning usage from normal payment activity on chain today. This is orthogonal to on-chain transaction linkage privacy (though some solutions apply to both). This is something that the Taproot (BIP 341) proposal aims to partially address (disclaimer: I'm a co-author).
Amount privacy: Bitcoin transactions today reveal information about the amounts being transferred (even if not always completely obvious due to change outputs). Both Monero and Zcash cover this as well with their respective approaches, but it can be treated as distinct from transaction linkage privacy, and hypothetical solutions exist that address one but not the other.

All of this to say: privacy is multi-faceted, and all aspects of it are important. And it turns out, some of them are much easier to improve upon than others.

I'm curious as to why Bitcoin has not perused a similar path to privacy.
Is there something about the Bitcoin Core code

Bitcoin Core has nothing directly to do with this. If the ecosystem demanded a particular change, it would get implemented, and people would switch to it - whether that's in the Bitcoin Core implementation or in something else. Of course, several people who participate in these discussions also contribute to Bitcoin Core, and it is a focal point for development - but doesn't necessarily have to remain that way (disclaimer: I'm a contributor to and maintainer for Bitcoin Core).

or the way Bitcoin functions at present that prevents it from pursuing this path in the future?

Specifically comparing with the approaches that Monero and Zcash have taken, I can give a few reasons that I personally think pose challenges. These aren't necessarily "Bitcoin cannot/will not do this because..." arguments; they're reasons why they could cause controversy, might not be acceptable, and indirectly may be reasons why people prefer to not work on them (or at least, work on other things first):

Necessity of "opt-in" approach: even if a system is proposed that enables better transaction-linkage privacy, it appears very hard to do in a way that doesn't either leave it optional (risking "why did you choose to use Private Mode for this transaction?" questions), or forces everyone to upgrade their wallet infrastructure (something that has historically been extremely rare) and may break systems built on top. This is even worse if the more private mode is more expensive, slower, or puts more load on the network.

ZCash's approach requires the introduction of new (and relatively new) cryptographic security assumptions (at least elliptic curve pairing-based constructions). This means that it's possible that with such an approach, future breakthroughs in cryptanalysis make it possible to steal coins, or violate other properties the system is supposed to protect. A similar risk exists of course for the assumptions Bitcoin relies on today for security, but these are older and more conservative (elliptic curve discrete logarithm), and perhaps also important: already accepted by the current users of the system. And even in case this new private mode is optional, if you're not personally comfortable with pairing-based cryptography and choose not to use it, you wouldn't be too happy if a significant portion of BTC in circulation move into it: if the assumption breaks, your own coins that aren't under such a system wouldn't retain any value if a sizable portion of the supply becomes perceived to be at risk for theft. Thus, you may see opposition to the introduction of such a system by those who aren't going to use it. Monero's approach has very similar security assumptions to Bitcoin's.

Both Zcash and Monero replace the UTXO set (whose size scales proportional to usage, and can and does shrink from time to time) with a different data structure that grows forever (proportional to how often coins have been moved). This is a major scalability concern, but only manifests itself under actual load. I believe both Zcash and Monero see far fewer transactions per unit of time than Bitcoin, so they may not suffer very much under this (yet). This makes it a fundamental trade-off: better scalability, or better on-chain privacy, and it's unclear if all users would be happy with changing that.

Auditability of supply: approaches that introduce better amount privacy (like Zcash and Monero, but also Confidential Transactions as mentioned in Prayank's answer - which doesn't directly affect transaction linking privacy) mean you don't have a simple database you can go over and sum up all UTXO amounts anymore to see what the total supply is. It gets replaced with a cryptographic construction, and trust that supply hasn't been inflated becomes entirely dependent on the security of the cryptography used. Alternative approaches exist that still have amount privacy, and don't make inflation protection dependent on security assumptions; only amount privacy itself. These are less efficient, and still make it hard to audit supply. Given the prominence of Bitcoin's supply schedule, it may be expected that many users aren't comfortable with giving up the auditability it has without very good alternative assurances.

So, yes, I believe there are specific challenges to pursuing the approaches those other systems used. But that's okay, there is lots of interesting research (partially due to the existence of these systems), and given enough time, I do expect that some of that will lead to improvements that Bitcoin can adopt. Furthermore, on-chain privacy doesn't exist in a vacuum, and liquidity matters: a system that is harder to use and/or sees less use for whatever reason inherently has a smaller anonymity set: the users of that system. Bitcoin sees actual use in the real world, and there are approaches to improve actual privacy that do not rely on on-chain cryptographic techniques, see this excellent article for example. The voluntary nature and actual usage also complicate fundamental improvements, but we'll get there.

Or is it related to extrinsic concerns that governments around the world might forcibly shut down the network if extreme privacy measures are employed?

As far as I am concerned, hell no.

Thanks, Pieter. A side note: on-chain privacy will become increasingly irrelevant as the majority of transactions move off chain. Lightning Network payments, for example, have privacy implications more similar to those of Tor traffic. I expect that on-chain transactions eventually will primarily comprise setup and teardown operations for off-chain payment systems like LN. The privacy implications of such on-chain operations would be limited to "this on-chain address chose to put X amount onto the Lightning Network at this time," which isn't really revealing.


text:
Storing your private key on a "security server"?
One of the suggested security precautions  when storing Bitcoin of users on a server is to store the private keys on a separate server:

The database storing the private keys or the seeds in case of HD
wallets should be running on a separate instance and only accessible
via the application server(AWS allows lots of configuration you can
make in the virtual private cloud i.e. VPC to accomplish this).

I understand that if the PK is stored on a separate server then that server would also need to be compromised in order for the security of the actual keys to be compromised. However, since presumably, the main server will be sending withdrawal/transfer requests to the "security server" what stops a hijacker from effectively liquidating the entire wallet balance by using the main server to forward requests to the security server? In other words, what is gained by adding an extra server to the equation if the security server is expected to "honor" (and sign) requests it receives from the main server?

you should look up what happened between bitfinex and bitgo. bitfinex was relying on bitgo's multisig setup to sign transactions but when finex got hacked the hacker simply sent the requests to bitgo which signed transactions without hesitating. so yes there's no point to it unless you have human oversight and limits placed on signing.

@Abdussamad very interesting (I did not know the hacker used bitfinex's server to forward requests to BitGo making MultiSig essentially worthless in this case) where can I read more about the mechanism of this hack?

Usually we try to discourage storing private keys on a server at all unless absolutely necessary.
However, if necessary, just having the keys on a separate server increases the complexity of the attack, as it's an extra step. But, in addition to that, you may employ things like rate limits, limits on transaction size, whitelists on addresses that can be sent to, etc. If there is unusually high transaction volume, a site operator could be notified to step in and review the activity log. In essence, you're right, such a system does have the risk of a hacker who has completely exploited the application server just using the application server to forward requests. But we can slow them down to limit the extent of possible damage.

you can also harden the key server because it will run a reduced set of software compared to the app server or web server.

"Usually we try to discourage storing private keys on a server at all unless absolutely necessary" In what scenario would you say it is not necessary to store the keys? I mean, imagine we're dealing with an exchange or marketplace with hundreds or thousands of withdrawals requests per day is there any other way to process the withdrawals without storing the private keys on a server? It isn't possible to have each request processed manually..

@S.O.S if you're running an ecommerce site where you just need to receive payments online while spending the money can be done manually then you can take advantage of the properties of bip32 extended public keys to generate receive addresses without letting the server spend the coins sent to them. as for the scenario of an exchange or marketplace you can manually do withdrawals once a day like bitmex does.

@Abdussamad so bitmex reviews and process each withdrawal request manually? Seems like a ton of work..

@S.O.S Nah. Download a list of requested withdrawals, run a script to audit for inconsistencies, then sign the withdrawal. Pretty straightforward.


text:
Strategies to Reduce High Transaction Fees in a Cryptocurrency Marketplace?
I’m building a cryptocurrency marketplace where users mainly buy and sell small ticket items (worth $10 - $50) using cryptocurrency. However, the "miner fees" are making it prohibitively expensive to run.
SCENARIO:
I have a marketplace of vendors and buyers where a user can be both a vendor and a buyer. A buyer must deposit funds in his account (top up account balance) before he can spend cryptocurrency on the platform. For every new user, we would generate a unique address so that any funds deposited to that address would be credited to that user. It makes it easy to know who to credit when we detect a deposit to a specific address. My main dilemma is regarding disbursements to the vendor and taking platform fee (see below).
After the buyer purchases an item (using account balance), the payment is held in escrow until the item is delivered to buyer. Once the item is delivered, the payment is “transferred” to the vendor minus a 1.9% “platform transaction fee” (which is paid to the platform owner). A vendor can withdraw his earnings at any time after paying a flat $5 withdrawal fee. Similarly, a buyer can withdraw his deposit (account balance) at any time for the same flat $5 fee. Keep in mind a withdrawal by a vendor typically includes payment received from hundreds of transactions (all which originate from numerous buyers and numerous addresses). It may also include a deposit the vendor himself made in order to top up his balance.
When a single order is complete (i.e, a product is delivered) it is obviously not viable to transfer payment from the buyer’s wallet to the vendor’s private wallet as this would incur a “mining fee” every time an order is placed on the site. Instead we would be relying on the internal ledger concept described in this reply.
In short, based on the ledger concept, if a product sold for $25, we would “credit” the vendor with $25 worth of a specific type of cryptocurrency without actually broadcasting the transaction to the blockchain. Similarly, we would “deduct” the $25 of crypto from the buyers balance (using an internal database, without actually broadcasting anything to blockchain). Now let’s say a vendor completes 100 transaction * $25 when Bitcoin is worth $10,000 per BTC. So we would now owe the vendor $2,500 USD or 0.25 BTC (minus 1.9% platform fee).
THE PROBLEM
When the vendor chooses to withdraw his earnings, the 0.25 BTC would be originating from 100 different addresses (100 buyers) which will obviously lead to excessive miner fees. Similarly, since the site owner takes 1.9% fee for each transaction, if the site owner wanted to consolidate all of the little cryptocurrency earned from 100 addresses to 1 address it would entail a similar process (and the relative cost would be far greater for the platform owner).
TIME SLOT APPROACH
One solution to this problem might be to have all users of the site deposit funds to a single cryptocurrency address. Of course, this makes it difficult to track who's who when making a deposit since everyone is sending to the same address. It is possible to dedicate address to a single user for a period of time (“time slot”) and then credit the user who has the dedicated “time slot” but this approach is not ideal since we would need to track which user had access to the address at a specific period of time. Furthermore, users may not remember that address allocation is time sensitive and may make deposits to that address at a future time under someone else’s “time slot”. It is also very confusing to the user and would still require dozens of unique addresses if the site has many users. However, in theory this would solve the primary issue since payment to vendor would be originating from a single address and any funds remaining in that address would go to the site owner as a platform fee.
Presumably, there are other solutions to this problem as there are many sites with similar functionality. What is the industry standard solution to this problem? What are some ways to tackle it? Any insight is highly appreciated.
Note: The marketplace will support deposits/withdrawals in Bitcoin, Ethereum, Bitcoin Cash, Ripple, Litecoin, USDC and USDT.
Note: I'm open to a native solution that relies on the blockchain client or a API solution from a reputable firm.

Please limit the scope of this question to Bitcoin. Other currencies are off-topic here.

@PieterWuille I thought that if the primary question relates to Bitcoin, I can include altcoins as secondary: "Questions about alternative cryptocurrencies are off topic unless they are applicable to Bitcoin"

I understand that to cover questions for which the answer is the same as for Bitcoin.

As @chytrik already described, address reuse does not solve your problem for UTXO-based coins, each transaction output must be individually referenced regardless.
When your users deposit into your site, you want to give them separate addresses, so that you can track whose internal balance should be credited. After that, the funds are in your custody, though. Which means that you can and should manage your UXTO pool. A good start would be to regularly consolidate smaller amounts into larger UTXOs during off-peak hours when the feerates are low. You may find this article about UTXO management for enterprise wallets interesting.
Generally, Bitcoin on-chain payments don't lend themselves to fast micropayments—as you observed the fees are too big of a portion of the value. Bitcoin's response to that is the Lightning Network, an instant payment network leveraging multisignature based payment channels.

Thanks for your reply. 1) Is the "time slot" proposal a viable solution for altcoins such as Ethereum which use the Account Model? 2) The fee to transfer $2,500 to Vendor is approx. $376.37 (USD) (15% of the total) with a 60 min time frame according to this site. For a 400 min time frame cost is reduced to $78.50 (USD) (1.5% of total). The platform charges a 1.9% fee which would be eaten up by the high cost. Would you say this is the lowest fee I could expect to pay using the legacy BTC protocol (The API I'm using doesn't support Lighting Network) ?

Bitcoin fees are not relative to the amount that is sent, but relative to the amount of blockspace a transaction occupies. If you can wait longer, you will eventually be able to get a transaction through at 5 sat/vB or lower. If you want to be really patient even at 1 sat/vB. For an average-sized transaction of 500 vB that translates to 500-2,500 satoshi of fees—at today's exchange rate less than a dollar. For questions about ethereum, I would suggest that you check out https://ethereum.stackexchange.com.

A SE user (@Prayank) commented on another question of mine  "I can have one website, user login, all pay to same address but updated in my local database with user id and transaction id when payment is done" Would you agree to that statement? Is it possible to track user deposits using the transaction ID (TXID) if everyone on the site is sending to the same Bitcoin address? It doesn't make sense to me..

While it is correct that every transaction has a unique id and therefore every unspent transaction output is uniquely identifiable, having everyone pay to the same address will introduce a lot of overhead with tracking who paid when. It will be much easier to assign a new address for every payment process (or at least every customer). Generally, address reuse has a lot of disadvantages, and afaict no palpable advantages in Bitcoin.

One solution to this problem might be to have all users of the site deposit funds to a single cryptocurrency address

This is definitely not a solution to the problem you've outlined. When creating a transaction, there is no difference between consolidating many payments that were made to the same address, and consolidating many payments that were made to unique addresses. Each payment you include will represent a single input to the transaction.
From the sounds of it, you are confusing the concept of an account based model for transactions, and a UTXO-based model for transactions (which is what bitcoin employs).

Thanks. While the main questions is about BItcoin, would the time slot approach be a solution for Ethereum (account based model) type transactions?

@S.O.S I don’t find Ethereum that interesting, so I am no expert in its operation, but I would guess that the ‘time slot approach’ is almost certainly not a good solution for any such situation, given the issue of many users potentially making concurrent deposits. (And the issue of delayed tx confirmation, etc)


text:
How to send user input data(Bitcoin address) from iPhone to server and then send Bitcoin back to user's Bitcoin address?
Background I just got started yesterday learning Python and I'm currently building my first iPhone game.
What I'm trying to do is create a Bitcoin Pot Jar inside an iPhone app like Sarutobi:https://itunes.apple.com/us/app/id932194840?mt=8
You can test out the game to see how it works. All the user does is paste their bitcoin address in an input field, somehow this data goes somewhere and then the user receives randomly small tip during gameplay. How do I create something like this? What code is used to make this work?

What is this?: client_pass = "dadfisasf#@$sdf3sfR"

I think this may be off-topic because this is a general programming question that is better suited for stackexchange.com.

I was sent here from stackexchange.com and now you're telling me to go back? http://stackoverflow.com/questions/28012008/how-to-send-bitcoin-address-from-iphone-to-server-and-then-send-bitcoin-back-to?noredirect=1#comment44412677_28012008

@cdecker While this is an incredibly broad question, its scope lies entirely within cryptocurrency. I've going to vote to leave open.

@bluebit You should get more familiar with Web Services. Bassically iPhone will send request for invoking method to Web Service that lies on your server. Server will create and broadcast the transaction. - Sorry for previously misleading link.

Ok, so this looks a lot harder than I expected. I'm totally new to code. Can someone breakdown a list of what I need to learn to accomplish my goal. Do I need my buy own Server or can I use an online service? I've been looking at resources on how to code, but there are so many languages, and everybody says something different, I need a good teacher.

@bluebit Please only ask one question per post.

I don't mean to be discouraging, but a project that involves transferring real money around (yes, Bitcoin is real money) is not a good idea for someone who's "totally new to code". You can very easily get all your money stolen, for one thing. I'd suggest starting with something much simpler.

How do I send a Bitcoin address from an iPhone to my server?
Basic Python client socket example:

Server side:
import socket

serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serversocket.bind(('localhost', 8089))
serversocket.listen(5) # become a server socket, maximum 5 connections

while True:
    connection, address = serversocket.accept()
    buf = connection.recv(64)
    if len(buf) > 0:
        print buf
        break

Client Side:
import socket

clientsocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
clientsocket.connect(('localhost', 8089))
clientsocket.send('hello')

How do I make a Bitcoin transaction using Python from my server?
How to make a simple payment with the python-bitcoinlib?

(Rewritten for brevity)
Run
  bitcoind,
  install python-bitcoinlib, then run this code:
from bitcoin.core import COIN, b2lx
from bitcoin.base58 import CBitcoinAddress
import bitcoin.wallet
import bitcoin.rpc

rpc = bitcoin.rpc.Proxy()
addr = CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))


text:
Successful national digital currencies
Are there any successful stories about coins created specifically for a country? (pre mined and drop)
I have seen cases like Auroracoin, but I want to know if there has been a success story.

Most altcoins have done very poorly. You can see the list of relatively successful ones here. There isn't a country coin that's got a market cap over a million. I would say there hasn't been a success story.


text:
How to avoid price pumps & dumps when trading with bot?
Recently I recieved $500 USD in credits for trading with Coinsetter, a NYC based bitcoin exchange, so I decided to use them and coded a bitcoin trading bot for myself (never have done such thing before); The problem I'm having right now is that my bot seem to be "buying higher, selling lower" and I don't know why, you see:
If I go to the bot's logs, I get something like this:

The prices shown there are the prices at which the market order is requested, (giving an invalid price as an argument for the API request supposedly results in a failed order, so I request the live price first from coinsetter twice before I do a buy/sell operation); BUT if we go to the coinsetter transaction history we have this instead:

So everytime I do a BUY I pump up the market, and every time I do a sell I dump it, how can this be avoided? I'd prefer buying at the lower prices and selling at the higher ones.
P.S. Another question would be: What you think is the real price at which I'm buying/selling? The price I REQUEST or the price coinsetter tells me at it's history?
Thanks for your advice.

It seems inconceivable that trading a couple of hundred bucks you are affecting the market price on any sensible exchange.

In a normal exchange, you have an order book of buys and sells. Usually, they don't cross over, that is, if the highest buy is 219, the lowest sell will be higher than that.
What you're doing is buying at market (aka market order) so any buys you do simply match the lowest sell and any sells you do simply match the highest buy. Whenever the two cross, they are simply filled by each other, so the gap will be there 99% of the time.
What you can do if you want to avoid this is to use limit orders. Generally, though, you have to wait for them to fill as you need price movement in order for that to happen.

So basically there's no way to have a "market order based" profitable bot?

Of course you can make one. You just need a strategy that sells higher than when you buy based on price movements. It's just that the prices are stacked in a way as to make that hard.

Now I know what to do... Thanks! after doing some research and reading your comment I understood the problem well, marking this answer as accepted.


text:
After power hit, wallet won't load
I downloaded Bitcoin core wallet a few days ago. It was all going well, it synced just to about 25 weeks ago or something. One day the power went down and it shutdown the computer.
When I started bitcoin core again it loaded up to "loading wallet" and is stuck there. Unfortunately I already send a few BTC's to the wallet. Since I could not access my wallet, I figured that my BTC's are lost but then I start reading about accessing my wallet using Bitcoind, however when I create the bitcoin.conf file with the
rpcuser=bitcoinrpc
rpcpassword=xxxxxxxxxxxx

It wont recognize it and still give me the same error and crash as before I created the file.
I am currently running on Windows XP. So since I can't access my wallet, and since the manual way does not seem to work either, is there any other way to withdraw the coins from the wallet? If not can anyone help me with the bitcoind problem. Thanks a lot.

You backed up your wallet.dat before the crash, right? Right?

The levelDB gets corrupted if bitcoind stops abruptly, like during an outage.
I'm not that familiar with running bitcoin core on Windows, but this fixes the issue on Linux. It isn't the quickest or best solution, but if manually transferring wallet.dat isn't an option (and you can't dump the private key as another person suggested because bitcoind won't run) this may work for you:
Go into your bitcoin data folder and delete the 'blocks' and 'chainstate' directories and restart bitcoind. It will of course have to re-download the blockchain and re-index which will take a long time, maybe even a week, but it will eventually catch up and you can use bitcoin core again.

Run bitcoind and on the command-line use this command:
dumpprivkey <your bitcoin address here>

This will dump your private key which can then be imported to any number of other bitcoin wallets like Mycelium, Electrum, Armory, etc. You will be able to access your funds in the other bitcoin wallet software once this key is imported.

Bitcoin Core has a built-in RPC command to reload custom wallets, if custom wallets stop showing after node restart, disk full issue or moved wallet from another node.
Loads a wallet from a wallet file or directory.
bitcoin-cli loadwallet "wallet name"

Note that all wallet command-line options used when starting bitcoind will be applied to the new wallet (eg -zapwallettxes, upgradewallet, rescan, etc)
Note: inside double quotes mention wallet folder name for custom wallets or use wallet.dat file name
Loadwallet Reference


text:
Correlation between Ripple and Bitcoin
Is there a correlation between the value of Ripple (XRP) and Bitcoin (BTC)?

Price correlation, most likely, but technical analysis is probably outside the purview of this site.

I agree about price correlation, but why would the question be offtopic? It's not "technical analysis" so much, as just a question of finding historical data and plugging them into the equation. It can easily be answered factually.

Bitcoin and Ripple's past 90 days prices somewhat correlated
Using price charts of the last 90 days in XRP/USD and BTC/USD, the daily prices of Ripple and Bitcoin appear to be somewhat correlated: Their correlation coefficient comes out as 0.741.
Correlations in Coingecko's Top Ten
I've proceeded to check the past 90 days correlations of the top ten cryptocurrencies as listed on Coingecko.com:

In the past ninety days:

Litecoin and Bitshares had a correlation of 0.93, as had Litecoin and NXT.
Bitcoin appears to be most correlated with Ripple and Litecoin, both 0.74.
Bitcoin appears to be least correlated with Stellar, at -0.19
The least correlation appears to be between Dogecoin and Monero at -0.05.

Procedure
All data was taken from Coingecko's last 90 days pricecharts on 2015-06-08. Therafter, I plugged them into LibreOffice, and ran Correl(A;B) on each pair.

In general, when bitcoin is rising, all the others cryptos do, and vice versa. You can say that bitcoin is leading the crypto in general, so any upthread in bitcoins rate usually leads to the raise of most of the alts

Could you please support that opinion with a reliable source or some numbers? So far it sounds like anecdotal evidence to me.


text:
What is saved in wallet.dat exactly?
As I know, wallet.dat saves all related data for a bitcoin wallet.  However, I don't understand what precisely is saved in the wallet.dat.  I think it must contain several private keys. Does it also contain the corresponding public key, and seed value?  Anything else?

The wallet.dat file contains your private keys, public keys, scripts (which correspond to addresses), key metadata (e.g. labels), and the transactions related to your wallet. If you have an HD wallet, it also includes the HD seed and and the derivation paths for each private key.

So 'backup wallet' is actually mean 'backup wallet.dat' and 'restore in another wallet support wallet.dat format', for all circumstances. Is this correct?

Yes, that is correct.


text:
Legal issue of bitcoin investment in the US as a foreigner
So after China banned CNY <=> bitcoin trading, I plan to invest in bitcoin with my USD. My plan is:

exchange USD with CNY (by wire probably)
Buy bitcoins with USD
Sell bitcoins for USD.
Exchange back to CNY (by wire).

In the above proccess, is there any legal issue against money laundering law of the US?

I agree that this is a good and relevant question but believe it should rightly be answered on Law SE provided it is suitable there.

I'm voting to close this question as off-topic because this question is asking for legal advice.  Consult a lawyer familiar with the topic and jurisdictions in question.