Bitcoin Forum
May 03, 2024, 10:00:24 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 [80] 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 ... 158 »
1581  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: February 22, 2014, 04:39:35 PM
What a shame.. Was planning on sending a wire monday morning if it didn't rise by then

The thing about this is you needed to send it last week - like last monday then hope it arrives in less than a week - which it won't.



Well I have made one deposit to gox (in december) and I think that took less than a week. Someone who wired 50k in this thread says it takes around 48 hours

Why did you wire to gox when you could buy cheaper at stamp?
1582  Economy / Speculation / Re: SecondMarket Bitcoin Investment Trust Observer on: February 22, 2014, 06:58:20 AM
About 1000XBT bought in the past 2 days
1583  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: February 20, 2014, 05:45:52 PM
I have 2FA and the bitcoin withdrawal page is normal. However I have 0 USD and BTC there right now
1584  Economy / Speculation / Re: SecondMarket Bitcoin Investment Trust Observer on: February 20, 2014, 02:27:17 PM
update?

thanks!

updated. not much action
1585  Bitcoin / Development & Technical Discussion / Re: How does a block complete when there are lots of transactions? on: February 20, 2014, 07:22:33 AM
Now I hope I understand it well enough to explain it to about 120 engineers tomorrow at noon.


No offence but I am not very sure. It took me 2 months before I fully understand mining.

For example, do you know the answer for the following question: Why couldn't a mining pool participant steal the reward when he finds a valid block?
1586  Bitcoin / Development & Technical Discussion / Re: Data Chain Idea - by Mikhail on: February 19, 2014, 04:42:08 AM
But why do we need consensus/timestamping for data storage? We may need consensus/timestamping for hash of data, but don't really need it for the data per se.

I discussed with Mikhail the possibility of a Datacoin (not the altcoin that's been made.. a real one)..

Mikhail passed away a couple of days ago..

after some quick discussion he sent me this .. i'm sure he did not think on it properly so it may be flawed, and it was only a quick thought..
(was 7 months ago now)

maybe the information is useful to someone for some other "ideas":

Quote
Suppose we create multiple parallel blockchains. Lowest is very fast (a block each 10 sec, or even 1 sec), the next one is e.g. block per minute, then 10 min etc. The topmost can be a block per day, or even a block per week.

Together they form a Merkle tree. Also the chains form a skip-list, see http://en.wikipedia.org/wiki/Skiplist

All chains support merged mining with each other. Difficulties are locked together, as are the block rewards (proportional to the desired block frequency).

Merged mining: miners mine the topmost chain only. But if they fail to meet the difficulty target, they still can try submitting the block to lower levels.

The tricky part: how to properly construct the Merkle tree, so the block is insertable into any level without modification? I think it's possible, but not sure how.

Now we have useful properties: the lowest level can be used for sending messages, since it's very fast. Even file sharing may be possible.

Miners are obliged to store all levels. So they need large HDD and good network connection, not only fast GPUs. Otherwise they'll get stale blocks in the lowest level (but still can mine on higher levels with less profit). Hopefully, this may result in a good distributed data storage.

Casual users download only the topmost level (1 block per day - not much data). Then they can navigate deeper as necessary, to access only specific low-level blocks (by querying them from the network).

Though top-level blocks should somehow contain a digest of transactions (a list of spent outputs?) over the whole block range of lower levels. Essentially every higher level is an array of checkpoints for previous level.

Optional things:
1) low-level chain can die and reborn every 2.5 days. So not to waste lot of space. Like in BitMessage.
1a) this can be applied to every level except the topmost. Each level has a finite lifetime. Topmost level is eternal.
1b) users can send data (e.g. messages) to higher levels to keep it for longer time - but the fee is also higher.

2) transactions can be roaming between levels - but also we can use the concept of coloured coins instead. Coins propagate to upper levels by trading with them. Coins at higher levels are used for long-term savings. Coins at lower levels are used for paying fees when sending data, registering names etc.
(not sure if it's possible to reach a good balance between supply/demand though)


-- Mikhail
1587  Economy / Speculation / Re: Problems besides mtgox: on: February 18, 2014, 04:56:30 AM
1. Final Capitulation

We won't know whether a capitulation is final until next bull market (and we won't be sure a bull market has started until the last ATH is broken). So this has no predictive power

Quote
2. PBOC policies still stand in China and no new chinese capital has come suddenly flying in as of Jan 31st/Feb8.

PBOC does not ban fiat transfer with banks. Huobi, OKCoin, and BTCChina are now processing deposit and withdrawal through the biggest banks in the country. Obviously these banks know what they are doing.

Quote
3. Russian ban.

The only single country that I would really worry about is the US, but a Russian-style ban is unlikely

Quote
4. Cyprus issues a bank advisory (like China), which leads to at least the perception that btc-e is at serious risk.

It seems they store money in Czech, not Cyprus: http://www.coindesk.com/btc-e-recent-issues-caused-surge-users/

Quote
5. India

Comparing with Russia, this is neglectable

Quote
6. Apple removed blockchain app from app store, and the implications that this has about corporate control of what the public eye sees.

Fact: iOS is dying, Android is growing: http://www.macrumors.com/2014/01/27/iphone-share-strong-android-lead/

Removing blockchain app is just one more nail in their coffin

Quote
7. Major exchanges were able to flashcrash to $100 (indicates weakness)

And went back to where it was in 2 minutes. The moron who sold to $100 is the only one who got hurt.

Quote
8. Flaws on Bitfinex have been exploited, traders on Bitfinex have lost money. The staff at Bitfinex showed themselves as bad at responding to issues and unfit to be running an exchange.
9. The exchanges have had large amounts of funds (millions) stolen from them which could lead to potential insolvency or unethical actions in the future (or at least more mistrust in exchanges).
10. A large loss in confidence and trustworthiness in the existing exchange system, for a variety of reasons.

This is actually getting better. The exchange industry is now oligopoly instead of monopoly

Quote
11. The malleability bug and its lasting impact on public trust and confidence in the Bitcoin software even if it gets fixed.

Bugs in traditional transaction platforms are common. By the way, what didn't kill you makes you stronger

Quote
12. Loss of trust in bitcoin foundation board members.

Then just let them die.

Quote
13. Large amounts of hacker coins, which will eventually be dumped for fiat.

We had plenty of hacker coins since 2010 and the price is >1000x higher now

Quote
14. FBI Silk Road coins (27K or 144K) entering the market (somehow).

So FBI will hold an auction with all Silicon Valley VC and Wall Street whales bid the "cleanest" coins ever. I couldn't imagine a more bullish headline than this.

Quote
15. Men in florida were arrested and received felony money laundering charges for using localbitcoins. Even if it was really due to credit card fraud, it makes the public scared of using LocalBitcoins and casts a bad light on government perception of Bitcoin.

When you touch fiat, you always need to follow the fiat rules. People will learn the lesson

Quote
16. Silk Road 2 closed its escrow service.

The late 2013 bubble was ignited by Silk Road closure, didn't it?

Quote
17. Gox started processing cash withdrawals, fiat is actually exiting the system, and many jaded investors are most likely actually leaving the economy altogether.

Is this what you mean?

Not processing cash withdrawals: bearish
Processing cash withdrawals: bearish

18. Btce halted fiat withdrawal.

The market does not think this is a problem as there is no panic and the price on BTC-E is still consistently lower than Bitstamp and Chinese markets.

19. The closure of btc withdrawals by major bitcoin exchanges. (resolved)


Quote
20. Major indicators on charts that turned down before the gox crash even began.

Just a normal cycle IMHO

21. Gox
[/quote]
1588  Bitcoin / Development & Technical Discussion / Re: Transaction Not Confirmed in over 7 hours on: February 18, 2014, 03:56:22 AM
It has a dust output: 0.00000001. Ask the sender why he did so.
1589  Economy / Speculation / Re: Mt. Gox - To resume withdrawals Feb 20th - New ATH approaching on: February 17, 2014, 05:57:48 PM
This is perfect:

1. Put fake bid order to push up the price
2. Sell at 900s
3. Crash the market by announcing a long-known bug
4. Use the bug to DDOS the network and further crash the price
5. Pull all fake bid order and let the price free fall
6. Buy at 200s
7. Reopen withdrawal with restriction
8. Goto step 1
1590  Bitcoin / Development & Technical Discussion / Re: Transaction script with block height as condition on: February 17, 2014, 04:09:19 PM
I've been reading some threads on allowing checks of block height in scripts, and I still don't understand what's so dramatically bad about it. It's clear enough that a previously valid transaction can become invalid after a reorganisation, but that is solved in most cases if you wait for enough confirmations. The exception appears to be that after a lengthy segmentation you would get much more collateral damage than usual.

There was some suggestion that it might also allow people to deliberately create reorganisations, but I don't understand how that would work. Also, some developers seem to have changed their minds a bit. So, what's current thinking about a block height opcode and what exactly are the scenarios people are worried about?

With the random malleability attack, the refund transaction in micro-payment channel is no longer reliable, as the txid is not fixed until confirmed. Pushing block height and block timestamp in the script will be very useful.

By the way, malleability will also make any previously valid transaction becoming invalid in case of reorg.
1591  Economy / Speculation / Re: Bitcoin long-term exponential trend (updated regularly) on: February 17, 2014, 05:34:56 AM
No visual aid pretty chart?  Huh

Maybe I would add it later if I could make it automatic
1592  Economy / Speculation / Re: Bitcoin long-term exponential trend (updated regularly) on: February 17, 2014, 05:24:19 AM
it seems fundamentally odd to consider Mt. Gox in any 'long term' measure of btc

While it has recently become almost irrelevant, only Mt Gox has been around long enough to be considered "long term".

What else would you use? Bitstamp? It doesn't even go back as far as the June 2011 bubble.

I'd like to see both Gox and Stamp plotted on the same chart, the one with a tenth of a penny as a base line (as used for Gox) rather than the one starting at a dollar (as used for Stamp). You'd get a truer visual representation that way and the individual could decide when to start disregarding Gox and focusing on Stamp.

Anyway, I switched to Bitstamp on 19 Jun 2013, when MtGox started having fiat withdrawal problem
1593  Economy / Speculation / Re: Bitcoin long-term exponential trend (updated regularly) on: February 17, 2014, 04:55:24 AM

Also, it seems fundamentally odd to consider Mt. Gox in any 'long term' measure of btc considering their present situation.



Please read
1594  Economy / Speculation / Re: Bitcoin long-term exponential trend (updated regularly) on: February 17, 2014, 04:45:57 AM
Some interesting days:

Date: 9 Jun 2011, where the VWAP ATH at 29.58
VWAP = 29.58
x = 327
a = 0.015305
b = -3.48544
Rsq = 0.903626
The day's expected price = 4.569171
Predicted date for the day's price = 9 Oct 2011
Days ahead = 122
Daily price rank = 1

Date: 18 Nov 2011, where the VWAP bottomed at 2.14
VWAP = 2.14
x = 489
a = 0.012087
b = -2.97171
Rsq = 0.813339
The day's expected price = 18.88924
Predicted date for the day's price = 21 May 2011
Days behind = -180
Daily price rank = 198
1595  Economy / Speculation / BETI: Bitcoin Exponential Trend Index and technical analysis on: February 17, 2014, 04:40:19 AM
2015-11-04:

UPDATE

Name of this thread is changed to "BETI: Bitcoin Exponential Trend Index and technical analysis". It will not only include a regular update of the BETI, but also general technical analysis and observations.

BETI = ln (daily VWAP / exponential tread expected price)

For example, on 2015-11-02, the VWAP was 347.89 and the expected price was 1848.06. BETI = ln (347.89/1848.06) = -1.670

Data source and calculation of the expected price are described below

Please consider to donate if you like this service

-------------------
2014-02-17:

Starting from today, I will offer a regularly update of the bitcoin long-term exponential trend.

Method:

Data source: bitcoincharts.com daily volume weighted average price (VWAP)

Reference exchange:
  17 Jul 2010 to 18 Jun 2013: MtGox
  19 Jun 2013 to now: Bitstamp

Dates omitted:
  20 Jun 2011 to 25 Jun 2011 (MtGox closed)
  6 Jan 2015 to 8 Jan 2015 (Bitstamp closed)

Regression model:
  y = ax + b,
  where y = natural logarithm of VWAP; x = days since MtGox inception, 17 Jul 2010 = 0; a = slope; b = intercept

Glossary:
  Rsq: R-square value of the regression model
  Today's expected price: The expected price of today based on the regression model
  Predicted date for today's price: The expected date for today's price based on the regression model
  Days ahead (behind): The difference between today and the predicted date for today's price. A positive value indicates we are currently above the regression and vice versa
  Daily price rank: The rank of today's VWAP among all historical VWAP. 1 means the all-time-high VWAP

------------------------

Date: 16 Feb 2014
VWAP = 625.45
x = 1310
a = 0.006037
b = -1.82098
Rsq = 0.871816
Today's expected price = 440.0484
Predicted date for today's price = 15 Apr 2014
Days ahead = 58
Daily price rank = 84
Predicted date for ATH ($1126) = 26 Jul 2014
------------------------

tl;dr:

ASSUMING the bitcoin price is growing with an exponential trend in long-term:

We expect bitcoin price to grow by about (1 - e^a) = (1 - e^0.006037) = 0.6055% per day
87.1816% (Rsq) of the variation in bitcoin price could be explained solely by time (which is very high)
The long-term "fair" price of today is only 440.0484. We are outpacing the long-term trend.
We expect to see today's price (625.45) on 15 Apr 2014, which is 58 days later
We expect to see ATH (1126) on 26 Jul 2014
Today's price is the 84th highest in the history of bitcoin

-----------------------------



y-axis is ln(price)
Blue line is the daily VWAP
Red line is the expected price of the day. For each day, a regression is fitted with all data of and before that day, so it is not a straight line.
Green line is the current regression line
1596  Bitcoin / Development & Technical Discussion / Re: Idea: embedding client update info in the blockchain on: February 14, 2014, 09:24:19 AM
Has probably been discussed before, but here goes, since none of the existing clients (AFAICT) support that:

Embedding client wallet update information into the blockchain

Currently updating the client wallets means manually checking news, downloading a client wallet from some website, trusting that the website hasn't been hacked, trusting that the client is okay, hasn't been tempered with, etc. Even when compiling from source, there is a degree of trust involved (since you can't manually check everything).

So the idea would be that client wallets would check for transactions from a special address in the blockchain (hardcoded into the client for each version), and those transactions would encode in their outputs (either via vanitygen'ed destination addresses and/or special amounts) information about new versions
  • hash of the updated/upgrade binary (so you don't just have to trust a website or a download)
  • basic update info (minor upgrade, compulsory major upgrade, hard fork coming, etc.)

This would allow a safe update notification and a safe signed upgrade mechanisms that doesn't rely on how the update binary is delivered. And only the devs (or rather whoever holds the private key to the special address) would be able to both announce and certify the update.

This wouldn't involve any protocol updates, and other/custom clients would be unaffected by what they would see as regular transaction.

We already have an emergency key to deliver such message
1597  Economy / Speculation / Re: SecondMarket Bitcoin Investment Trust Observer on: February 14, 2014, 02:53:44 AM
940 bought yesterday
1598  Bitcoin / Development & Technical Discussion / Re: The malleability attack is creating a lot of trouble, we need a quick fix on: February 12, 2014, 04:55:28 PM
The malleability attack becomes a DOS attack. We need a quick fix. Before there is a better solution, the bitcoind should not report unconfirmed transactions. Account balance should be solely based on confirmed transactions. Before malleability is fixed (if ever), unconfirmed outputs should not be spent.

How does it become a DoS attack? Care to explain? The clients track unspent outputs before forwarding tx (or mining it). How does malleability cause a problem? I don't see any issue (non-gox) unless I missed something.

Why the quick fix? It does not seem urgent. Lets do it properly and thoughtfully.


Most current wallets will attempt to spend unconfirmed change outputs.  If the tx id is mutated and the mutated versions ends up in a block then the spent change output becomes permanently invalid.   For a site like an exchange with a large amount of withdraws (spends) it is very likely they will spend using unconfirmed change outputs and thus end up with broken outgoing payments.

More info:
https://bitcointalk.org/index.php?topic=460944.0

The "quick fix" is to have clients deal with the possibility of tx being mutated before confirmation in a more consistent and expected way.
The improvement to immutable tx ids is a long complex process which will require extensive testing.  It won't be quick.


I didn't realize that spending unspent newly generated outputs used the txid.  That's actually a potentially serious design flaw, as the core dev knew these were mutable.

To fix this at the exchange level, you can just only send outputs to clients after a new block is received once and only once... just make huge tx with all of the inputs you need to use to pay your clients and all of the outputs to all of your clients withdrawing.  Then use my proposed txid system.

Exchange can still send bitcoin at any time, just don't try to spend unconfirmed change. Anyway, it is always a good idea to pay multiple clients in one transaction
1599  Bitcoin / Development & Technical Discussion / Re: A proposal to permemenantly fixing the malleability problem on: February 12, 2014, 04:23:40 PM
Another obvious solution is to adopt non-malleable signature, such as Lamport Signature, and close all malleability in scriptSig
1600  Bitcoin / Development & Technical Discussion / Re: A proposal to permemenantly fixing the malleability problem on: February 12, 2014, 10:58:01 AM
Shuffling inputs and outputs will make the signature invalid so this is not malleable
Pages: « 1 ... 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 [80] 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 ... 158 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!