any reason why ltc responded to the opening on huobi by tanking? now i wonder what an opening on gox would've been like - worse?
see the news |
|
|
|
This is a little off topic, but what hasn't been for the last week or so  So... I was gonna donate a little and got to this page: English is not their first language, but they made their statement pretty clear. We have quite a ways to go before global acceptance is assured. Sorry, I've been missing meetings...where is this from? PoolMinor gave you the basics, but here is the home page: http://www.autistici.org/en/index.htmlI'm not giving a shit. It's their loss, not ours. Just look at the story of Overstoke and Tigerdirect. People will soon realize that they can't afford NOT to accept bitcoin As bitcoiners, what we should do is to put bitcoin-accepting merchants at a higher priority. |
|
|
|
That's completely nonsense. BIT is 100% backed by real BTC. If a customer wants to liquidate their BIT share, BIT will just sell the bitcoin at market price.
That has nothing to do with the issue. What that "100% backed in BTC" promise means is that, for each share held by investors, BIT will keep 0.1 BTC in its posession. It does not mean that BIT must sell those BTC when the investor liquidates; if BIT has cash reserves, it can just pay the investor from those and keep the corresponding BTCs as reserve instead. That would not violate the "100% backed by BTC" promise to other investors, on the contrary. (The whole point of the trust is to insulate the investors from the BTC trading that BIT must do to honor BIT's part of the contract.) I don't think so, because they do not have other source of USD. All USD from investors (with fee deducted) were spent on buying real BTC. Therefore, they have to sell the BTC if investors request for USD simply because they shouldn't have extra USD to pay Even if they have surplus in USD, paying out USD without selling BTC is equivalent to BIT itself investing in BTC. If they really want to do so, they can buy BTC from the open market at any time. |
|
|
|
For both a transaction entering, and, leaving a multisig address, along with the address itself, what information do people who are **NOT** part of the address themselves see (I.E. Someone random on the network, such as a miner, or simply a full-node)?
Do they know the public key/hashed public key (I.E. address) of the participating clients?
Do they know how many clients there are (N in M-of-N)?
Do they know how many clients are needed to sign a key (M in M-of-N)?
And, another question:-
If I know two pub keys (I.E. pubA & pubB), can I determine if an address/transaction on the network includes those two pub keys in a 2-of-3? And how resource wasteful would that be (Checking to see if an address/transaction included my two pub keys)? So, imagine I was part of a service, I gave them my two pubkeys, and, they randomly generated their pubkey (from one of their private keys), then send $amount BTC to the address they generated without telling me the third key, would I be able to determine what address they sent to and be able to cash out my money? Or am I clueless without that third key (And thus even though I should be able to cash out the money (Due to me owning enough privatekeys), I can't because I don't know the TXID)?
Sorry, slightly confused about multisig.
Note:- Please give each answer a three-part answer, for both:-
1. Address on its own (I.E. address that has never had a transaction in/out)
2. Address with a singular TXIN
3. Address with a singular TXIN and singular TXOUT
EDIT:- Also, small little question at the end, is there anything random about a multisig address generation? I.E. if I had the three pubkeys and ran createmultisig ten times, would I always get the same address, assuming I used the same pubkeys & M-of-N?
There are 2 types of multisig: "traditional" one, with all public keys shown in the scriptPubKey; and P2SH With the traditional one, all public keys, and the redemption rules, are known to everyone at any time With P2SH, only the payee would know the public keys and the redemption rules, until it is spent |
|
|
|
I suppose that BIT may be tempted try to drive the BTC price down before enabling liquidity, because then they would have to pay less USD to the investors who liquidate. In that "plan", BIT would later buy back those coins on-market to drive the price back up. I don't know whether this would work; it may push more investors to liquidate and may scare new investors (not that they have many now it seems). Note that this manipulation is possible with bitcoin due to the limited liquidity of the exchanges.
Does this make sense?
EDIT: typo
I don't understand why BIT wish to drive price down and then liquidate their bitcoins. This undermines their customers and does no good for themselves. Or I'm not smart enough to understand what is it ? Maybe I am not understanding it right, but this month some of their investors who bought shares at 12$ will be allowed to liquidate, meaning that BIT will have to pay them ~60$ per share (and tear those shares up). The BIT share price is pegged to the BTC price, so if the latter goes down to 300$ before those investors have time to liquidate, then BIT would have to pay them ~30$/share, instead of ~60$/share. If the BTC price later returns to 600$, BIT shares will go back to 60$, the other investors (who can't liquidate yet) will be in the same state they were before --- but BIT would have saved a lot of money. Thanks for the explanation. I see the logic. That's completely nonsense. BIT is 100% backed by real BTC. If a customer wants to liquidate their BIT share, BIT will just sell the bitcoin at market price. i thought BIT would open up a market for BIT shares, were poeple could buy and sell BIT, which should track bitcoin prices closely because its backed by bitcoin. I'm not sure but if it works like an ETF, customers may also request delivery of real BTC |
|
|
|
I suppose that BIT may be tempted try to drive the BTC price down before enabling liquidity, because then they would have to pay less USD to the investors who liquidate. In that "plan", BIT would later buy back those coins on-market to drive the price back up. I don't know whether this would work; it may push more investors to liquidate and may scare new investors (not that they have many now it seems). Note that this manipulation is possible with bitcoin due to the limited liquidity of the exchanges.
Does this make sense?
EDIT: typo
I don't understand why BIT wish to drive price down and then liquidate their bitcoins. This undermines their customers and does no good for themselves. Or I'm not smart enough to understand what is it ? Maybe I am not understanding it right, but this month some of their investors who bought shares at 12$ will be allowed to liquidate, meaning that BIT will have to pay them ~60$ per share (and tear those shares up). The BIT share price is pegged to the BTC price, so if the latter goes down to 300$ before those investors have time to liquidate, then BIT would have to pay them ~30$/share, instead of ~60$/share. If the BTC price later returns to 600$, BIT shares will go back to 60$, the other investors (who can't liquidate yet) will be in the same state they were before --- but BIT would have saved a lot of money. Thanks for the explanation. I see the logic. That's completely nonsense. BIT is 100% backed by real BTC. If a customer wants to liquidate their BIT share, BIT will just sell the bitcoin at market price. |
|
|
|
Goodbye, Bitstamp and BTC-E. AFAIK Bitstamp and BTC-E neither operate nor have any bank account in US |
|
|
|
Also I believe Satoshi Nakomoto will be eventually outed and will eventually win a Nobel Peace Prize in economics.
Whether the bitcoin in current form will succeed or fail, I have no doubt Satoshi will win a Nobel Prize (if the rules allow awarding it to anonymous person(s)) BTW, we have Nobel Peace Prize. We have Nobel Prize in Economics. There is no Nobel Peace Prize in economics.  |
|
|
|
It's just like in Bitcoin's early days, when people could tip 10BTC for an interesting post here |
|
|
|
Ok I will explain again, I am a newbie and half the talk your saying is going past my head about a million k's. Im not a retard, but you need to explain things simply to I get it.
All I got out of that is that one transaction has already been spent, and you agree that why does it not show.
Your confused about the isvalid as much as me!
I have already said -scan did not work and I done it twice. It scanned, but never showed the missing payments. How on earth can you expect the world to take Bitcoin seriously if these problems cannot be understood even by well seasoned user?? The sad part is I am out of pocket here! I seriously cant believe you said it doesn't matter that much!!
Well, for a starter, I am saying that there is no fucking way that your bitcoin client ( working in a non-testnet mode) would return: ... after validateaddress 1JJA3L6UGUtrK3MzscbKdWFt8mrv6eHfkk Either you found a bug in a piece of code that is very well tested (because completely wallet/chainstate independent) - or you cannot even execute a simple command properly. Not to offend you, but knowing life, my odds are on the later. In other words, paraphrasing you: how on earth can you expect anyone to take you seriously if the data you are providing are extremely hard to believe in? Interesting point  EDIT: Well, I know what happened: He ran  validateaddress <1JJA3L6UGUtrK3MzscbKdWFt8mrv6eHfkk> |
|
|
|
Yes, a power shortage, natural disaster, or government disaster could cause a sudden and permanent 92% reduction in hashrate and that would be bad. Wait, what?
By "government disaster", I meant "government caused disaster". For example, all of the EU bans mining. >50% permanent reduction in mining Mining could be completely anonymous with TOR. The ONLY practical way for government to ban mining is to shutdown the internet. Who care bitcoin when the internet is already shut down? True, but when you can raid the house of anyone who uses more than enough electricity for a few light bulbs under the guise of the "war on drugs", you can shut down miners over a few Mhash/s pretty quickly Yes, welcome to north Korea  |
|
|
|
Yes, a power shortage, natural disaster, or government disaster could cause a sudden and permanent 92% reduction in hashrate and that would be bad. Wait, what?
By "government disaster", I meant "government caused disaster". For example, all of the EU bans mining. >50% permanent reduction in mining Mining could be completely anonymous with TOR. The ONLY practical way for government to ban mining is to shutdown the internet. Who care bitcoin when the internet is already shut down? |
|
|
|
The line is technically only straight on Log plots, its a exponential formula that appears straight when the y-axis is log. I personally don't ignore any relationship that has an R squared of >0.9 . Can it be wrong? Sure. Does the trend show a close relationship of the two variables, you bet.
edit: accidentally wrote "logarithmic", now fixed
Using all data since the inception of MtGox gives and Rsq of 0.879, still very impressing: https://bitcointalk.org/index.php?topic=470453.msg5739610#msg5739610I like the wallets squared model better. It actually explains something. You do know that an exp(exp(t)) model actually fits better, with higher R^2, right? exp(exp(t)) is arbitrary because there is no absolute zero for the t. the wallet (do you mean unique addresses?) number is confounding with t, so we need to do a multiple regression |
|
|
|
The line is technically only straight on Log plots, its a exponential formula that appears straight when the y-axis is log. I personally don't ignore any relationship that has an R squared of >0.9 . Can it be wrong? Sure. Does the trend show a close relationship of the two variables, you bet.
edit: accidentally wrote "logarithmic", now fixed
Using all data since the inception of MtGox gives and Rsq of 0.879, still very impressing: https://bitcointalk.org/index.php?topic=470453.msg5739610#msg5739610 |
|
|
|
I am curious if there is any discussion that has ever occurred about a time limit parameter during which an unconfirmed tx can stay valid, and after which it is no longer a valid tx?
sort of like an SLA, so that people can have a reasonable expectation of performance, if they need a tx to happen before a certain time, and to be able to then gather statistics on that performance.
No, but we have the opposite, i.e. TX only valid after block X |
|
|
|
It is not real for Bitcoin. It is real (or about to be if they go ahead with their ill-advised hardfork) for AUR however. Bitcoin, like AUR, allows timestamps before the previous block (down to the median of the last 11 blocks) but because it adjusts difficulty once every 2016 blocks, you cannot use that feature to jump back over more than one difficulty adjustment. AUR has a maximum 20% upward/downward difficulty adjustment using KGW starting after a scheduled hardfork any day now, and adjusts EVERY BLOCK. So the attacker can mine 5 blocks with timestamps reaching as far into the future as necessary to get the 20% easier adjustment each, then mine a block with a timestamp as far back in time from there as he can get, making up all or most of the time increment his prior five blocks have added but incurring the 20% difficulty penalty only once. It doesn't take a genius to see that if you adjust difficulty downward five times and up once by the same amount, you get a ridiculously low difficulty fast. BTCX has warned them about this vulnerability and warned them that he will exploit it immediately if they do this hardfork. And let's face it, he makes deadly serious warnings, not idle threats. He keeps alt developers honest, at least in terms of calling them out on easy exploits. You cannot look at the things he's already done to other alts and exchanges that made stupid security blunders, and believe that he will not carry through with the exploit he's already warned them about. But they appear to be going ahead with the hardfork anyway. So grab some popcorn and pull up a seat. Well, I'm quite sure something is going to be done. But the main question is that the easiest fix would be preventing blocks in the past. However, everyone seems to be afraid of touching that 'median 11 block rule', most likely because no one really understand why it is there. So all are afraid of that by changing it, they might open some unknown vulnerability. I fully understand that reasoning, but is this a real fear? I don't see any vulnerability it would open and have not heard of any. Of course, that does not prove there are no vulnerabilities, something unknonw can allways pop up. But it would help pondering, if the original reason for that rule was known. So WHY allow median 11 block time warp? I see it only as a risk, not preventing any fraud. I think people have answered your question in different ways but you seem couldn't get it. Let me try to explain in a moral, non-technical standpoint. Why allow blocks whose timestamps are behind head block? If the timestamp of the head block is 1 hour beyond the ACTUAL time, why must I, as a honest miner, be forced to tell lie by generating a new block with timestamp 1 second after the head block? The lesson is: due to the decentralized nature of the network, the timestamp is never intended to be a PRECISE timing source. It could be off by at most 2 hours. It is good enough for a long time span but never rely on it for short term timing. Even we don't allow "blocks in the past", it won't change this fact. |
|
|
|
|
Show Posts
