|
/sigh
So many tutorials on various linux things just stuff "sudo" onto the beginning of random command lines with little or no explanation. One can hardly blame people that have never actually been root for thinking that sudo is a necessary part of nearly every command.
|
|
|
|
Scenario 2: What if Johnny, instead of "cashing out," uses a service, such as amagimetals, to buy equivalent gold/silver directly for his bitcoin. Is this "realization?" I recall a quote from some government agency about virtual goods to real goods not needing to be... something.
The IRS reporting requirements of precious metals varies with both the type of metal, quantity, and it's form according to the commodity futures trading commission (CFTC). Oddly enough, if your precious metals purchases is something traded on an ETF, you probably have an IRS reporting requirement. http://www.coinworld.com/Articles/ViewArticle/what-coins-are-reportableThere is no ETF for New Liberty Dollars, so all my customers are safe here.  Some but not all of Amagi's are also not IRS reportable depending on quantity. Another gotcha: If you have had US$10K of "value" in a foreign account which you control (even if it is only Bitcoin). There is a very serious reporting requirement, for which failure to report could cost you the whole account, or even more depending on how long you fail to report. http://bitcoinmagazine.com/real-compliance-getting-your-way-by-giving-in/"Control" of the account is measured by whether you can get the value out of the account while on foreign soil without going through a US financial entity. This is a weird and not very well known requirement. It is likely to be the single strongest weapon the IRS has to take bitcoins from US taxpayers who remain unaware of it. ---------- The foregoing is not to be construed as legal or tax advice. Do your own research, and hire your own advisers upon which you may rely. 1. In order to determine whether or not the FBAR is required, all of the following must apply:
A. The filer is a U.S. person; (or person equivalent, partnership, corp, etc)
B. The U.S. person has a financial account(s);
C. The financial account is in a foreign country;
D. The U.S. person has a financial interest in the account or signature or other authority over the foreign financial account; and, (you have the password)
E. The aggregate amount(s) in the account(s) valued in dollars exceed $10,000 at any time during the calendar year.
Seems like a stretch. |
|
|
|
This one in particular is hilarious. I'll summarize it for you: "Americans fucking HATE demurrage currency" |
|
|
|
There are avalon tech support threads over in the custom hardware section. You might even be able to find the answer by reading one of them if you don't want to wait for a mod to move this thread. |
|
|
|
|
It is a hypothetical. Several pieces don't exist yet, and he sorta handwaves some important bits.
So... No, there is no documentation available.
But, implementing a proof-of-concept version is on my todo list. Unfortunately, for the last six months at least, I've been losing the battle with said list, and I doubt I'll get a free weekend to do it in the near future.
|
|
|
|
|
I'm not sure that you'll actually gain much.
There is nothing internal to bitcoind that cares enough about confirmation count to give you an easy place to hook for that.
I strongly suggest that you split your problem into two parts. The first is a lightweight program that accepts the input from -walletnotify and -blocknotify and dumps it into an asynchronous processing queue. The second is either a cron job or a long running process that inspects that queue and can do slower things like making RPC calls back to bitcoind for more information.
As an aside, I've never seen a transaction that gave more than 2 hits it -walletnotify. Can you tell me more about the send that you saw 3 notices for?
|
|
|
|
In that case, why do you bother extracting the pubkey? The satoshi client just compares the script to a stored copy of the script that matches a key.
So it's building up: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG and just matching on that? Yes, exactly. Understanding this is the key to making sense of compressed keys and WIFs too. |
|
|
|
|
Hmm... I'm going to say SCAM until proven otherwise.
Also, a very low post account posting a thread advertising a service by "asking about" it. I'm also going to say spam. Again, until proven otherwise.
|
|
|
|
I have a full script engine, but I'm writing an SPV node now that isn't doing full script evaluation. It just wants to extract the addresses to test against the local wallet. I guess it doesn't really matter too much if I get false positives, since they'll be filtered out by the bloom filter / local db anyway. In that case, why do you bother extracting the pubkey? The satoshi client just compares the script to a stored copy of the script that matches a key. |
|
|
|
Can the NFC be disabled (by shielding or something like that?). Or can the ID be changed? Even tho is got a private and a public part, one could still easily track your movement if he can identify the Ring based on a specific ID that is locked to the NFC chip. I don't want another tracking device, people already enough of them even of they call it "Smart phone".
Good point. probably since the NFC technology only works on a very short distance (if I am not mistaken not more than a few inches or 8-10 cm), it cannot really be defined as a "tracking" system. You usually don't establish any radio communication unless you want to. Am I wrong? I am not an RFID specialist, yet I think that the distance depends on the amount of energy induced into the chip. For it to be truely private and non-tracable there should be a way to shield it (even something as simple as moving a small peace of cryptalloy integrated in the ring over the NFC chip my sliding some thing on the rings surface around). or it has to randomly change the chip ID or be reprogrammable to a random ID. != RFID |
|
|
|
|
Sheesh. 0.9 isn't even out yet, much less 0.10. Why the impatience for 1.0?
|
|
|
|
|
Single-block forks happen fairly often. I haven't kept up on the numbers, but the last time I looked at the fork data it looked like an average of one single-block fork per 300 blocks, roughly every other day. This corresponds to a double-block fork every 3002 blocks, or roughly every other year.
Six confirmations is good insurance against honest (latency-based) chain forks.
|
|
|
|
Well, there is some discussion: at http://www.coindesk.com/bitcoin-activists-suggest-hard-fork-to-bitcoin-to-keep-it-anonymous-and-regulation-free/, there are comments from Jeff Garzik himself. He said that: a) It’s another altcoin ... The marketing of most altcoins is inevitably Bitcoin-critical, as they want to distinguish themselves from the main competitor.So, they criticize bitcoin just to promote their altcoin? Sorry Mr. Garzik, but it is just not true. They'are not planning any altcoins development, they just concerned with bitcoin going Pay-Pal way. Are you? Sorry, Mr. Troll, but it is indeed true. Changing the network rules is to make something that is not-bitcoin. Another name for not-bitcoin, in general, is altcoin. Jeff isn't always right, but if you ever find yourself about to take the opposite side of a debate from him, you should really sit down and think for a while to make sure you didn't miss anything. b) Wouldn’t it be wonderful if major corporations or governments published completely open, transparent, auditable, cryptographically proven accounting? Bitcoin technology enables that.So, you'll let Big Brother spy on us, but we can spy on him as well. Do you really think it's good tradeoff?  I had a poll recently on general subforum (" https://bitcointalk.org/index.php?topic=256428.msg2738253#msg2738253"). "How much coin anonimity you want". 72% voted for bitcoin become absolutely anonymous. Sorry guys, but you're not going to get it. Bitcoin dev team prefers bitcoin to become "tax-friendly" money. I dare you to find one quote from a core dev that backs up your claim that they want to change bitcoin to become "tax-friendly". Note that I'm familiar with a variety of quotes that mean nothing of the sort, but are usually twisted inside the minds of the lunatic fringe. |
|
|
|
|
This thread delivers!
Of course, every time this topic comes up, we get a repeat of the same old thread.
For every actual female bitcoin/forum user here, there are like 5 scammers pretending to be female because it makes their scams easier. This makes it statistically valid to troll anyone that openly claims to be female. On top of that, there are actual 13 year old boys here, and they are pretty much indistinguishable from the trolls. And then you have the adults that have no desire to play parent to random children (of all ages) on the internet, or the ones that just don't feel like ordering the tide back into the ocean.
Now, into that mix, toss a couple of people that feel the need to alert everyone to their (real or imagined) outrage over the sexism on the forums while blindly ignoring the rampant sexism directed against people that aren't in the group they care about, not to mention the gross incivility of pretty much everyone here.
And now you have this thread. It'll die out soon, like it always does, but another near-identical thread will show up in a month or two.
This is a public forum. On the internet. No one can survive here if they take any of it too seriously.
|
|
|
|
|
Ok, so it iterates starting with CBlockIndex* pindex and pushes the result of pindex->GetBlockHeader() into a vector of CBlock.
CBlock includes a vector of CTransaction, vtx.
CBlock::IMPLEMENT_SERIALIZE does the block proper, and then the transaction vector.
Because this is done in a way that does not ever add any transactions, the transaction list here is always serialized as 0x00, which is the proper coding for a count of zero followed by zero records.
To be perfectly honest, I have no idea where this message is processed when received. ProcessMessage has a giant if/elseif/else structure that looks for the ASCII string of each message type. None of the ifs seem to care about the string "headers", and I can't find it anywhere else either.
|
|
|
|
I'm in the same boat. Rise a ticket with them at their support site.
Tickets are ignored. PM Bitsyncom here? Meh, their support is really spotty...
PMs are ignored. Also, phone calls and emails are ignored. My lawyer is drafting a letter that will be sent by certified mail to BitSyncom LLC's registered agent in Nevada. There doesn't seem to be any other way to reach them. By the way, forum staff, there are enough of these reports to support a scammer tag. |
|
|
|
|
Look in main.cpp, function ProcessMessage. Search for "getheaders" because ProcessMessage is a long function.
|
|
|
|
Ok, when a user sends money, bitcoind sees 2 addresses and if i have understood correctly we can't tell whch is change and which the original input right?
so sending to any of those will be fine as long as the user is not using a web wallet, is that right?
No, this is never right. There is no such thing as a "from address". Banish the idea from your mind. if he is using a web wallet, the only way is to let him set his own receive address, right?
|
|
|
|
|
Show Posts
